Service layer pattern: Difference between revisions

Revision as of 12:49, 7 May 2010

Revision as of 00:01, 16 May 2010

Line 3:

{{One source|date=April 2010}}

'''Service Layers''' is a [[Design_pattern_(computer_science)|design pattern]], applied within the [[service-orientation]] [[design paradigm]], which aims to organize the services<ref name='services'>[http://www.whatissoa.com/p11.php services]</ref>, within a service inventory<ref name='serviceinventory'>[http://www.whatissoa.com/p13.php service inventory]</ref>, into a set of logical layers. Services that are categorized into a particular layer share the same type of functionality. This helps to reduce the governance burden related to the service inventory, as the services belonging to the same layer only contain a particular type of solution logic and as a result are easy to maintain.

==Rationale==

As more and more services are added to a service inventory, the management of services within the service inventory gets difficult. In an unorganized service inventory, just by having a look at a service, it’s very hard to predict what kind of functionality is contained in it. This further makes it difficult to pickup the right type of service until all of its functions are reviewed. Similarly, a service can be designed in a manner that it contains both the reusable logic as well as the process-specific logic. When it comes to change the process-specific logic, this can inadvertently impact the reusable logic as well, which means that the reusability potential of such a service is reduced. Contrary to this, the [[Service Reusability Principle|Service Reusability]] design principle dictates that services should be designed in a manner so that they can be reused as much as possible. Similarly, the [[Service Composability Principle|Service Composability]] design principle advocate designing services in a manner so that they can be composed into multiple service compositions<ref name='servicecompositions'>[http://www.whatissoa.com/p12.php service compositions]</ref>. Both of these qualities are only possible if the service only contains a specific type of logic e.g. either reusable logic or process-specific logic.

<br/>

In order to design a service so that it contains a particular type of logic, different logical groups of services need to be established within a service inventory as advocated by the application of the Service Layers design pattern<ref name='SOAMag'>Thomas Erl.[http://soa.sys-con.com/node/645271?page=0,1 Introducing SOA Design Pattern][Online].Date accessed:6 April 2010.</ref>. Each group only contains a particular type of logic<ref name='WK' />, so by restricting the service to only contain a particular type of functionality, the design of the service remains rather straightforward and one can predict the type of functionality the service provides and its behavior by looking at which layer does it belong to e.g. services in a particular group may not be suitable for composition as compared to another group.