axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "St-Germain, Sylvain" <Sylvain.StGerm...@cognos.com>
Subject RE: Client side soap:header support.
Date Mon, 29 Apr 2002 13:50:19 GMT
Chris, 
I agree that the current implementation, although simpler and possibly less
obtrusive for the WS consumer, is quite restrictive because it enforces a
behavior.  

The current behavior is that response header will update the requests
headers.  I realize that this is not a rule that should *not* be dictated by
the implementation but rather by user's choice.

So I am definitely willing to make sure the implementation is not
restricting in any way.  WS consumer should be allowed to have the headers
roundtrip or not.

Sylvain.

-----Original Message-----
From: Chris Haddad [mailto:chris.haddad@cobia.net]
Sent: Friday, April 26, 2002 8:40 AM
To: axis-dev@xml.apache.org
Subject: RE: Client side soap:header support. 


Sylvain - let me see if I can convey a compelling position for the dual
stack implementation.

Think of the ability to define a request header of tag name
TransactionID that represents the senders transaction token, and the
receiver sending an response header tag of TransactionID that represents
their corresponding transaction token.  The name is the same, the
semantics surrounding the scope of the variable is totally different.

The fact that soap header definitions are commonly assigned to messages
which are then associated <input> or <output> sub-elements of
<operation> lends credence to the request and response stack being
distinct from a soap-WSDL perspective.  Otherwise, one would just assign
them to <operation> in the WSDL and have the header automatically relate
to the entire message set.

Granted, dotNet could define the concept of an INOUT header that would
munge the concept of request and response stacks; but how is the
difference between IN, OUT, and INOUT represented in the dotNet WSDL?
I'm still getting up to speed with the dotNet tools, can you share an
example that illustrates your perspective?

maybe making every header INOUT may be a MS inspired abstraction that
removes capability at the sake of convenience.  However, the abstraction
is a red herring if the <input> and <output> definitions differ.  

/Chris



-----Original Message-----
From: St-Germain, Sylvain [mailto:Sylvain.StGermain@cognos.com] 
Sent: Thursday, April 25, 2002 5:59 PM
To: axis-dev@xml.apache.org
Subject: RE: Client side soap:header support. 

Glen, Tom, 

I understand your concerns and I have been thinking about this concept
of
having two distinct stacks of headers one for request and one for
response.
However, using dotNet we clearly see that you can set header "a" on the
request, have it modified by the server and the next request is sending
the
updated header "a".  Which seems to clearly show that requests and
responses
header are the same.

Now, this is (dotNet) the only knowledge I have about the behavior/life
cycle/roundtrip of headers.  And after thinking about it now makes sense
to
me.

Can you explain further what makes you propose your approach?  It sure
means
for a consumer of the service that the headers are a lot more in the way
than the submitted approach (at least from a coding point of view, i.e.
you
would have to set them all the time manually)   

I have no problem with modifying the implementation I have now (it is
far
from perfect anyway) but I would like you to look at it from the
perspective
explained at
http://marc.theaimsgroup.com/?l=axis-dev&m=101855699714103&w=2
and we will go from there.

Regards,
Sylvain.

-----Original Message-----
From: Tom Jordahl [mailto:tomj@macromedia.com]
Sent: Thursday, April 25, 2002 5:28 PM
To: 'axis-dev@xml.apache.org'
Subject: RE: Client side soap:header support. 



I have been talking with Glen and giving this a bit of thought.  It
believe
that we do NOT want the headers on the Service, but they need to be
associated with the Call, i.e. they are per-operation things.  This is
reflected in WSDL, which lists headers per operation.

Also, Glen has convinced me that you probably do want the headers going
out
from a client and the headers coming back to be different.  You should
have
setRequestHeader() and getResponseHeader() APIs.  This will prevent the
server from overwriting headers that you might not want blasted.

I hope you can make these changes to your implementation without too
much
pain.
--
Tom Jordahl
Macromedia


-----Original Message-----
From: St-Germain, Sylvain [mailto:Sylvain.StGermain@cognos.com]
Sent: Tuesday, April 23, 2002 2:27 PM
To: axis-dev@xml.apache.org
Subject: RE: Client side soap:header support. 


Tom, 

As you noticed I did not set "required" for the reason I pointed out,
this
is one of the thing I am investigating now.

As a service consumer you simply do on the client side:

	service.setHeader(String partName, Object o);
	// Note that there is currently no validation done in the setter
	// to ensure you provide the appropriate type, I believe we have

	// all the info so we should check.

	Object o = service.getHeader(String namespace, String partName);
	// Ideally you should probably not have to bother with the 
	// namespace here.   I'll have a look at it.

About implicit ServiceContext, I understand the idea brought by JAX-RPC
but
I see little value (as a WS consumer) in using it.   My idea of header
is
that you set them and they are roundtrip, you avoid setting and
unsetting
them in a given session... but I could be wrong.  I am not sure if we
have
to support both implicit and explicit headers to be JAX-RPC compliant.

I certainly can bundle a userGude section as well as a test case.

Headers and Header are clones of Parameter and Parameters but I can
change
this no problem.
I can also get rid of some "ownership" information in there!  as well as
cleaning up the System.out and the tabs.

Thanks Tom for your warm welcome!
Looking forward to see soap:header support in early B2 versions!

Sylvain.

-----Original Message-----
From: Tom Jordahl [mailto:tomj@macromedia.com]
Sent: Tuesday, April 23, 2002 12:07 PM
To: 'axis-dev@xml.apache.org'
Subject: RE: Client side soap:header support. 



Sylvain,

I took a look at this code and its looking good.
I do have some JAX-RPC concerns however.

A few comments/questions:

- The required attribute isn't getting set?  You probably want to
investigate
  and fix that problem as part of your submission.  See your comment in
  Header.java.

- How, as a user of the stub, do I set headers? How do I retrieve them?

- JAX-RPC (chapter 11) talks about the ServiceContext.  In 11.2.2, they
  talk about an Explicit Service Context, which is added as a
  parameter to the stub method signature.  Do we need to implement
  headers this way to be JAX-RPC compliant?

- Make sure you write up a section for the users guide and include that
  as part of the submit.  That way people will have something to
reference.

- Make sure to include a functional test that verifies the feature.

Nit picking:
- Header and Headers aren't very good class names, too much alike. :-)
  How about Header and HeaderList?

- Look like you have tabs in some places, make sure you use spaces.

- Probably no need for the @author comment for methods (i.e.
Service.java)

- Make sure you remove all the System.out.println() statements


I agree that we do not want these changes in for Beta 2, but I think
we should work to get them in shortly after B2 is release.

Thanks again for jumping in and helping out with this!

--
Tom Jordahl
Macromedia




-----Original Message-----
From: St-Germain, Sylvain [mailto:Sylvain.StGermain@cognos.com]
Sent: Monday, April 22, 2002 3:51 PM
To: Axis Dev (E-mail)
Subject: Client side soap:header support. 


Hi all, 

Here is some code that provide client side support for soap:header entry
in
the WSDL operation binding.  

Modified files:
  xml-axis/java/src/org/apache/axis/client/Service.java
  xml-axis/java/src/org/apache/axis/wsdl/toJava/JavaStubWriter.java
Added files:
  xml-axis/java/src/org/apache/axis/serviceContext/ServiceContext.java  
  xml-axis/java/src/org/apache/axis/serviceContext/HeaderKey.java
  xml-axis/java/src/org/apache/axis/wsdl/toJava/Headers.java
  xml-axis/java/src/org/apache/axis/wsdl/toJava/Header.java

>>From a high level point of view:

1 - WSDL2Java now adds the appropriate setHeader() before call.invoke()
as
well as the appropriate updateHeader() following call.invoke()

2 - I have added a ServiceContext class stored in the Service that
currently
simply stores a Hashtable of all the service's header.  The key to the
hash
is a HeaderKey (which could/should (not sure) be replace by a String if
someone can confirm that the key to a header is the part name...)  I did
create HeaderKey because originaly I was using the combination of the
part
and the message to find a Header in the ServiceContext hash.

I believe that this will not make its way into the build before Beta-2
(right?) so I am sending it to get feedback, let me know if my
understanding
of soap:header is right and what should be changed may this be the case.

To try it simply have some entry like this in your input operation :
<soap:header required="false" message="tns:tracking" part="tracking"
use="encoded"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>

--
Sylvain

This message may contain privileged and/or confidential information.  If
you
have received this e-mail in error or are not the intended recipient,
you
may not use, copy, disseminate or distribute it; do not open any
attachments, delete it immediately from your system and notify the
sender
promptly by e-mail that you have done so.  Thank you.
          

This message may contain privileged and/or confidential information.  If
you
have received this e-mail in error or are not the intended recipient,
you
may not use, copy, disseminate or distribute it; do not open any
attachments, delete it immediately from your system and notify the
sender
promptly by e-mail that you have done so.  Thank you.

This message may contain privileged and/or confidential information.  If
you
have received this e-mail in error or are not the intended recipient,
you
may not use, copy, disseminate or distribute it; do not open any
attachments, delete it immediately from your system and notify the
sender
promptly by e-mail that you have done so.  Thank you.



This message may contain privileged and/or confidential information.  If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.  Thank you.

Mime
View raw message