Web Services Management Architecture Concepts

by Igor Sedukhin (igor.sedukhin@ca.com)

Need to manage Web Services (WS) Architecture elements: components (e.g. a service, contract, client, etc.) and interactions (e.g. messages, discovery). Management is a transcendental concept.

WS Management Architecture blueprint does not specify how management concept should to be implemented and does not prescribe any specific management applications. This architectural blueprint defines

Extensible Management Information Schema that directly correlates with the WS Architecture elements
Base set of Management Operations/Events that WS Architecture elements need to provide
Access to Management Information/Operations/Events (discovery is part of access definition)

Essentially, WS Management Architecture blueprint defines an extensible information set and information flow that enable various interested parties to realize management of Web Services and Web Services Architectures. Policies (access control, trust, etc.) that govern management information flow are out of the scope of this architectural blueprint. Such policies are therefore part of the conduit of the management information flow.

Client discovers and directly interacts with a Service Instance that provides necessary operational semantics. A Service Instance concretizes an “Abstract” Service that encapsulates necessary functional semantics. An Execution Environment hosts (contains, runs) the Service Instance. That makes it a “Hosted” Service, which is aware of its Execution Environment and vice versa.

The above diagram informally describes a conceptual use case of managing a WS Architecture component (e.g. a Service, Discovery Agency, Execution Environment, etc.).

Management Client discovers the WS Architecture component it is interested in using standard discovery mechanism (e.g. looking up a Service via a Discovery Agency or scanning the network for Web Servers)
WS Architecture component has Management Interfaces that allow interactions via a Management Protocol. For example, Service may include definitions of those Management Interfaces and Management Protocol requirements in its Contract.
Management Client uses Management Protocol to interact with the Management Interfaces. Management Protocol delivers management information, carries management operation interactions and conveys management events.
Management Interfaces deliver and operate the Management Model (Schema & Objects).
Management Model contains Management Components that represent WS Architecture Components and relate to other Management Components.
Management Client first discovers Management Component that represents WS Architecture component it is interested in. It then navigates to other Management Components following their relationships (e.g. containment, dependency, etc.).
Management Client may operate a Management Component. That directly affects (configure, control) corresponding WS Architecture component.
WS Architecture component generates management events that are delivered via Management Component, Management Interfaces and Management Protocol directly to the Management Client. Events conform to the Management Component information schema.

WS Management Architecture Components

The diagram below formally identifies basic set of WS Management Architecture components and captures the relationships between them. More diagrams follow to define other, supplementary components and relate them to the basic components.

In other words, these are the components that we need to manage and these are the relationships that we need to reflect in the management information schema.

Figure 1: Basic WS Management Architecture components

Notes for Figure 1:

Discovery Agency may be implemented by a set of Service Instances (e.g. a replicated UDDI registry implemented at several locations). A Service Instance may implement one or more Discovery Agencies, but only Discovery Agencies are aware of that.
Service Instances are aware of the Clients and Clients are aware of the Service Instances. It is a many-to-many relationship.
A Service Instance may advertise itself using several Discovery Agencies.
A Discovery Agency keeps an inventory of advertised Service Instances.
A Service Instance concretizes one abstract Service. One abstract Service may be concretized in several Service Instances.
A Contract specifies the abstract Service. Service maintains its own Contract.
Bindings are a flavor of a Contract that makes Service Instances concrete. Service Instance maintains its own Bindings.
A Client may use several Discovery Agencies to locate Service Instances.

Figure 2: Client-Service Interaction components

Notes for Figure 2:

An Interaction is a navigable association between a Client and a Service Instance. One or two messages form the Interaction sequence. Sequence is ordered.
A Hosted Service is a flavor of a Service Instance. Hosted Services can only be Service Instances.
A Hosted Service may keep a history of Interactions that the Service Instance carried out.

Figure 3: Discovery Mechanism components

Notes for Figure 3:

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

Figure 4: Intermediary and Proxy Service components

Notes for Figure 4:

An Intermediary is a flavor of Execution Environment that contains Proxy Services.
Proxy Service is a flavor of Hosted Service. This makes Proxy Service containable in an Intermediary and, via indirect Service Instance generalization, accessible by Clients.
One Proxy Service may represent one or more Service Instances. Multiple Proxy Services may represent one (same) Service Instance.
A Service Instance, which is a Proxy Service, concretizes the same abstract Service as the one concretized by a Service Instance represented by the Proxy Service. [Read it twiceJ!]

Figure 5: Client-Proxy-Relay-Service Interaction components

Notes for Figure 5:

A Proxy Service carries out Correlated Interactions. It may record its activity.
A Proxy Service is itself a Service Instance that is exposed to external Clients.
A Proxy Service uses a Relay Point (which is a flavor of a Client) to interact with the represented Service Instance. A Proxy Service is aware of the relay and a Relay Point is aware of its controller.
Correlated Interaction encapsulates right Interaction (i.e. external Client to the Proxy Service) and left Interaction (i.e. Rely Point to the represented Service Instance).