Web Services Service Group 1.2
(WS-ServiceGroup)

OASIS Standard, 1 April 2006

Document identifier:

 wsrf-ws_service_group-1.2-spec-os

Location:

http://docs.oasis-open.org/wsrf/wsrf-ws_service_group-1.2-spec-os.pdf

Editors:

Tom Maguire, IBM <tmaguire@us.ibm.com>

David Snelling, Fujitsu <David.Snelling@UK.Fujitsu.com>

Tim Banks, IBM <Tim_Banks@uk.ibm.com>

Abstract:

A ServiceGroup is a heterogeneous by-reference collection of Web services. ServiceGroups can be used to form a wide variety of collections of services or WS-Resources [WS-Resource], including registries of services and associated 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 a variety of Web services standards including WS-ResourceLifetime [WS-ResourceLifetime] which defines standard patterns by which resources can be destroyed, WS-BaseNotification [WS-BaseNotification] which defines how third parties may subscribe to be informed of changes to the ServiceGroup and WS-ResourceProperties [WS-ResourceProperties] which defines how the properties of a ServiceGroup and its entries are made accessible through a Web service interface.

Status:

This document is an OASIS Standard.

Committee members should send comments on this specification to the wsrf@lists.oasis-open.org list. Others may submit comments to the TC via the web form found on the TC's web page at http://www.oasis-open.org/committees/wsrf. Click the button for "Send A Comment" at the top of the page. Submitted comments (for this work as well as other works of that TC) are publicly archived and can be viewed at
http://lists.oasis-open.org/archives/wsrf-comment/.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the WSRF TC web page
(http://www.oasis-open.org/committees/wsrf/).

 


Table of Contents

1      Introduction. 5

1.1        Goals and Requirements. 5

1.1.1     Requirements. 5

1.1.2     Non-Goals. 5

1.2        Notational Conventions. 6

1.3        Namespaces. 6

1.4        Fault Definitions. 7

2      Example. 8

3      Terminology and Concepts. 10

4      Grouping Services. 11

5      ServiceGroup. 12

5.1        ServiceGroup ResourceProperties. 12

5.1.1     MembershipContentRule Resource Property. 12

5.1.2     Entry Resource Property. 13

5.2        ServiceGroup: Operations. 14

6      ServiceGroupEntry. 15

6.1        ServiceGroupEntry: Resource Property Declarations. 15

6.1.1     ServiceGroupEPR. 15

6.1.2     MemberEPR. 15

6.1.3     Content 16

6.2        ServiceGroupEntry: Message Exchanges. 16

7      ServiceGroupRegistration. 17

7.1        ServiceGroupRegistration: Resource Property Declarations. 17

7.2        Add. 17

7.2.1     Example SOAP Encoding of the Add Message Exchange. 19

8      Notification of ServiceGroup Modification. 21

8.1        EntryAdditionNotification Message. 22

8.2        EntryRemovalNotification Message. 22

9      Security Model 24

9.1        Securing the message exchanges. 24

9.2        Securing the resource properties. 24

9.2.1     A Note on MembershipContentRules. 24

Appendix A. Acknowledgments. 25

10     References. 26

10.1      Normative. 26

10.2      Non-Normative. 26

Appendix B. XML Schema. 27

Appendix C. WSDL 1.1. 33

Appendix D. Revision History. 38

Appendix E. Notices. 41

 

1        Introduction

In this document, we consider a distributed computing environment consisting of Web services and resources. A pattern defining the relationship between Web services and resources is detailed in WS-Resource [WS-Resource]. The term WS-Resource is used to describe the relationship between a Web service and a resource.

This WS-ServiceGroup specification defines a means by which Web services and WS-Resources can be aggregated or grouped together for a domain specific purpose. In order for requestors to form meaningful queries against the contents of the ServiceGroup, membership in the group must be constrained in some fashion. The constraints for membership are expressed by intension using a classification mechanism. Further, the members of each intension must share a common set of information over which queries can be expressed.

In this specification, the ServiceGroup membership rules, membership constraints and classifications are expressed using the resource property model [WS-ResourceProperties]. Groups are defined as a collection of members that meet the constraints of the group. The ServiceGroupRegistration interface extends the basic ServiceGroup capabilities with message exchanges for managing the membership of a ServiceGroup.

The ServiceGroup and ServiceGroupRegistration interfaces defined in this document are commonly expected to be composed with other application domain specific interfaces, which define more specialized interaction with the service group and/or with the services that are members of the service group. For example, specialized interfaces may offer means of querying the contents of the ServiceGroup, and for performing collective operations across members of the ServiceGroup.

WS-ServiceGroup is inspired by a portion of the Global Grid Forum’s “Open Grid Services Infrastructure (OGSI) Version 1.0” specification [OGSI 1.0].

1.1      Goals and Requirements

The goal of WS-ServiceGroup is to standardize the terminology, concepts, message exchanges, WSDL and XML needed to express the aggregations of Web services and resources as defined by the WS-Resource [WS-Resource].

1.1.1      Requirements

This specification intends to satisfy the following requirements:

·         Define the standard resource properties by which a requestor can query and retrieve contents of a service group.

·         Define the standard resource properties by which a requestor can query and retrieve details of an entry in the service group.

·         Define standard message exchanges and resource properties by which a requestor can add new entries for a member in a service group.

1.1.2      Non-Goals

The following topics are outside the scope of this specification:

·         It is not an objective of this specification to define the message exchanges representing the function of a member.

1.2      Notational Conventions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119].

When describing abstract data models, this specification uses the notational convention used by the [XML-Infoset]. Specifically, abstract property names always appear in square brackets (e.g., [some property]).

This specification uses a notational convention, refered to as “Pseudo-schemas” in a fashion similar to the WSDL 2.0 Part 1 specification [WSDL 2.0]. A Pseudo-schema uses a BNF-style convention to describe attributes and elements:

·         `?' denotes optionality (i.e. zero or one occurrences),

·         `*' denotes zero or more occurrences,

·         `+' one or more occurrences,

·         `[' and `]' are used to form groups,

·         `|' represents choice.

·         Attributes are conventionally assigned a value which corresponds to their type, as defined in the normative schema.

<!-- sample pseudo-schema -->

<element

      required_attribute_of_type_QName="xs:QName"

      optional_attribute_of_type_string="xs:string"? >

  <required_element />

  <optional_element />?

  <one_or_more_of_these_elements />+

  [ <choice_1 /> | <choice_2 /> ]*

</element>

Where there is disagreement between the separate xml schema and wsdl files describing the messages defined by this specification and the normative descriptive text (excluding any pseudo-schema) in this document, the normative descriptive text will take precedence over the separate files. The separate files take precedence over any pseudo-schema and over any schema and wsdl included in the appendices.

1.3       Namespaces

The following namespaces are used in this document:

Prefix

Namespace

s11

http://schemas.xmlsoap.org/soap/envelope

xsd

http://www.w3.org/2001/XMLSchema

wsa

http://www.w3.org/2005/08/addressing

wsrf-bf

http://docs.oasis-open.org/wsrf/bf-2

wsrf-rp

http://docs.oasis-open.org/wsrf/rp-2

wsrf-rpw

http://docs.oasis-open.org/wsrf/rpw-2

wsrf-rl

http://docs.oasis-open.org/wsrf/rl-2

wsrf-rw

http://docs.oasis-open.org/wsrf/rw-2

wsnt

http://docs.oasis-open.org/wsn/b-2

wsrf-sg

http://docs.oasis-open.org/wsrf/sg-2

wsrf-sgw

http://docs.oasis-open.org/wsrf/sgw-2

wstop

http://docs.oasis-open.org/wsn/t-1

1.4      Fault Definitions

All faults generated by a WS-Resource SHOULD be compliant with the WS-BaseFaults [WS-BaseFaults] specification.

All faults defined by this specification MUST use the following wsa:Action URI:

http://docs.oasis-open.org/wsrf/fault

2        Example

As an example of using a service group, let's consider a group containing services that one has accessed recently.  In effect, this is a Web services equivalent of a Web browser's "history" feature.  The services that have been accessed can implement any interface.  They could be simple Web services or Web services that are part of a WS-Resource, so they can have resource properties or not.

The only constraint the group has on its members is that the membership information of the members contains the date of last interaction with the service and whether the outcome or this interaction was successful or not. This constraint is exposed by the following membership rule:

<wsrf-sg:MembershipContentRule

  ContentElements="ns1:DateOfLastInvoke ns1:Outcome”/>

In the schema for the namespace referenced by prefix ns1, ns1:DateOfLastInvoke has been defined as an xsd:dateTime representing when the member service was last invoked and ns1:Outcome has been defined as either "success" or "failure" and is used to represent the outcome of the last invocation. 

Let us now modify the example to one where the services invoked can include one of two different types: a catalog service or a purchase service.  In addition, if the service invoked was a purchase service, we want the amount of the purchase to be specified as a content element in the membership.  The set of rules to describe the constraints of this group now is:

<wsrf-sg:MembershipContentRule

  ContentElements="ns1:DateOfLastInvoke ns1:Outcome”/>

 

<wsrf-sg:MembershipContentRule

    MemberInterfaces="ns2:CatalogPortType"

    ContentElements=""/>

 

<wsrf-sg:MembershipContentRule

    MemberInterfaces="ns3:PurchasePortType"

    ContentElements="ns3:PurchaseAmount"/>

As a result, the WS-Resource that represents the membership of a service of type ns3:PurchasePortType in the service group is guaranteed to include the elements described by the following pseudo-schema:

<wsrf-sg:Content>

  <ns1:DateOfLastInvoke>xsd:dateTime</ns1:DateOfLastInvoke>

  <ns1:Outcome>xsd:string</ns1:Outcome>

  <ns3:PurchaseAmount>xsd:nonNegativeInteger</ns3:PurchaseAmount>

</wsrf-sg:Content>

The WS-Resource that represents the membership of a service of type ns2:CatalogPortType is not required to contain the property ns3:PurchaseAmount.

Once this service group has been established, requestors can retrieve the composition of the group, subscribe for notifications on modification of the group composition (if supported) and retrieve content elements of the memberships by using the mechanisms described in this specification.

3        Terminology and Concepts

The following definitions outline the terminology and usage in this specification. This section gives only brief description of these terms

Member:

o        A Web service that belongs to a ServiceGroup. Note, this Web service may be a component of a WS-Resource as defined in “Web Services Resources” [WS-Resource].

ServiceGroup:

o        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:

o        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:

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

4        Grouping Services

A ServiceGroup maintains information about a collection of Web services. Each of the Web services represented in the collection may be a component of a WS-Resource. These Web services may be members of a ServiceGroup for a specific reason, such as being part of a federated service, or they may have no specific relationship, such as the Web services contained in an index or registry operated for Web service discovery purposes.

Three sets of message exchanges provide the interface to service groups ServiceGroup, ServiceGroupEntry and ServiceGroupRegistration. The member interface is not a part of the WS-ServiceGroup specification but is included for completeness. The depiction below details the interfaces relevant to ServiceGroups.


5        ServiceGroup

A ServiceGroup is a WS-Resource and MUST comply with the definition of a WS-Resource in [WS-Resource]; the ServiceGroup represents a collection of other Web services. The individual services represented within the ServiceGroup are the ServiceGroup’s members, or its membership. The model for membership of a ServiceGroup is an entry resource property of the ServiceGroup. An entry WS-Resource also represents an association with a given member in the ServiceGroup and is used to manage the membership relationship. Additionally a ServiceGroup has the following characteristics:

o        When a ServiceGroup WS-Resource is destroyed, all of the ServiceGroupEntry WS-Resources are also RECOMMENDED to be destroyed. Note however, that the actual member Web services or WS-Resources are not affected.

o        Once a ServiceGroup is destroyed, a requestor MUST make no assumptions about either the existence of the entry WS-Resources or the validity of the contents of those WS-Resources.

o        A member MAY belong to several ServiceGroups.

o        A member MAY belong to the same ServiceGroup more then once.

o        The member of a ServiceGroup MAY implement message exchanges from various interfaces.

o        If a member WS-Resource is destroyed, the ServiceGroup MAY destroy the corresponding entry WS-Resource.

o        A ServiceGroupEntry in isolation has no semantic meaning.

5.1      ServiceGroup ResourceProperties

In addition to the message exchanges described in this specification, a ServiceGroup MUST also support the required message exchanges defined in the WS-ResourceProperties specification and MAY support the optional message exchanges defined in the WS-ResourceProperties specification. The resource property document defined by the ServiceGroup MUST include the following resource property elements.

5.1.1      MembershipContentRule Resource Property

The resource property document contains a potentially empty set of MembershipContentRule elements that specify the intensional constraints on membership of the service group.  That is, membership can be restricted to members that implement particular interfaces and/or it can require the presence of particular child elements in the wsrf-sg:Content resource property of the ServiceGroupEntry representing the membership in the group.

The ServiceGroup resource property document MAY contain zero MembershipContentRule child elements.  When no MembershipContentRule elements are specified, the members of the ServiceGroup are unconstrained.  When the ServiceGroup is unconstrained any member MAY be present in the ServiceGroup.

When at least one MembershipContentRule element specification exists, the members of the ServiceGroup are constrained.  When the ServiceGroup is constrained, the ServiceGroup MUST NOT include a member that does not conform to at least one MembershipContentRule element.  If more than one rule applies to a given member all rules that apply MUST be satisfied.  Membership conformance to an individual MembershipContentRule is described below in the MembershipContentRule component constraints.

The general form of a MembershipContentRule resource property element is:

<wsrf-sg:MembershipContentRule

    MemberInterfaces="list of QName"?

    ContentElements="list of QName"

/>

(see Appendix I: MembershipContentRule element definition & Appendix II: ServiceGroup resource property)

This resource property element is further constrained as follows:

/wsrf-sg:MembershipContentRule

The MembershipContentRule constrains the ServiceGroup membership to those members that implement the interfaces described below in /wsrf-sg:membershipContentRule/@MemberInterfaces if present. A MembershipContentRule is further satisfied according to the rules defined below in wsrf-sg:membershipContentRule/@ContentElements.

/wsrf-sg:membershipContentRule/@MemberInterfaces

This optional attribute, when present, specifies the members to which this MembershipConentRule applies according to the interface (WSDL 1.1 portType) of the member Web service. 

A MembershipContentRule applies to a member if, for each QName in the value of @MemberInterfaces, there is a corresponding interface (WSDL 1.1 portType) of the member Web service whose name matches that QName.  Two QNames are equivalent when they have the same local part and they have prefixes which have been bound to namespace names that are identical [XML-Names].  If this attribute is not present, all members MUST satisfy the enclosing MembershipContentRule’s @ContentElements constraint.

/wsrf-sg:membershipContentRule/@ContentElements

This attribute 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 wsrf-sg:Content resource property of the ServiceGroupEntry that MUST be satisfied for membership.  The list MAY be an empty list.  When an empty list is specified there are no content constraints on the resource properties of the ServiceGroupEntries that match the enclosing MembershipContentRule. 

A member satisfies a MembershipContentRule if, for each QName in the value of @ContentElements, there is at least one child element of the wsrf-sg:Content of the ServiceGroupEntry’s resource properties document whose name matches that QName.  Two QNames are equivalent when they have the same local part and they have prefixes which have been bound to namespace names that are identical [XML-Names].

Note: It is possible to construct a MembershipContentRule without a MemberInterface and with an empty list for the ContentElements.  Such a MembershipContentRule would have no effect on the membership as per the normative semantics described for this component.

5.1.2      Entry Resource Property

An Entry resource property is a projection of the aggregation of the resource property documents of the ServiceGroup’s entry WS-Resources. An Entry resource property has the following form:

<wsrf-sg:Entry>

   <wsrf-sg:ServiceGroupEntryEPR>

     wsa:EndpointReferenceType

   </wsrf-sg:ServiceGroupEntryEPR>

   <wsrf-sg:MemberServiceEPR>

     wsa:EndpointReferenceType

   </wsrf-sg:MemberServiceEPR>?

   <wsrf-sg:Content>

     <wsrf-sg:RPDoc>

       {any}

     </wsrf-sg:RPDoc> ?

     {any} *

   </wsrf-sg:Content> ?

</wsrf-sg:Entry>

(see Appendix I: Entry type and element definition & Appendix II: ServiceGroup resource property)

This resource property element is further constrained as follows

/wsrf-sg:Entry

The entry provides the logical structure of the constituent members of the ServiceGroup. There is one entry element for each member in the ServiceGroup. In the event of an entry’s removal or destruction from a ServiceGroup, the corresponding element in the ServiceGroup’s resource property MUST also be removed. The removal of the element from the ServiceGroup’s resource property SHOULD occur temporally near the removal or destruction of the entry.

/wsrf-sg:Entry/ServiceGroupEntryEPR

Endpoint reference as defined in [WS-Addressing] to the ServiceGroupEntry WS-Resource with which the entry is associated.

/wsrf-sg:Entry/MemberServiceEPR

This optional element is the endpoint reference as defined in [WS-Addressing] to the member to which the entry refers.

/wsrf-sg:Entry/Content

The optional Content element contains the resource property values that conform to the wsrf-sg:MembershipContentRule/@ContentElements of the ServiceGroup. In the absence of concurrency controls a requestor MUST NOT assume that this element will be identical to the element that the WS-Resource, referenced by @ServiceGroupEntryEPR, contains in its wsrf-sg:Content resource property.  In the case that wsrf-sg:Entry/Content is not identical to the wsrf-sg:Content resource property of the WS-Resource referenced by the @ServiceGroupEntryEPR then the wsrf-sg:Content is assumed to be authoritative.  (For further discussion reference "ACID Properties of Operations on WS-Resources" [WS-ResourceProperties])

/wsrf-sg:Entry/Content/RPDoc

This optional element, if present, MUST be conformant to the schema associated with the wsrf-rp:ResourceProperties extensibility attribute from the portType associated with the member service.  The contents of this element SHOULD be identical to the contents of the member's ResourcePropertyDocument.

5.2      ServiceGroup: Operations

The ServiceGroup interface defines no message exchanges. A ServiceGroup SHOULD implement one of the message exchange sets defined in WS-ResourceLifetime if it needs to support either immediate resource destruction or scheduled resource destruction.

6        ServiceGroupEntry

The representation of a member Web service within the ServiceGroup is a managed by a WS-Resource.  The Web service component of this WS-Resource implements the ServiceGroupEntry interface.  The ServiceGroupEntry interface describes the requirements on the Web service through which management of the entry occurs.

A member MAY appear in a ServiceGroup multiple times.  A separate ServiceGroupEntry WS-Resource represents each appearance of that member in a ServiceGroup.  A ServiceGroupEntry WS-Resource MUST belong to exactly one service group.

A ServiceGroupEntry interface MAY provide additional management functions for a ServiceGroupEntry WS-Resource.  In particular, it MAY provide independent lifetime management functions for individual ServiceGroupEntry WS-Resources (if it implements message exchanges defined in WS-ResourceLifetime).  In the case where the ServiceGroupEntry Web service implements one of the message exchange sets defined in WS-ResourceLifetime, a ServiceGroupEntry WS-Resource MAY be removed from a ServiceGroup by managing the lifetime of the ServiceGroupEntry WS-Resource. Additional message exchanges MAY be defined to provide more advanced ServiceGroupEntry capabilities.

6.1      ServiceGroupEntry: Resource Property Declarations

In addition to the message exchanges described in this specification, a ServiceGroupEntry MUST also support the required message exchanges defined in the WS-ResourceProperties specification and MAY support the optional message exchanges defined in the WS-ResourceProperties specification.

6.1.1      ServiceGroupEPR

The general form of a ServiceGroupEPR resource property element is:

<wsrf-sg:ServiceGroupEPR>

  wsa:EndpointReferenceType

</wsrf-sg:ServiceGroupEPR>

(see Appendix I: ServiceGroupEPR element definition & Appendix II: ServiceGroupEntry resource property)

This resource property element is further constrained as follows:

/wsrf-sg:ServiceGroupEPR

Contains an endpoint reference [WS-Addressing] to the ServiceGroup of which this entry represents membership. This endpoint reference MUST refer to the same Web service or WS-Resource throughout the lifetime of the ServiceGroupEntry.

6.1.2      MemberEPR

The general form of a MemberEPR resource property element is:

<wsrf-sg:MemberEPR>

  wsa:EndpointReferenceType

</wsrf-sg:MemberEPR>?

(see Appendix I: MemberEPR element definition & Appendix II: ServiceGroupEntry resource property)

This resource property element is further constrained as follows:

/wsrf-sg:MemberEPR

This optional element contains an endpoint reference [WS-Addressing] to the member to which this entry pertains. If present, this endpoint reference MUST refer to the same Web service or WS-Resource throughout the lifetime of the ServiceGroupEntry.

6.1.3      Content

The general form of the Content resource property element is:

<wsrf-sg:Content>

  <wsrf-sg:RPDoc>

    {any}

  </wsrf-sg:RPDoc> ?

  {any} *

</wsrf-sg:Content>

(see Appendix I: Content element definition & Appendix II: ServiceGroupEntry resource property)

This resource property element is further constrained as follows:

/wsrf-sg:Content

This XML element contains information pertinent to the group membership represented by the ServiceGroupEntry. The Content elements conform to the XSD element declarations listed (by QName) in the membershipContentRule resource property of the ServiceGroup containing this ServiceGroupEntry.

/wsrf-sg:Content/RPDoc

This optional element, if present, MUST be conformant to the schema associated with the wsrf-rp:ResourceProperties extensibility attribute from the portType associated with the member service.  The contents of this element SHOULD be identical to the contents of the member's ResourcePropertyDocument.

6.2      ServiceGroupEntry: Message Exchanges

The ServiceGroupEntry interface defines no operations. The service implementing the ServiceGroupEntry interface SHOULD implement the message exchanges and resource properties from one of the interfaces described in WS-ResourceLifetime if it supports immediate destruction and scheduled destruction of ServiceGroupEntry resources. In addition, the service implementing the ServiceGroupEntry interface SHOULD implement the message exchanges and resource properties for the NotificationProducer interface [WS-BaseNotification]. The service implementing the ServiceGroupEntry SHOULD also support resource property value change notification as defined in [WS-ResourceProperties]. In particular, it SHOULD include wsrf-sg:Content as a value of its Topics resource property.        

7        ServiceGroupRegistration

The ServiceGroupRegistration interface is an extension of the ServiceGroup interface. ServiceGroupRegistration defines the message exchanges that allow a requestor to add entries to a ServiceGroup WS-Resource explicitly. Third party controlled aggregations of services are made possible by the ServiceGroupRegistration extension of ServiceGroup.

7.1      ServiceGroupRegistration: Resource Property Declarations

The ServiceGroupRegistration interface defines no resource properties. The resource properties defined by the interfaces in WS-ResourceLifetime SHOULD be included in the ResourceProperty document of a ServiceGroupRegistration. The resource properties defined in the ServiceGroup interface MUST be included in the resource property document of a ServiceGroupRegistration.

7.2      Add

When a requestor wishes to add a new entry to a ServiceGroup WS-Resource, the requestor must issue a request message of the following form:

<wsrf-sg:Add>

  <wsrf-sg:MemberEPR>

    wsa:EndpointReferenceType

  </wsrf-sg:MemberEPR>

  <wsrf-sg:Content>

    {any}

  </wsrf-sg:Content>

  <wsrf-sg:InitialTerminationTime>

    [xsd:dateTime | xsd:duration]

  </wsrf-sg:InitialTerminationTime>?

</wsrf-sg:Add>

The components of the Add message are further described as follows:

/wsrf-sg:Add/MemberEPR

This component contains the endpoint reference of the member Web service to include in the ServiceGroup. It MUST satisfy the semantics as specified by the ServiceGroup resource property /wsrf-sg:MemberhipContentRules.

/wsrf-sg:Add/Content

This component contains information to associate with the MemberEPR in the ServiceGroup. This component represents input for the ServiceGroupEntry content element. This input MAY be augmented or modified with other information that the ServiceGroup may derive. This allows the ServiceGroup to tailor or modify the content.  

/wsrf-sg:Add/InitialTerminationTime

An optional element, indicating the requestor’s suggestion for the initial setting of the termination time resource property [WS-ResourceLifetime] of the ServiceGroupEntry WS-Resource. 

There are two forms of this element, absolute time and duration. If the type of this element is xsd:dateTime, the value of the element is to be interpreted as an “absolute time”. If the type of this element is xsd:duration, the value of the element is to be interpreted as a “relative time” or “duration”. Regardless of the form, time is relative to the time source used by the ServiceGroup.

The duration form is used to “compute” the “absolute time” form in the following fashion. The value of this element in “absolute time” form is computed by adding the xsd:duration value to the current time value of the ServiceGroup.

The “absolute time” form (whether computed from a duration, or contained within the request message) is used to initialize the value of the TerminationTime resource property of the ServiceGroupEntry resource.

If the ServiceGroup is unable or unwilling to set the TerminationTime resource property of the ServiceGroupEntry resource to the given value of the “absolute time” form or a value greater, then the Add request MUST fault. If the value is not “in the future” relative to the current time as known by the ServiceGroup, the Add request MUST fault. The use of the xsi:nil attribute with value “true” indicates there is no scheduled termination time requested for the ServiceGroupEntry. If the element does not include the time zone designation, the value of the element MUST be interpreted as universal time (UTC) time.

If this element is not included, the initial value of the TerminationTime resource property is dependent on the implementation of the ServiceGroup.

If a ServiceGroupRegistration accepts the Add request it MUST update the TerminationTime resource property of the resulting ServiceGroupEntry WS-Resource to the value specified in the message or to a value “in the future” relative to the requested time.

The wsa:Action MUST contain the URI http://docs.oasis-open.org/wsrf/sgw-2/ServiceGroupRegistration/AddRequest.

If the ServiceGroupRegistration accepts the request to add a member, it MUST respond with an AddResponse message of the following form:

<wsrf-sg:AddResponse>

  <wsrf-sg:ServiceGroupEntryReference>

    wsa:EndpointReferenceType

  </wsrf-sg:ServiceGroupEntryReference>

  <wsrf-sg:TerminationTime xsi:nil=”xsd:boolean”?>

     xsd:dateTime

  </wsrf-sg:TerminationTime>

  <wsrf-sg:CurrentTime>

     xsd:dateTime

  </wsrf-sg:CurrentTime>

</wsrf-sg:AddResponse>

Further constraints on the AddResponse message are as follows:

/wsrf-sg:AddResponse/wsrf-sg:ServiceGroupEntryReference

An EndpointReference as described in [WS-Addressing].  This endpoint reference refers to the ServiceGroupEntry WS-Resource created by the ServiceGroup to represent the association of the member within the ServiceGroup. The Web service associated with the ServiceGroupEntry returned by the AddResponse MUST implement the message exchanges and resource properties specified by the ScheduledResourceTermination interface and the ImmediateResourceTermination interface [WS-ResourceLifetime].

/wsrf-sg:AddResponse/wsrf-sg:TerminationTime

This value MAY be “in the future” relative to the xsd:dateTime requested by the service requestor in the wsrf-sg:AddRequest/wsrf-sg:InitialTerminationTime.

This value reflects the new date and time at which the ServiceGroupEntry WS-Resource is scheduled to be destroyed. If the value is xsi:nil, it implies that the resource will not be destroyed for an indefinite period of time.

This value MUST also be reflected through the value of the TerminationTime resource property.

/wsrf-sg:AddResponse/wsrf-sg:CurrentTime

This value MUST be the time, as it is known by the ServiceGroup, at which the WS-Resource processed this AddRequest message.

 

The wsa:Action MUST contain the URI http://docs.oasis-open.org/wsrf/sgw-2/ServiceGroupRegistration/AddResponse.

 

If the WS-Resource does not respond to the Add request message with the AddResponse message, then it MUST send a fault. This specification defines the following faults associated with failure to process the Add request message, in addition to those faults defined for all WS-Resources in [WS-Resource]:

ContentCreationFailedFault:

The operation was unable to create a valid Content element (as defined by the membershipContentRule resource property) from the provided Content and MemberEPR components of the Add request message.

UnsupportedMemberInterfaceFault:

The member service referred to by the MemberEPR argument is not conformant with the MembershipContentRule.

AddRefusedFault:

The ServiceGroupRegistration refused to create a new entry for the member service based the semantics of the ServiceGroupRegistration (or subtype).

One of these faults, or a specialization thereof, SHOULD be sent upon failure although other fault messages MAY be returned instead.

 

7.2.1      Example SOAP Encoding of the Add Message Exchange

The following is a non-normative example of an Add request message using SOAP 1.1 [SOAP 1.1].

<s11:Envelope xmlns….>

  <s11:Header>

    <wsa:Action>

      http://docs.oasis-open.org/wsrf/sgw-2/ServiceGroupRegistration/AddRequest

    </wsa:Action>

  </s11:Header>

  <s11:Body>

    <wsrf-sg:Add>

      <wsrf-sg:MemberEPR>

         <wsa:Address>

            http://www.producer.org/ProducerEndpoint

         </wsa:Address>

         <wsa:ReferenceParameters>

           <npex:ResourceDisambiguator>

               uuid:84decd55-7d3f-65ad-ac44-675d9fce5d22

           </npex:ResourceDisambiguator>

         </wsa:ReferenceParamenters>

      </wsrf-sg:MemberEPR>

      <wsrf-sg:Content>

        <wsn:TopicExpression>

          wsrf-rp:ResourcePropertyValueChangeNotification

        </wsn:TopicExperssion>

      </wsrf-sg:Content>

      <wsrf-sg:InitialTerminationTime>

         2003-12-25T00:00:00.00000Z

      </wsrf-sg:InitialTerminationTime>

    </wsrf-sg:Add>

  </s11:Body>

</s11:Envelope>

The following is a non-normative example of an Add response message using SOAP 1.1 [SOAP 1.1]:

<s11:Envelope xmlns… >

  <s11:Header>

    <wsa:Action>

        http://docs.oasis-open.org/wsrf/sgw-2/ServiceGroupRegistration/AddResponse

    </wsa:Action>

  </s11:Header>

  <s11:Body>

    <wsrf-sg:AddResponse>

      <wsrf-sg:ServiceGroupEntryReference>

        <wsa:Address>

           http://www.producer.org/ServiceGroupEndpoint

        </wsa:Address>

        <wsa:ReferenceParameters>

          <npex:ResourceDisambiguator>

             uuid:95fefeb3-f37d-5dfe-44fe-675d9fce12df

          </npex:ResourceDisambiguator>

        </wsa:ReferenceParameters>

      </wsrf-sg:ServiceGroupEntryReference>

      <wsrf-sg:TerminationTime>

         2003-12-31T12:00:00Z

      </wsrf-sg:TerminationTime>

      <wsrf-sg:CurrentTime>

         2003-12-20T11:00:00Z

      </wsrf-sg:CurrentTime>

    </wsrf-sg:AddResponse>

  </s11:Body>

</s11:Envelope>

8        Notification of ServiceGroup Modification

If the Web service component of the ServiceGroup WS-Resource also implements the NotificationProducer interface defined by the WS-BaseNotification specification [WS-BaseNotification], then it MUST provide a topic [WS-Topics] to allow requestors to subscribe for notification of the modification of the ServiceGroup. The form of the TopicNamespace [WS-Topics] is:

<wstop:TopicNamespace name="ServiceGroupTopicNamespace"

   targetNamespace="http://docs.oasis-open.org/wsrf/sg-2"

   xmlns:wsrf-rp="http://docs.oasis-open.org/wsrf/rp-2"

   xmlns:wstop="http://docs.oasis-open.org/wsn/t-1" >

   <wstop:Topic name="ServiceGroupModification" >

      <wstop:MessagePattern>

         <wsrf-rp:QueryExpression

           dialect=”http://www.w3.org/TR/1999/REC-xpath-19991116” >

              boolean((/*/*EntryAdditionNotification

                \[namespace-uri()='http://docs.oasis-open.org/wsrf/sg-2']) |

                (/*/*EntryRemovalNotification

                \[namespace-uri()='http://docs.oasis-open.org/wsrf/sg-2']))

             boolean(/*/EntryAdditionNotification |

                     /*/ EntryRemovalNotification)

         </wsrf-rp:QueryExpression>

      </wstop:MessagePattern>

   </wstop:Topic>

</wstop: TopicNamespace>

 

This TopicNamespace defines the TopicNamespace associated with the WS-ServiceGroup XML namespace (http://docs.oasis-open.org/wsrf/sg-2). The TopicNamespace is further constrained as follows:

/wstop: TopicNamespace/@name

The name of the TopicNamespace associated with the WS-ServiceGroup XML namespace MUST be “ServiceGroupTopicNamespace”.

/wstop:Topic

This topic is associated with notification messages when a ServiceGroupEntries are added or removed from a ServiceGroup. A Web service that supports the message exchanges associated with the NotificationProducer role as specified in WS-BaseNotification and that wishes to support subscriptions and notifications related to ServiceGroup modifications SHOULD include this topic in its list of supported topics. When a ServiceGroup detects that the contents of the group have been modified, it SHOULD create a notification message artifact recording the situation and, if the message artifact is generated, it MUST associate this notification message with this topic. Note: there are many circumstances in which a modification of a ServiceGroup does not result in the generation of a notification message.

/wstop:Topic/@name

The name of the Topic representing ServiceGroup modifications MUST be named “ServiceGroupModification”. The namespace property of this topic MUST be the WS-ServiceGroup XML namespace (http://docs.oasis-open.org/wsrf/sg-1).

/wstop:Topic/wstop:MessagePattern

This topic is associated with messages that MUST contain an wsrf-sg:EntryAdditionNotification element or an wsrf-sg:EntryRemovalNotification element. These elements and their corresponding complexTypes are described later in this section.

8.1      EntryAdditionNotification Message

The wsrf-sg:EntryAdditionNotification element is a form of notification message associated with the wsrf-sg:ServiceGroupModification topic.  This element is defined as follows:

<wsrf-sg:EntryAdditionNotification>

   <wsrf-sg:ServiceGroupEntryEPR>

     wsa:EndpointReferenceType

   </wsrf-sg:ServiceGroupEntryEPR>

   <wsrf-sg:MemberServiceEPR>?

     wsa:EndpointReference

   </wsrf-sg:MemberServiceEPR>

   <wsrf-sg:Content>

     <wsrf-sg:RPDoc>

       {any} *

     </wsrf-sg:RPDoc> ?

     {any} *

   </wsrf-sg:Content> ?

</wsrf-sg:EntryAddtionNotification>

The form of the EntryAdditionNotification is further constrained as follows:

/wsrf-sg:EntryAdditionNotification

One EntryAdditionNotification element is created for each ServiceGroupEntry addition situation detected by the service associated with ServiceGroup resource. This artifact records the addition of an entry to the ServiceGroup.

/wsrf-sg:EntryAdditionNotification/ServiceGroupEntryEPR

This element MUST contain the EndpointReference of the ServiceGroupEntry that was added to the ServiceGroup.

/wsrf-sg:EntryAdditionNotification/MemberServiceEPR

This optional element, if present, MUST contain the EndpointReference of the member service that the WS-Resource referenced by @ServiceGroupEntryEPR contains in its MemberEPR resource property.

/wsrf-sg:EntryAdditionNotification/Content

If this optional element is present, it MUST contain a copy of the Contents resource property element of the ServiceGroupEntry referenced by @ServiceGroupEntryEPR.

8.2      EntryRemovalNotification Message

The wsrf-sg:EntryRemovalNotification element is a form of notification message associated with the wsrf-sg:ServiceGroupModification topic. This element is defined as follows:

<wsrf-sg:EntryRemovalNotification>

   <wsrf-sg:ServiceGroupEntryEPR>

     wsa:EndpointReferenceType

   </wsrf-sg:ServiceGroupEntryEPR>

   <wsrf-sg:MemberServiceEPR>

     wsa:EndpointReferenceType

   </wsrf-sg:MemberServiceEPR>?

   <wsrf-sg:Content>

     <wsrf-sg:RPDoc>

       {any} *

     </wsrf-sg:RPDoc> ?

     {any} *

   </wsrf-sg:Content> ?

   <wsrf-sg:Reason>xsd:string</wsrf-sg:Reason> ?

</wsrf-sg:EntryRemovalNotification>

The form of the EntryRemovalNotification is further constrained as follows:

/wsrf-sg:EntryRemovalNotification

One EntryRemovalNotification element is created for each ServiceGroupEntry removal situation detected by the service associated with ServiceGroup resource. This artifact records the removal of an entry to the ServiceGroup.

/wsrf-sg:EntryRemovalNotification/ServiceGroupEntryEPR

This element MUST contain the EndpointReference of the ServiceGroupEntry that was removed to the ServiceGroup. Note: The EndpointReference for the ServiceGroupEntry will not be a valid reference since the removal mechanism from a ServiceGroup is removal of the ServiceGroupEntry.

/wsrf-sg:EntryRemovalNotification/MemberServiceEPR

This optional element, if present, MUST contain the EndpointReference of the member service that the WS-Resource referenced by @ServiceGroupEntryEPR contains in its MemberEPR resource property.

/wsrf-sg:EntryRemovalNotification/Content

If this optional element is present, it MUST contain a copy, from some point prior to the removal, of the Contents resource property element of the ServiceGroupEntry referenced by @ServiceGroupEntryEPR.

/wsrf-sg:EntryRemovalNotification/Reason

If this optional element is present it will contain human readable text regarding the reason for the removal for the ServiceGroup.

9        Security Model

In the context of this specification, there are two categories of security aspects that need to be considered: (a) securing the message exchanges and (b) securing the resource properties.

9.1      Securing the message exchanges

When messages exchanges occur between a requestor and a Web service in order to access or act on one or more resource properties, it is RECOMMENDED that the communication between services be secured using the mechanisms described in WS-Security.

9.2      Securing the resource properties

Given WS-ServiceGroup defines a mechanism to expose properties about its member WS-Resources through its “Content” resource property on ServiceGroupEntry, security considerations specified in WS-ResourceProperties are applicable to ServiceGroupEntry. Therefore, security policies should be established that ensure that only authorized requestors can access the value of a resource property of a member WS-Resource. It should also be noted that the authorization policies on the properties of a WS-Resource accessible through a ServiceGroup should be consistent with the authorization policies that are applicable when those properties are accessed directly form the resource itself. Similarly, the security policies about message exchanges (e.g., requiring the resource property value to be encrypted when sent in a response) should be equivalent in order to provide the same protection irrespective of the access point.

9.2.1      A Note on MembershipContentRules

The MembershipContentRules resource property along with Entry resource property provide a mechanism to allow for requestors to query about the members of a service group based on their interface or a resource property that is contained in member Ws-Resource’s resource properties document, as well as the value of a resource property itself. There may need to be privacy considerations with respect to exposing those values. Therefore, authorization policies as well as message protection policies should be consistent between these values retrieved through ServiceGroup, and those values retrieved through the WS-Resource itself.  It is not a good practice to form membership rules based on properties whose values are to remain confidential.

Appendix A. Acknowledgments

Special thanks to the Global Grid Forum’s Open Grid Services Infrastructure working group, which defined the OGSI v1.0 [OGSI 1.0] specification which was a large inspiration for the ideas expressed in this specification.

The following individuals were members of the committee during the development of this specification:

Mario Antonioletti (EPCC, The University of Edinburgh), Akhil Arora (Sun Microsystems), Tim Banks (IBM), Jeff Bohren (OpenNetwork), Fred Carter (AmberPoint), Martin Chapman (Oracle), Glen Daniels (Sonic Software), David De Roure (University of Southampton), Thomas Freund (IBM), John Fuller (Individual), Stephen Graham (IBM), Anish Karmarkar (Oracle), Hideharu Kato (Hitachi), David Levine (IBM), Paul Lipton (Computer Associates), Mark Little (Arjuna Technologies Limited), Lily Liu (WebMethods, Inc.), Tom Maguire (IBM), Susan Malaika (IBM), Mark Mc Keown (University of Manchester), David Martin (IBM), Samuel Meder (Argonne National Laboratory), Jeff Mischkinsky (Oracle), Roger Menday (Forschungszentrum Jlich GmbH), Bryan Murray (Hewlett-Packard), Mark Peel (Novell), Alain Regnier (Ricoh Company, Ltd.), Ian Robinson (IBM), Tom Rutt (Fujitsu), Mitsunori Satomi (Hitachi), Igor Sedukhin (Computer Associates), Hitoshi Sekine (Ricoh Company, Ltd.), Frank Siebenlist (Argonne National Laboratory), Alex Sim (Lawrence Berkeley National Laboratory), David Snelling (Fujitsu), Latha Srinivasan (Hewlett-Packard), Rich Thompson (IBM), Jem Treadwell (Hewlett-Packard), Steve Tuecke (Argonne National Laboratory), William Vambenepe (Hewlett-Packard), Katy Warr (IBM), Alan Weissberger (NEC Corporation), Pete Wenzel (SeeBeyond Technology Corporation), Kirk Wilson (Computer Associates) and Umit Yalcinalp (SAP).

In addition, the following people made contributions to this specification:

Nick Butler (IBM), Karl Czajkowski (Globus / USC/ISI), Donald F Ferguson (IBM), Ian Foster (Globus / Argonne), Diane Jordan (IBM), Andreas Meier (IBM), Nataraj Nagaratnam (IBM), Martin Nally (IBM), John Rofrano (IBM), Ellen Stokes (IBM), Tony Storey (IBM), Jay Unger (IBM), Sanjiva Weerawarana (IBM), Dave Booz (IBM), Jim Knutson (IBM), Heather Kreger (IBM), Frank Leymann (IBM).

 

10  References

10.1Normative

 

[RFC 2119]
 S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.

[URI]
T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax," RFC 2396, MIT/LCS, U.C. Irvine, Xerox Corporation, August 1998.

[WS-Addressing]
http://www.w3.org/TR/ws-addr-core

[WS-BaseFaults]
http://docs.oasis-open.org/wsrf/wsrf-ws_base_faults-1.2-spec-os.pdf

[WS-BaseNotification]
http://docs.oasis-open.org/wsn/wsn-ws_base_notification-1.3-spec-pr-02.pdf

[WS-Resource]
http://docs.oasis-open.org/wsrf/wsrf-ws_resource-1.2-spec-os.pdf

[WS-ResourceLifetime]
http://docs.oasis-open.org/wsrf/wsrf-ws_resource_lifetime-1.2-spec-os.pdf

[WS-ResourceProperties]
http://docs.oasis-open.org/wsrf/wsrf-ws_resource_properties-1.2-spec-os.pdf

[WS-Topics]
http://docs.oasis-open.org/wsn/wsn-ws_topics-1.3-spec-pr-01.pdf

[XML-Infoset]
http://www.w3.org/TR/xml-infoset/

[XML-Names]
http://www.w3.org/TR/REC-xml-names/

[XPATH]
http://www.w3.org/TR/xpath

10.2Non-Normative

[OGSI 1.0]
Open Grid Services Infrastructure (OGSI) V1.0
http://forge.gridforum.org/projects/ggf-editor/document/draft-ogsi-service-1/en/1

[SOAP 1.1]
http://www.w3.org/TR/2000/NOTE-SOAP-20000508

[WS-Basic Profile 1.1]
http://www.ws-i.org/Profiles/BasicProfile-1.1.html

[WS-Security]
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

[WSDL 2.0]
http://www.w3.org/TR/wsdl20

 

Appendix B. XML Schema

The XML types and elements used in this specification are included here for convenience. The authoritative version of this schema document is available at
http://docs.oasis-open.org/wsrf/sg-2.xsd,

The XML types and elements used in this specification are defined in the following XML Schema

<?xml version="1.0" encoding="UTF-8"?>

<!--

 

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.

 

OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.

 

Copyright (C) OASIS Open (2005). All Rights Reserved.

 

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

 

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

 

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

 

-->

<xsd:schema

  xmlns="http://www.w3.org/2001/XMLSchema"

  xmlns:xsd="http://www.w3.org/2001/XMLSchema"

  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

  xmlns:wsrf-bf="http://docs.oasis-open.org/wsrf/bf-2"  

  xmlns:wsrf-sg="http://docs.oasis-open.org/wsrf/sg-2" 

  xmlns:wsa="http://www.w3.org/2005/08/addressing"

  elementFormDefault="qualified"

  attributeFormDefault="unqualified"

  targetNamespace="http://docs.oasis-open.org/wsrf/sg-2" >

<!-- ======================== Imports ============================ -->

 

     <xsd:import

       namespace="http://www.w3.org/2005/08/addressing"

       schemaLocation="http://www.w3.org/2005/08/addressing/ws-addr.xsd"/>

     <xsd:import

        namespace="http://docs.oasis-open.org/wsrf/bf-2"

        schemaLocation="http://docs.oasis-open.org/wsrf/bf-2.xsd" />

             

<!-- =============== Resource Property Related  =================== -->

<!-- ============ Resource Properties for ServiceGroup ============ -->

  <xsd:simpleType name="AbsoluteOrRelativeTimeType">

    <xsd:union memberTypes="xsd:dateTime xsd:duration"/>

  </xsd:simpleType>

 

  <xsd:simpleType name="ContentElementsType">

    <xsd:list itemType="xsd:QName"/>

  </xsd:simpleType>

 

  <xsd:simpleType name="MemberInterfacesType">

    <xsd:list itemType="xsd:QName"/>

  </xsd:simpleType>

 

  <xsd:element name="MembershipContentRule">

    <xsd:complexType>

      <xsd:attribute name="MemberInterfaces"

                     type="wsrf-sg:MemberInterfacesType"/>

      <xsd:attribute name="ContentElements"

                     type="wsrf-sg:ContentElementsType"

                     use="required"/>

      <xsd:anyAttribute namespace="##other"

                        processContents="lax"/>

    </xsd:complexType> 

  </xsd:element>    

 

  <xsd:complexType name="RPDocType">

    <xsd:sequence>

      <xsd:any namespace="##any" processContents="lax"

               minOccurs="1" maxOccurs="1" />

    </xsd:sequence>

    <xsd:anyAttribute namespace="##other"

                      processContents="lax"/>

  </xsd:complexType>

 

  <xsd:complexType name="ContentType">

    <xsd:sequence>

      <xsd:element name="RPDoc"

                   type="wsrf-sg:RPDocType"

                   minOccurs="0" maxOccurs="1" />

      <xsd:any namespace="##other" processContents="lax"

               minOccurs="0" maxOccurs="unbounded" />

    </xsd:sequence>

    <xsd:anyAttribute namespace="##other"

                      processContents="lax"/>

  </xsd:complexType>

 

  <xsd:complexType name="EntryType">

    <xsd:sequence>

      <xsd:element name="ServiceGroupEntryEPR"

                   type="wsa:EndpointReferenceType"

                   minOccurs="1" maxOccurs="1"

                   nillable="true"/>

      <xsd:element name="MemberServiceEPR"

                   type="wsa:EndpointReferenceType"

                   minOccurs="0" maxOccurs="1"/>

      <xsd:element ref="wsrf-sg:Content"

                   minOccurs="0" maxOccurs="1"/>

    </xsd:sequence>

    <xsd:anyAttribute namespace="##other" processContents="lax"/>

  </xsd:complexType>

 

<!-- ========== Resource Properties for ServiceGroupEntry ========= -->

 

  <xsd:element name="Entry"

               type="wsrf-sg:EntryType"/>

 

  <xsd:element name="Content"

               type="wsrf-sg:ContentType"/>

 

  <xsd:element name="MemberEPR"

               type="wsa:EndpointReferenceType"/>

 

  <xsd:element name="ServiceGroupEPR"

               type="wsa:EndpointReferenceType"/>

 

<!-- =============== Resource Property Related  =================== -->

<!-- ============ Resource Properties for ServiceGroup ============ -->

        <xsd:element name="ServiceGroupRP">

          <xsd:complexType>

            <xsd:sequence>

              <xsd:element ref="wsrf-sg:MembershipContentRule"

                           minOccurs="0" maxOccurs="unbounded"/>

              <xsd:element ref="wsrf-sg:Entry"

                           minOccurs="0" maxOccurs="unbounded"/>

            </xsd:sequence>

          </xsd:complexType>

        </xsd:element>

 

<!-- ========== Resource Properties for ServiceGroupEntry ========= -->  

        <xsd:element name="ServiceGroupEntryRP">

          <xsd:complexType>

            <xsd:sequence>

              <xsd:element ref="wsrf-sg:ServiceGroupEPR"

                           minOccurs="1" maxOccurs="1"/>

              <xsd:element ref="wsrf-sg:MemberEPR"

                           minOccurs="0" maxOccurs="1"/>

              <xsd:element ref="wsrf-sg:Content"

                           minOccurs="0" maxOccurs="1"/>

            </xsd:sequence>

          </xsd:complexType>

        </xsd:element>

 

<!-- ================= Message Specific Types  ==================== -->     

<!-- ======== Message Types for ServiceGroupRegistration  ========= -->

        <xsd:element name="Add">

          <xsd:complexType>

            <xsd:sequence>

              <xsd:element name="MemberEPR"

                           type="wsa:EndpointReferenceType" />

              <xsd:element ref="wsrf-sg:Content" />

              <xsd:element name="InitialTerminationTime"

                           type="wsrf-sg:AbsoluteOrRelativeTimeType"

                                   nillable="true"

                           minOccurs="0" maxOccurs="1" />

            </xsd:sequence>

          </xsd:complexType>

        </xsd:element>

 

        <xsd:element name="AddResponse">

          <xsd:complexType>

            <xsd:sequence>

              <xsd:element name="ServiceGroupEntryReference"

                     type="wsa:EndpointReferenceType"

                     minOccurs="1" maxOccurs="1" />

              <xsd:element name="TerminationTime"

                     nillable="true"

                     type="xsd:dateTime"

                     minOccurs="1" maxOccurs="1" />

              <xsd:element name="CurrentTime"

                     type="xsd:dateTime"

                     minOccurs="1" maxOccurs="1" />

            </xsd:sequence>

          </xsd:complexType>

        </xsd:element>

                     

        <xsd:complexType name="ContentCreationFailedFaultType">

          <xsd:complexContent>

            <xsd:extension base="wsrf-bf:BaseFaultType"/>

          </xsd:complexContent>

        </xsd:complexType>

        <xsd:element name="ContentCreationFailedFault"

                     type="wsrf-sg:ContentCreationFailedFaultType"/>

 

        <xsd:complexType name="UnsupportedMemberInterfaceFaultType">

          <xsd:complexContent>

            <xsd:extension base="wsrf-bf:BaseFaultType"/>

          </xsd:complexContent>

        </xsd:complexType>

        <xsd:element name="UnsupportedMemberInterfaceFault"

                     type="wsrf-sg:UnsupportedMemberInterfaceFaultType"/>

 

        <xsd:complexType name="AddRefusedFaultType">

          <xsd:complexContent>

            <xsd:extension base="wsrf-bf:BaseFaultType"/>

          </xsd:complexContent>

        </xsd:complexType>

        <xsd:element name="AddRefusedFault"

                     type="wsrf-sg:AddRefusedFaultType"/>

 

<!-- = Messages Related to ServiceGroup Change Notification ======= -->

  <xsd:complexType name="ServiceGroupModificationNotificationType">

    <xsd:sequence>

      <xsd:element name="ServiceGroupEntryEPR"

                   type="wsa:EndpointReferenceType"

                   minOccurs="1" maxOccurs="1"

                   nillable="true"/>

      <xsd:element name="MemberServiceEPR"

                   type="wsa:EndpointReferenceType"

                   minOccurs="0" maxOccurs="1"/>

      <xsd:element ref="wsrf-sg:Content"

                   minOccurs="0" maxOccurs="1"/>         

    </xsd:sequence>

  </xsd:complexType>

 

  <xsd:complexType name="ServiceGroupRemovalNotificationType">

    <xsd:complexContent>

      <xsd:extension

           base="wsrf-sg:ServiceGroupModificationNotificationType">   

        <xsd:sequence>

          <xsd:element name="Reason"

                       type="xsd:string"

                       minOccurs="0" maxOccurs="1"/>

        </xsd:sequence>

      </xsd:extension>

    </xsd:complexContent>

  </xsd:complexType>

 

  <xsd:element name="EntryAdditionNotification"

              type="wsrf-sg:ServiceGroupModificationNotificationType" />

 

  <xsd:element name="EntryRemovalNotification"

              type="wsrf-sg:ServiceGroupRemovalNotificationType" />

 

</xsd:schema>

Appendix C. WSDL 1.1

The WSDL 1.1 for the Web service methods described in this specification is compliant with WS-I Basic Profile 1.1 [WS-I Basic Profile 1.1]  and is included here for convenience. The authoritative version of this WSDL is available at http://docs.oasis-open.org/wsrf/sgw-2.wsdl,

The following illustrates the WSDL 1.1 for the Web service methods described in this specification:

<?xml version="1.0" encoding="utf-8"?>

<!--

 

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.

 

OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.

 

Copyright (C) OASIS Open (2005). All Rights Reserved.

 

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

 

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

 

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

 

-->

 

<wsdl:definitions name="ServiceGroup"

  xmlns="http://schemas.xmlsoap.org/wsdl/"

  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

  xmlns:xsd="http://www.w3.org/2001/XMLSchema"

  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

  xmlns:wsa="http://www.w3.org/2005/08/addressing"

  xmlns:wsrf-bf="http://docs.oasis-open.org/wsrf/bf-2"  

  xmlns:wsrf-rp="http://docs.oasis-open.org/wsrf/rp-2"

  xmlns:wsrf-rpw="http://docs.oasis-open.org/wsrf/rpw-2"

  xmlns:wsrf-rw="http://docs.oasis-open.org/wsrf/rw-2" 

  xmlns:wsrf-sg="http://docs.oasis-open.org/wsrf/sg-2"

  xmlns:wsrf-sgw="http://docs.oasis-open.org/wsrf/sgw-2"

  targetNamespace="http://docs.oasis-open.org/wsrf/sgw-2">

 

<!-- ========================== Imports =========================== -->

   <wsdl:import namespace="http://docs.oasis-open.org/wsrf/rpw-2"

     location="http://docs.oasis-open.org/wsrf/rpw-2.wsdl" />

 

   <wsdl:import namespace="http://docs.oasis-open.org/wsrf/rw-2"

     location="http://docs.oasis-open.org/wsrf/rw-2.wsdl" />

 

<!-- ===================== Types Definitions ====================== -->

   <wsdl:types>

      <xsd:schema>

       <xsd:import namespace="http://docs.oasis-open.org/wsrf/sg-2"

          schemaLocation="http://docs.oasis-open.org/wsrf/sg-2.xsd" />

 

       <xsd:import namespace="http://docs.oasis-open.org/wsrf/rp-2"

          schemaLocation="http://docs.oasis-open.org/wsrf/rp-2.xsd" />

 

       <xsd:import namespace="http://docs.oasis-open.org/wsrf/bf-2"

          schemaLocation="http://docs.oasis-open.org/wsrf/bf-2.xsd" />

    </xsd:schema>

  </wsdl:types>

 

<!-- ==================== Message Definitions ===================== -->

<!-- =============== ServiceGroupRegistration::Add ================

  Add(MemberEPR, Content, [InitialTerminationTime])

  returns: EPR to ServiceGroupEntry

-->

  <wsdl:message name="AddRequest">

    <wsdl:part name="AddRequest" element="wsrf-sg:Add"/>

  </wsdl:message>

 

  <wsdl:message name="AddResponse">

    <wsdl:part name="AddResponse" element="wsrf-sg:AddResponse"/>

  </wsdl:message>

 

  <wsdl:message name="ContentCreationFailedFault">

    <wsdl:part name="ContentCreationFailedFault"

               element="wsrf-sg:ContentCreationFailedFault" />

  </wsdl:message>

 

  <wsdl:message name="UnsupportedMemberInterfaceFault">

    <wsdl:part name="UnsupportedMemberInterfaceFault"

               element="wsrf-sg:UnsupportedMemberInterfaceFault" />

  </wsdl:message>

 

  <wsdl:message name="AddRefusedFault">

    <wsdl:part name="AddRefusedFault"

               element="wsrf-sg:AddRefusedFault" />

  </wsdl:message>

 

<!-- =================== PortType Definitions ===================== --> 

  <wsdl:portType name="ServiceGroup"

            wsrf-rp:ResourceProperties="wsrf-sg:ServiceGroupRP">

    <wsdl:operation name="GetResourceProperty">

      <wsdl:input name="GetResourcePropertyRequest"

            message="wsrf-rpw:GetResourcePropertyRequest" />

      <wsdl:output name="GetResourcePropertyResponse"

            message="wsrf-rpw:GetResourcePropertyResponse" />

      <wsdl:fault name="InvalidResourcePropertyQNameFault"

            message="wsrf-rpw:InvalidResourcePropertyQNameFault" />

      <wsdl:fault name="ResourceUnknownFault"

            message="wsrf-rw:ResourceUnknownFault" />

    <wsdl:fault name="ResourceUnavailableFault"

              message="wsrf-rw:ResourceUnavailableFault" />

    </wsdl:operation>

  </wsdl:portType>

 

  <wsdl:portType name="ServiceGroupEntry"

                 wsrf-rp:ResourceProperties="wsrf-sg:ServiceGroupEntryRP">

    <wsdl:operation name="GetResourceProperty">

      <wsdl:input name="GetResourcePropertyRequest"

                  message="wsrf-rpw:GetResourcePropertyRequest" />

      <wsdl:output name="GetResourcePropertyResponse"

                   message="wsrf-rpw:GetResourcePropertyResponse" />

      <wsdl:fault name="InvalidResourcePropertyQNameFault"

                  message="wsrf-rpw:InvalidResourcePropertyQNameFault" />  

      <wsdl:fault name="ResourceUnknownFault"

            message="wsrf-rw:ResourceUnknownFault" />

    <wsdl:fault name="ResourceUnavailableFault"

              message="wsrf-rw:ResourceUnavailableFault" />

    </wsdl:operation>

  </wsdl:portType>

 

  <wsdl:portType name="ServiceGroupRegistration"

                 wsrf-rp:ResourceProperties="wsrf-sg:ServiceGroupRP">

    <wsdl:operation name="GetResourceProperty">

      <wsdl:input name="GetResourcePropertyRequest"

                  message="wsrf-rpw:GetResourcePropertyRequest" />

      <wsdl:output name="GetResourcePropertyResponse"

                  message="wsrf-rpw:GetResourcePropertyResponse" />

      <wsdl:fault name="InvalidResourcePropertyQNameFault"

                  message="wsrf-rpw:InvalidResourcePropertyQNameFault" />

      <wsdl:fault name="ResourceUnknownFault"

            message="wsrf-rw:ResourceUnknownFault" />

    <wsdl:fault name="ResourceUnavailableFault"

              message="wsrf-rw:ResourceUnavailableFault" />

    </wsdl:operation>

    <wsdl:operation name="Add">

      <wsdl:input name="AddRequest"

                  message="wsrf-sgw:AddRequest" />

      <wsdl:output name="AddResponse"

                  message="wsrf-sgw:AddResponse" />

      <wsdl:fault name="ContentCreationFailedFault"

                  message="wsrf-sgw:ContentCreationFailedFault"/>

      <wsdl:fault name="UnsupportedMemberInterfaceFault"

                  message="wsrf-sgw:UnsupportedMemberInterfaceFault"/>     

      <wsdl:fault name="AddRefusedFault"

                  message="wsrf-sgw:AddRefusedFault"/>

      <wsdl:fault name="ResourceUnknownFault"

            message="wsrf-rw:ResourceUnknownFault" />

    <wsdl:fault name="ResourceUnavailableFault"

              message="wsrf-rw:ResourceUnavailableFault" /> 

    </wsdl:operation>

  </wsdl:portType>

 

 </wsdl:definitions>

Appendix D. Revision History

Rev

Date

By Whom

What

wd-01

2004-06-05

Tom Maguire

Initial version created from submission by contributing companies. Minor modifications made to reflect OASIS formatting.

wd-02

2004-06-07

Tom Maguire

Updated to include elementFormDefault and attributeFormDefault.  Changed URI from 2004/05 to 2004/06.  Updated acknowledgements section. 

wd-02

2004-06-11

Ian Robinson

Consistency edit for status, acknowledgements and references sections.

wd-03

2004-11-10

Tom Maguire

Issue resolutions from October F2F:

o        WSRF30, WSRF43, WSRF49, WSRF53, WSRF56

o        Replaced refs to [State Paper]

o        Update to use “WS-Resource Access Pattern”

o        Changed doc identifier to “Summary Info Title”

o        Added missing wsdl:import for WS-Addressing in wsdl

o        Fixed selector for “UniqueInterfaces” in wsdl (WSRF60 & WSRF70)

o        Fixed namespace prefix errors in wsdl

o        Fixed namespace prefix errors in SOAP examples

o        Updated UML diagram

o        Removed erroneous wsa:to in AddResponse example

wd-04

2005-02-18

Tom Maguire

Corrected concrete message element namespaces. 

Updated OASIS copyright to 2005.

Issue resolutions from February F2F:

  • Updated namespace declarations to latest 2005/03
  • WSRF62 Basic profile 1.1 statement
  • WSRF96 Statement specifying the authoritative versions of wsdl and xsd
  • WSRF63 add attribute extensibility
  • WSRF86 add ResourceUnknown fault to all operations
  • WSRF81 remove xsd:include in favor of xsd:import.  Move all schema definitions to xsd.

wd-05

2005-05-16

Tom Maguire

Updated namespaces to CD levels

Issue resolutions

  • WSRF-44 change MembershipContentRule MemberInterface to be a list of QName.  Changed name to MemberInterfaces and updated normative infoset.
  • WSRF58 remove unnecessary imports to resource lifetime
  • WSRF59 inconsistencies
  • WSRF69 Content element of ServiceGroupEntry needs to be minOccurs=0
  • WSRF87 InitialTerminationTime on Add request strengthed.
  • WSRF91 updates for Last call of WS-Addressing
  • WSRF92 update examples for Last call of WS-Addressing
  • WSRF99 use SOAP 1.1 instead of SOAP 1.2
  • WSRF101 remove non-normative specifications without SDO standing
  • WSRF104 Content rule applies in two ways.  Delete line 453
  • WSRF103 wsa:action updates

 

wd-05a

2005-05-17

Tom Maguire

Updates for Example SOAP headers

Fixes to schema

wd-05b

2005-05-17

Tom Maguire

WSRF100 – Fix for faults must be BaseFaults

WSRF109 – Artifact precedence for authoritativeness

WSRF113 – namespace updates for separation

WSRF114 – wsa:action for faults

WSRF115 – RP Document in SGE/@Content

Update acknowledgements

pr-01

2005-06-10

Tom Maguire

Change status to PR

wd-06

2005-09-15

David Snelling

Change status to WD-6

Update references for PR2

WSRF124 - back slash in WS-Addressing location.

WSRF127 - Remove reference to "access pattern".

 

pr-02.a

2005-11-22

Tim Banks

Fixed broken links in references which appear after pdf processing.

pr-02.b

2005-12-13

Tim Banks

Updates Schema in appendix B to fix issues 157 and 164

cs-01

2006-01-11

Tim Banks

Change front page for Committee Spec

os

2006-01-11

Tim Banks

Change front page, footers & references  for OASIS standard

 

Appendix E. Notices

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.

 

OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.

 

Copyright (C) OASIS Open (2005). All Rights Reserved.

 

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

 

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

 

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.