[wsif] Attachment support

[Mark Whitlock <ma...@uk.ibm.com>]

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