Service composability principle: Difference between revisions

Content deleted Content added
References: Added reference
added text + citation
Line 1:
'''Service Composability''' is a design principle, applied within the [[service-orientation]] [[Design_paradigm|design paradigm]], which encourages the design of [[Service (computer science)|services]] in a manner so that they can be reused in multiple solutions that are themselves made up of composed services. The ability of the service to be recomposed should be independent of the size and complexity of the service composition<ref name='servicecomposition'>[http://www.whatissoa.com/p12.php Service Composition]</ref>.
:This principle is directly related to 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>.
 
==Purpose==
Line 9 ⟶ 10:
==Application==
<br/>
The application of this design principle requires designing services in a manner 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' />.
<br/>
In order for the service to provide this dual functionality, the service contract<ref name='servicecontract'>[http://www.whatissoa.com/p11.php Service Contract]</ref> needs to be designed in a manner 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 needs to be as stateless as possible ([[Service Statelessness Principle|Service Statelessness principle]]) so that it can provide optimum performance when composed within multiple service compositions.