ServiceMix HTTP BC not working in OpenESB
I have finally installed the ServiceMix HTTP BC into OpenESB (Glassfish) without any start up errors; most of which were classpath issues.
Now when I send an HTTP request to the HTTP BC I get the following Exception:
javax.servlet.ServletException: Failed to process request:
javax.jbi.messaging.MessagingException: Operation name required to send message exchange.
at org.apache.servicemix.http.HttpBridgeServlet.doPost(HttpBridgeServlet.java:79)
This is thrown by OpenESB's MessageExchangeProxy.validate() method who throws this Exception when the javax.jbi.messaging.MessageExchange.getOperation() returns null.
So it appears that ServiceMix doesn't require the operation to be set and OpenESB does. Is this a compatibility issue? What can be done to resolve this? Is this related to this http://forum.java.sun.com/thread.jspa?forumID=512&threadID=734834
[906 byte] By [
mailguya] at [2007-11-26 14:35:00]
# 1
Lately I have been working with Guillaume Nodet at Apache ServiceMix to get this issue resolved. I have been able to get around the operation name required issue by setting the default operation. However without this capability I would not be able to install any ServiceMix components in OpenESB because it requires the operation name to be set.
Where in the specification does it mention that the operation name is required to be set?
To follow the thread on nabble click here: http://www.nabble.com/ServiceMix-HTTP-BC-not-working-in-OpenESB-tf2947046s12049.html#a8278082
# 2
The JBI specification doesn't explicitly require that the operation name be set. It does define an address (for a new message exchange instance) as: "a service reference, endpoint reference, and operation name for the logical address which the NMR uses to route message exchanges. (section 5.2). The plain meaning of this is that the operation name is part of the address.
On the other hand, MessageExchange.setOperation(QName) allows a null parameter. (Page 177). That would imply that operation names are indeed optional.
I'd say, on balance, that the Open ESB implementation is incorrect when it faults the sending of a new message exchange instance with a null operation name. On the other hand, I'd say that, in general, not using operation names is a very poor practice, because it violates the WSDL model of services, which requires an operation name. I assume that ServiceMix component is relying on the document type of the normalized message to discover the implied operation. This is a very SOAP-like behaviour, but is not consistent with the abstract WSDL 2.0 model that JBI uses. However, poor practice doesn't mean non-JBI compliant.
I suggest you submit a bug report over on open-esb.dev.java.net.
-Ron
# 3
I appreciate your honest and clear response. I think JBI developers out there are suffering from ServiceMix not requiring Components to provide an abstract WSDL. And without a simple and complete example of how to create a JBI component, things like this will continue to happen. To my knowledge this is the best example http://java.sun.com/integration/reference/techart/DevelopingAServiceEngineComponent-1-2.pdf we have. This example doesn't include a WSDL, it's pre 1.0, and 1.5 years old. Also it doesn't show a real implementation of the ComponentLifeCycle.getServiceDescription() method.
The JBI community really needs an new "Developing a Service Engine Component" white paper. It would be based off the 1.0 spec and be a complete example, compliant with OpenESB. Are you aware of one that is currently being written? If not I would love to create it.
Knowing what I know now, I agree that not using an operation is poor practice. Also I would say there are or could be components that may not need an operation. For example an XSLT transformer may not need an operation. He just takes content, applies a stylesheet, put content back in, and sends it off. Another example is the ServiceMix EIP Component. We also have one that wouldn't necessary require an operation. It is our Encoding component who is similiar to the transformer. It takes content, encodes it, adds that as an attachment and forwards it on. So I could definitely see components who may not require an operation.
Again I appreciate your involvement in this forum. Your words of wisdom are a great help to the community. I will go forward with submitting a bug report.
Thanks again.
