Hi All,

We have a requirement where we have to call another IS service which is situated in different location and uses diferent broker. We have 2 solutions for communication between 2 IS viz. :

1. Broker to broker communication (Broker 6.1 to 7.1 communication)
2. Exposing IS service as a webservice

While option (1) would be used mostly when both integration platforms are of same product (it suits here as both are webMethods) however option (2) would make it generic and loosely coupled.

Please suggest your views and suggesstions on this.
It would be really helpfull for better understading.

Thanks & Regards,
Sumit

Both will work well if implemented correctly. For IS to IS communication I generally prefer messaging as it has a lot more built in reliability(store and forward, retry etc). However if the service on the IS server needs to be accessed by processes outside of the webMethods IS broker combo then I would go with a Web Service in most cases especially if it needs to be a synch call.

:eek:

Only if designed and implemented correctly. Web Services can be and often are just as brittle/tightly coupled as any other solution.

Thanks for your suggesstion.

Also if we have different intergration platform in future which needs to communicate with WM platform then in that case broker would not be a suggested approach.

Yes I forgot if we configure broker with JMS, probably this cross platform interobility would not be a problem. However that would be a asyn call.

JMS does not insure cross platform interoperability. There is an underlying provider of the JMS implementation and these don’t typically talk to each other without a communication bridge ie webMethods JMS implementation doesn’t talk with Tibco’s without some help in between maybe an adapter or some other program. Kind of the same concept as JDBC you oracle jdbc driver is not going to talk to SQLServer. But your JDBC calls would be standard.

If your code base is standard base and doesn’t call any JMS provider specifc services then switching out JMS providers is fairly easy. This is different however than dropping a message on Providers A queue and expecting to see it on Provider B’s queue. There are products and adapters that let you do this.

Here’s more food for thought; Don’t make this a technology only decision. How the service in the target environment is exposed should also consider business and process aspects.

Other technical options:

1. expose a service that accepts an XML document over HTTP (no SOAP)
2. call that service using remote invoke
3. don’t call the service directly at all; drop off a file in a directory/FTP server somewhere and let the target IS pick it up however it wants to

My preference would be:

• Web service using doc/literal (RPC is evil)
• Caller must implement some sort of retry or store/forward mechanism to allow for target outages. There are various ways to do this.