The ‘Wire’ Is Global
Whether you are going to directly base your 'wire' design on the internet, or you are going to limit it to some particular set of users, you want to make sure that every 'wire' design you do, works globally. You have to get outside of the confines of the internet. The whole point is you do not control the technologies that your consumers or your providers are using. The only way to get eBusiness to integrate is to make sure that each 'wire' is, by definition, Global. And the truth is, for the most part, the only global communication stack that works today is the HTTP stack - modulo, email, FTP, etc. and a few others. So you need to be suspicious of folks who tell you that you could do an abstract design and somehow you can disconnect it from HTTP - specifically, like some people who say the SOAP Envelope is independent of the underlying protocol - don't believe it.

The ‘Wire’ Is Peer-to-Peer
A lot of conversations involve you being both a consumer and a provider. In a typical situation, when you are exchanging messages asynchronously, you are typically shipping messages to each other, and are sharing these messages through HTTP resources. In such a situation, the only thing that allows you to correlate these messages is the content in the messages themselves. You cannot rely on this shared data to be in the context of a session, or some kind of pseudo-conversational mode where you can send somebody a cookie as a systems-level cookie and somehow they return the shared state because you don't store systems-level cookies in the database so you can associate your response with that cookie.

The ‘Wire’ Is Asynchronous
The wire is asynchronous when you are dealing with it from an infrastructure integration level. When you are doing this asynchronous integration, the exchange of messages have to be correlated to the business functionality itself. The wire is more ad-hoc than conventional integration in the sense that the messages that you are exchanging are going across business process boundaries. Each side of the business process has its own objectives that it is trying to accomplish. The wire is a network resource. We are continuously evolving what we think of as a network resource. Technical elements are continuously being added  to what we think of as the wire. At the business integration layer, we are just beginning to learn what it actually takes to make these eBusiness compositions. We need to think of this composition mechanism as something  fundamentally different to code composition. What we do inside of our applications to create the stream of bits which is the network resource is secondary to what the actual resource is.

Difference between Web-site Interaction and eBusiness Integration
There is a core difference between website interaction and eBusiness Integration. If you force the people who are communicating with you to reply immediately, with a business response in the same Message Exchange Pattern (MEP), you are severely constricting how they use you. By separating the business response into a separate Message Exchange Pattern (MEP) interaction, you are freeing up both sides to interact asynchronously. That is the core issue of why eBusiness Integration is very much peer-to-peer rather than client/server. If you are kind of stuck in the client/server mode of thinking, it is very difficult to architect eBusiness Integration since client/server is not the model for eBusiness Integration. The core idea in eBusiness Integration is that businesses are off on their own, doing their thing, and they communicate only when they want to and on their own schedule.

Design Focus 

Message Exchange Patterns (MEPs) are transient message exchange elements. If there is work that can be accomplished in a single, one-shot, stateless, self-contained collaboration, use a single MEP. For long-running, conversational, peer-to-peer collaborations, where there is an asynchronous lag between a request and a response with shared state use multiple MEPs with correlations.

You cannot have an asynchronous collaboration without having peer-to-peer message exchanges.

Related Blog Entries: 

• JBI/SOA Tips: Message Exchange Patterns (MEPs) are the units of 'wire' collaboration
• JBI/SOA Tips: Use Separate MEPs for Business Responses
• JBI/SOA Tips: What is a Conversation in a collaboration wire-design
• JBI/SOA Tips: Identify Shared Conversational State Upfront
• JBI/SOA Tips: Use Correlation Values to Reference Shared State

Like this write-up? Subscribe to receive more like it.