Performance and Calling a BPEL WSDL From an EJB

In most of my current Java SOI/JBI (Netbeans/Glassfish/OpenESB) project, where a BPEL needs to be invoked from inside an EJB, I have done some variation of simply using Netbeans' wizard to create a Web Service Client, and then dragging the operation from the WSDL over into the EJB source editor. This creates a service class, and classes for the message and response that are generally pretty close to what I needs, all using Jaxb-ws.

At one point in the project however, I determined that one of these calls created a really significant performance hit. The hit occurred someplace between leaving my EJB code:

MyOperationDataResponse myOperationDataResponse = port.MyOperationDataSoapOperation(myOperationDataRequest);

...and the initial Receive operation in the BPEL (in a different Service Assembly - this might be a factor), which was the earliest I could place a log message. The delay in there was as long as 4-5 minutes, and seemed to be driven by the size of the request payload (about 2 MBs, large but not huge).

According to VisualVM, a great tool by the way, the process was spending a large amount of time in this method:

com.sun.enterprise.server.ss.provider.ASSelector.select(long)

...Which was interesting, but did not help me determine a course of action. In the end, I replaced the jaxb-style code with code that calls the web service using XMLBeans and javax.xml.soap.* classes only. I was unable to get the JAXB version of this call to hit the actually service with less than about a 5 minute delay, with the "large" payload I'm using. The equivalent part of this new call happens in .2 seconds (that's point-two). I don't know the repercussions of doing this sort of call vs. the web service client generated by Netbeans, or of having the XML Beans classes in the environment. It would be nice not to have to introduce this other style into the application. This does seem to confirm some sort of issue in either the jaxb-ws layers, or the HTTP Binding Component, though. I suspect the HTTP-BC because the payload size alone does not seem to cause a problem.

Here's the XMLBeans-style WS client code.

MyOperationDataDocument putCardDataDocument = MyOperationDataDocument.Factory.newInstance();

MyOperationDataResponse.MyOperationDataResponseDocument myOperationDataResponseDocument = MyOperationDataResponse.MyOperationDataResponseDocument.Factory.newInstance();

MyOperationDataDocument.MyOperationData myOperationData = myOperationDataDocument.addNewPutCardData();

myOperationData.setSomeField(something);

SOAPFactory sf = SOAPFactory.newInstance();

SOAPMessage soapMessage = MessageFactory.newInstance().createMessage();

SOAPPart part = soapMessage.getSOAPPart();

SOAPEnvelope soapEnvelope = part.getEnvelope();

SOAPBody body = soapEnvelope.getBody();

org.w3c.dom.Node node = putCardDataDocument.getDomNode();

SOAPBodyElement soapBodyElement = body.addDocument((Document)node);

SOAPConnectionFactory scf = SOAPConnectionFactory.newInstance();

SOAPConnection con = scf.createConnection();

URL endpoint = new URL("http://localhost:9080/MySoapService/MySoapPort");

SOAPMessage reply = con.call(soapMessage, endpoint);

con.close();

The message and response classes are created using the scomp command line utility that comes bundled with an XMLBeans install. I found surprisingly few examples like the above code online, so I hope this is helpful to someone else down the road.