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.
]]>
