Content deleted Content added
→Application: Added internal link |
|||
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|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. 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==
| |||