Hi I'm adding in support for Soap with Attachments into the Axis provider. I've added it into tests/proposals.mime currently. There is a MimeTest that demonstrates which pieces currently work. Here's a list of questions that I would appreciate any help or advice on. Unfortunately attachment support doesn't seem to be well documented in Axis.
I got Mime/Axis/Http working, so I tried Mime/Axis/Jms. It seems that org.apache.axis.transport.http.HTTPSender sets up information in the http headers that is needed to make sense of the mime attachments. I could set these headers up as jms properties (prefixed by WSIF_). If the JMS2HTTPBridge was being used, it could convert these back into http headers. Where do I find documentation on what these http headers really mean? Is it sensible to copy them all into jms properties for Mime/Axis/Jms? Currently to pass in an attachment, the user needs to set a javax.activation.DataHandler, java.awt.Image, java.lang.String, javax.xml.transform.Source, or a javax.mail.internet.MimeMultipart as a part on the WSIFMessage (depending on the content type). Is that the right interface, and is that the complete list of types that map to attachments? When returning an attachment from a service, axis passes back a javax.xml.soap.AttachmentPart instead of the DataHandler that I was expecting. WSIFOperation_ApacheAxis can easily turn the AttachmentPart into a DataHandler, and return the DataHandler instead. Should I also allow AttachmentParts to be pass in and returned by WSIF? Is there any advantage for users of WSIF being able to pass in and get out AttachmentParts instead of DataHandlers? I'm only adding attachment support into the Axis provider, but I would like to make this support extendable so other providers could implement attachment support as well. Consequently I do not want to pass in any axis-specific types as message parts. I could imagine this function would be useful for the NativeJms provider. The jms message would not contain a mime message, since that would make the native jms provider depend on axis, and this function is already provided by the axis provider. What do people think? Do mime attachments make sense using doc-style? Is the user expected to do a mapTypes() to map a tns:datahandler to a DataHandler? This seems wrong to me because it implies the application programmer requires prior knowlege about the WSDL and the operation that is being invoked. Is there a standard XSD or WSDL type for a DataHandler, and if not should WSIF define one? What about attachments passed by reference? Passing the attachment by value as a mime attachment in the message, means that this (possibly huge) file gets copied multiple times. Alternatively WSIF could support passing a reference (url?) to this file, which the eventual recipient could retrieve. I don't think this needs any support in WSIF, since callers could do this already. What do you think? For text/plain, I register a type mapping for String to be serialized with the JAFDataHandlerSerializerFactory. Unfortunately this means that all Strings get treated as mime attachments. I guess I need to pass in the string as an AttachmentPart instead of doing the mapping. Would this fix the problem? Even though I pass an Image (,String,etc) to Axis, Soap 2.3 on the server always invokes the backend service with a DataHandler. So the WSIF dynamic proxy implements my testcase's interface but the the backend service does not. Is this just a peculiarity of mixing soap and axis? Surely the WSIF dynamic proxy and the backend service must both implement the same interface. Should WSIF support complex types that extend DataHandler, Image, etc? Should WSIF support complex types that contain DataHandler, Image, etc? Any ideas? Mark Mark Whitlock, IBM Hursley Web Services
