Enterprise Server vs Intergration Server Decision Criteria

, , ,
1

Appreciate inputs here

What are the criterias when choosing EnterpriseServer vs Integration Server in an EAI project

E.g.

  1. Fault-Tolerance
  2. Guarantee Delivery
  3. Inside/Outside Firewall
  4. Availabilty of Adapters (e.g. EDI in IS only)
  5. Performance

Thanks in advance for more criteria

BTW, is that right Enteprise Server is going away soon ??

2

Of course the following is all just unfetterred opinion…

IMO, if you don’t already have Enterprise Server (now called webMethods Broker) don’t get it/use it. The direction of the product suite is clearly toward Integration Server.

  1. Fault-tolerance: Both environments provide support for clustering and failover.

  2. Guaranteed delivery: Broker provides message queueing. IS provides services to implement guaranteed delivery (TN is the way to go here). Both require some work to provide client-side queueing–meaning if you want an application to be able to queue up messages/documents if the wM server is down, you’ll need to build something. It’s not difficult, just another task. Both environments can use “real” MQ software such as WebSphere MQ (MQ Series), MSMQ, JMS servers, etc. Broker is a JMS provider.

  3. Inside/outside firewall: both can be used across the 'net, though IS is more attuned to doing so.

  4. Availability of adapters: the adapters are being unified into one environment–IS. IMO, the only adapters that were better in the Broker environment were the DB adapters.

  5. Performance: this always depends on what you’re doing but generally speaking, the Broker wins this hands down as far as raw through-put of documents. But it’s hard to get a true comparison. Broker can deliver docs very quickly but the Broker doesn’t do any transformation. The ONLY thing the Broker does is receive docs and put them on queues for pick up by adapters/agents/clients. Transformation is done by the adapters. A typical IS integration does a receive, transform, process, deliver. The transform is normally the cycle-eater.

To sum up, go with IS/TN. Broker is being positioned as the component between various IS installs but I really don’t see the point. With the exception of pub/sub, which should be added to IS directly, Broker adds next to nothing to the mix. IMO, if you want an MQ facility to connect your IS boxes, use a JMS provider. You can use Broker for this but it’s a little spendy in comparison with the solid JMS-based servers that are available.

Of course this is just my opinion. I could be wrong.

3

I’ll add Business Problem or Context as another criteria. What is it that you are integrating?

If it is high level information such as PurchaseOrders that are produced by one system for the consumption of one or more other systems, then the IS is probably the more appropriate tool. What I am really trying to define is an integration with few types of information, relatively speaking few number of documents, and often single producers of documents with single consumers of documents.

If you are talking about integrating two or more systems internally in near realtime and in order to keep the systems in synch you need to exchange many different types of information of much smaller granularity with a much greater volume, then the Enterprise Server is more appropriate.

The only reason I think (note: CONJECTURE) the Enterprise Server might go away is if webMethods decides to get out of the Enterprise Application Integration at a systems level in favor of Enterprise Application Integration at a business level.

4

Can someone guide me to the documentation on fault tolerance (clustering and failover) feature of enterprise server.