|
[[Image:Service Layers Image A.JPG|thumb|alt=Diagram A|Diagram A<br/>In the absence of any layers, services contain a mixture of different types of logic. This makes it difficult to manage these services.]]
[[Image:Service Layers Image B.JPG|thumb|alt=Diagram B|Diagram B<br/>A service inventory divided into layers where each layer contains the same type of logic.]]
Applying this pattern requires creating a service inventory blueprint,<ref name='serviceinventoryblueprint'>
In order to apply this pattern, first it needs to be established which different types of layers are required. This requires creating a service inventory blueprint<ref name='serviceinventoryblueprint'>[http://www.soamethodology.com/p2.php service inventory blueprint]</ref>: a pool of services consisting of candidate services containing candidate functionality. By creating such an inventory, enough information is available to find out the different types of functionality within the intended service inventory. Based on this information, the required types of layers can be established. On the other hand, by applying this pattern at this stage within the service delivery process, the design of the service can be modified so that it contains the relevant type of logic as dictated by the type of the service layer under which this particular service falls.
[http://www.soamethodology.com/p2.php service inventory blueprint]</ref> a list of services with associated functionality. Next, group the services into layers according to function. Adopting a common layering strategy across the enterprise facilitates reuse in other applications, because developers don't have as much to learn (or invent) when they join a project.<ref name='service models'>[http://www.soamethodology.com/p5.php service models]</ref> One common layering uses task,<ref name='task'>[http://www.soamethodology.com/p7.php Task Service]</ref> [[Entity Abstraction Pattern|entity]] <ref name='entity'>[http://www.soamethodology.com/p6.php Entity Service]</ref> and [[Utility Abstraction Pattern|utility]] <ref name='utility'>[http://www.soamethodology.com/p8.php Utility Service]</ref> layers.<ref name='ProcessAbstraction'>
<br/>
[http://www.soapatterns.org/process_abstraction.php Process Abstraction]</ref><ref name='WK'>
Although service grouping can be performed based different types of functionalities, however, to keep the grouping standardized across the enterprise, the actual groups can be based on established service models<ref name='service models'>[http://www.soamethodology.com/p5.php service models]</ref> that depict the most common types of logic that services would normally contain. Depending upon the particular area of the business, a service inventory would usually be divided into task<ref name='task'>[http://www.soamethodology.com/p7.php Task Service]</ref>, entity<ref name='entity'>[http://www.soamethodology.com/p6.php Entity Service]</ref> and utility<ref name='utility'>[http://www.soamethodology.com/p8.php Utility Service]</ref> services. Each of these different types of service models bear specific characteristics that would be eventually demonstrated by the services that belong to the layer, which is based on a particular service model. To design a service based on the aforementioned service models the Process Abstraction<ref name='ProcessAbstraction'>[http://www.soapatterns.org/process_abstraction.php Process Abstraction]</ref>, the [[Entity Abstraction Pattern|Entity Abstraction]] and the [[Utility Abstraction Pattern|Utility Abstraction]] design patterns can be applied as these design patterns help in structuring the solution logic of the services according to specific types<ref name='WK'>Wajid Khattak [http://www.informit.com/articles/article.aspx?p=1583177 Service Layers][Online].Date accessed: 21 April 2010.</ref>.The aforementioned service types are by no means concrete and an SOA could be categorized into a different set of service layers depending upon which characteristics constitute a particular layer, for example, as argued by Bieberstein et al.<ref>Bieberstein. et al.[http://books.google.com/books?id=NISyExeJ5mAC&pg=PA88&dq=%22service+layer%22&lr=&hl=sv#PPA87,M1 Service-oriented Architecture Compass: Business Value, Planning, and Enterprise Roadmap].FT Press, 2005. ISBN 0-13-187002-5, 9780131870024</ref>, an SOA could be divided in to five different layers, namely Enterprise, Process, Service, Component and Object layers.
Wajid Khattak [http://www.informit.com/articles/article.aspx?p=1583177 Service Layers][Online].Date accessed: 21 April 2010.</ref>.
An alternative layering from Bieberstein et al.<ref>Bieberstein. et al.[http://books.google.com/books?id=NISyExeJ5mAC&pg=PA88&dq=%22service+layer%22&lr=&hl=sv#PPA87,M1 Service-oriented Architecture Compass: Business Value, Planning, and Enterprise Roadmap].FT Press, 2005. ISBN 0-13-187002-5, 9780131870024</ref>, involves five layers, namely Enterprise, Process, Service, Component and Object.
The application of the Service Layers pattern would necessitate a change in the architecture of the service and the overall architecture of the service inventory<ref name="SvcArch">[[Service-Oriented Architecture Types|SOA Types]]</ref>.
The Service Layers pattern invokes a specific [[Service-Oriented Architecture Types|service architecture]].
==Considerations==
| 