I’m a little confused: what is the basic difference between Integration Server and Enterprise Integration ?
What reasons could be valid to deploy Enterprise within an existing environment with multiple Integration Servers ?
Thanks in advance for all replies.
with kind regards,
Paul
Paul, this is the question that I hear most often and the one for which there is no best answer.
First, let’s tackle the functional difference between Integration Server and Enterprise Server. IS employs the Request-Reply model and ES is Publish-Subscribe. In simple terms, the Integration Server is best served to handle 1-to-1 relationships for DOCUMENTS and the Enterprise Server is best served to handle 1-to-Many relationships for DOCUMENTS.
Why do I put DOCUMENTS in ALL CAPS? Because the relationship in a business integration is not defined by the applications and databases involved but instead the DOCUMENTS that define a transaction. Re-read that statement if you think it didn’t sink in.
Now, you say that you already have multiple instances of the Integration Server deployed. One could assume that you are, therefore, comfortable and familiar building integrations using the tool. Enterprise Server is a different animal. IS uses a language called “Flow” for development; ES uses “Component Script”. webMethods does not provide Built-In Services for Component Script like it does for Flow. This means that much of your code for Enterprise Server must be written by hand relative to using the Integration Server.
That said, webMethods will be releasing a unified product in Q3 2002. The unified 6.0 release will represent a fundamental change in Platform Architecture and will not employ Component Script. If this is a surprise to you, I suggest you review the webMethods User Conference 2002 Recap which discusses a lot of the changes and has a helpful architecture diagram.
Back to your question: At first look, most integrations demonstrate the 1-to-1 relationship discussed above. The impulse, therefore, is to use Integration Server. BUT! Look ahead 2-3 months. Look ahead 2-3 years. Is the document exchanged by the applications relevant in another part of your business? Will there be a need to use the data in this document for some other purpose? If so, deploying Enterprise Server may be advantageous.
For example, if TODAY your Purchasing Department is sending a SAP IDOC to your Billing Department’s Mainframe MQ Series channels, you would deploy Integration Server with the SAP Adapter (for Purchasing) and the MQ Adapter (for Billing). When your Logistics Department wants the same data from the SAP IDOC, you will need to define another relationship whereby your SAP IDOC is mapped to your Logistic Department’s Oracle Database. This means that your Purchasing Department will need to perform two transactions – one for Billing and one for Logistics.
Using Enterprise Server, the Purchasing Department publishes its data once; Billing and Logistics are registered subscribers of this data and both receive the published document’s data.
Again, I refer you to the webMethods User Conference 2002 Recap which may help clarify some of the points made above.
The short answer is that there is no one best option. Working within your budget and minimizing your business exposures is the only universal answer here.
I am sure that others will chime in with their two cents. You’ll see that their are varying opinions and numerous suggestions of Best Practices. None of us know your business or your architecture, though. You need to make the decision that best suits your Business Integration strategy within the framework of your network topology.
IS is meant to be the communication layer to perform custom mapping from and to partners. It is responsible of the delivery of the document, the security, protocols and more…
EI is meant to distribute the same message accross multiple systems, inside the firewall. IS has mecanisism to persist transaction management across multiple systems. It is use to publish data and subscribe to data. It is the main message hub of the enterprise. There is no web protocol inside EI (unless you use java classes) and does not provide security to deal with the
internet.
IS is more a point to point delivery mecanism and is more limited as far as transaction management, available adaptors, granularity etc…
Hope that help a little bit.
This is the $43 dollar question. I’ve been struggling with this myself but I think I’ve reached a conclusion. I guess I’ll start with the basics from my narrow little point of view.
Caveat: Forward looking statements are MY OWN ASSUMPTIONS. These are based on what I’m seeing with product announcements and positioning. I suspect wM folks may disagree with some of the things I say below. Although it is exceedingly rare, I have been wrong before. 
ES is a message broker. It’s job is to accept messages (often referred to as events and most recently referred to as “documents” by wM) from clients and give them to other clients. Which client it decides to give a message to is normally done via subscription–e.g. a client registers an interest in a certain message type, and whenever the broker gets a message of that type from any other client, it passes it to the subscribers. However, clients can direct messages to specific clients as well, so one can do point-to-point messaging if desired.
With ES, clients can do pub/sub, request/reply, and direct deliver. Fundamentally speaking, message brokers are “stupid.” The only thing they do is move messages around. They provide guaranteed message delivery (holding messages for adapters/clients until they connect again), message filtering based on content, message ordering, and that’s about it. All the real hard work is done by the adapters/clients and the APIs.
Contrary to popular belief, ES can happily work across the 'net. All that is needed is TCP/IP socket connection. For security, it supports SSL between brokers and between a broker and its adapters/clients. True, it doesn’t use HTTP or FTP, but IMO this is really immaterial to whether or not ES can communicate over the 'net–it can.
ES has generally been much better than IS for interacting with databases, but this will change. This is due to the rich set of adapters that ES has. With the unifying of the platforms, IS will now have access to the same cool stuff.
IS can be viewed as a “lightweight” document broker. Generally speaking, it moves a document from point A to point B, with the specifics of the moving/translating being defined by scripts. It doesn’t offer the same subscription ability (yet) that ES has. It doesn’t keep documents in a queue to be delivered to adapters/clients later, though the guaranteed delivery facility and Trading Networks address this issue to some degree.
Though IS is generally deployed to connect to external entities, it can be used quite effectively internally as well. It excels at handling XML (ES and its adapters are rather dismal wrt XML) and supports all the neato 'net protocols. As we all know, these protocols are useful insided the firewall too. The lines between “EAI” and “B2B” have blurred–so much so that now “EAI” is beginning to be used as a term for any type of integration, regardless of “inside” or “outside”.
It is possible to put a pub/sub framework into IS (did it with TN at a client site). Presumably, with the unification of the platforms, what is known now as IS will get the ability to do pub/sub on its own. Even without it, it can be done using your favorite messaging/queuing facility, which many people already do.
Regarding the ability to distribute a single document to multiple destinations, with multiple formats, that’s doable in IS now as well. The key here is to follow this principle: Do not create point-to-point exchanges. When a system “publishes” a document, convert it to a “canonical” format. That is, a format that is system independent. It is this document that gets routed around. At the target side, the canonical can be converted, if needed, to the format required by the t
First of all, thanks very much for all replies. Things are starting to get much clearer to me.
The latest rumour I heard was that Integration Server and Enterprise Integration will be merged into a single product.
Can anyone confirm or deny this rumour ?
Thanks again for all your time.
Paul
Hi, Paul. It’s not a rumor; it’s absolutely true. The short explanation is that webMethods Integration Server and webMethods Enterprise Broker are being unified as one platform.
For more detailed explanations, visit these URLs:
And, of course, you could re-read some of the notes made above in this thread.
If you have specific questions, be sure to ask them.
(Message edited by admin on June 30, 2003)
I am fairly new to webMethods products and may be tempting fate by making a comment. To be honest I am only looking for reactions to this comment to assist me in positioning the two products correctly.
My experience to date leans me heavily toward IS, the only justifiable reason for intrdoucing ES (or EB or EI or whatever) has been to make use of it’s ability to deploy an adapter on a remote server without implementing the entire wm solution.
Is this a fair comment ? Or am I overlooking something in IS ? Or mis/abusing ES’s capabilities ?
Great discussion, and I have to throw in my 2 cents.
Greatest difference IS - Synchronous and ES - Asynchronous.
This means that all the systems that IS is interacting with must be up and available when the document comes in. If anything is wrong then the entire process for the document fails. Even network slowdowns can cause the processing for your next 500 documents to fail. The guaranteed delivery and Trading Networks apparently helps avoid making a complete mess out of this scenario.
For ES the documents once they are initially processed by an adapter are sent to the broker that keeps them in a queue for any interested subscribers. This makes the ES a single point of failure and if the documents can’t be sent to the broker then we have the same problem IS has when anyone of the systems have problems. The advantage is that a solution for high availability and failover only has to be implemented for the ES and not for all the systems in your enterprise in order for your integration to be stable.
IS makes use of text based xml documents. This makes them easy to understand. XML is an open standard and a lot of tools can be used for them. XML makes it possible for the B2B implementations of different enterprises to be different. All they have to agree on is the XML format to use for exchanging information. The greatest drawback to XML is that it is a very inefficient format when it comes to size and processing. This is partly the reason why EDI was so incomrehensible, making it more efficient from a size perspective.
ES makes use of a proprietary format for communication. The documents exchanged are much smaller and can be processed much faster by the broker. This proprietary format would force two enterprises to use the same product, ES, if one of them wants to use ES across the internet using tcp/ip. For integration between large enterprise systems where a lot of information has to be exchanged to maintain synchronized information a lot of communication has to take place. The IS would never be able to handle the volume.
It comes down to what the products are used for. If you are only dealing with high-level documents that you receive from your partners, then you most likely would do just fine with IS. If you need to synchronize multiple (>2) enterprise systems where information should be shared between them and there is a lot of information that has to be kept in synch, then ES is probably the only way to go.
If you don’t think that was 2 cents worth, then please send the change to John Noggo0d, 555 Givememoney Drive, LA 90210 
Rgs,
Andreas
I have webMethods 4.6 installed on my machine?I want to create and use canonicals.How do i start with it.
Hi Vinay,
Looks like Systime is setting up a webMethods team…Another query came from your colleague Shalini…Anyway…welcome to webMethods community…
To your query, what canonical are you mentioning? Are you talking about canonical XML messages?
Hi JJ,
thanx for replying.We r just doing some R&D.Actually we have installed wm6.0 now and we have absolutely no idea how to create an integration thru it.it uses a wm developer for creating integrations.If u could send me some steps for doing a simple integration like reading data from an xml file to a database,it would be very helpful.
thanx.
Perhaps the tutorials and other wM docs would be helpful in this regard?