Binary SOAP attachment using Websphere

[Costanza Smith]

I am currently attempting to send a pdf file via webservice. I am using Websphere. I have the following code to send the pdf file across:

public DataHandler requestAttachment()
{
File file = new File( "C:\\test\\testfile.pdf");
FileDataSource fDataSource = new FileDataSource(file);
DataHandler dataHandler = new DataHandler(fDataSource);
return dataHandler;
}

When I generate new web service via the wizard, the wsdl it generates does not contain the following piece which I have modify:
<mime:multipartRelated >
<mime art >
<wsdlsoap:body use="literal"/>
</mime art>
<mime art>
<mime:content part ="requestAttachmentReturn" type= "application/pdf"/>
</ mime art>
</mime:multipartRelated>

So, then I attempt to test my service and I recieve the following exception when the actual call is made:

faultCode: Server.generalException
faultString: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.MarshalException: CORBA MARSHAL 0x4942f896 No; nested exception is:
org.omg.CORBA.MARSHAL : Unable to read value from underlying bridge : null vmcid: IBM minor code: 896 completed: No

faultActor: null
faultDetail:

java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.MarshalException : CORBA MARSHAL 0x4942f896 No; nested exception is:
org.omg.CORBA.MARSHAL: Unable to read value from underlying bridge : null vmcid: IBM minor code: 896 completed: No

at com.ibm.ws.webservices.engine.WebServicesFault.makeFault(WebServicesFault.java:156)


So, I just wanted to find out what am I doing wrong?
Do I need to have a wrapper class that implements Serializable?

[Peer Reynders]

I presume you've given this a go to create an example that works and then incrementally modify it toward a version that is useful to you?
SOAP attachments with JAX-RPC

[Costanza Smith]

That is correct. I have followed that exact example. The only difference, my Datahandler is an output of my service vs its input.

So, the service itself is responsible for looking up a pdf file and wrapping it into a DataHandler object which is then sent back.

Is there something I am missing?

[Peer Reynders]

The fact that it doesn't generate the MIME element in the WSDL is disturbing.
It leads me to believe that the wizard can't deal with the javax.activation.DataHandler as the return type of the endpoint interface.
The DataHandler return type must be represented in some way in the WSDL.

If you went WSDL2Java (I believe the article used this path), WebSphere may allow you to specify a JAX-RPC Mapping file that may get the point across

    ...
            <wsdl-return-value-mapping>
                <method-return-value>javax.activation.DataHandler</method-return-value>
                <wsdl-message>tns:YourWsdlResponseMessage</wsdl-message>
                <wsdl-message-part-name>tns:YourWsdlResponseMessagePartName</wsdl-message-part-name>
            </wsdl-return-value-mapping>
        </service-endpoint-method-mapping>
    </service-endpoint-interface-mapping>
</java-wsdl-mapping>

Implementing Enterprise Web Services 1.1 (contains JAX-RPC mapping file specification)
Roundtrip issues: the mapping meta-data file

[Costanza Smith]

That is correct. There are two files I had to apply changes to manually once the wizard generated all the appropriate files for the new web service:

1) The MyEJB.wsdl file had to be changed to change the return type as hexBinary and specify content type as application/pdf.
...
<element name="requestPDFResponse">
<complexType>
<sequence>
<element name="requestPDFReturn" nillable="true" type="xsd:hexBinary"/>
</sequence>
</complexType>
</element>
...
<mime:multipartRelated>
<mime art>
<wsdlsoap:body use="literal"/>
</mime art>
<mime art>
<mime:content part="requestAttachmentReturn" type="application/pdf"/>
</mime art>
</mime:multipartRelated>

2) I changed the MyEJB_mappings.xml file as well to reflect the return type which is now a byte[] as its class type and also to specify the return value which is the DataHandler. I actually tricked it a bit in order for WSAD to regenerate the mapping for me. Basically, once I manually changed the above wsdl file with the content type changes, I did a Web Service->Generate Java Bean Skeleton. It is then recreated for me the mappings file.
...
<java-xml-type-mapping id="JavaXMLTypeMapping_1140546093755">
<class-type>byte[]</class-type>
<root-type-qname id="RootTypeQname_1140546093755">
<namespaceURI>http://www.w3.org/2001/XMLSchema</namespaceURI>;
<localpart>hexBinary</localpart>
</root-type-qname>
<qname-scope>simpleType</qname-scope>
</java-xml-type-mapping>
...
<method-return-value>javax.activation.DataHandler</method-return-value>
<wsdl-message id="WSDLMessage_1140546093755">
<namespaceURI>http://myspace</namespaceURI>;
<localpart>requestPDF</localpart>
</wsdl-message>
....

I can send you my full wsdl file, as well as the mappings file if you like to take a look at.

So, I am kind of stuck at this point... Also, I am curious, DataHandler object is obviously NOT serializable. So, I am not sure does that mean it can not be sent across and we need to write our own serializable wrappers for it but all the examples on the web that show the SOAP attachment, just simply pass the DataHandler. So, I guess I am a bit confused at that part. Also, WSAD flags that fact as well...

[Peer Reynders]

Originally posted by Costanza Smith:
... MyEJB.wsdl...

You are using an EJB service endpoint? That makes me wonder...I don't recall that there are any guarantees that an EJB service endpoint supports the full functionality supported by a JAX-RPC service endpoint (JSE). EJB service endpoints are handled by the EJB Container while JSEs operate out of the Servlet Container using the JAX-RPC runtime. And attachments are a special SAAJ/JAX-RPC feature.

I don�t think the DataHandlers are serializable as such but JAX-RPC is supposed to know how to use their interface to stream them to and from MIME parts.

You may want to try if you can get it to work as a JSE. Even if EJB service endpoints can�t handle attachments directly you may be able to use attachments by installing a SOAP handler. The handler would use the SAAJ API to strip off any incoming attachments and place them in the current javax.xml.rpc.MessageContext. Inside the endpoint the MessageContext can be retrieved through the endpoint's javax.ejb.SessionContext getMessageContext() method. Outgoing attachments could be placed in the MessageContext, so that the SOAP handler can build a MIME envelope around the outgoing response.

EJB 2.1 Web Services: Part 1
EJB 2.1 Web Services: Part 2

This suggests however that attachments/DataHandlers are supported by EJB Service Endpoints in WebSphere.

You may also want to experiment with a .jpg file rather than a .pdf file. FileDataSource relies on the mimetypes.default registry file. That file should have a mapping for JPEGs but it may not have the "application/pdf pdf PDF" mapping - in which case it will use the "application/octet-stream" MIME type. Once you get it working for a JPEG you can add your own mime.types file which includes the pdf mapping.
[ February 22, 2006: Message edited by: Peer Reynders ]

[ahmed sharaf]

so how exactly can make a webservice return a datahandler?
i created a webservice that it's input is a datahandler and it works fine but when i set the output in the wsdl to be a datahandler the function signature is generated as void!!

[ashma rack]

Hi,

I have created a webservice that accepts a DataHandler [] parameter and an xml string with meta data regarding the files in the handler, however, i get this error message when the message hits the endpoint:

java.rmi.MarshalException: CORBA BAD_PARAM 0x4f4d0006 Maybe; nested exception is:
java.io.NotSerializableException: javax.activation.DataHandler is not serializable

ahmed , you said you were able to successfully send a DataHandler to a web service. any idea as to how i can get rid of this error.
Thanks.

[Naren Chivukula]

Hi Ashma,
Instead of re-opening more than one year old posts, you can do a fresh post and may refer the old post link into it. In that way, whoever is trying to read your post might not go through unrelated content.