MTF Proposal for Web
Services Architecture
Elements and Relationships
Contributors
Heather Kreger (kreger@us.ibm.com)
Mark Potts (mark.potts@talkingblocks.com)
Igor Sedukhin (igor.sedukhin@ca.com)
Table of Contents
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.4. Discovery Agency Hierarchy
1. Introduction
This document presents Management Task Force (MTF) proposed additions to the Web Services Architecture (WSA) as described in the following draft document http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch.html. 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.
The proposal is to add clarity to certain aspects of the WSA and to make possible for the MTF to express sensible Web Services Management Architecture.
2. Additional WS Architecture Elements
2.1. Service and Client Environment Role
To better differentiate responsibilities of the Service Provider and the Service Requestor roles ( http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch.html#roles) from implementation/deployment/infrastructure aspects, addition of Service and Client Environment roles is proposed.
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 ( http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch.html#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).
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.
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.
Diagram 1: Relationships in the Basic WSA
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 Diagram 1:
- 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.
Diagram 2: Relationships in Basic WSA + Service/Client Environment Role
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
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:
3.3. Description Components
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.
- 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).