What you need to make middle out SOA architecture work
In middle-out SOA, we want to do as little as possible from the "center." The real value is at the edge, where the services are being created and where value actually lies.
Our goal, in middle out architecture, is to set up standards, mechanisms, and protocols that everyone will follow. We will give names to services that need to be created, and we will describe a small set of standard message exchange patterns, complete with the names to be used at the endpoint. Where possible, we will specify transport mechanisms as well.
Important: in Middle Out SOA, the central group writes NO code.
Let me give you an example. In the metropolitan area around Seattle, there are quite a few suburban cities. East of Seattle, across Lake Washington, is the city of Bellevue. Next to it are the cities of Redmond and Kirkland. These cities each began from their own centerpoint and grew outward until they collided in the same area. The Microsoft campus is on a 'spur' of Redmond that is surrounded almost entirely with the city of Bellevue.
If you look at the map, you will see that there are PLENTY of roads that are either borders between the cities or cross from one city to the other. As a driver who drives in this area, I can tell you that the roads have the same name on both sides of the city lines. Normally, you do not know which side of the line you are on, or where the transition happened.
Why is it so seamless? It is not overtly controlled. The cities are quite distinct from one another. Rememer, they grew from their own centers out. So why is it, when they intersected, the arterials lined up and the names are standard and the roads don't change width or designation?
It is because the planning departments in these cities all work together on standards. There is a standard numbering scheme for the entire of King county (5,974 square km) that allows all streets, even ones in rural areas, to have names and numbers that don't change from city to city. The roads have a standard width, and roads of a particular arterial classification have standards for sidewalks and traffic lights. I can find a business by its address, regardless of what side of the street that business is located on.
My car is a data packet that travels over these roads, and I have the routing mechanism in my brain, deciding the route and alternatives as needed to find my destination address. It works because those roads and addresses are consistent and integrated.
The coordination between the two cities is practical and useful. Each city has an ordinance requiring its planning department to cooperate with other cities. That is important. The ordinance is a fixed decision, made by their governing bodies, that gives their planning boards support and direction. Without the ordinance requiring cooperation, passed by each city, the roads would not work.
This is the fundamental idea behind middle-out architecture. Know the MINIMUM set of standards that everyone has to agree on, and get the management to buy in to requiring that minimum amount of cooperation. Then cooperate. Each area is responsible for their own governance.
It is an inherently distributed mechanism, and therefore scales well. Note that the minimum set useful in an enterprise is larger than the minimum set useful across the internet as a whole (at this time). Mashups and SaaS services will not have a consistent mechanism for sharing data... at least not until customers demand it. On the other hand, in an organization, consistency at the data level makes more sense and therefore a common event and schema model can be expected and used.
Middle out is not new. It is a way of describing what works in other areas. It is only new to SOA because SOA is new to IT. We are still learning what other folks already have learned. We are still catching up.
