Service layer pattern: Difference between revisions

Revision as of 08:22, 17 April 2010

Revision as of 09:19, 17 April 2010

Line 8:

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'>[http://soa.sys-con.com/node/645271?page=0,1 Introducing SOA Design Pattern][Online].Date accessed:6-4-10 April 2010.</ref>. 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.

==Usage==

Line 23:

== References ==

<!--- See [[Wikipedia:Footnotes]] on how to create references using <ref></ref> tags which will then appear here automatically -->

{{Reflist}}

* 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 0136135161.

* 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.] [onlineOnline], pp.1-10, 2010 43rd Hawaii International Conference on System Sciences, 2010. Date accessed: 6-4-10 April 2010.

* [http://www.soapatterns.org/ SOA Patterns]

== External links ==