|
...a specified function.
There is a large degree of standardization in the operation of Web services. (2,3,4) Figure 1A illustrates the Web-services model that includes a service requestor, a service registry, and a service provider.
[FIGURE 1 OMITTED]
To assess the challenges involved in using Web services in environments in which tens or hundreds of services are offered to customers, consider exception handling. If a service bound to a client fails, there is no easy way for the client to switch to a comparable service. The client has to be able to query the service registry, locate an available service, establish a new binding, back out from the point of failure, and rerun the service request. It is also likely that there are several service instances to choose from and the client has to include the logic to select an appropriate service instance. The logic becomes complex and needs to be included in each client. The situation may become unmanageable if hundreds of services need to be handled this way.
Although recovery services and highly available platforms are often provided on the service provider end, clients are still required to handle exceptions. This is so because SOA enables dynamic mixing and matching of requestors and providers. If the service providers are independent businesses, the services provided may be viewed by the client as less reliable. In addition to the possibility of disturbances such as hacker attacks and network outages, additional factors such as business relationship and operation policy need to be considered as well. Availability will continue to be a critical consideration for stand-alone service implementations.
Consider the issue of integration, which is present in most modern IT systems. In today's dynamic business environment, Web services are ideal for implementing either internal or external business functions, such as inventory control and order processing. When businesses are forming partnerships and alliances, the number of suppliers can grow as businesses are expanding. The characteristics of suppliers can also become more diverse. For example in a catalog sales scenario, the suppliers could specialize in different classes and categories of merchandise, carry merchandise of different quality levels, and adhere to different volume-discount agreements. Suppliers may come and go, may fail on their deliveries, may have relationship constraints, and so on. There is no fast and easy way to manage these changes dynamically in real time. The main business processes can be implemented as workflows, but keeping the processes robust may depend on the performance of specific suppliers. The logic becomes unmanageable when tens and hundreds of suppliers need to be managed. This could be one reason why organizations tend to implement SOA with only a small number of suppliers. We believe that environments with hundreds of competing or collaborating suppliers will be a common phenomenon of the future. In order to achieve the full benefit of SOA in such environments, new techniques to overcome complexity are required.
A service domain (SD) maps a collection of comparable or related services to a single logical service. It is implemented as a service domain node consisting of a service entry component, a rule-based policy component, a service catalog, and a service-rendering component. In addition, an aggregation engine contains node services, such as monitoring, logging, error recovery, and so on. The SD presents a single Web-services interface, describable by standard Web-services specifications, but it provides a higher-level interface for managing a group of Web services (a service may be an application, a software function, a data access, or an IT resource used in a solution implementation).
The SD aggregates and manages multiple service instances as a single virtual service. It offers a SOA solution that reduces the complexity of building business applications because the applications need only focus on the services and user interfaces (UIs) specific to the business while the SD provides most of the enabling logic. Figure 1B illustrates the Web services model with an SD replacing the individual service provider. A client needs to find and bind once to an SD. The SD hides the complexities involved with using services: discovery, selection, exception handling, and so on. Solution deployment is faster and easier, and client access is simpler.
[FIGURE 1B OMITTED]
The SD model starts with what is available today and builds a service management and brokering middleware solution designed to address the previously mentioned challenges. Its objective is not to define new application programming interfaces (APIs) or new standards, but to construct from the existing components a new, higher-level structure that can hide complexities from service users, simplify deployment for service suppliers, provide self-managing capabilities, and give administrators a set of tools for managing the IT solution.
The SD, which implements Web services and grid concepts, is extendable to include new grid standards that are still evolving. SDs often can be structured as a logical hierarchy. For example, an SD that provides portfolio management and purchase-ordering services may direct requests to a descendant (child) SD that provides services for executing the transactions (e.g., the submission and processing of jobs). A further descendant SD may provide resource-allocation services, such as allocation of computing power, storage capacity, and other execution-related resources (similar to data and resource management in grid computing). Such an implementation of an SD hierarchy is a service grid.
The SD model enhances the Web services concepts of proxy, interceptor, handler, gateway, mediator, and broker by incorporating concepts of grid computing (5,6,7) and autonomic computing. (8) Instead of implementing individual functions for each service, such as action selection, routing, failover, and change management, the SD model provides a service grid, a pool of dynamically assembled service instances. The SD automatically dispatches the best service instance corresponding to the user request through built-in mechanisms for registering and discovering service instances.
The SD model is based on the standards specified by W3C ** (9) and OASIS. (10) These include Web Services Description Language (11) (WSDL), Extensible Markup Language (12) (XML), Simple Object Access Protocol (13) (SOAP), Hypertext Transfer Protocol (14) (HTTP), Universal Description, Discovery, and Integration (15) (UDDI), Web Services Inspection Language (16) (WSIL), and Web Services invocation Framework (17) (WSIF).
Kraft (18) presents a Web services collection model that can contain a group of abstract Web services objects. This approach, which provides a convenient way to group Web services, is useful for designing a distributed access-control mechanism because it facilitates the management of authorization specifications and meta-data and the composition and specialization of Web services. This model does not support rule-based automatic service aggregation.
The Global Grid Forum (5) (GGF) defines a Service Group port type as an interface to a collection of grid services. The grouping model does not assume any relationship among the member services in the group. It also does not support rule-based automatic service aggregation.
The emergence of the Web Services Resource Framework (19) (WSRF) and the associated WS-Notification are bringing together grid computing and Web services. (20) The Open Grid Service Architecture (21) (OGSA) defines key building-block services for grid computing. These defined services are fundamental to IBM's on demand operating environment (22) that provides system management, autonomic computing, data management and storage management, knowledge management and collaboration, and business-computing services. Given the independent nature of its service abstraction (whether it is for a specific IT resource, system service, software solution, or business-application function), the SD model could become a key building block for the OGSA fabric as well.
The rest of the paper is organized as follows. In the next section on the architecture of SDs, we cover the concepts of port-type aggregation and SD hierarchy, we describe the structure of an SD node and its components, and we discuss the handling of the state associated with a Web service. In the section that follows, "Implementation," we describe our reference implementation and its application to the implementation of a large grid now in progress. Next, in the section "Implementation aspects," we provide additional implementation details by discussing setup and deployment of services, failover and recovery, and rule-based service selection. We conclude with a summary of the paper and directions for future work.
Architecture
The SD model allows the aggregation and sharing of multiple WSDL-described Web services. Services from various sources are virtualized as a single logical service. An SD has a set of port types representing the set of distinct services it offers. Each port type corresponds to a collection of similar service instances. Rules are provided to manage and control the behavior of the aggregated services.
Figure 2 illustrates the aggregation of services and the resulting port types. The SD node shows five aggregated ports. Each port has a set of arrows indicating the operations and message flows. There are three service providers shown; provider 1 supports port type 1, provider 2 supports port types 2 and 4, and provider 3 supports port types 2 and 5. A requestor sends a request for port type 2 of the SD. The request can be forwarded either to port type 2 of provider 2 or port type 2 of provider 3.
[FIGURE 2 OMITTED]
Each port type is associated with a set of service level agreements (SLAS), each specifying a service level. In order to offer a service to clients, the service provider registers the service with the SD, specifying the port type and an SLA. The SD can then incorporate that service into its own version of service. In the scenario depicted in Figure 2, the SD matches the user service level with the provider service level and selects provider 2. The two service levels are compatible but need not be identical. By using SDS a service broker is thus established that can manage a heterogeneous group of service suppliers in order to provide virtual and additional value-add services to consumers. (23,24) The simplest SD is a single collection of similar service instances, much like a customer service desk in a store in which the service desk is staffed with several attendants. Whereas a store may have several customer service desks, an SD implementation may have a nested architecture consisting of a hierarchy of SD nodes. In that case, a service requestor interfaces with a single logical SD. The SD implemented as a hierarchy of nested SDS allows the creation of a large virtual business complex referred to as a service grid.
The motivation behind the SD concept is to achieve manageability when dealing with a large number of services and service providers. Although we consider how the SD can exploit existing standards, products, and emerging technologies, the main focus is on reducing the complex issues to simple Web service invocations and thus view Web services as the ultimate standard.
Here is a list of the SD-related terms used in this paper:
* Two service instances...
NOTE: All illustrations and photos
have been removed from this article.
More articles from IBM Systems Journal
MyMED: a database system for biomedical research on MEDLINE data.(Prod..., December 01, 2004
Looking for additional articles?
Search our database of over 3 million articles.
Looking for more in-depth information on this industry?
Search our complete database of Industry & Market reports by text, subject, publication
name or publication date.
About Goliath
Whether you're looking for sales prospects, competitive information, company
analysis or best practices in managing your organization,
Goliath can help you meet your business needs.
Our extensive business information databases empower business
professionals with both the breadth and depth of credible,
authoritative information they need to support their business
goals. Whether it be strategic planning, sales prospecting,
company research or defining management best practices -
Goliath is your leading source for accurate information.
|
%20%20&position=1)