At the level of speculations, one of the major reasons for the scalability mentioned by Fluid is in technical obfuscation of SOA with Web Services and related concept of interface wrapprs and 'Composite Applications'. These wrappers and applications cannot work as services - as independent autonomous entities - because they share the code libraries underneath the interfaces. Services must be independent applications to fluently compose new orchesrations or to be replaced in existing orchestrations regardelss of their location - inside or outside of the company.
- Michael
From: Gervas Douglas <[email protected]>
To: [email protected]
Sent: Fri, July 16, 2010 1:42:17 PM
Subject: [service-orientated-architecture] Benian on Fluid Services
 |
Fluid Services by Ilkay Benian  Published: July 11, 2010 (SOA Magazine Issue XLI: July 2010) Download PDF Digg This • De.licio.us • Slashdot • Technorati • StumbleUpon • Google Bookmark |
<<Introduction
As organizations continually build their software integration architecture based on the SOA paradigm, more and more services are being developed and reused to build other services. Just as OOD and CBD paradigms introduced code reuse in applications and component reuse across applications, SOA has brought the advantage of enabling reuse across distributed applications and platforms with flexibility and agility.
However, as systematic reuse of such services become more and more widespread, performance is becoming a real concern; Latencies introduced at each back-end call are accumulated, large units of work hinder utilization of parallelism, chained service calls cause large amounts of wasted resources deteriorating scalability. SOA has to address these problems to advance to the next level of maturity. This article analyzes some of the important bottlenecks and proposes a new approach for rethinking and redesigning existing services to use a stream-oriented rather than message-oriented communication in order to make them more responsive which will in turn encourage more service reuse, increase composability and provide better development agility without the performance concerns.
Revisiting the Goal of SOA (Service-oriented Architecture)
SOA has emerged with the prospects of solving mainly the agile software integration needs of growing organizations. SOA borrows the contract based approach in component software and applies similar principles to enable independently developed systems communicate. Once contracts are established and agreed upon, it is possible to develop systems in parallel, integrate them easily and evolve them in time without having to be always in lock-step. It also ensures that future consumers or even future providers of data can continue to deliver the services using the same contract without breaking other parties in the conversation. Thus, SOA manages the asynchrony between naturally independently developed systems and their emergent complexity. To achieve this goal, SOA’s strategy is to lay down the guidelines for establishing the necessary agreement or contractual platform to allow systems that co-evolve over time even if they are not in sync.
This strategy is actually just a scaling up of a principle in software engineering that has been addressed by various methodologies; managing complexity. By acknowledging the inherent characteristics of such distributed development, their asynchrony, and their independence, SOA was able to address the issue very wisely. SOA’s success can be observed in the fact that more and more systems are written as services and built on top of other services. Large scale distributed computing has been thus rendered accessible and complexity that plagued old monolithic systems has been reduced to a manageable level.>>
You can read this in full at: http://www.soamag. com/I41/0710- 2.php
Gervas
