Content deleted Content added
→Considerations: Added text |
→Application: Added citation |
||
Line 15:
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.
<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 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<ref name='IBMRed'>[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 [[Service Loose Coupling|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.
==Considerations==
| |||