Content deleted Content added
Strikerforce (talk | contribs) Filled in 3 bare reference(s) with reFill () |
Robincantin (talk | contribs) Short description |
||
| (4 intermediate revisions by 3 users not shown) | |||
Line 1:
In computing, '''service composability''' is a design principle, applied within the [[service-orientation]] [[design paradigm]], that encourages the design of [[Service (computer science)|services]] that can be reused in multiple solutions that are themselves made up of composed services. The ability to recompose the service is ideally independent of the size and complexity of the service composition.<ref name='servicecomposition'>{{cite web|url=http://www.whatissoa.com/p12.php|title=Service Composition|publisher=}}</ref>▼
{{Short description|Computing design principle}}
▲In computing, '''service composability''' is a design principle, applied within the [[service-orientation]] [[design paradigm]], that encourages the design of [[Service (computer science)|services]] that can be reused in multiple solutions that are themselves made up of composed services. The ability to recompose the service is ideally independent of the size and complexity of the service composition.<ref name='servicecomposition'>{{cite web|url=http://www.whatissoa.com/p12.php|title=Service Composition|publisher=|access-date=2010-03-04|archive-url=https://web.archive.org/web/20100311045214/http://www.whatissoa.com/p12.php|archive-date=2010-03-11|url-status=dead}}</ref>
This principle is directly responsible for the agility promised by SOA as it promotes composing new solutions by reusing existing services.<ref name='MP'>Michael Poulin.[http://www.ebizq.net/blogs/service_oriented/2009/02/evolution_of_principles_of_service_orientation_service_statelessness_part_6.php Evolution of principles of Service Orientation: Service Statelessness, part 7][Online].Date accessed: 21 April 2010.</ref>
Line 11 ⟶ 13:
The application of the service composability principle requires designing services so that they can be used in a service composition either as a service that controls other services, i.e. a controller service, or as a service that provides functionality to other services in the composition without further composing other services, i.e. a composition member.<ref name='MP' />
For the service to provide this dual functionality, the service contract<ref name='servicecontract'>{{cite web|url=http://www.whatissoa.com/p11.php|title=Service Contract|publisher=|access-date=2010-03-04|archive-url=https://web.archive.org/web/20120501123049/http://www.whatissoa.com/p11.php|archive-date=2012-05-01|url-status=dead}}</ref> must be designed so that it presents functionality based on varying levels of input and output data. In case if it is required to participate as a composition member, then usually the input parameters to the service would be more fine grained as compared to the situation when it is required to participate as a composition controller. A heavily reused service must be as stateless as possible ([[service statelessness principle]]) so that it can provide optimum performance when composed within multiple service compositions.
<br/>
The effectiveness of this principle depends upon the extent to which [[Service-orientation design principles|rest of the design principles]] have been applied successfully. The application of the [[standardized service contract]] principle makes the services interoperable with others, and helps to keep the composition design simpler by avoiding the need to perform runtime data model transformation.<ref name='IBMRed'>IBM Red Books [http://www.redbooks.ibm.com/redbooks/pdfs/sg247607.pdf Power Systems and SOA Synergy][Online].Date accessed: 21 April 2010.</ref> By applying the [[service loose coupling principle]], a service could be recomposed with the confidence that it would not create any form of negative coupling<ref name='CoupTypes'>[[Service loose coupling#Coupling types|coupling types]]</ref> with the other service in the composition. The application of the [[Service autonomy principle|service autonomy]] and the [[Service statelessness principle|service statelessness]] principles increase the reliability and availability of the service so that it be reused in multiple service compositions with increased confidence.
Line 20 ⟶ 22:
As more and more service compositions are built, there is a tendency of getting dependent on a service that is highly reused. This requires careful analysis during the design of the service compositions and considering alternate standby services for critical functionality. On the other hand, it may become difficult to evolve a service that is now become a part of multiple service compositions. This could be addressed by the application of the Concurrent Contracts design pattern that advocates maintaining multiple concurrent contracts for a service.<ref name='CC'>{{cite web|url=http://www.soapatterns.org/concurrent_contracts.php|title=SOA Patterns|website=SOA Patterns}}</ref> This way the service can evolve while providing backward compatibility.
Some of the factors that determine the composability potential of a service include:<ref name='Reddy'>Reddy. et al.[
* Ability to provide functionality at different levels within a business process.
* Message Exchange pattern
Line 26 ⟶ 28:
* Support for exception handling.
* The availability of meta-data about service capabilities and behavior.
==See also==
*[[Executable choreography]]
*[[Service choreography]]
== References ==
{{Reflist}}
* Kjell-Sverre Jerijærvi.[http://www.infoq.com/articles/soa-contract-maturity-model SOA Contract Maturity Model][Online].Date accessed: 21 April 2010.
* Mauro. et al. [https://web.archive.org/web/20110203194511/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: 8 April 2010.
* Dino Esposito.[http://msdn.microsoft.com/en-us/magazine/cc699560.aspx The HTML Message Pattern][Online].Date accessed: 21 April 2010.
* [[Service-oriented_architecture#Principles|Service-orientation Principles]]
| |||