Hi,Sorry if this question is a dog's-breakfast with incorrect terminology (allthe test stuff is back in another office and I'm too lazy to re-look it allup :-) but the fundemental question is a very basic one. We're using JAX-WSto generate client code from a Application Service provider's WSDL that isintended to provide stateful sessions between client and server. We haveturned on http message dumping to the console and can see that incomingreplies contain a SOAP header (with a Session Id) but the outgoing callsonly have a SOAP body. So, how do we (or the WSDL authors) tell Java to turnon SOAP headers so that we can reply with the SessionId we got back from theAuthenticate?1) I've turned on the(portormaybeservice)somethingBinding.SESSIONSOMETHINGPERSISTENT=true (butwithout a header we can't really tell the server what session id they gaveus last time?)2) I've seen the code examples about injecting seemingly arbitrary headertags, but I'm guessing if we can just make the header appear at all then theSession Id <tag> will automagically appear?3) I've seen at the GlassFish site that @webParams has a (mode=out,head=true) option, but it didn't like "out" and the head(er)=true didn'tseem to do anything (and this should be controlled by the WSDL right? Or theImport?)The SessionId and Stateful Sessions stuff is supposed to be transparent isit not?Anyway, just thought I'd run it up the flag-pole in case it's obvious toeveryone except me.Cheers Richard Maher

Richard Maher wrote:> Sorry if this question is a dog's-breakfast with incorrect terminology (all> the test stuff is back in another office and I'm too lazy to re-look it all> up :-) but the fundemental question is a very basic one. We're using JAX-WS> to generate client code from a Application Service provider's WSDL that is> intended to provide stateful sessions between client and server. We have> turned on http message dumping to the console and can see that incoming> replies contain a SOAP header (with a Session Id) but the outgoing calls> only have a SOAP body. So, how do we (or the WSDL authors) tell Java to turn> on SOAP headers so that we can reply with the SessionId we got back from the> Authenticate?> > 1) I've turned on the> (portormaybeservice)somethingBinding.SESSIONSOMETHINGPERSISTENT=true (but> without a header we can't really tell the server what session id they gave> us last time?)> 2) I've seen the code examples about injecting seemingly arbitrary header> tags, but I'm guessing if we can just make the header appear at all then the> Session Id <tag> will automagically appear?> 3) I've seen at the GlassFish site that @webParams has a (mode=out,> head=true) option, but it didn't like "out" and the head(er)=true didn't> seem to do anything (and this should be controlled by the WSDL right? Or the> Import?)> > The SessionId and Stateful Sessions stuff is supposed to be transparent is> it not?> > Anyway, just thought I'd run it up the flag-pole in case it's obvious to> everyone except me.Is the session supposed to be maintained at the HTTP level (via cookies)or at the SOAP level (with an element within the SOAP envelope) ?The first should be relative easy. See something like: http://weblogs.java.net/blog/ramapulavarthi/archive/2006/06/maintaining_ses.htmlThe second could be more difficult. And I would find it tempting touse a heavier web service toolkit like Axis to do it.Arne

Hi Arne,

Thanks for the reply.

> Is the session supposed to be maintained at the HTTP level (via cookies)
> or at the SOAP level (with an element within the SOAP envelope) ?
>
> The first should be relative easy. See something like:
>
>
http://weblogs.java.net/blog/ramapulavarthi/archive/2006/06/maintaining_ses.html
>
> The second could be more difficult. And I would find it tempting to
> use a heavier web service toolkit like Axis to do it.
>

In this particular case, as we are obviously bound by the rules an
conventions of the Application Provider, we had to poke a "SessionId tag
into the SOAP header. What's more, we had to append a sequence number to
categorize/demarcate each message interaction. That is, set it to N when we
send a message and then get N back, before incrementing it to N+1 for the
next exchange, and so on.We did this with: -

  WSBindingProvider bp = (WSBindingProvider)myProxyPort;
  bp.setOutboundHeaders(
    Headers.create(new QName("http://somehost.com","SessionId"), SessionId +
"|" + SessionSeq)

(I'm guessing this is similar to SQL Server and <sqloptions:sqlSession>?)

Setting this tag had the desired side effect of forcing the SOAP headers
out. I had already read the web-link you provided and we had previously
tried the
bp.getRequestContext().put(WSBindingProvider.SESSION_MAINTAIN_PROPERTY,true)
; Exactly what [WS]BindingProvider provides over and above BindingProvider
I'm not sure, but these seem to be the instruments of the mega-fudge for
poking all sorts of crap in there that were left out of the standard.

I think the main problem here is that, like all http, "By design
Web-services are stateless"! This seems to be a common theme running through
most of the web-sites discussing SOAP-Sessions that I could find. (If there
are people using the WSSE standards out there, I certainly couldn't find
them.) I did have a brief look at Axis2 and ServiceGroupId but it started to
look even more idiosyncratic and certainly harder. Which reminded me of one
of the pages I visited recently: -

"Why is Java Web Services so hard?" blog
http://soabook.com/blog/?p=5

Dave Podnar's 5 Stages of Dealing with Web Services
-------------------------------------------------------

Denial - It's Simple Object Access Protocol, right?

Over Involvement - OK, I'll read the SOAP, WSDL, WS-I BP, JAX-RPC, SAAJ,
JAX-P,. specs. next, I'll check the Wiki and finally follow an example
showing service and client sides.

Anger - I can't believe those #$%&*@s made it so difficult!

Guilt - Everyone is using Web Services, it must be me, I must be missing
something.

Acceptance - It is what it is, Web Services aren't simple or easy.
-----------------------------------------------------------------------

Then this particular Application Provider Authentication deploys:-

.. Application-specific authentication with Username/Password sent via the
XML/body

.. Authentication/sign-on errors returned via XML messages while other
exceptions are thrown as SOAP[Fault]Exceptions (which presumably are more
appropriate and the mut's-nut's when compared to simple SOAPExceptions?

.. Customer tailored WSDL files then generate nested Java Sub-classes for
every layer of XML tag.

At this stage I'm wondering what *exactly* SOAP gives us over and above a
simple XMLHttpRequest-type mechanism? But like David Podnar's "Guilt" I
figure it must be me, and it's time to learnt more about SOAP, until I hear
that a colleague's wife over here, at an ex-government quango utility, has
just cost USD$15K to go on a SOAP course! No wonder Gartner, and IT industry
in general, love SOAP; it's ahuge money-spinner! We get to stick-it to the
customer one more time - hoorah! And we wonder why everyone's outsourcing to
Mumbai and Bangalore :-(

Cheers Richard Maher

"Arne Vajh�j" <arne@vajhoej.dk> wrote in message
news:47c224bd$0$90266$14726298@news.sunsite.dk...
> Richard Maher wrote:
> > Sorry if this question is a dog's-breakfast with incorrect terminology
(all
> > the test stuff is back in another office and I'm too lazy to re-look it
all
> > up :-) but the fundemental question is a very basic one. We're using
JAX-WS
> > to generate client code from a Application Service provider's WSDL that
is
> > intended to provide stateful sessions between client and server. We have
> > turned on http message dumping to the console and can see that incoming
> > replies contain a SOAP header (with a Session Id) but the outgoing calls
> > only have a SOAP body. So, how do we (or the WSDL authors) tell Java to
turn
> > on SOAP headers so that we can reply with the SessionId we got back from
the
> > Authenticate?
> >
> > 1) I've turned on the
> > (portormaybeservice)somethingBinding.SESSIONSOMETHINGPERSISTENT=true
(but
> > without a header we can't really tell the server what session id they
gave
> > us last time?)
> > 2) I've seen the code examples about injecting seemingly arbitrary
header
> > tags, but I'm guessing if we can just make the header appear at all then
the
> > Session Id <tag> will automagically appear?
> > 3) I've seen at the GlassFish site that @webParams has a (mode=out,
> > head=true) option, but it didn't like "out" and the head(er)=true didn't
> > seem to do anything (and this should be controlled by the WSDL right? Or
the
> > Import?)
> >
> > The SessionId and Stateful Sessions stuff is supposed to be transparent
is
> > it not?
> >
> > Anyway, just thought I'd run it up the flag-pole in case it's obvious to
> > everyone except me.
>
> Is the session supposed to be maintained at the HTTP level (via cookies)
> or at the SOAP level (with an element within the SOAP envelope) ?
>
> The first should be relative easy. See something like:
>
>
http://weblogs.java.net/blog/ramapulavarthi/archive/2006/06/maintaining_ses.html
>
> The second could be more difficult. And I would find it tempting to
> use a heavier web service toolkit like Axis to do it.
>
> Arne