2004 IBM Corporation WS-ResourceFramework Service Groups Tom Maguire.

© 2004 IBM Corporation

WS-ResourceFrameworkService Groups

Tom Maguire

April 16, 2004 © 2004 IBM Corporation

ServiceGroup model

•Heterogeneous by-reference collection of Web services or WS-Resources. •Can be used to form a wide variety of collections of services or WS-Resources, •Members of a ServiceGroup are represented using components called entries. •A ServiceGroup entry is a WS-Resource. •The Web service associated with a ServiceGroup entry can be composed from:

– WS-ResourceLifetime - defines standard patterns by which resources can be destroyed

– WS-BaseNotification - defines how third parties may subscribe to be informed of changes to the ServiceGroup

– WS-ResourceProperties - defines how the properties of a ServiceGroup and its entries are made accessible through a Web service interface.


ServiceGroup componentsThree sets of MEPs provide the interfaces to service groups

ServiceGroup - A Web service that is a collection of other Web services or WS-Resources and the information that pertains to them. The purpose of the group is application domain specific. The means by which the membership in the ServiceGroup is formed may be through ServiceGroupRegistration, or through other means not defined by this specification.

ServiceGroupEntry - An atomic entry in a ServiceGroup which associates a member to a ServiceGroup. A ServiceGroupEntry also contains content information by which the member’s participation in the ServiceGroup is advertised.

ServiceGroupRegistration - A ServiceGroup that provides the means to allow users of the service to explicitly insert new members.

Member - A Web service that belongs to a ServiceGroup. Note, this Web service may be a component of a WS-Resource.

Note: The member interface definition is not a part of the WS-ServiceGroup specification but is included for completeness.


ServiceGroup model


ServiceGroup characteristics

When a ServiceGroup is destroyed, all of the ServiceGroupEntries are also recommended to be destroyed. However, the members are not affected.

Once a ServiceGroup is destroyed, no assumptions can be made about either the existence of the ServiceGroupEntry or it’s contents.

A member may belong to several ServiceGroups. A member may belong to the same ServiceGroup more then once. The member of a ServiceGroup may implement message

exchanges from various interfaces. If a member is destroyed, the ServiceGroup may destroy the

corresponding ServiceGroupEntry(s). The grouping and membership aspects of a ServiceGroup are only

manifest in the linkage between a ServiceGroup and a ServiceGroupEntry. Accordingly, a ServiceGroupEntry in isolation has no semantic meaning.


ServiceGroup

MembershipContentRule – these elements specify the constraints on membership of the service group.

Entry – these elements represent the projection of the aggregation of the resource property documents of the ServiceGroup’s entry resources

ServiceGroup must support the required message exchanges defined in WS-ResourceProperties specification and may support the optional message exchanges. Additionally, a ServiceGroup must include the following resource property elements:


ServiceGroup MembershipContentRule property

MemberInterface - specifies the members to which this MembershipConentRule applies according to the interface (WSDL 1.1 portType) of the member Web service. There must be at most one MembershipContentRule for any given value of @MemberInterface.

ContentElements - specifies the content restrictions according to the list of QNames, each of which refer to a XML Schema global element declaration. This list defines the constraints on the wssg:Content resource property of the ServiceGroupEntry that must be satisfied for membership. The list may be an empty list. An empty list places no content constraints on the resource properties of the ServiceGroupEntries that match the enclosing MembershipContentRule.

<wssg:MembershipContentRule MemberInterface="QName"? ContentElements="list of QName“/>


ServiceGroup Entry property

ServiceGroupEntryEPR - Endpoint reference to the ServiceGroupEntry with which the entry is associated.

MemberServiceEPR - Endpoint reference to the member to which the entry refers.

Content - The optional Content element contains the resource property values that conform to the MembershipContentRule ContentElements attribute of the ServiceGroup.

<wssg:Entry> <wssg:ServiceGroupEntryEPR> wsa:EndpointReferenceType </wssg:ServiceGroupEntryEPR> <wssg:MemberServiceEPR> wsa:EndpointReferenceType </wssg:MemberServiceEPR> <wssg:Content> {any} </wssg:Content> ?</wssg:Entry>


ServiceGroupEntry

•Represents an appearance of a member in a ServiceGroup.

•Must belong to exactly one service group.

•May provide independent lifetime management functions for individual ServiceGroupEntry.

•If the ServiceGroupEntry implements one of the MEPs defined in WS-ResourceLifetime, then the ServiceGroupEntry may be removed from a ServiceGroup by managing the lifetime of the ServiceGroupEntry.


ServiceGroupEntry resource properties

ServiceGroupEPR – Endpoint reference to the ServiceGroup to which this entry represents membership.

MemberEPR – Endpoint reference to the member to which this entry pertains.

Content – Information pertinent to the group membership represented by the

ServiceGroupEntry.

– Must conform to the XSD element declarations in the membershipContentRule of the ServiceGroup

A ServiceGroupEntry must include the following resource property elements:

<wssg:ServiceGroupEPR> wsa:EndpointReferenceType </wssg:ServiceGroupEPR>

<wssg:MemberEPR> wsa:EndpointReferenceType </wssg:MemberEPR>

<wssg:Content> {any} </wssg:Content>


ServiceGroupEntry message exchanges

•Defines no operations.

•Should implement the MEPs and RPs from one of the WS-ResourceLifetime interfaces if it supports immediate destruction and scheduled destruction of ServiceGroupEntry resources.

•Should implement the message exchanges and resource properties for the NotificationProducer interface.

•Should also support resource property value change notification.

•Should include wssg:Content as a value of its Topics resource property.


ServiceGroupRegistration

•Defines the message exchanges allow a requestor to add entries to a ServiceGroup explicitly.

•This allows controlled aggregations of services.

•Defines no resource properties.

•Should include RPs from WS-ResourceLifetime interface in the resource property document.

•Must include RPs from the ServiceGroup interface in the resource property.


ServiceGroupRegistration Add request message<wssg:Add> <wssg:MemberEPR> wsa:EndpointReferenceType </wssg:MemberEPR> <wssg:Content> {any} </wssg:Content> <wssg:InitialTerminationTime> xsd:dateTime </wssg:InitialTerminationTime> ?</wssg:Add>

MemberEPR - Endpoint reference of the member to include in the ServiceGroup. It must satisfy the semantics of the MemberhipContentRules.

Content - Information to associate with the MemberEPR in the ServiceGroup. This must be an element that conforms to those MembershipContentRules that apply to the member. This input may be augmented or modified with other information that the ServiceGroup may derive. This allows for tailoring.

InitialTerminationTime - Optional element, indicating the requestor’s suggestion for the initial setting of the termination time resource property of the ServiceGroupEntry.


ServiceGroupRegistration Add response message<wssg:AddResponse> wsa:EndpointReferenceType</wssg:AddResponse>

•Must respond with an AddResponse message.

•Content of a AddResponse message is an EndpointReference of the ServiceGroupEntry that was created.

•EndpointReference returned must implement the MEPs and RPs of ScheduledResourceTermination interface the ImmediateResourceTermination interface.


So what is it good for…

Collections – Aggregations

– Relationships Registries


Architecting Registries

There is no single registry that can serve all purposes– A community must architect registries that are appropriate to their needs

But there are common primitives that can be used to architect many different registries

– Resource Properties

– Notification

– Soft-state Registration


Need for Different Queries

Need registries that can answer radically different queries– “Find me all Redhat Linux 7.2 machines which are available for my use

with a load < 0.3.”– Requires a registry that can deal with dynamic information

– “Find me both an available cluster and a one my project database servers with good network connectivity between them.”

– Requires a registry that can join information from multiple services


Use of Resource Properties (content)

A registry’s content should be architected to support query requirements

– Customized XML types

– More powerful (e.g. Xpath, Xquery) or custom query languages

A registry is defined largely by its content and query language


Hierarchical with Caching

Soft-state registration up the tree– Various services in an organization are configured to send soft-state registrations

to registries

– Registry services may be configured to send soft-state registrations to higher-level registries

Query & Subscription down the tree– Registry gathers information that it cares about from each registered service or

resource

– Registry caches that information as its content, with some refresh policy


Hierarchical with Forwarding

Soft-state registration up the treeForwards query & subscription down the tree

– When registry receives query from client, it:– Queries lower level registries & services– Collects results, formats them appropriately– Replies to client query

2004 IBM Corporation WS-ResourceFramework Service Groups Tom Maguire.

Documents

Transcript of 2004 IBM Corporation WS-ResourceFramework Service Groups Tom Maguire.