Entries from October 2009 ↓

Taking a leaf from the Agile playbook, a group of SOA thought leaders has put together the SOA Manifesto, a succinct list of SOA principles and preferences to guide Service Oriented Architecture. Great work!

(I could comment further, but it speaks for itself).

Go visit and find out.

My last post explored some distinguishing characteristics of three common architectural styles in an attempt to understand better how they differ and therefore how they may apply in different contexts. A fourth distinguishing characteristic of these architectural styles is the way in which state is managed during the execution of a business process.

There are three aspects of state that I want to consider:

• Management – how state change is initiated or managed through a business process.
• Monitoring – how state is monitored or accessed or derived during the execution of a business process.
• Consistency – how state is made consistent across different systems involved in a business process.

A summary of the state characteristics of the different architectural styles is listed in the following table along with the other characteristics discussed in my last post.

In EAI, state is managed within one application and then synchronised to other applications, usually after the business process has completed. This means that in some cases state may be inconsistent across the organisation or its systems. That may or may not be a problem (see ‘Eventually Consistent‘) but is a common side effect when a business process is executed within one system rather than across systems in an independent process layer. During the execution of an EAI process, there is often no monitoring of the state. I.e. the process may simply replicate data changes to other systems without explicily tracking state. A limited form of state monitoring may exist in the sense that the local application or associated middleware may check the status of data synchronization and error out in the event of an exception. I refer to this as ‘local’ state monitoring. So under the EAI architectural style, state is managed locally, monitored locally (if at all) and is eventually consistent.

Under SOA, the driver of a business process is BPM orchestration in an independent process layer. In this case, we can say that state is managed centrally (in the BPM layer) and monitored centrally (also in the BPM layer). State in end-systems is updated progressively through the business process (via service calls) and so we could say that state is ‘progressively’ consistent as opposed to ‘eventually’ consistent.

Under EDA, there is no central or even local management of state. Instead, events signify distributed actions which together may be used to infer the state of a system. To the extent that any ‘management’ occurs, we could say that state is managed in a distributed fashion – one or more agents each acting on their own. Perhaps  it is more accurate to say that state is manifested globally. Converesely, state is monitored centrally within an Event Processing (CEP) layer which correlates events to infer system state. Under EDA, state is progressively consistent because the system is progressively reacting to events which are a by-product of a hidden or implicit business process.

I’ve recently been thinking about simple ways to characterise the different architectural approaches we use in distributed systems today. Three simple architectural characteristics I have come up with are:

• Asset – this is a core capability or “thing” that must be built, procured, maintained and managed in a corporate IT “inventory”.
• Element – these are the “atomic” building blocks used in the process of Composition.
• Composition – this is the mechanism which allows the different assets to work together to support a business requirement.

If we apply these characteristics to three common architectural approaches then we get the results in the following table.

EAI, although  unfashionable is still prevalent – even dominant in the industry. For EAI, we are primarily concerned with applications (usually COTS) which embody and support the requirements of different parts of the business. Multiple applications must be coordinated to support the whole business. The primary coordination mechanism under EAI is synchronization of state between the different applications – primarily via data integration. The composition element is the API.

SOA is characterised by Services as the key asset. Services are acquired or built to execute business operations. Elemental Services are composed to support business processes – a sequence of operations which results in a business outcome. BPM (or process orchestration) is the composition mechanism within SOA. The underlying functionality of a Service may reside in one or more applications, but from an SOA perspective this is of secondary importance…SOA is concerned with the Service, not necessarily its implementation.

EDA (Event Driven Architecture) is characterised by Event Services as the key asset which represent an asynchronous notification of an important event associated with the business. Elemental Events are correlated and further processed to derive higher-order business intelligence which may in turn trigger other Events. The primary composition mechanism within EDA is Event Processing (or CEP). An important part of this composition mechanism is the ability to manage or track system state.

This characterization gives more clarity to the difference between JABOWS and true SOA. Many so-called SOA projects have simply involved the “bottom up” exposure of application APIs using web-services standards – resulting in “Just a Bunch of Web Services” which don’t realise the business value of a true SOA. JABOWS is EAI because the applications are the core “asset”. A true SOA has a “top down” process-centric architecture with Services as the core asset.

Tony Abbott says that he is unconvinced by the science behind climate change. I’m guessing that like most of our politicians, Mr Abbott has no science education beyond High School, so he is making this science value-judgement from a position of ignorance.

Most politicians would not provide financial advice, or medical advice, or advice on how to build a skyscraper because they know it is irresponsible and dangerous to voice an uneducated opinion on complex and technical matters. So why do politicians like Mr Abbott and Mr Fielding persist in taking a stance on climate science which is in direct opposition to the consensus of the world’s leading scientists?

What would convince Mr Abbott? Is he gathering new data on molecular resonances in the upper atmosphere? Is he running new oceanographic models on his parliamentary PC? No, Mr Abbott simply chooses to deny the problem because it absolves him from
taking any action. As a politician, Mr Abbott is not qualified to make value judgements on the science. The overwhelming,
peer-reviewed scientific consensus is that man-made climate change is a clear and present threat to the natural systems
that support humanity. As a politician, Mr Abbott should be working on policy and legislation to address the threat from
climate change.

If Mr Abbott doesn’t like the proposed Emissions Trading Scheme (ETS) then there are a number of valid politicial responses he can make. A valid political position might be that the proposed ETS is not the best way to control carbon emissions – but then he would need to come up with a better alternative. Another valid political position might be that the short term economic costs of the proposed ETS are too high – but then he would have to address the long-term economic costs of doing nothing. Simply denying the problem is not a valid political position.

Politicians should not be debating climate science – they have nothing new or valid to add. They should be taking immediate action to address the threat from climate change. We need effective policy and most of all we need leadership.

</rant>