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
5.1 ServiceGroup ResourceProperties
5.1.1 MembershipContentRule Resource Property
6.1 ServiceGroupEntry: Resource Property Declarations
6.2 ServiceGroupEntry: Message Exchanges
7.1 ServiceGroupRegistration: Resource Property Declarations
7.2.1 Example SOAP Encoding of the Add Message Exchange.
8 Notification of ServiceGroup Modification
8.1 EntryAdditionNotification Message
8.2 EntryRemovalNotification Message
9.1 Securing the message exchanges
9.2 Securing the resource properties
9.2.1 A Note on MembershipContentRules
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].
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].
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.
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.
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>
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 |
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
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.
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.
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.
![]() |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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>
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.
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.
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.
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.
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.
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.
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.
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).
[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
[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
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>
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>
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:
|
wd-05 |
2005-05-16 |
Tom Maguire |
Updated namespaces to CD levels Issue resolutions
|
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 |
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.