SOAs reuse enablement: fine grain vs. coarse grain
There is no doubt that SOAs encourage the reuse of components. SOAs foster a development methodology that enables the sharing of distributed application functions that are remotely evocable. SOAs provide a way of doing more with less, where composite applications can be orchestrated from reusable components incrementally either without custom coding or with fewer coding steps. At SunGard, deploying applications with our SOA (the CSA, or Common Services Architecture) has proven to allow new applications to be built quicker, with less original code, while preserving legacy investments at the same time. Thus, I’m a huge fan of the capabilities of agility and reuse that SOAs have to offer. Developers and product managers write new applications (or modify existing ones) by looking up requisite functionality first in the SunGard Product Registry, which contains information and interfaces on all products, components and application parts available. Services found are utilized and those not found are built, and later registered for later reuse. The SOA approach has allowed SunGard to ‘connect-the-dots’ in the development cycle where practical, which speed the overall development process and reduces risk.
I cringe, however, at the extent to which some expect the reuse of remotely evocable services to go. At the coarse grain level, business services through SOAs indeed provide an ideal virtualization for the reuse of functionality. For example, in the context of financial services, consider an order execution service for securities trading. All orders at a coarse grain level look the same, and the typical required inputs at a service level are: quantity, amount, security identifier, trade type, buy/sell account information and a few others. A service interface in this example can be high-level enough to truly abstract the underlying infrastructure, enabling easy reuse from many different applications. This is an ideal level for Orchestration, where various other services can be tied together to model a business process, without much knowledge of how the services are deployed, built and executed.
Consider, however fine grain services such as a financial calculations library, a logger, a message formatter, or even the infrastructure implementing the SOA framework, like the service broker, the bus or messaging middleware. Reuse of fine grained components typically wouldn’t be considered remotely over a distributed network, due to the overhead involved with remote invocation. However, reuse of fine grained components and the very SOA infrastructure itself should also be shared and reused where two or more services are both served and consumed from different SOAs yet within the bounds of a single IT infrastructure. Sharing fine grained components however requires a different method than the request/response framework an SOA provides high-level services. At SunGard, we’ve addressed this issue by making available a common reference implementation, where all the fine grained components live in tangible form. This allows native invocation (as opposed to remote invocation) for fine grained components, ensuring sharing and reuse, without the unnecessary overhead of the distributed computing environment.
In short, fine grained services can’t be reused in the same way as coarse grained services due to high-level messaging invocation, but should be shared nevertheless. The lower-level is often not shared when the focus is on service virtualization and most often are replicated between service infrastructures. A common location, process and reference implementation are required in order for fine-grained components to be shared.