After that I checked out the EchoAttachment sample of the latest Axis release (1.4). After deploying it I looked at the automatically generated WSDL file and was a little bit irritated...
The type of the parameter of the echo function is declared as DataHandler in the WSDL file. There is nothing to be found in the WSDL file about MIME like in the mentioned IBM article. It looks to me like DataHandler will constrain the use of the web service to Java users because DataHandler is only known in the Java space - or am I missing something here?
Originally posted by Bernhard Pauler: After deploying it I looked at the automatically generated WSDL file and was a little bit irritated ... - or am I missing something here?
The article that you quoted starts with a WSDL and generates the needed Java (WSDL2Java). The use of javax.activation.DataHandler is simply the Java-centric way of dealing with MIME types.
You apparently did the opposite. You started with the Java-implementation and expected to "automatically" be able generate an interoperable WSDL (Java2WSDL).
When is comes to designing SOAP web service interfaces WSDL is the lingua franca - not an interface specification in some platform specific programming language. So WSDL2Java should be the primary tool. Java2WSDL is merely a convenience that may have the tendency to produce Java-centric WSDL. Apparently it wasn't worth while in Java2WSDL to detect that the use of a DataHandler probably meant that an exchange of SOAP attachments is taking place. Furthermore the Java code may not contain enough information to exactly describe the MIME types that need to be mentioned in the WSDL - so Java2WSDL did the best it could.
Between the article and your own experiments you should have enough information to cobble together your own SOAP Attachment WSDL that WSDL2Java will translate into the Java interface that you are looking for.