MTF Proposal for Web Services Architecture Elements and Relationships

Editors:
Heather Kreger, IBM
Mark Potts, Talking Blocks
Igor Sedukhin, Computer Associates

Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

Abstract

The document is to clarify aspects of the WSA in order to express sensible Web Services Management Architecture.

Status of this Document

This document is an editors' copy that has no official standing.

This document captures work done by the management task force of the W3C Web Services Architecture Working Group. The Working Group felt this work was valuable but beyond the scope needed in the Web Services Architecture document. It is provided here for archival purposes.

This document was proposed in November 2002 by the Management Task Force of the Web Services Architecture Working Group. It is based on the 14 November 2002 version of the Web Services Architecture and the 14 November 2002 version of the Web Services Architecture Requirements. Consequently, this document is not entirely consistent with the current Web Services Architecture document.

Comments on this document should be sent to www-ws-arch@w3.org (public archives).

Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page.

Table of Contents

1 Introduction
2 Additional WS Architecture Elements
    2.1 Service and Client Environment Role
    2.2 Hosted Service and Hosted Client Components
3 Relationships Between WS Architecture Elements
    3.1 Relationships in the Basic WS Architecture
    3.2 Hosted Service and Hosted Client Components
    3.3 Description Components
    3.4 Discovery Agency Hierarchy

1 Introduction

This document presents Management Task Force (MTF) proposed additions to the Web Services Architecture [WSA]. The contents of this document was contributed by the members of the MTF and discussed among the following active members of the MTF: Heather Kreger (IBM), Mark Potts (Talking Blocks), Igor Sedukhin (CA), Hao He (Thomson), Ying-Leng Husband (HP), Zulah Eckert (HP). The final consensus on the details in this document was not reached.

2 Additional WS Architecture Elements

2.1 Service and Client Environment Role

To better differentiate responsibilities of the Service Provider and the Requestor roles from implementation/deployment/infrastructure aspects, addition of Service and Client Environment roles is proposed.


Figure 1

Figure 2-1. Figure 1


WSA defines that a Service Requestor discovers and directly interacts with a Service Provider that exposes necessary functional (e.g. submit purchase order) and operational (e.g. SOAP over HTTP) semantics.

In most cases, a Service or a Client components will actually be "hosted" (run, contained) in an environment specifically supporting Web Services. These environments provide execution facilities such as message listening, parsing, security, and dispatching to the service along with deployment, configuration and management. Some environments also provide scalability via pooling, clustering, and workload balancing. Certainly, services don't have to execute in such an environment and may do all their own listening, parsing, and dispatching. In this case the environment and service provider roles are collapsed into one and the same. Because services (and clients) are usually running in such an environment, it is necessary to manage the "Environment" for availability and performance as well. The environment of a Web Service may also be leveraged to provide management information on behalf of a service or a client.

Service and Client Environment roles are introduced that "host" (contain, run) the Service and/or the Client. An Environment is aware of the components it hosts, but components do not directly have knowledge of their Environment (see Hosted Service and Hosted Client below).

Since the Service and Client Environments are roles, a Client Environment of one Service Requestor may be the same as a Service Environment of another Service Provider. It may also be that a Service Requestor and its Client Environment are one and the same.

2.2 Hosted Service and Hosted Client Components

Basic Service and Client components are not directly aware of the environment. However, some services or clients may be aware of the "hosting" environment. To capture this awareness Hosted Service and Hosted Client components are proposed. A "Hosted" component is a kind of basic component that is aware of its environment. Essentially a "Hosted" component may know (or refer to) how it is provisioned for, and the basic component does not care about it (it just works).


Figure 2

Figure 2-2. Figure 2


A "Hosted" component may expose management information that is unique to the component that is "hosted" by its environment. In fact, most of the management data provided by hosted components may actually be tracked and provided for by the environment, like an interaction history. This same concept applies to Service and Client components in the WSA.

3 Relationships Between WS Architecture Elements

MTF believes that relationships between roles and components in the WSA are important for clarity. The relationships are also fundamental to defining WS Management architecture.

3.1 Relationships in the Basic WS Architecture

The diagram below formally captures the relationships between roles and components in the WSA. More diagrams follow to define other, supplementary relationships.


Figure 3

Figure 3-1. Figure 3


In other words, these are the components that need to be managed and these are the relationships that need to be reflected in the management information schema.

In the above UML diagram WSA components and roles are represented by classes.

Relationships between roles and components are represented by associations (and cases of associations such as an aggregation). Associations are drawn between classes. Therefore associations between instances follow the associations between classes, but do not necessarily coincide on the same instance even if they coincide on the class. For example a Service Requestor instance may be associated with a different instance of a Discovery Agency than an instance of a Service Provider (for clarity: both may be associated to the same instance as well).

Necessary clarifications for the Figure 3:

  • Discovery Agency may be implemented by a set of Service Providers (e.g. a replicated UDDI registry implemented at several locations) (implements). A Service Provider may implement one or more Discovery Agencies, but the Service Provider is not specifically aware of that.
  • A Service Provider may advertise itself using several Discovery Agencies (advertizedBy).
  • A Discovery Agency keeps an inventory of advertised Service Providers (lists).
  • A Service Requestor may use several Discovery Agencies to locate Service Providers (discoversFrom).
  • Service Requestors are aware of and use the Service Providers (uses). It is a many-to-many relationship. Service Providers are not aware of potential Service Requestors.

Figure 4

Figure 3-2. Figure 4


Necessary clarifications for the Diagram 2:

  • A Service Provider may contain a set of Service Environments.
  • A Service Environment contains a set of Services.
  • Whether via aggregation of Service Environments or not, a Service Provider is aware of its Services.
  • Same applies to the Service Requestor, Client and Client Environment.

3.2 Hosted Service and Hosted Client Components


Figure 5

Figure 3-3. Figure 5


The above diagram introduces a Hosted Service that is a kind of a Service that is aware of its Service Environment.

Again, the same concepts apply to the Hosted Client:


Figure 6

Figure 3-4. Figure 6


3.3 Description Components


Figure 7

Figure 3-5. Figure 7


The above diagram expresses relationships between a Service and Service Description components in the WSA. It also expresses that a Service Description conforms to certain Service Types (a set of portTypes in WSDL sense) and is concretized by a set of Bindings which implicitly "refine" the Service Type.

3.4 Discovery Agency Hierarchy

Discovery Agencies can be implemented using a variety of mechanisms. However, there should be a set of basic aspects that are common to all Discovery Agencies regardless of if they are centralized, distributed, push-populated, crawler populated, cached, etc. This part of the architecture will try to define the basic aspects for all discovery agencies to optionally support as well as basic characteristics for a few of the existing, common agencies like UDDI and WS-IL.


Figure 8

Figure 3-6. Figure 8


  • A Discovery Agency may be centralized or distributed.
  • A concrete implementation of a Discovery Agency of a Centralized registry type is UDDI (replicated or delegated).
  • Concrete implementations of a Discovery agency of a distributed Registries type (Discovery Mechanisms, rather) are WS-Inspection (WS-IL) and Open Grid Services Architecture (OGSA).