Passing binary files in webservices

[alain martin]

I need send binary files in my webservice. And I need it can be used by non java clients. Can I do it? Do you have any example?
Thankss


___________________
http://www.hhdirecto.net
http://www.dechiste.com

[Stan James]

Look into Base64 encoders. The algorithm is (just about) standard enough for cross-language use. Encoded strings are 4/3 as big as the original data (or something like that) and might even be safe for inclusion in XML. If not a CDATA section will do the trick.

[William Brogden]

The SOAP standard provides attachments to the SOAP message that may be binary.
Sun's web services package has what they call SAAJ to handle this.
Attachements are intended to handle the situation with large binary data such as images. For small binary data, the Base64 encoding of an XML element is fine.
Bill

[alain martin]

Thanks

Do you have any implementation expample of attachments to the SOAP message or by base68?

[Peer Reynders]

Originally posted by Stan James:
Might even be safe for inclusion in XML. If not a CDATA section will do the trick.

There is nothing (that is legal) that could appear in an element of either the {http://www.w3.org/2001/XMLSchema}:hexBinary or {http://www.w3.org/2001/XMLSchema}:base64Binary (RFC 2045) type that should require a CDATA section. (unless its a size issue - in which case some .NET clients may still give you some grief, see Send binary data without using attachments)

XML, SOAP and Binary Data
[ April 10, 2006: Message edited by: Peer Reynders ]

[Ulf Dittmer]

The WebServicesFaq has a couple of links to articles about that.

[alain martin]

Thanks a lot.

Do you know where there is a example of SOAP with attachmentes with axis?

[William Brogden]

My copy of AXIS 1.3 seems to contain a samples/attachments directory containing an example that sends a specified file as an attachment.

Bill

[alain martin]

Thanks, I found that sample too. But I see it return a DataHandler, and this is a java type.

I think it won't run with non java client

[Peer Reynders]

Originally posted by alain martin:
But I see it return a DataHandler, and this is a java type.
I think it won't run with non java client

Have another close look at SOAP attachments with JAX-RPC. The javax.activation.DataHandler only appears in the Java service endpoint interface (i.e. on the server side) � it does not appear anywhere in the WSDL (or SOAP message for that matter). The DataHandler is simply JAX-RPC�s way of dealing with the MIME conversion of the attachments � that functionality already existed in the JavaBeans Activation Framework (JAF).

SOAP with Attachments doesn�t send a SOAP message � it sends a MIME envelope that contains the SOAP message followed by one or more MIME attachments. So the restriction is that the client has to support the SOAP with Attachments specification.
[ April 11, 2006: Message edited by: Peer Reynders ]

[alain martin]

Hi,

I have just created a simple webservice:
public DataHandler getFile()

But in the wsdl I found

<wsdl:message name="getFileResponse">
<wsdl:part name="getFileReturn" type="apachesoap:DataHandler"/>
</wsdl:message>

What am I doing bad?
Thanks

[Peer Reynders]

I suspect that the Java2WSDL tool you are using is defaulting to "RPC/encoded" mode. SOAP with attachments is not used with encoded binding but with literal binding. So find a way to specify LITERAL instead of ENCODED. If you are using the Axis Java2WSDL tool use the "�-use" command line option.
Java2WSDL Reference

-y, --style <argument>
  The style of binding in the WSDL, either DOCUMENT, RPC, or WRAPPED.
-u, --use <argument>
  The use of items in the binding, either LITERAL or ENCODED

There is also the possibility the Java2WSDL doesn't support SwA. To get SwA you may need to use WSDL2Java.
[ April 19, 2006: Message edited by: Peer Reynders ]

[alain martin]

Hi, I'm developing with axis. I have change deploy wsdd file to
provider="java:RPC" style="rpc" use="literal"

But the wsdl have yet

<element name="getFile">
<complexType/>
</element>
<element name="getFileResponse">
<complexType>
<sequence>
<element name="getFileReturn" type="apachesoap :mrgreen: ataHandler"/>
</sequence>
</complexType>
</element>

[Peer Reynders]

I'd assume that the axis Java2WSDL cannot deal with SwA. The SwA sample (axis/samples/swa) that comes with Axis clearly uses WSDL2Java.

So basically define your Java interface as far as you can without SwA and generate the WSDL with Java2WSDL. Then using the SwA sample as a template modify the WSDL to include SwA and use WSDL2Java to create the Java endpoint interface.

[Jesus Angeles]

Originally posted by Peer Reynders:
...Then using the SwA sample as a template modify the WSDL to include SwA and use WSDL2Java to create the Java endpoint interface.

Peer, is this right?

what he has to do is change the

 
type="apachesoap :mrgreen: ataHandler"

with the type of his binary file right?

like, for example,

 
type="application/pdf"

...

and then use wsdl2java to generate the interface (that will contain DataHandler as parameter, unless the compiler implementation doesnt support DataHandler)?

[Peer Reynders]

Originally posted by Jesus Angeles:
Peer, is this right?

Not Exactly. If you look at Listing 1 (WSDL) and 2 (Service endpoint interface) of SOAP attachments with JAX-RPC you should notice that the DataHandler parameter is mapped to xsd:hexBinary type but that the containing message is bound using the mime:multipartRelated element -the actual mime-type of the parameter/part only appears in the mime:content element of the binding.
With that knowledge you should be able to craft the Java interface you want but put a dummy standard datatype like String for the parameter or return type where you want the Datahandler to appear. Then use Java2WSDL to generate the initial WSDL. Now modify the WSDL by the rules evident in the SOAP attachments with JAX-RPC and make the approprate replacements in the message definitions and their bindings (also including the xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" namespace declaration and binding the mime message part with the mime:content element). Then simply use WSDL2Java on the modified WSDL and see if it generates the desired Service Endpoint Interface with the DataHandler parameter/return type.

[Jesus Angeles]

Also, this is a result of lack of specifics in the specification for the DataHandler as a parameter, on j2ee web services. Some vendor implementations will fail in generating an interface with an arbitrary mime type(unless we use mapping file).