Three approaches to avoiding the spider web

One of the primary advantages of using an intermediary is defeating the n(n-1) integration problem.

Leveraging the intermediary involves one of three approaches.

The first way is classic SOA and involves a modeling stage before any development moves forward. In this approach architects model the canonical representation of entities that represent their business. So Customer, Sale etc. are created and the web services exposed are those entities. This is a great approach if you have the time and if you have a strong architecture team. I rarely see it used in practice however because most organizations will not commit the SME resources necessary to produce the entitities and many SOA "architects" talk about contract first and then proceed to create point to point web services based on exposing aggregations to current back end systems. Proper SOA modeling is about modeling the business not the systems of the moment.

The second method is to think more in terms of leveraging a flexible intermediary designed for change. In this approach there is a defacto acceptance that services will constantly be changing and that spending a lot of time on entity modeling won't be done. The easiest way to accomplish this is to stand up a typeless endpoint or "OnRamp" combined with a flexible routing, transformation,and aggregation framework. This model will not give the stability benefits of canonical modeling but it will accomodate evolving interfaces driven by either the consumer or producer.

The third involves the best of both worlds. Model the entities then expose them via a single endpoint and binding. Location transparency, binding consolidation and all of the SOA goodness all in one shot...

The good news for Neuron users is Neuron can be used for all of these. Want to stand up an endpoint for each entity Neuron can do that.(Neuron doesn't produce WSDL for those endpoints but as a dedicated and serious SOA architect you would never depend on WSDL that had to be generated by an active endpoint and couldn't be sent out of band would you?) Want an OnRamp? Neuron can do that..And of course since Neuron supports both building blocks you can support the third.