Recent studies show that 40% of the code written for the average service developed using an application server is unnecessary "plumbing" code.
Large office buildings don't have duplicate plumbing systems and the business units of a large corporation that inhabit those buildings don't build duplicate HR departments. In SOA, the same principle applies. Services must be reused across as much of the organization as possible to get the full benefit of SOA.
Services with very broad reuse and services with long life spans both imply a heterogeneous service environment. No company can standardize on a single development language or toolkit and expect that they will use it forever. Internal personalities, corporate mergers, and technological progress will all contribute to a library of services based on different programming languages and frameworks.
Heterogeneous environments make sense. The computers found that in the typical corporate office there are a mix of different form factors (laptops, desktops, servers) that run on different operating systems and run different software packages. However, those computers all connect to the same network and power infrastructure.
The same must be true of services. A services-based application can certainly be an orchestration leveraging a Java service, a .NET service, and a C++ service. All of those services should communicate, be deployed and monitored using the same mechanisms.
Service virtualization is an approach to deploying and managing services that provides the common plumbing required by all services-based applications. This lets developers focus on building new functionality and provides a foundation on which you can plug that new functionality.
To do this, new services must be written to run as components in a service container. That container must then provide a straightforward mechanism by which the newly deployed service can both be invoked, and invoke other services. This clear separation between the service logic and its communication with other services is the most important requirement for effective service virtualization.
Enterprise Service Bus (ESB) products have already been implemented by many companies with SOA initiatives. These products provide enormous value by allowing companies to easily bridge communications between services, packaged applications, and legacy assets. Complete ESB offerings also provide a mechanism by which legacy systems can be intelligently exposed as services without any changes to those existing system. Many even go so far as to providing the ability to very quickly orchestrate a set of services into a higher-level business service using a graphical flow language.
It's not enough to provide a single definition for a "service" and a single model for describing that service. To have a single container that can host heterogeneous services there has to be a standard by which all of those services can "plug-in" to a container.
Large buildings rely on a single solid foundation and a well-designed infrastructure to survive. Large-scale SOA is no different. Building your services on top of a solid service virtualization layer will reduce operational cost and complexity while allowing your developers to focus on writing new functionality and providing new business value. In today's hyper-competitive business climate this increased agility provides an invaluable edge. |
Service Oriented Architecture (SOA) promises to reduce the amount of new coderequired to create new applications by allowing the reuse of existing services. To get significant benefit from SOA, an organization must have as many services exposed as possible at as broad a level as possible.
