Content deleted Content added
clean up, copy edit |
|||
Line 13:
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]]) 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'>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|
==Considerations==
| |||