One of the ideas that has been floating around the integration community is Why can't integration be more like networking?

I am a bit more on the fence on that aspect; one can't help but wonder
whether you should be using Web services in the first place if your
performance requirements force to use a fixed binary format. Edwin got
to be up on stage with Thomas Kurian and demo'd the Collaxa tools turned
Oracle BPEL Process Manager.

Unfortunately, most visual representations these days are linked to the
term modeling as in model-driven architecture.

Particularly in loosely coupled, asynchronous systems it can be very
difficult for the developers to maintain a "big picture" view of what is
going on in the system.

Unfortunately, this is where things get complicated. Depending on the
implementation the requestor could even use the Message ID value to set
the Correlation ID field. Scott Dietzen from BEA demo'd the latest
process designer additions to WL WorkShop under the Liquid Computing
banner. The fact that the forecast reaches out this far into the future
might give us a hint that this market is still early in the life cycle.
This seems to solve out correlation dilemma quite nicely.

Unfortunately, for users of Web services things seem to get more and
more confusing and the WS-I profile seems to lag more and more behind
the reality.

We can use each of these layers to move data between the application and
the integration backbone.

I hope patterns can help us do this.

However, not all queues a component interacts with are known up front.
Because integration is such a broad and varied field, there are
definitely additional ways to categorize solutions, for example by the
topology, such as Message Bus, or Hub-and-Spoke.

Interaction MechanicsSo far we have identified ways to categorize the
overall intent of building an integration solution and the mechanics of
connecting to a single application.

One of the issues at the core of asynchronous messaging is for example
the lack of a call stack, so the developer is responsible for keeping
track what needs to happen next once a method completes. A simple binary
format can cut the message volume and parsing effort quite a bit.