Hi all, Back on the header stuff...
I had an interesting discussion with Charles here about headers and now I think that caching headers in the Service is not right too (maybe not for the same reason than you though about Tom and Glenn) The reason, is that one could bind to many servers using the getServicePort(URL) api and it would not make sense to send the same headers to different bindings. This means that I am now looking to add the caching of the headers in the generated Stub class itself. As I mentioned earlier today, I believe that the implementation should not dictate the headers behavior but offer the choice to the consumer of having the response's headers overwriting the request's ones or not. Considering those new elements, here is what I propose to solve the header issues: 1) Keep two hashes of headers in the Stub. This allows different binding to have their own set of headers. 2) a) stub.setHeader(String partName, object header, boolean replace) b) stub.setHeader(String partName, object header) // replace = false c) stub.setHeader(SOAPHeaderElement) I believe we do not need to have setRequestHeader() since you would never set the header on a response. Right? The (c) setHeader(SOAPHeaderElement) method is to allow non-WSDL-defined-header to be set on the request, which is not currently possible outside the Stub. 3) a) Object stub.getHeader(headerIdInfo) b) SOAPHeaderElement stub.getHeader(String) After the call to invoke() the headers that were registered with replace=true will end up in both headers hash thus allowing the roundtrip trick. getHeader() always return the response's header. Is this design getting better or worse? (!) Please send feedback on this... my fingers are burning... 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.
