The two worlds of SOA

Nick Malik posted a reaction on the idea that entity services are anti-patterns. I agree with his conclusion that it depends on where you stand.

Looking from the business side, there is the composition of business activities into autonomous business functions. These functions offer services to each other and communicate - preferably - events based to obtain their autonomy. Such a business service could easily be outsourced without any disruption of the overall business process. Such a business service can also easily be delivered (shared) to different business contexts (internal or external). I call this the Service Oriented Enterprise. This has nothing to do with IT.

On the other hand there is the composition of application constructs. The top level of such a construct preferably maps with an autonomous business function. Current standards based technologies make it possible for IT to support events based interaction between the autonomous business functions, which in turn boosts the Service Oriented Enterprise.

The idea (or pattern, if you like) of autonomous business functions can be prolongated into the finer grained application constructs which may e.g. lead to autonomous entity services or deeper layers of granularity.

See also:

• How EDA extends SOA and why it is important

• Granularity of Services

So: No, entity services are not an anti-pattern.

Business doesn't ask for SOA

Testimony from practice: Up till now, at this very moment in time, I didn't meet one single business manager who begged me to please deliver him an SOA-based solution. They are running after deadlines and project-cost reductions, but not after SOA. They are even cynical about SOA as being yet another promise after all those previous ones. Of course all those previous promises were a step ahead, just as SOA is. And I believe SOA is a big step ahead. But our business people don't want SOA's, they want flexible and cheap solutions. And they want I.T. not to be a big hurdle when they change the way they happen to do things. But they definitely did not ask me for an SOA.

And another testimony from practice: Developers - in general - don't get the clue of SOA. The marketeers of most software companies evangelize their ability to build service oriented systems. But the people who really have to deal with the details are not educated to get a grip on the practical use of the principles of autonomous business functions, loose coupling and asynchronous design. They are trained to use the modelling tools of Websphere, Sonic and Tibco, but SOA is not their mind-set. It's the individual passionated nerds we have to rely on, not the average developer or designer.

But fortunately I can also testify about curious development teams that are slowly adopting the new wave. Development teams that operate very close to the business in a very rapidly ever changing commercial context. These are the people I enjoy working with.

And another good sign is that the builders of packaged software - like SAP - not only evangelize SOA, but are really spending big efforts to service enable their legacy. Also the SOA initiatives of SaaS-providers like SalesForce are a great boost.

All together I believe it will take at least another 10 years or so before SOA becomes mainstream and common sense to all of us. And keep in mind that we are not hired to deliver SOA's to the business, but solutions. That's what they ask for.

Do we understand SOA?

I came across this posting of Galen Gruman, contributing editor at InfoWorld. He cites Roberto Medrano, executive vice president of SOA Software:

• "Maybe 20 percent of IT folks understand SOA and half of the rest think they do"

He might be right. Perhaps we currently understand that breaking down your business activity into a business component model of autonomous business functions is key to SOA. It is a lot less common thinking to loosely connect these autonomous business functions, events based. I tried to clarify this aspect in SOA Magazine.

And then there is the widely spread misuse of some core terminology. "Experts" tend to speak of "reusable" services. But what they mean is "shareable" services, which is quite a different thing. It makes sense to focus on shareable messages and not only on shareable services. Did you ever hear somebody talk about "shareable messages", typically representing business events? I didn't, while the use of shareable messages really is the key to success. It's shared messages that make the innovation, not shared services.

And what about the idea of loose coupling related to SOA? I quote: "Shared services are disruptive, increasing dependencies and raising questions about what it means to own a service and who should own it." From a lower level IT-perspective this is such a very truth! However it doesn't seem to bother most of our "experts". Not to mention how and why exactly to "share" a service, if a service equates to a properly designed autonomous business function.

How to implement loosely coupled transaction processing

This pattern describes how to accomplish transaction processing within the context of autonomous services. The pattern is based on the idea that - by design - every action has a compensating action to undo the original action.

The autonomous services fulfill action requests from the transaction controller (see "1" in figure). If one or more services reply not to have been able to fulfill the request (see "2" in figure, fault feedback) then the transaction controller will send requests for compensating actions to the services that did fulfill the original requests (see "3" in figure).

The concerning services do not distinguish between a normal action and a compensating action. To the services compensating actions are normal actions like any other. The services are not even aware of being part of a transaction.

Examples

• A service is designed to make, change and cancel reservations for hotel rooms. These are three equivalent types of actions. In the context of compensating actions, a cancellation can be considered a compensation for making a reservation. This compensating action results in undoing the original make reservation action.
  

• A service is designed to increase or decrease the balance of an account. These are two equivalent actions. Both can be seen however as compensating actions for each other (mutual com-pensating actions). An action that increases the balance with 100 euros can be compensated with an action the decreases the balance with 10 euros.

It need not only be fault feedbacks that lead to compensation. The transaction controller may make use of a timer to detect if an acknowledgement has been received within a preset time-frame. If one of the services doesn’t respond with this preset time-frame, requests for compensating actions will be sent to the other services. If a service sends the acknowledgement after the preset time elapsed and compensation action requests have been sent to the other services, this late service will be sent a compensating action request as well. Or one might choose to resend the original action requests to the other services if that is appropriate.

Design considerations

The designer of the transaction system must for every action always design a compensating action. This is not trivial. Consider the second of the above mentioned examples. Suppose the service was not developed to increase or decrease an amount, but to replace the old amount with a new one. Compensation would then not be possible. If the action would replace the old amount with a new amount of 10 euros, this can not be reverted without endanger the integrity of the data. Not even if the transaction controller would be aware of the old amount (or if the old amount would have been returned to the transaction controller). Other amount changes (triggered by other sources) may have occurred after the replacement transaction has been executed. If afterwards a compensating action would replace the amount back to the original amount, the amount would be corrupted.

Why?

In situations where by nature the transaction processing cycle is long (minutes, hours, days, weeks, …) the described pattern of loosely coupled transaction processing allows for an adequate alternative to the well known two-phase-commit mechanism. Also in loosely coupled of decoupled environments (B2B) where minimal dependency (maximal autonomy) is pursued, this pattern offers a more appropriate solution then two-phase-commit.

Traditionally transaction systems use the two-phase-commit mechanism. All participating software components must support and adhere to this mechanism. All components reply whether or not they can honour the request of the transaction controller and - if so - retain the action until a commit- or rollback command has been received. A commit command is issued by the transaction controller as soon as all concerning components have replied that they made their preparations and are ready to commit. If one or more of the components deny the request, the transaction controller will send a roll-back command to the other components in order to allow them to release their retention state.

Because after a commit command the participating components must actual perform the action if they replied to be ready to commit, these components must - awaiting the commit - place locks on the data that is involved in the transaction. This puts a claim on the performance of the system. Such a mechanism is therefore only appropriate for (very) short running processes where a participating component can rely on the performance of the other participating components and on the performance of transaction controller.

If the processing time to complete the transaction takes relatively a long period of time, the inherent locking strategy of the two-phase-commit mechanism is not appropriate because it can hang the complete system. Also in loosely coupled of decoupled environments such as B2B the two-phase-commit mechanism puts undesirable dependencies on the environment and the proposed loosely coupled transaction processing will be more appropriate.

Rambling thoughts of an architect

Quoted from Martin Fowler:

Complexity

• Making something easy to change makes the overall system a little more complex, and making everything easy to change makes the entire system very complex. Complexity is what makes a system hard to change.

Limitations

• Software is not limited by physics, like buildings are. It is limited by imagination, by design, by organization. In short, it is limited by properties of people, not by properties of the world. “We have met the enemy, and he is us.”

Know any similar wisdoms? Please drop them here...