What is the "composite computing model,” you ask? The most straightforward definition we’ve found is:
An architecture that uses a distributed, discovery-based execution environment to expose and manage a collection of service-oriented software assets.
A software asset is nothing more than a piece of business logic; it can be a component, a queue, or a single method that performs a useful function that you decide to expose to the outside world. Like the client-server and n-tier computing models, the composite computing model represents the architectural principles for governing roles and responsibilities of its constituents. It was designed to solve a specialized group of business problems that have the following requirements:
Dynamic discovery of the business logic’s capabilities
Separation between the description of the business logic’s capabilities and its implementation
The ability to quickly assemble impromptu computing communities with minimal coordinated planning efforts, installation procedures, or human intervention
The computing industry has been moving towards this model for some time now; much of the last decade has been devoted to defining and refining distributed-computing technologies that allow you to look up components on the fly; discovering a component’s interface at runtime; and building applications from components on an ad-hoc basis, often using components in ways that weren’t anticipated when they were developed. Listing the steps by which we arrived at the composite computing model is a tangent we won’t follow, but remember that Java has played, and continues to play, a very important role in the development of distributed technologies.
In short, the “composite computing model” is the direction in which computing has headed ever since networking became cheap and easy. Instead of trying to build larger applications on ever larger computers, we’re trying to assemble smaller components that interact with one another across many computers, and possibly thousands of miles. Instead of building a large, monolithic, proprietary inventory system, for example, we’re trying to build services that access inventory databases and can easily be combined as needed. Instead of forcing a customer to call customer service to find out if your plant can deliver 10,000 widgets by Wednesday (and if another plant can deliver 15,000 gadgets by Thursday), you can run an application that knows how to search for vendors that supply widgets and gadgets, figures out how to query each vendor’s service interface, and says, “Yes, we can do a production run of 5,000 next week at a cost of $40,000.” If you’re not working on applications that do this now, you will be soon.
The composite computing model defines a vision for what computing should be. Service-oriented architecture (SOA) represents a way to achieve this vision using the set of technologies that make up the Web Services Technology Stack. This set of technologies currently consists of SOAP, WSDL, and UDDI, though other components may be added in the future.
Like other concepts associated with web services, the SOA seemed to appear almost out of nowhere in September 2000. The originator was IBM and the introduction mechanism was an article by the IBM Web Services Architecture team on the developerWorks web site (http://www.ibm.com/developerWorks). Since then, this group has used it as a way to extol the virtues of web services to nontechnical users. The SOA is an instance of a composite computing model, and thus something that can be used to further our understanding of it.
Conceptually, the SOA model is comprised of three roles performing three fundamental interactions. The components of the SOA are our good friends, web services. Each web service is made up of two parts:
- Service
The implementation for a web service. A service can be as minuscule as a JavaScript file or as elaborate as a 30-year-old, industrial-strength COBOL application running on a mainframe. The key requirement is that it be on a network-accessible platform, provided by the web service provider.
- Service description
The interface for a web service. It is expressed in XML and is governed by one or more standards. This description includes the datatypes, operations, protocol bindings and network location (i.e., the URL, etc.) for the web service’s implementation. Additional documents provide categorization and other metadata to facilitate discovery.
The SOA is based upon the interactions between three roles: a provider, a registry (or broker), and a requestor. These roles are illustrated in Figure 2-1. The interactions between these roles involve publishing information about a service, finding which services are available, and binding to those services.
In a typical scenario, a provider hosts the implementation for a service. Providers define service descriptions for services and publish them to a registry. A requestor then uses a registry to find service descriptions for services they are interested in using. With the service description in hand, the requestor binds (i.e., creates a service request for) to a service.
Let’s take a closer look at the roles of the SOA.
In the SOA, a provider is considered the owner of a service. From a composite computing perspective, it is a software asset that others regard as a network-accessible service. In most cases, this software asset is exposed as a web service, which by definition:
Has an XMLized description
Has a concrete implementation that encapsulates its behavior
Almost any piece of logic can be exposed as a service in an SOA—from a single component to a full-blown, mainframe-based business process, such as loan processing. Likewise, how the service is exposed is up to the provider; you can access it through SOAP over HTTP, through a JMS message queue, or via other technologies (such as SMTP); the service may implement a request/response protocol, or it may just receive messages and deliver asynchronous replies.
As is often the case in modern software development, some fundamental ambiguities exist in basic terms such as “provider.” Does it mean the organization providing the service, the software itself, or the computer (or computers) on which the software runs? The meaning is almost always clear from the context.
A registry, or a broker, manages repositories of information on providers and their software assets. This information includes:
Business data such as name, description, and contact information (“white pages” data)
Data describing policies, business processes, and software bindings—in other words, information needed to make use of the service (“green pages” data)
A service broker usually offers intelligent search capabilities and business classification or taxonomy data (called “yellow pages” data). From a composite computing perspective, a broker represents a searchable registry of service descriptions, published by providers.
During the development cycle for a web service, a programmer (or tool) can use the information in registries to create static bindings to services. At runtime, an application can tap into a registry (local or remote) to obtain service descriptions and create dynamic bindings to services.
Registries often sound abstract, but they solve a very concrete problem. They allow you (or, more properly, your software) to ask questions such as, “Who sells widgets?” Once you have an answer to that question, you can ask more questions, such as, “How do I interact with their service to find prices, place orders, etc.?” In short, a registry lets you look up a service and then find its programmatic interface.
In the service-oriented architecture, a requestor is a business that discovers and invokes software assets provided by one or more providers. From a composite computing perspective, a requestor is an application that looks for and initiates an interaction with a provider. This role could be played by:
A person using a web browser
Computational entities without a user interface, such as another web service
Again, there’s a lot of ambiguity: is a requestor a person, an organization, or a piece of software? If it’s software, is it a browser of some sort, or is it another kind of software? Again, the answer depends on the context.
Having defined the roles that participants in web services can play, we’ll look in more detail at how they interact. There are three fundamental types of interaction: publishing, service location, and binding.
Providers publish information (or metadata) about services to a registry. These providers are usually standards organizations, software vendors, and developers. According to IBM’s Web Services Conceptual Architecture document, several different mechanisms are used to publish service descriptions:
- Direct
The service requestor retrieves the service description directly from the service provider, using email, FTP, or a distribution CD. Here, the service provider delivers the service description and simultaneously makes the service available to a requestor. There is no registry as such; the requestor is responsible for locating services and retrieving their descriptions.
- HTTP GET request
This mechanism is currently used at http://www.xmethods.com, a public repository of web services that developers can use to test their wares. The service requestor retrieves the service description directly from the service provider by using an HTTP GET request. This model has a registry (the public web repository), though only in a limited sense.
- Dynamic discovery
This mechanism uses local and public registries to store and retrieve service descriptions programmatically. In the web services world, the most frequently used registry is UDDI, though others exist (for example, ebXML R). Contextually, the service provider is an application that uses a specialized set of APIs to publish the service description.
The direct publishing method is a historical artifact and of little interest to us. Publishing with a GET request is more interesting, particularly since http://www.xmethods.com has been on the forefront of web services development. However, we see this means of publishing as transitional—a temporary tool to get us from direct publishing to dynamic discovery. (We suspect the developers of XMethods would agree.)
Dynamic discovery (see Figure 2-2) is the most interesting and versatile publishing model. UDDI and other protocols designed to support dynamic discovery are at the center of the web services landscape.
Given that registries or brokers publish services, how do you locate services that you wish to use? Requestors find services using a registry or broker. Service location is closely associated with dynamic discovery. In this context, the requestor is an application that uses a specialized set of APIs to query a public or private registry for service descriptions. These queries are formatted in a well-defined, standard XML format and transmitted using an XML messaging format, such as SOAP or XML-RPC. The criteria used to find a service include the quality of service (How quickly can the service respond? How good are its results?), supported protocols (Can my client talk to your service?), and the service taxonomy (What kind of service?). It’s easy to imagine other criteria that you could use to locate a service. Figure 2-3 shows the process of service location.
The binding interaction involves the requestor and provider and, optionally, the registry. In context, binding is what an application does when it uses the service description to create a message to be sent to the service provider. Web service description documents (WSDL documents) specify the network protocols (i.e., HTTP, MIME, SMTP, etc.) that a service supports, the APIs by which the service is accessed, and everything else that a requestor needs to use a service. Figure 2-4 illustrates the binding interaction.
The participants in an SOA have different objectives, and hence different perspectives on the SOA itself. This section looks at the perspectives of the three main participants in an SOA: the service provider, service requestor, and service broker.
Interestingly, both IBM and Microsoft are setting up business units to function in multiple roles, sometimes simultaneously. For Microsoft, the bCentral initiative will be both a service broker and service provider, MSN will be a service broker, and their desktop products will be service requestors.
Just because these participant roles have been defined with business-to-business interactions in mind, it doesn’t mean an SOA can be used only in business technologies. A web service doesn’t have to be an e-service or be associated with revenue generation at all. Forward-thinking companies have already predicted that the web services platform will logically evolve into a full-blown, Internet-based “virtual distributed computing environment.” In that world, the services supplied by a provider must:
Perform with high efficiency
Scale to handle an extremely large volume of requests
Support versioning and online self-reparation
Support being part of a workflow
Be highly available
A business that sees itself as performing some degree of an electronic service will most likely identify with the service provider role. Whether that service is defined as processing data or carrying out a specific task, the business entity must believe it is performing mission-critical work for others. Since almost anything can be a service, coming up with an exhaustive list of applicable businesses is difficult. However, we can mention a few straightforward examples:
Independent software vendor This business owns and maintains software that performs one or more tasks. This software could be made available as an aggregation of services or broken down into distinct service resources.
Business process center This business accesses a diverse set of applications that perform an entire business process. For example, a bank usually has a business process for loan processing; it may wish to generate additional income by offering its loan processing service to other lenders. The bank could expose its loan processing business process as a web service, thus becoming a service provider.
Web service aggregators The SOA—and indeed, the whole composite computing paradigm—offers the opportunity for intermediaries to build new services by aggregating other services. In the loan example, it’s easy to imagine a service that checks a number of banks to find a good rate and uses another loan processing service to request a loan on the part of a customer. This new service doesn’t provide services of its own; it just packages services that are provided by others.
As expected, the service provider views the SOA as a framework for exposing its web services. These services are islands of code designed to solve one aspect of an overall business problem. Here’s a short list of what typically goes through the mind of a service provider:
Ensuring availability A web service is not very useful if it isn’t available. Making sure that a web service can accept service requests from a SOAP router is paramount. The web sites that host today’s web applications have already figured out how to do this in a load-balanced, scalable way, so ensuring availability should be a piece of cake.
Providing a secure transaction environment Most businesses already have security in place. However, the SOA presents interesting and nontrivial security problems. An SOA may encompass multiple sites, each with its own way of implementing security. The challenge is to come up with a standards-based mechanism that allows each site in the SOA to propagate a security context, without necessarily having to use the same software. More likely than not, the two main security aspects, authentication and authorization, will end up being web services themselves.
Quality of service Web services are an innovative and powerful new mechanism for heterogeneous distributed computing, but they still need to follow old “rules of conduct” to gain rapid, widespread acceptance. One of these rules guarantees a certain level of service.
Preventing denial of service (DOS) attacks DOS attacks are currently the bane of large consumer shopping portals (such as Amazon) and online auction sites (such as eBay). There are mechanisms that deal with these problems, though ultimately the goal is to stay one step ahead of the hackers who try to attack your site. Whenever security is an issue, it’s important to run operating-system software that is fundamentally sound and to stay up to date with the latest patches and bug fixes.
A service registry, also called a broker, is a business or software component whose main SOA-related activity involves maintaining service registries and their entries. Service providers customarily pay registration fees to these brokers, who in turn advertise their service offerings. UDDI and ebXML Registries are the main “tools of the trade” for a service broker.
What kind of things would a service broker look for in an SOA? The answer depends on the type of broker. If the broker functions as a gateway, then it is probably interested in finding other service registries (brokers). Gateways serve as a connection point to a network of external service registries. They differ from other service registries in that they are used primarily by the service registries themselves, as opposed to service requestors and providers. This being the case, gateways are primarily interested in finding other brokers and expanding their reach.
Other types of brokers may be concerned with locating and installing documentation for web services. This activity is usually done on behalf of a service requestor. It includes all the work required to obtain, install, version, and configure services before they are made available to clients.
A business that finds some commonality between its own activities and the actions of others who request service will most likely see itself in the service requestor role. Two revenue-generating activities a service requestor might perform are content aggregation and service aggregation. In content aggregation, thebusiness entity interacts with various content providers to process or reproduce such content in the desired presentation format of its customers. A service aggregator interacts with service providers to rebrand, host, or offer a composite of services to its customers. Earlier, we talked about a hypothetical loan service that aggregated several pieces of the loan application and processing puzzle. To its customers, this aggregate service is just another provider; to the banks that provide the loans and the loan processing, this service is a requestor.
A service requestor typically views an SOA as something it uses to access the web services that provide it with the data it gives to its customers. Ideally, these web services allow the business to receive this data in an exact format or structure, thereby eliminating the need for elaborate data integration or mapping. Here’s a short list of what is typically on the mind of a service requestor:
Locating the cheapest web services Cost is one of the chief driving factors for goods and services; a service requestor wants to get the most bang for its buck. We’ll see how UDDI can help do this in the next section.
Mechanisms for choosing an alternate service Networks fail and servers crash with distressing regularity. A service requestor has no control over the availability of a web service, unless it is also the service’s provider. Currently, no web services platform detects when a service is unavailable and automatically fails over to another service. For the time being, the service requestor must figure out how to choose an alternate web service when the desired service is unavailable. In the future, the web services platform should be able to take care of this requirement, or at least be sufficiently extensible to allow the requestor to work out its own solution.
Subscribing to a secure environment Web services will undoubtedly become an incubator for serious hackers and mischievous adolescents. This is a serious problem that could severely hamper the widespread adoption and usage of web services. DOS attacks are probably the biggest concern.
The service-oriented architecture has been praised for how it enables the deployment of large, complex systems of applications. It is an equally useful framework for application developers. Here, a service provider performs several activities that are part of the development realm:
Designing and describing the service’s interface
Writing code to implement the service, assembling it into a deployable package, and subsequently deploying it
Publishing XML and non-XML artifacts (i.e., WSDL files, usage documentations, specifications, etc.) for the service to a service registry or other interested parties
All of these activities, with the possible exception of the last one, fall squarely in the world of development. IBM defines the development aspect of the SOA as an “end-to-end” development lifecycle that consists of four steps or phases: build, deploy, run, and manage. Since the service provider performs most of these steps, we’ll start with it.
In many cases, the implementation for our web service is already built: we have a backend application (or maybe even a web application) and only need to put a web service frontend onto it. With the application already in hand, we only need to create a service description. Most serious Java-based web services platforms include tools for producing this description directly from a class using reflection.
If a service provider doesn’t have an existing implementation, it needs to start by developing and testing the web services implementation, developing the service interface description, and developing the service implementation description. Developing a new web service involves using the programming languages and models that are appropriate for the service provider’s environment.
Next, the developer needs to assemble the web service solution for deployment. Don’t confuse deploying and publishing, as they are not synonymous. Deploying makes the web service visible to the outside world; publishing tells everyone it’s there.
Finally, a service provider needs to maintain and enhance its web services. This maintenance phase covers ongoing management and administration of the web service application.
Developers build the service implementations that service requestors consume. Once coded, this service implementation plays the role of provider, and you or another developer craft a piece of software that acts as a requestor. Binding to a service means that the developer has a blueprint for using the service and a mechanism for executing the service. The blueprint contains both a definition of the service’s interface and any requirements for using the service.