I have to say that when it comes to integration using SOAP my default position is that using JMS is overkill. I take that default position for a number of reasons:
- The Siebel limitations associated with generating/reading WSDL when a JMS binding is used.
- I don't like breaking open standard rules like using SOAP with a binding not in the standard. (Yes, I do realize there is extensive non-standard support for using SOAP with a JMS binding. )
- Usually there is a misconception that JMS as a transport allows more web service volume than HTTP. (It is the same Siebel internal dispatching method!)
- other items I wish I could think of at time of writing...
Recently I started working with a customer (using Siebel 8) who felt that JMS was just the answer to their need for guaranteed message delivery. (That premise can be challenged but is a whole other topic.) With that belief, there came the need to find a way to implement the strategy within Siebel. Since we would use SOAP for messages, the simplest choice was just to use SOAP over JMS which Siebel supports. Naturally, there was a challenge to this implementation in the form of the JMS adapter for both inbound and outbound messages. This makes sense since you can then bypass the inbound web service dispatcher giving you finer grain control. However, this brought up the following issues:
- When using the JMS adapter directly, you lose the ability to publish or consume a WSDL defining your web service operations along with supporting message and fault structures.
- Inbound SOAP formatted messages need to be parsed. When you pick up a message from the JMS queue for processing, you need to parse the SOAP message. While this is possible in eScript, (done it) it is not trivial or likely to be robust.
- Like it or not, the inbound web service dispatcher validates message format for inbound web services. This eliminates the need to write custom code to validate the format of inbound messages.
- Outbound SOAP messages need to be constructed. Once you convert an integration object into XML you still need to wrap it within a properly formatted SOAP message. You can do this a variety of ways (XSLT, eScript) but it is work that needs to be done.
- Since we are using SOAP over JMS we can't use the popular document literal format. Why? Simply because there is no SOAPAction HTTP header field that can be set. Thus you must use the less popular RPC literal format. This has a significant impact on the WSDL you must generate by hand. (see earlier point)
As you can determine from the list above, there are some real challenges associated with SOAP over JMS if you use the JMS adapter directly. However, the more daunting issues "go away" when you take advantage of the Siebel SOAP over JMS feature
- Inbound SOAP messages are parsed and format validated without custom code
- Outbound SOAP messages are properly formatted within a SOAP envelope.
- WSDL can be generated and consumed if you take the manual step to convert between HTTP and JMS transport via the web service administration views.
We still have to deal with the SOAP RPC literal issue but that seems trivial to the other problems addressed. Thus to be objective, even though I still don't like or recommend using SOAP over JMS, I admit that it can provide some advantages.
However, I retain the position that the entire need to use JMS directly with Siebel can be eliminated by placing Fusion Middleware (FMW) in front of Siebel. Doing so allows the FMW part of the solution to take responsibility to interact with JMS as required. Required interactions between FMW and Siebel still take place using SOAP over HTTP with the FMW code responsible for handling error recovery/retry. But that is the topic for a whole other post and article.
