To answer your curiousity (I presume) about my questions about Soap over HTTP: well HTTP is an inherently unreliable protocol. It is layered in the OSI network model on the application level. Your internet-browser that brought you my article might have to wait for a long time, and even time-out, when requesting for a page. In fact this is why I started to edit this article in a text-editor, because the blog-server and my browser did not connect properly at the moment.
But puting your soap message on a queue that is also connectable by your receiving system might give you a very welcome abstraction. Your message providing application does not have to wait until your message consuming application consumes it. Your message provider can fire and forget it (unless you choose for a request-reply topology). If the remote application is unavailible for a time-being then it can pick up the messages when it comes up again.
A few years ago I had to integrate with a BSCS billing system. Back in 2002 I think it was, they builded a new Customer Access System and by then I was surprised that they used a kind of propietry command protocol with comma delimited parameters. It was not XML what was pretty much was a standard already. Also you had to connect to this CAS server using tcp. Since our integration server was in The Hague in Holland and the BSCS System and the CAS Server in Munich in Germany I stated that I wanted to have an Oracle database in Munich in the same cabinet as the CAS Server. Then I could create an AQ (nowadays called Oracle Streams - Advanced Queueing) queuing and propagation mechanism between our Oracle Hub Database in The Hague and the Oracle Adapter Database in Munich. Between this Oracle Adapter Database I used a simple external procedure that we could call from the database and that connected over a short tcp connection with the CAS server. Since it was an internal Datacenter gigabit tcp connection it was reliable enough.
But the main distance I bridged with AQ that had all the reliability and monitoring tools that you expect from a standard Queueing mechanism.
The same applies comparing Soap over HTTP and Soap over JMS, partly. The only thing is that you have to keep in mind that HTTP is a network protocol and JMS is an API on a queueing implementation. The propagation mechanism that provided my bridge between The Hague and Munich like I sketched above is not provided by JMS but the Oracle AQ implementation. Also JMS is a Java api, so it is not as technology independend as HTTP is. For example I assume it is a little hard to natively post on a JMS Queue or Topic using .Net.
Also keep in mind that although you have a wsdl (webservice description language) in a standard form that can be consumed by your development tool, the system that is "consuming" the service in runtime has to call the jms-api's to connect to the queue and publish on or consume a message from it. Because the address is not a transparent network address but a local jms-queue. If your consuming system is far-far-away from your producing system, then you have to create a local queue on both systems and implement a propagating technology between these queues (like in my AQ-story).
For more critical notes on Soap over JMS see:
- http://dev2dev.bea.com/blog/pdone/archive/2007/03/using_soap_over.html
- http://blogs.oracle.com/rnaszcyniec/2008/03/04#a48
For a description on how to do it on the Oracle Application Server 10.1.3 platform see the Oracle documentation on: http://download-uk.oracle.com/docs/cd/B25221_03/web.1013/b25603/transportjms.htm
Soap Over JMS is not an industry standard as Soap over HTTP is. Maybe that is the reason that it is not as natively supported by the different tools. If I'm in the BPEL or ESB Designer in jDeveloper I would expect that I could create a Partnerlink (bpel) or Adapter Service (ESB) and simply say: here is a wsdl, there is the queue, have fun with it: create me a Soap over JMS service consumer or provider.
I'm very pro-queueing. I'm very fond of AQ because of it's simplicity, reliability and maybe most of all the simple api's I have in Pl/Sql for it. But I probably would not use Soap over JMS except when the Customer has good reasons to ask for it. For example because they do not have a Integrating tool that has an adapter to post messages on a jms-queue.
Since both provider and consumer has to be able to post on or consume from the same local queue I expect that you probably be easier of using the Oracle JMS adapter. At my customer they also have Tibco and also Tibco is capable of queueing on a JMS queue. So I would suggest creating serveral queues on both Application Servers and have the Oracle JMS adapter using it. If I must I could have an jms-adapter service in Esb and create a Routing Service based on a predesigned wsdl. This provides me a service that is invocable as a "native" webservice but puts the message on a jms queue.
And if reliability is a heavy requirement I could base the jms-queue in the Oracle Application Server on a AQ queue in an Oracle 10g Database. Then each message is reliably stored in the database until it is consumed.
But if your heterogeneous platform servers are in the same datacenter and can rely on a profound network architecture then why not use the simplicity of Soap over HTTP?
Conclusion
Soap over JMS is a very good idea, I think. But there need to be some work done on the productivity and connectivity, to be really usefull. I would not dare to say that there is no future for Soap over JMS. But I think in most cases I would need the reliability over a very long distance (like my The Hague/Munich example). If you do indeed have the same requirement (reliable messaging over a long distance) I would suggest you to take a look into the ebXML/ebMS standards. Oracle Integration B2B for example could help you with that.
No comments :
Post a Comment