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:[EMAIL PROTECTED]] Sent: Thursday, April 25, 2002 5:59 PM To: [EMAIL PROTECTED] 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:[EMAIL PROTECTED]] Sent: Thursday, April 25, 2002 5:28 PM To: '[EMAIL PROTECTED]' 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:[EMAIL PROTECTED]] Sent: Tuesday, April 23, 2002 2:27 PM To: [EMAIL PROTECTED] 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:[EMAIL PROTECTED]] Sent: Tuesday, April 23, 2002 12:07 PM To: '[EMAIL PROTECTED]' 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:[EMAIL PROTECTED]] 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.
