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