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.
My son, like the rest of kids his age, as well as many others is spending every waking hour reading the
I agree completely. However, your analogy sparked a side thought which may be worth consideration. If your car is a data packet, you, the driver, are a process. The function of the process is to deliver the data packet to its intended destination. While the departments of the cities create standards, intended to grease the wheels of the enterprise, some cities (like the ones around the Hampton Roads area in Virginia, where I live) have ancient roots, and structure that existed prior to the emergence of these standards. In addition, because humans are involved in the implementation of the standards, there may be improper or incomplete implementations at various points. In other words, no standard is a complete solution to a problem, but only approaches the solution.
On the other hand, it is the responsibility of the driver (process) to deliver the car (data packet) to its destination. This requires a certain amount of independence and creativity on the part of the driver, a measure of intelligence. While the ultimate goal is to keep this requirement to a mimimum, because that goal can only be approached, processes in an enterprise should be designed to be able to deal with these exigencies, balancing that against the goal of making them light-weight.
Sometimes a seamless transition is not what you want.
Here in the Northeast you often have roads with the names of the cities to which they lead. For example in Canton, MA the road to Randolph MA is Canton Street. When you cross into Randolph the same road becomes Canton Street.
Here the numbers often change when you change cities.
Do you consider this a legacy system, or a more decentralized, flexible system that allows for local optimization?
@Michael,
I love the Northeast. My mother and brother live in Providence and my oldest brother lives in Boston. Lots of history.
I think the example you give is a problem in that the streets are designed to allow very local folks navigate. In other words, if you live in Canton and you want to go to Randolph, then naming the road Randolph road is great. But if you don’t live in either city but need to move between them, or find an address near the boundary, then it is not a good idea.
Clearly, the idea is one of local optimization. In my opinion, if there is very little need for out-of-towners to find their way, then there is little need to make addresses work well. Local optimization is fine if that’s all you have to optimize for.
If anything, your example is simply complementary to mine. That said, when the road does cross city boundaries, does it suddenly change from paved to unpaved?
Does the road suddenly change from being 21 feet wide to 28 feet wide? Do roads dead-end when they reach city limits? I’ve certainly seen examples of all of these, and I fail to see them as a good thing.
" SOA is not something you buy. SOA is an architectural approach, not a product. Anyone saying anything
" SOA is not something you buy. SOA is an architectural approach, not a product. Anyone saying anything
" SOA is not something you buy. SOA is an architectural approach, not a product. Anyone saying anything
" SOA is not something you buy. SOA is an architectural approach, not a product. Anyone saying anything
So, I am totally thrilled in my new role at Neudesic , where today, I got to spend quite a bit of time
Nick
Most of the time the road stays the same size. Sometimes, however, the road on one side of the border is well plowed in snow, and the other side is not. 🙂 Some services are a lot more responsive than others. 🙂
Seriously, there is one road at the Brookline-Boston border where they put up a road block to prevent kids from using the road for racing. The barrier was large enough to prevent racing, but small enough to let the fire trucks manuover around it. The locals on the Brookline side of the border thought it was a good thing.
The analogy with SOA is here you are crossing a trust domain. When you cross a trust domain, some times things are made difficult on purpose.
This is 9th of a series. I haven’t really received much feedback. Please let me know if this is
This is 9th of a series. I haven’t really received much feedback. Please let me know if this is
This is 9th of a series. I haven’t really received much feedback. Please let me know if this is
This is 9th of a series. I haven’t really received much feedback. Please let me know if this is useful, if posts too long, too abstract, your thoughts. Symptoms of a Problem, Diagnosis and Why SOA? Dynamic IT to Support the Agile Business and Business
So, I am totally thrilled in my new role at Neudesic , where today, I got to spend quite a bit of time with one of our Distinquished Engineer, David Pallmann , the architect of our Neuron ESB . We’re doing a lot of thinking and doing with SOA at Neudesic.
My son, like the rest of kids his age, as well as many others is spending every waking hour reading the latest Potter book. Ruby/IronRuby/CLR/DLR Great news from John Lam of the first public drop of the IronRuby source code . IronRuby is licensed under
This is 9th of a series. I haven’t really received much feedback. Please let me know if this is useful, if posts too long, too abstract, your thoughts. Symptoms of a Problem, Diagnosis and Why SOA? Dynamic IT to Support the Agile Business and Business