The computing ecosystems of today are complex in terms of both the software and the hardware that drives the software. The complexity arises from the gradual acquisition and evolution of software and hardware that run a business as well as the competitive nature of selling into a business. For example, a small business that grows into a large business adds functionality as it becomes more successful. A small business may not require a distribution management application whereas a large business can optimize and leverage distribution applications to trim costs and compete against other businesses. As the small company grows, it may want to add distribution applications to its existing business infrastructure.
Businesses need some of the following capabilities in the architecture to help tame their computing ecosystem:
Allow computers to share their computing power.
Create dynamic applications that span networks.
Provide well-encapsulated pieces of logic for use by a variety of applications.
Allow application behavior and content to vary without redeployment or rebuilding of any application components .
Allow applications to coexist with each other without regard for their implementation language, platform, or architecture.
In short, these capabilities add up to a component-oriented architecture with location and implementation transparency as primary goals of the architecture. The Jini platform is a service-oriented architecture that fulfills all of these goals, except the last-implementation transparency. Over time, it became apparent that the Jini implementation actually required implementation transparency. This was necessary because small devices, a primary target for initial Jini marketing campaigns , could not support a full Java environment and therefore could not participate in a Jini network. The Jini team corrected the oversight through the addition of the Surrogate architecture, but the fact remains that the base Jini architecture is natively Java. Programmers must acquire additional knowledge and expertise to adapt their services to other languages. Had the Jini architecture originally added implementation transparency in such a way that it was robust and easy to facilitate, this book could be about the Jini platform instead of Web Services.
Today's large business applications are a mix of technologies and programming languages. In many cases, access to the Java language would be difficult and simply unrealistic . Further, there does not appear to be a time in our lives where there will be a single programming language. Just as Java passed 50 percent of new implementations , Microsoft's C# became available, so the battle for a de facto programming language is starting to heat up.
Web Services implement both location transparency and implementation transparency in the primary architecture. Interestingly, the core pieces of the service-oriented architecture are the same from a high level ”thus the development of a pattern to address the service-oriented architecture.
Service-oriented architectures are useful in a variety of scenarios:
Two or more separate architectures or programming platforms need to leverage functionality from each other: In this scenario, the service- oriented architecture is an integration point for the different architectures and platforms.
You want to expose services to the others, but you are not in control of the architecture or platform from which they will access your service: In this case, the service-oriented architecture can simplify others' jobs of using your service.
You build applications that can dynamically expand, contract, and change in terms of the functionality that they provide or represent: Hardware-based scenarios are easy to visualize using this scenario. Consider storage management applications that need to be aware of available storage devices and have policies to manage the available storage. In this case, the application needs to be immediately aware of the addition of storage devices. Further, replaceable management policies are well suited to the service-oriented architecture.
You build an application that leverages functionality available across the Internet and/or from multiple providers: A credit check authority is a great example of this capability. Several businesses can provide credit-checking capabilities to your application; each one uses similar databases of information. In this case, you may want the ability to switch providers based on price point and availability rather than being statically bound to a provider at design time.
Service-oriented architectures are useful in many other scenarios. In all cases, your application will be network based and dynamic in nature.