Service layer pattern: Difference between revisions
Content deleted Content added
Andy Dingley (talk | contribs) Reverted 1 edit by 91.159.53.89 (talk): Rv self-promotional spam that doesn't offer anything to meet WP:EL. (TW) |
m Cleaned up using AutoEd |
||
| (13 intermediate revisions by 9 users not shown) | |||
| Line 1: | Line 1: | ||
{{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. |
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|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. |
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 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.]] |
[[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'> |
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'> |
||
Wajid Khattak [http://www.informit.com/articles/article.aspx?p=1583177 Service Layers][Online].Date accessed: 21 April 2010.</ref> |
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.[ |
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 |
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 [[Top-down and bottom-up design|top-down]] service delivery approach facilitates the use of this pattern. |
||
| Line 25: | Line 25: | ||
== 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}} |
|||
* {{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}} |
|||
* [[Thomas Erl|Erl]] et al.,(2009).[http://www.amazon.com/dp/0136135161 SOA Design Patterns]. Prentice Hall. ISBN 0-13-613516-1. |
|||
* {{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}} |
|||
* Mauro. et al. [http://www.computer.org/portal/web/csdl/doi/10.1109/HICSS.2010.336 Service Oriented Device Integration - An Analysis of SOA Design Patterns.] [Online], pp. 1–10, 2010 43rd Hawaii International Conference on System Sciences, 2010. Date accessed: 6 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}} |
|||
| ⚫ | |||
* 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] |
||
[[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.