JAX-WS - Turning on outgoing SOAP headers for client

[Richard Maher]

Hi,

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.

Cheers Richard Maher

 

[Arne Vajhøj]

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

 

[Richard Maher]

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