Service layer pattern: Difference between revisions
Content deleted Content added
clean up, typos fixed: et al → et al. (2) using AWB |
m Cleaned up using AutoEd |
||
| (30 intermediate revisions by 20 users not shown) | |||
| Line 1: | Line 1: | ||
{{Mergeto|Service layer|date=April 2010}} |
|||
{{Copyedit|date=April 2010}} |
|||
{{One source|date=April 2010}} |
{{One source|date=April 2010}} |
||
'''Service |
'''Service layer''' is an [[architectural pattern]], applied within the [[service-orientation]] [[design paradigm]], which aims to organize the services, within a service inventory, into a set of logical layers. Services that are categorized into a particular layer share functionality. This helps to reduce the conceptual overhead related to managing the service inventory, as the services belonging to the same layer address a smaller set of activities. |
||
==Rationale== |
==Rationale== |
||
Grouping services into functional layers reduces the impact of change. Most changes affect only the layer in which they're made, with few side-effects that impact other layers. This fundamentally simplifies service maintenance. |
|||
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 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/> |
|||
The [[Service Reusability Principle|service reusability]] principle dictates that services should be designed to maximize reuse. Similarly, the [[Service Composability Principle|service composability]] principle advocates designing services so that they can be composed in various ways. Both principles require that a service contain only a specific type of logic e.g., either reusable or process-specific logic.<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> Restricting each layer to a particular functionality, simplifies the design of the service. |
|||
==Usage== |
==Usage== |
||
[[ |
[[File: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.]] |
||
[[ |
[[File: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, 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. One common layering uses task, [[Entity Abstraction Pattern|entity]] and [[Utility Abstraction Pattern|utility]].<ref name='WK'> |
|||
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. |
|||
| ⚫ | |||
<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 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. |
|||
An alternative layering from Bieberstein et al.,<ref>Bieberstein. et al.[https://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}}, {{ISBN|978-0-13-187002-4}}</ref> involves five layers, namely enterprise, process, service, component and object. |
|||
The service layer pattern invokes a specific [[Service-oriented architecture types|service architecture]]. |
|||
The [[Top-down and bottom-up design|top-down]] service delivery approach facilitates the use of this pattern. |
|||
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>. |
|||
== |
== See also == |
||
* [[Service layer]] |
|||
The application of this design pattern depends upon having enough knowledge about the kind of services in a service inventory before they are actually developed. Consequently, a [[Top-down and bottom-up design|top-down]] service delivery approach<ref name="TopDown">[http://www.soamethodology.com/p9.php Top-Down Service Delivery Approach]</ref> needs to be adopted so that a pool of candidate services exists from which the need for different service layers can be established. This will increase the time and efforts required to actually deliver a set of usable services. Secondly, the confidence with which the need for different types of service layers can be established is directly proportional to the size of the service inventory. This means that as more and more services are added to the service inventory, the already established service layers may need to be modified in case new services do not fit into these existing service layers. |
|||
== References == |
== References == |
||
{{Reflist}} |
{{Reflist}} |
||
* {{cite book |author-link1=Thomas Erl |last1=Erl |first1=Thomas |year=2009 |title=SOA Design Patterns |publisher=[[Prentice Hall]] |isbn=978-0-13-613516-6}} |
|||
* Erl et al.,(2009).[http://www.amazon.com/gp/product/0136135161/ref=s9_simi_gw_p14_i1?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center-1&pf_rd_r=0FBSA23BKC0AXWVZ5Q9G&pf_rd_t=101&pf_rd_p=51471022&pf_rd_i=507846 SOA Design Patterns]. Prentice Hall. ISBN 0-13-613516-1. |
|||
* Mauro |
* {{cite conference |display-authors=1 |last1=Mauro |first1=Christian |last2=Leimeister |first2=Jan Marco |last3=Krcmar |first3=Helmut |year=2010 |title=Service Oriented Device Integration - An Analysis of SOA Design Patterns |department=HICSS 2010 |work=2010 43rd Hawaii International Conference on System Sciences |pages=1–10 |doi=10.1109/HICSS.2010.336 |isbn=978-1-4244-5509-6 |issn=1530-1605 |url=https://doi.ieeecomputersociety.org/10.1109/HICSS.2010.336 |accessdate=2020-07-26}} |
||
* {{cite web |last1=Seshadri |first1=Srikanth |date=2007-01-17 |df=dmy |url=https://www.infoworld.com/article/2077670/logically-soa.html |title=Logically SOA |work=[[JavaWorld]] |accessdate=2020-07-26}} |
|||
* Dave Oliver.[http://geekswithblogs.net/SabotsShell/archive/2006/07/11/84708.aspx SOA Logical Model][Online].Date accessed: 17 April 2010. |
|||
| ⚫ | |||
* Srikanth Seshadri.[http://www.javaworld.com/javaworld/jw-01-2007/jw-01-soa.html A logical architecture for SOA][Online].Date accessed: 17 April 2010. |
|||
* {{cite web |last1=Bieberstein |first1=Norbert |last2=Jones |first2=Keith |last3=Laird |first3=Robert G. |last4=Mitra |first4=Tilak |date=2008-07-17 |df=dmy |url=https://www.informit.com/articles/article.aspx?p=1194198 |title=Executing SOA: A Methodology for Service Modeling and Design |work=[[InformIT]] |accessdate=2020-07-26}} |
|||
| ⚫ | |||
* {{cite web |url=https://collaboration.opengroup.org/projects/soa-book/pages.php?action=show&ggid=1334 |title=High-Level Perspective of the SOA RA |work=SOA Source Book |publisher=[[The Open Group]] |accessdate=2020-07-26}} |
|||
* Bernhard Borges, Kerrie Holley and Ali Arsanjani.[http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1006206,00.html Service-oriented architecture][Online].Date accessed: 17 April 2010. |
|||
| ⚫ | |||
* The Open Group.[http://www.opengroup.org/projects/soa-book/page.tpl?ggid=1334 High-Level Perspective of the SOA Reference Architecture][Online].Date accessed: 17 April 2010. |
|||
== External links == |
== External links == |
||
* [https://web.archive.org/web/20201111163522/https://patterns.arcitura.com/soa-patterns SOA Design Patterns] |
|||
* [http://www.whatissoa.com/ SOA Concepts] |
|||
* [http://www.soaglossary.com/ SOA Terms Glossary] |
|||
* [http://www.soapatterns.org SOA Design Patterns] |
|||
[[Category:Service-oriented (business computing)]] |
[[Category:Service-oriented (business computing)]] |
||
Latest revision as of 05:04, 2 March 2023
 | This article relies largely or entirely on a single source. (April 2010) |
Service layer is an architectural pattern, applied within the service-orientation design paradigm, which aims to organize the services, within a service inventory, into a set of logical layers. Services that are categorized into a particular layer share functionality. This helps to reduce the conceptual overhead related to managing the service inventory, as the services belonging to the same layer address a smaller set of activities.
Rationale
[edit]Grouping services into functional layers reduces the impact of change. Most changes affect only the layer in which they're made, with few side-effects that impact other layers. This fundamentally simplifies service maintenance.
The service reusability principle dictates that services should be designed to maximize reuse. Similarly, the service composability principle advocates designing services so that they can be composed in various ways. Both principles require that a service contain only a specific type of logic e.g., either reusable or process-specific logic.[1] Restricting each layer to a particular functionality, simplifies the design of the service.
Usage
[edit]
In the absence of any layers, services contain a mixture of different types of logic. This makes it difficult to manage these services.
A service inventory divided into layers where each layer contains the same type of logic.
Applying this pattern requires creating a service inventory blueprint, 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. One common layering uses task, entity and utility.[2]
An alternative layering from Bieberstein et al.,[3] involves five layers, namely enterprise, process, service, component and object.
The service layer pattern invokes a specific service architecture.
The top-down service delivery approach facilitates the use of this pattern.
See also
[edit]References
[edit]- ^ Thomas Erl.Introducing SOA Design Pattern [Online]. Date accessed:6 April 2010.
- ^ Wajid Khattak Service Layers [Online].Date accessed: 21 April 2010.
- ^ Bieberstein. et al.Service-oriented Architecture Compass: Business Value, Planning, and Enterprise Roadmap.FT Press, 2005. ISBN 0-13-187002-5, ISBN 978-0-13-187002-4
- Erl, Thomas (2009). SOA Design Patterns. Prentice Hall. ISBN 978-0-13-613516-6.
- Mauro, Christian; et al. (2010). Service Oriented Device Integration - An Analysis of SOA Design Patterns. HICSS 2010. 2010 43rd Hawaii International Conference on System Sciences. pp. 1–10. doi:10.1109/HICSS.2010.336. ISBN 978-1-4244-5509-6. ISSN 1530-1605. Retrieved 2020-07-26.
- Seshadri, Srikanth (17 January 2007). "Logically SOA". JavaWorld. Retrieved 2020-07-26.
- "Service-Oriented Architecture and Java - Service Layer". Technology. Binary Spectrum. Retrieved 2020-07-26.
- Bieberstein, Norbert; Jones, Keith; Laird, Robert G.; Mitra, Tilak (17 July 2008). "Executing SOA: A Methodology for Service Modeling and Design". InformIT. Retrieved 2020-07-26.
- "High-Level Perspective of the SOA RA". SOA Source Book. The Open Group. Retrieved 2020-07-26.