Service composability principle: Difference between revisions

Content deleted Content added
Yobot (talk | contribs)
m clean up, References after punctuation per WP:REFPUNC and WP:CITEFOOT using AWB (8797)
Yobot (talk | contribs)
m Considerations: WP:CHECKWIKI errors fixed + general fixes using AWB (8961)
Line 20:
As more and more service compositions are built, there is a tendency of getting dependent on a service that is highly reused. This requires careful analysis during the design of the service compositions and considering alternate standby services for critical functionality. On the other hand, it may become difficult to evolve a service that is now become a part of multiple service compositions. This could be addressed by the application of the Concurrent Contracts design pattern that advocates maintaining multiple concurrent contracts for a service.<ref name='CC'>[http://www.soapatterns.org/concurrent_contracts.php Concurrent Contracts Pattern]</ref> This way the service can evolve while providing backward compatibility.
 
Some of the factors that determine the composability potential of a service include:<ref name='Reddy'>Reddy. et al.[http://www.springerlink.com/content/36107373037136n2/fulltext.pdf Evaluating legacy assets in the context of migration to SOA][Online].pp 58.Date accessed: 21 April 2010.</ref>:
* Ability to provide functionality at different levels within a business process.
* Message Exchange pattern