Service Oriented Architectural Layers
I mentioned in an earlier blog that I’d talk about SO layers at some point. Well, given that they featured in my presentation the other day I guess that now is as good a time as any to do so.
SOA as I've said previously is more than just a distributed technology; it is a decentralised technology and as such services can be created at any time and at any place within your enterprise, without necessarily a clear indication as to what purpose they may ultimately serve. It would appear that through this process of 'accidental devolution' one could see the proliferation of services that if left unchecked would undoubtedly lead to some level of SO Anarchy.
The key is obviously good governance, something we may preach in the enterprise, but far too often do not practice in full. Ok, but how does this relate to SO Layers? Well here goes:
SO Layers are conceptual layers or perhaps more correctly categories of services into which one can notionally allocate each service. It is important to note that these layers do not constrain service communication or location as in the case of the layers within an n-tiered architectural model. A service at one layer may interact with any other service layer for what ever reason; 'all services are equal'. SO Layers represent groupings of functionally compatible types of service and therefore tend to reflect different levels of abstraction or business orientation. This is with the notable exception of enterprise services as will be discussed below.
Principal SO Layers, at increasing levels of abstraction, or business orientation
Entity Services represent simple atomic operations on an entity such as the representation of a customer for example.
Activity Services coordinate several entity services to enable some business function execution (UpdateCustomer, AcceptPO). They implement common business transactions.
Process services represent long running business processes that may involve complex workflow and human interaction (using BizTalk for example)
Infrastructure Services provide common functionality to other services. They represent horizontal common services across organisations. Examples include Authentication, Authorization, Logging, Exception management etc.
Event Services notify subscribers of interesting events triggered. This may include the use of publish/subscribe mechanisms incorporated in most queuing technology.
Enterprise Services represent enterprise wide or public B2B services. As stated earlier these differ to the other service layers as they represent the natural end points in an Enterprise SOA and as such will generally only consume other inter-enterprise services rather than being consumed internally themselves. This is not mandatory, but will affect how the service is managed in terms of governance and policy.
The benefit of categorising and cataloguing our services in such a way is clear. As with enterprise frameworks such as Zachman, SO layering will organise the enterprise’s service assets, will promote reuse and enable good governance. The mechanism is supportive of organic local growth of services, but enables them to be managed centrally. As such, a core integration architecture team can develop the expertise necessary to manage the growth and proliferation of an enterprise’s service evolution.
I would guess that the realisation of this into an active dynamic searchable repository would be the next step leveraging the features of UDDI most probably. Personally, I haven’t done enough research into this yet, but am looking forward to the Enterprise Architect Conference (London 14-15th June) and a chance to talk to the guys at Popkin about it (what a name – I always think of a certain childhood show when I say it!).
