Content deleted Content added
→Usage: Added diagrams |
Removed the external links from article body |
||
Line 1:
{{New unreviewed article|source=ArticleWizard|date=March 2010}}
'''Service Layers''' is a [[Design_pattern_(computer_science)|design pattern]], applied within the [[service-orientation]] [[Design_paradigm|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==
<br/>
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. Each group only contains a particular type of logic, 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.
Line 15:
In order to apply this pattern, first it needs to be established which different types of layers are required. This requires creating a [http://www.soamethodology.com/p2.php service inventory blueprint]: 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.
<br/>
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]</ref>, entity<ref name='entity'>[http://www.soamethodology.com/p6.php entity]</ref> and utility<ref name='utility'>[http://www.soamethodology.com/p8.php utility]</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 [
<br/>
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>.
| |||