Service composability principle: Difference between revisions

Revision as of 22:02, 4 March 2010

Revision as of 00:44, 5 March 2010

Line 1:

{{New unreviewed article|source=ArticleWizard|date=March 2010}}

'''Service Composability'' is a design principle, applied within the [[Service-orientation|service-orientation]] design paradigm, which encourages the design of [[Service_Service (computer_sciencecomputer 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 [http://www.whatissoa.com/p12.php service composition].

==Purpose==

<br/>

The concept of developing software out of independently existing components encourages the concept of composition. This is the underlying concept within object-orientation where the end product is composed of several interlinked objects that have the ability to become part of multiple software solutions, no matter how complex the solution is. The same composition concept is inherited by service-orientation, whereby a business process is automated by combining multiple services. However, within service-orientation there is even greater focus on building services that can be composed and recomposed within multiple solutions in order to provide the [[Agility|agility]] promised by the SOA. As a result of this emphasis, some guidelines are required in order to develop services that can be effectively aggregated into multiple solutions.

<br/>

The Service Composability principle provides design considerations that help towards designing composable services with a view to encourage service reuse as much as possible. The guidelines provides by this principle prepare the service so that it is ready to participate in service compositions without requiring any further design changes.

Line 15:

In order for the service to provide this dual functionality, the [http://www.whatissoa.com/p11.php service contract] 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) 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_PrinciplesOrientation Design Principles|rest of the design principles]] have been applied successfully. The application of the [[Standardized_Service_Contract|Standardized Service Contract]] principle enables the services to be interoperable with other and helps to keep the composition design rather simpler by avoiding the need to perform runtime data model transformation. By applying the Service [[Service_Loose_CouplingService Loose Coupling|Loose Coupling]] principle, a service could be recomposed with the confidence that it would not create any form of negative coupling with the other service in the composition. The application of the [[Service_Autonomy_PrincipleService Autonomy Principle|Service Autonomy]] and the [[Service_Statelessness_PrincipleService 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.

==Considerations==

Line 33:

* [http://www.soamethodology.com SOA Methodology]

[[Category:Service-oriented (business computing)]]