Speaking at this week's Microsoft TechEd
conference in Amsterdam, he compared the development of SOA infrastructures
to the growth of major cities. Another analogy used the development of
mass-market manufacturing processes to show how developers can see the
change in process flow that they need to work with if they are to build
successful service-based implementations.
This one in particular worked well at
outlining a fundamental difference for SOA-based environments, compared
to traditional computing. This is that services will be performing actions
across boundaries of trust - for example between different departments
or divisions of a single enterprise, or indeed between different enterprises.
This requires developers to be thinking in terms of how they manage the
transactions between services and, as Helland observed, one fairly common
proposal being made is to use the traditional 2-phase commit approach.
But his contention is that this can only operate within a trust relationship;
in other words inside a single department or operating unit, where one
service can get away with controlling the action of another. But in an
SOA, this simply cannot be allowed to work.
The answer, Helland feels, can be found
in guns. Well, to be fair, in the concept of interchangeability that first
developed in the world of arms manufacturing, many years ago. This is
where the `mature thinking' comes in, for it is based on the history of
manufacturing. Guns, like everything, were hand-made by individual craftsmen,
once upon a time. But this meant that parts from one gun could not be
used in any other - which was vital to keep weapons useable in a war situation
- as the components were only ever consistent with the others from the
same gun. They could not be interchanged. Achieving that marked one of
the fundamental turning points in the development of manufacturing. Early
machine tools started to appear but they were crude, and the final gun
often still needed to services of a `fitter', someone to tease the components
together.
Next came assembly line manufacturing
and the de-skilling of the craftsmen. Henry Ford is saddled with this
responsibility but, as Helland pointed out, it actually came from a firm
of meat packers, Hormel and Swift, in Chicago. This company came up with
the idea of a `disassembly' line, with slaughtered animals hanging from
a moving rail and the skilled butchery reduced to a number of individuals
making the same single cut on each carcass. The downside of this for Ford
was that its machine tools were fixed in purpose, which meant that the
design of the Model T car did not change for some 20 years. This problem
was finally solved by General Motors' flexible manufacturing approach,
based on machine tools that could be adapted and re-purposed, coupled
to multi-site manufacturing, with different factories making different
sub-systems, such as transmissions and suspensions. It was only here that
the `fitter' approach finally disappeared.
But it is, according to Helland, still
with us in IT and that is what the 2-phase commit represents. It blocks
Interchangeability and can actually lock up business processes so that
they do not work. For example, an order can be placed by an application
but, if rejected by the recipient application, then the relevant records
can get locked. What is needed instead, he suggests, is a tentative commit
process where a tentative process is initiated - an order placed for example
- and the first stage would be with rejection or tentative acceptance.
But final confirmation or rejection of the order would only come later.
To Helland, service to service operations
are business operations that do not share data. They work in an environment
of distrust between loosely coupled services that are autonomous in nature.
This means that no service can issue `orders' to another service but instead
must have to request an action or service that is solely based on business
logic. This is because an SOA has to work in the same way business does,
and he highlighted the tentative nature of booking a trip as an example
of this. If hotel rooms got booked (removing them from the available resources)
every time a customer enquiry was made, most hotel chains would go out
of business. All operations, therefore, have to be not only cancellable
but also `re-orderable'. And this is somewhat different from an UNDO operation.
Instead, Helland called it a `compensation'.
Summing up the difference between traditional
IT procedures and SOAs, he highlighted the fact that all the services
have to be able to deal with this level of uncertainty. So, where there
are `N' systems or services in an SOA infrastructure, developers must
accept their applications will be working in an environment where N-1
of them are operating in a state of uncertainty about what might be happening.
www.microsoft.com
