1. © 2004 IBM Corporation WS-ResourceFramework Service Groups Tom Maguire

2. 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.

3. April 16, 2004 © 2004 IBM Corporation ServiceGroup components Three 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.

4. April 16, 2004 © 2004 IBM Corporation ServiceGroup model

5. April 16, 2004 © 2004 IBM Corporation 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.

6. April 16, 2004 © 2004 IBM Corporation 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:

7. April 16, 2004 © 2004 IBM Corporation 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“ />

8. April 16, 2004 © 2004 IBM Corporation 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. wsa:EndpointReferenceType {any} ?

9. April 16, 2004 © 2004 IBM Corporation 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.

10. April 16, 2004 © 2004 IBM Corporation 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: wsa:EndpointReferenceType {any}

11. April 16, 2004 © 2004 IBM Corporation 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.

12. April 16, 2004 © 2004 IBM Corporation 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.

13. April 16, 2004 © 2004 IBM Corporation ServiceGroupRegistration Add request message wsa:EndpointReferenceType {any} xsd:dateTime ?  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.

14. April 16, 2004 © 2004 IBM Corporation ServiceGroupRegistration Add response message wsa:EndpointReferenceType 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.

15. April 16, 2004 © 2004 IBM Corporation So what is it good for…  Collections –Aggregations –Relationships  Registries

16. April 16, 2004 © 2004 IBM Corporation The Registration interface may be used to register services or resources with a registry –A set of services or resources can periodically register their endpoint references into a registry service, to allow for discovery of services in that set –Just registration of existence, not of information Registrations are exposed in the resource properties of the registry service –Standard discovery mechanisms can then be used to discover registered services –Content schema may be registry specific Registration interface allows

17. April 16, 2004 © 2004 IBM Corporation 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

18. April 16, 2004 © 2004 IBM Corporation 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

19. April 16, 2004 © 2004 IBM Corporation 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

20. April 16, 2004 © 2004 IBM Corporation 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

21. April 16, 2004 © 2004 IBM Corporation Hierarchical with Forwarding Soft-state registration up the tree Forwards 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