Web Services Resource Lifetime 1.2

(WS-ResourceLifetime)

OASIS Standard, 1 April 2006

Document identifier:  wsrf-ws_resource_lifetime-1.2-spec-os

Location:

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

Editors:

Latha Srinivasan, Hewlett Packard Company <Latha.Srinivasan@hp.com>

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

Abstract:

The relationship between Web services and stateful resources is defined in [WS-Resource].

This specification defines message exchanges to standardize the means by which a WS-Resource may be destroyed, and resource properties [WS-ResourceProperties] that may be used to inspect and monitor the lifetime of a WS-Resource. This specification defines two means of destroying a WS-Resource: immediate destruction and time-based, scheduled destruction.

 

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

1.1        Goals and Requirements. 3

1.1.1 Requirements. 3

1.1.2 Non-Goals. 4

1.2 Terminology. 4

1.3 Namespaces. 5

1.4 Fault Definitions. 6

2      Terminology and Concepts. 7

3      Example. 8

4      Immediate Destruction. 10

4.1 Example SOAP Encoding of the Destroy Message Exchange. 10

5      Scheduled Destruction. 12

5.1 Regarding Time. 12

5.2 Querying Current Time. 12

5.3 Determining Current Termination Time. 13

5.4 Requesting Change to Termination Time. 13

5.5 Example SOAP Encoding of the SetTerminationTime Message Exchange. 15

5.6 Termination Time Expiration. 16

6      Notification of Resource Destruction. 17

7      Security Considerations. 18

7.1 Securing the Message Exchanges. 18

7.2 Securing Resource Destruction. 18

8      References. 19

8.1 Normative. 19

8.2 Non-Normative. 19

Appendix A. 20

Appendix B. 21

Appendix C. WSDL 1.1. 25

Appendix D. Revision History. 28

Appendix E. Notices. 30

 

1 Introduction

In this document, we consider a distributed computing environment consisting of WS-Resources.  The definition of WS-Resource, in terms of its relationship with a Web service, is detailed in the WS-Resource specification [WS-Resource].

The lifetime of a WS-Resource is defined as the period between its instantiation and its destruction. The WS-ResourceLifetime specification standardizes the means by which a WS-Resource can be destroyed. The specification also defines the means by which the lifetime of a WS-Resource can be monitored. However, this specification does not prescribe (nor proscribe) the means by which a WS-Resource is created.

Normally, a service requestor’s interest in a WS-Resource is for some period of time - rarely is it indefinite. In many scenarios, it is appropriate for clients of a WS-Resource to cause its immediate destruction. The immediate destruction of a WS-Resource may be accomplished using the message exchanges defined in this specification.

In addition, this specification defines the means by which a resource may be destroyed after a period of time. In a distributed computing environment, a client may become disconnected from the service provider’s endpoint and therefore may be unable to, or unwilling to, cause the immediate destruction of the WS-Resource. This specification defines the means by which any client of a WS-Resource may establish and extend the scheduled termination time of a WS-Resource. If that time expires, the WS-Resource may self-destruct without the need for an explicit destroy request message from a client. Periodically extending the termination time of a WS-Resource can serve to extend its lifetime. WS-ResourceLifetime defines a standard message exchange by which a service requestor can establish and renew a scheduled termination time for the WS-Resource, and defines the circumstances under which a service requestor can determine that this termination time has elapsed.

A service requestor may want to determine the current time and the termination time of a WS-Resource. WS-ResourceLifetime defines resource properties, as defined in [WS-ResourceProperties], for accessing this information.

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

1.1      Goals and Requirements

The goal of WS-ResourceLifetime is to standardize the terminology, concepts, message exchanges, WSDL and XML needed to monitor the lifetime of, and destroy, WS-Resources as defined in [WS-Resource].

1.1.1 Requirements

This specification intends to meet the following requirements:

·         Define the standard message exchange by which a requestor can request the immediate destruction of a WS-Resource.

·         Define the means by which a service requestor can set an initial termination time for the scheduled termination of a WS-Resource.

·         Define the means by which a service requestor can update the termination time associated with a WS-Resource that is scheduled for termination. 

·         Define the means by which a service requestor can determine the current termination time as known by a WS-Resource.

This specification MUST NOT require entities in the system to share synchronized clocks.

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 WS-Resource factory. Factory requirements are too varied to allow a general-purpose factory message exchange to be usefully defined. 

1.2 Terminology

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. 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 wsd lfiles 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/

wsa

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

wsrf-rp

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

wsrf-rpw

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

wsrf-bf

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

wsrf-bfw

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

wsrf-rl

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

wsrf-rlw

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

wstop

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

xsd

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

xsi

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

 


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        Terminology and Concepts

This section specifies the notations, namespaces, and terminology used in this specification.

 

For definitions of the terms WS-Resource and WS-Resource Reference please refer to the WS-Resource [WS-Resource] specification.

 

For definitions of the terms Resource Property, Resource Properties Document, Resource Property Element and Resource Property Value, please refer to the WS-Resource Properties [WS-ResourceProperties] specification.

.

3        Example

Consider the case of a subscription entity within a notification system such as WS-BaseNotification [WS-BaseNotification]. This situation is depicted in the following figure:

Figure 1 - Example WS-Resource Creation

A service requestor (1), playing the role of a subscriber, sends a subscribe message (2) to a NotificationProducer (3) because it wishes to receive notifications related to a particular situation such as a failure of a component. A subscription WS-Resource (4) is created as a result of the subscribe message, and a WS-Resource Reference (5) [WS-Resource] is returned to the requestor. As part of the application-specific understanding of the subscribe message exchange, both the requestor and provider understand that part of the semantics of processing a subscribe message is the creation (usually for a limited period of time) of a subscription WS-Resource. The subscribe request message contains the initial scheduled termination time of the subscription WS-Resource.

The reference that is returned as a result of the subscribe message is a WS-Resource Reference as described in [WS-Resource]. It contains a reference that refers to the newly-created subscription state represented by the WS-Resource. The endpoint reference (as enumerated by the WS-Addressing embodiment) also contains the address of the Web service component of the WS-Resource that implements the message exchanges defined by WS-BaseNotification’s SubscriptionManager interface.

Subsequent to the creation of the subscription WS-Resource, the application-specific behavior of delivering notifications continues. Occasionally, the subscriber may examine the subscription WS-Resource using standard WS-ResourceLifetime resource properties to inquire about the remaining time before the subscription WS-Resource may be destroyed. If the subscriber wishes to extend the lifetime of the subscription WS-Resource beyond its scheduled termination time, it sends a specific WS-ResourceLifetime message to the subscription WS-Resource referenced by its WS-Resource Reference, prior to the expiration of its current scheduled termination time. The response to this message contains the (potentially unchanged) termination time associated with the subscription WS-Resource.

When the subscriber no longer wishes to receive notifications, it may cause the immediate destruction of the subscription WS-Resource by sending another WS-ResourceLifetime message to the WS-Resource through use of its WS-Resource Reference. As another option, it may simply allow the termination time of the subscription WS-Resource to expire, at which time the subscription WS-Resource may be destroyed.

4        Immediate Destruction

A WS-Resource MAY support a message exchange pattern that allows a service requestor to request its immediate destruction.

The format of the destroy request message is:

  <wsrf-rl:Destroy/>

The wsa:Action MUST contain the URI:  “http://docs.oasis-open.org/wsrf/rlw-2 /ImmediateResourceTermination/DestroyRequest”.

If the WS-Resource accepts the DestroyRequest message, upon receipt of this message the WS-Resource MUST either return the following DestroyResponse message to acknowledge successful destruction, or return a fault message indicating failure.

  <wsrf-rl:DestroyResponse />

The receipt of the DestroyResponse message serves as a confirmation of the destruction of the WS-Resource. Once it has sent a DestroyResponse message, any further message exchanges directed at the subject WS-Resource MUST respond with a fault. In the absence of any other fault conditions that may take precedence this MUST be the “ResourceUnknownFault” fault message enumerated in the WS-Resource [WS-Resource] specification.

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

 

·         ResourceNotDestroyedFault

o        The WS-Resource could not be destroyed for some reason.

 

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

The wsa:Action MUST contain the URI:  “http://docs.oasis-open.org/wsrf/rlw-2/ImmediateResourceTermination/DestroyResponse”.

 

4.1 Example SOAP Encoding of the Destroy Message Exchange

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

<s11:Envelope . . .>

  <s11:Header>

   . . .

    <wsa:Action>

        http://docs.oasis-open.org/wsrf/rlw-2/ImmediateResourceTermination/DestroyRequest

    </wsa:Action>

    . . .

  </s11:Header>

  <s11:Body>

    <wsrf-rl:Destroy/>

  </s11:Body>

</s11:Envelope>

The following is an example DestroyResponse message using SOAP 1.1 [SOAP 1.1]:

<s11:Envelope . . .>

  <s11:Header>

       . . .

    <wsa:Action>

        http://docs.oasis-open.org/wsrf/rlw-2/ImmediateResourceTermination/DestroyResponse

    </wsa:Action>

       . . .

   </s11:Header>

  <s11:Body>

    <wsrf-rl:DestroyResponse />

  </s11:Body>

</s11:Envelope>

5        Scheduled Destruction

A time-based approach MAY be used for managing the destruction of a WS-Resource. In this case, the WS-Resource has an associated termination time that defines the time after which the WS-Resource is expected to be destroyed and thus before which the WS-Resource can reasonably be expected to be available. As defined in the following subsections, a WS-Resource’s termination time may be inspected through the TerminationTime resource property, and may be changed using the SetTerminationTime request message.

Typical use of scheduled destruction is to allow a service requestor to keep a WS-Resource active by adjusting the WS-Resource’s termination time to some appropriate point in time using the SetTerminationTime request message.

Note that termination time is not required to monotonically increase, nor is a service required to accept a requested termination time. An implementation MAY refuse a request to adjust termination time for various reasons, including, for example, to enforce a policy that allows termination time to only change monotonically.

If a WS-Resource wishes to provide support for scheduled WS-Resource destruction, it MUST support all of the message exchanges and resource properties specified in this section.

5.1 Regarding Time

This specification assumes that services and clients use the UTC global time standard, expressed as type dateTime from XML Schema. Note that xsd:dateTime includes an optional designation of a time zone. The use of the time zone designation is RECOMMENDED. In the absence of the time zone designation, the xsd:dateTime value MUST be interpreted as universal time (UTC).

The approach allows operations and resource properties to refer unambiguously to absolute times. However, assuming the UTC time standard to represent time does not imply any particular level of clock synchronization between clients and services. No specific accuracy of synchronization is specified or expected by this specification, as this is a service-quality issue.

The scheduled destruction operations and resource properties have been designed to allow for tolerance of lack of clock synchronization between clients and services. The CurrentTime resource property may be used by a client to determine the clock skew between the client and the service, within a margin of error determined by the round-trip latency of the message exchange to retrieve that value. This clock skew and margin of error can then be factored into subsequent decisions of when to send subsequent requests to change the termination time, and what termination times to request. The skew can also be monitored and adjusted with each SetTerminationTime message exchange, based on the CurrentTime that is returned from this request. This approach can also be used, to a limited extent, to accommodate clocks that “jump” either forward or backward in time.

5.2 Querying Current Time

In order to assist the service requestor in inspecting and setting a WS-Resource’s termination time without requiring a specific accuracy of clock synchronization between the service requestor and the service provider, the WS-Resource must provide information about its local time. If the SetTerminationTime request is supported, the resource properties document MUST include a resource property element that provides the current time as it is known by the WS-Resource. The form of this resource property element is:

 

<wsrf-rl:CurrentTime>xsd:dateTime</wsrf-rl:CurrentTime>

The resource properties definition of the WS-Resource MUST contain exactly one element of QName wsrf-rl:CurrentTime. The constraints on this element are as follows:

/wsrf-rl:CurrentTime

 A WS-Resource MUST NOT allow the CurrentTime resource property to be modified by a SetResourceProperties request message as defined in [WS-ResourceProperties].

If the element does not include the time zone designation, the value of the element MUST be interpreted as universal time (UTC).

5.3 Determining Current Termination Time

If the SetTerminationTime request is supported, the WS-Resource MUST provide a resource property element that indicates the current termination time of the WS-Resource. The form of this resource property element is:

  <wsrf-rl:TerminationTime xsi:nil=”xsd:boolean”?>xsd:dateTime</wsrf-rl:TerminationTime>

The resource properties definition of the WS-Resource MUST contain exactly one element of QName wsrf-rl:TerminationTime. The constraints on this element are as follows:

/wsrf-rl:TerminationTime

The time, relative to the time source used by the WS-Resource, after which the WS-Resource MAY be destroyed.

If the value of this resource property element contains the xsi:nil attribute with value “true” then the lifetime of the WS-Resource is considered to be indefinite; that is, there is no scheduled destruction time.

A WS-Resource MUST NOT allow the TerminationTime resource property to be modified by a SetResourceProperties request message as defined in [WS-ResourceProperties].

If the element does not include the time zone designation, the value of the element MUST be interpreted as universal time (UTC).

5.4 Requesting Change to Termination Time

The SetTerminationTime request message MUST be implemented by a WS-Resource supporting scheduled destruction in order to allow a requestor to change its scheduled termination time. There are two forms of the SetTerminationTime message described by the 'choice’ in the following pseudo-schema:

  <wsrf-rl:SetTerminationTime>

    [<wsrf-rl:RequestedTerminationTime xsi:nil=”xsd:boolean”?>

       xsd:dateTime

    </wsrf-rl:RequestedTerminationTime>]

       |

    [<wsrf-rl:RequestedLifetimeDuration>

 xsd:duration

    </wsrf-rl:RequestedLifetimeDuration>]

  </wsrf-rl:SetTerminationTime>

The wsa:Action MUST contain the following URI: “http://docs.oasis-open.org/wsrf/rlw-2/ScheduledResourceTermination/SetTerminationTimeRequest”.

Further constraints on the processing of the SetTerminationTimeRequest message are as follows:

/wsrf-rl:SetTerminationTime/wsrf-rl:RequestedTerminationTime

This is the new WS-Resource termination time that is being requested by the client. This value is interpreted relative to the time source known to the WS-Resource. If the element does not include the time zone designation, the value of the element MUST be interpreted as universal time (UTC).

If the value is “in the past” relative to the current time as known by the WS-Resource, then the WS-Resource MAY be destroyed immediately. This facility provides the ability to support an asynchronous form of immediate destruction.

If the value is xsi:nil, then the intent of the service requestor is to specify there is no scheduled termination time for the WS-Resource. In such situations it is RECOMMENDED that the WS-Resource support the immediate WS-Resource destruction operations described in Section 4.

/wsrf-rl:SetTerminationTime/wsrf-rl:RequestedLifetimeDuration

The new TerminationTime requested by the client is to be calculated by adding the duration of time specified in the message to the CurrentTime known to the WS-Resource.

If a zero or negative duration is specified then the WS-Resource MAY be destroyed immediately. This facility provides the ability to support an asynchronous form of immediate destruction.

 

A WS-Resource that receives this message MAY reject the request to change the WS-Resource’s termination time for any reason (e.g. policy). In this case, a fault message MUST be returned to the service requestor.

If a WS-Resource accepts the request to set the WS-Resource’s termination time, it MUST update the TerminationTime resource property of the WS-Resource to the value specified in the message or to a value “in the future” relative to the requested time. If the SetTerminationTime request message is accepted, the WS-Resource MUST respond with the following message:

  <wsrf-rl:SetTerminationTimeResponse>

    <wsrf-rl:NewTerminationTime xsi:nil=”xsd:boolean”?>

       xsd:dateTime

    </wsrf-rl:NewTerminationTime>

    <wsrf-rl:CurrentTime>

       xsd:dateTime

    </wsrf-rl:CurrentTime>

  <wsrf-rl:SetTerminationTimeResponse>

Further constraints on the SetTerminationTimeResponse message are as follows:

/wsrf-rl:SetTerminationTimeResponse/wsrf-rl:NewTerminationTime

This value MAY be “in the future” relative to the xsd:dateTime requested by the service requestor in the SetTerminationTime request message.

This value reflects the new date and time at which the 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. In such situations, it is RECOMMENDED that the WS-Resource support the immediate WS-Resource destruction operations outlined in Section 4.

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

/wsrf-rl:SetTerminationTimeResponse/wsrf-rl:CurrentTime

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

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

·         UnableToSetTerminationTimeFault

o        The request for termination time could not be changed for some reason.

·         TerminationTimeChangeRejectedFault

o        In the case where a WS-Resource is willing to update its TerminationTime, but only with a value “in the past” relative to the requested termination time, then the WS-Resource MAY include a “hint” in the TerminationTimeRejectedFault message indicating the time to which it is willing to extend its TerminationTime.

 

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

The wsa:Action MUST contain the following URI: “http://docs.oasis-open.org/wsrf/rlw-2/ScheduledResourceTermination/SetTerminationTimeResponse”.

 

5.5 Example SOAP Encoding of the SetTerminationTime Message Exchange

The following is a non-normative example of a SetTerminationTime request message using SOAP 1.1 [SOAP 1.1]:

<s11:Envelope . . .>

  <s11:Header>

     . . .

    <wsa:Action>

        http://docs.oasis-open.org/wsrf/rlw-2/ScheduledResourceTermination/SetTerminationTimeRequest

    </wsa:Action>

     . . .

  </s11:Header>

  <s11:Body>

    <wsrf-rl:SetTerminationTime>

      <wsrf-rl:RequestedTerminationTime>

         2001-12-31T12:00:00Z

      </wsrf-rl:RequestedTerminationTime>

    </wsrf-rl:SetTerminationTime>

  </s11:Body>

</s11:Envelope>

The following is an example SetTerminationTimeResponse message using SOAP 1.1 [SOAP 1.1]:

<s11:Envelope . . . >

  <s11:Header>

    . . .

    <wsa:Action>

        http://docs.oasis-open.org/wsrf/rlw-2/ScheduledResourceTermination/SetTerminationTimeResponse

    </wsa:Action>

    . . .

  </s11:Header>

  <s11:Body>

    <wsrf-rl:SetTerminationTimeResponse>

      <wsrf-rl:NewTerminationTime>

         2001-12-31T12:00:00Z

      </wsrf-rl:NewTerminationTime>

      <wsrf-rl:CurrentTime>

         2001-12-31T11:00:00Z

      </wsrf-rl:CurrentTime>

    </wsrf-rl:SetTerminationTimeResponse>

  </s11:Body>

</s11:Envelope>

5.6 Termination Time Expiration

If the service requestor fails to successfully update the termination time of a WS-Resource before the termination time expires, the WS-Resource MAY be destroyed and therefore no longer be accessible. Termination time has expired when the termination time of the WS-Resource (as reflected by the value of the WS-Resource’s TerminationTime resource property element) is “in the past” relative to the current time as expressed in the value of the WS-Resource’s CurrentTime resource property element.

The specific mechanisms employed to destroy the WS-Resource after termination time has expired is implementation dependent. An implementation MAY delay destruction of the WS-Resource at its own discretion. The requestor MUST NOT depend on the destruction of the WS-Resource occurring at termination time expiration but SHOULD assume that the WS-Resource is no longer accessible after termination time has expired.

 

6        Notification of Resource Destruction

A WS-Resource MAY choose to support the pattern of notifying interested parties when it is destroyed. If a WS-Resource chooses to support this pattern and if the WS-Resource uses WS-BaseNotification [WS-BaseNotification] to implement this pattern, then it MUST follow the approach described in this section. An implementation MAY choose to not support this pattern, or it MAY choose to do so using some means other than WS-BaseNotification; in such circumstances, the implementation MAY ignore the approach described in this section.

If the WS-Resource is also a NotificationProducer, according to the WS-BaseNotification specification [WS-BaseNotification], then it SHOULD provide a topic [WS-Topics] to allow requestors to subscribe for notification of its destruction. The notification applies to both immediate and scheduled destruction. The form of the topic is:

<wstop:TopicNamespace name="ResourceLifetime"

   targetNamespace=

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

… >

   <wstop:Topic name="ResourceTermination" …>

      <wstop:MessagePattern>

         <wsrf-rp:QueryExpression

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

             boolean(/*/TerminationNotification)

         </wsrf-rp:QueryExpression>

      </wstop:MessagePattern>

   </wstop:Topic>

</wstop:TopicNamespace>

 

The value of /wstop:Topic/@MessageTypes is implementation-dependent; this specification does not define the exact content of the notification messages produced on this topic. However, the notification message associated with this topic MUST contain the following element:

<wsrf-rl:TerminationNotification>

  <wsrf-rl:TerminationTime xsi:nil=”xsd:boolean”?>xsd:dateTime</wsrf-rl:TerminationTime>

  <wsrf-rl:TerminationReason>xsd:any</wsrf-rl:TerminationReason>?

</wsrf-rl:TerminationNotification>

This constraint is specified in the /wstop:Topic/wstop:MessagePattern element. The TerminationNotification element is further constrained as follows:

/wsrf-rl:TerminationTime

This element contains the date and time when the WS-Resource was destroyed.

/wsrf-rl:TerminationReason

This OPTIONAL element contains an explanation of the situation surrounding the destruction of the WS-Resource. This element is specific to the type of the WS-Resource that was destroyed.

A requestor would send a subscribe request message, following the WS-BaseNotification specification, specifying the “ResourceTermination” topic and referencing a chosen WS-Resource using a WS-Resource Reference [WS-Resource].

7        Security Considerations

This specification defines the message exchanges used to request the destruction of a WS-Resource, or to obtain information about the termination time of the WS-Resource. In this context, there are two categories of security aspects that need to be considered: (a) securing the message exchanges and (b) securing the operations that perform the WS-Resource destruction.

7.1 Securing the Message Exchanges

When messages are exchanged between a requestor and a WS-Resource in order to access or act upon one or more resource properties, it is RECOMMENDED that the communication between the services be secured using the mechanisms described in WS-Security. 

7.2 Securing Resource Destruction

Given that WS-ResourceLifetime defines a mechanism to destroy WS-Resources, security policies should be established to ensure that only authorized requestors can destroy a WS-Resource. Authorization policies should be defined so that the implications of destroying a WS-Resource either through immediate requests or by setting termination time, are considered. The two approaches for destruction may be considered equivalent for authorization reasons. In other words, an authorization policy that describes the ability to perform a Destroy operation on a WS-Resource, conforming to the ImmediateResourceTermination portType, may also need to be applied when the SetTerminationTime operation is performed on the same resource.

It should be noted that this specification does not allow modifications to the CurrentTime and TerminationTime resource properties through the SetResourceProperty request message of WS-ResourceProperties.  Therefore, there should be no authorization enforcement performed when these resource properties are accessed using the Set request message; however, it should be left to the runtime to enforce the requirement as specified. Given a requestor can subscribe for notification of the destruction of the resource using “ResourceLifetime” topic, the security considerations specified in WS-BaseNotification specification are applicable to this topic.

 

8        References

8.1 Normative

 

[WS-Addressing]

http://www.w3.org/TR/ws-addr-core/

[WS-BaseNotification]

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

[WS-BaseFaults]

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

[WS-Resource]

http://docs.oasis-open.org/wsrf/wsrf-ws_resource-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]

http://www.w3.org/TR/REC-xml

[XML-Infoset]

http://www.w3.org/TR/xml-infoset/

 

8.2 Non-Normative

[OGSI]

GGF GFD.15 “Open Grid Services Infrastructure (OGSI) Version 1.0”. Available at   http://forge.gridforum.org/projects/ogsi-wg

[SOAP 1.1]

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

[WS-Security]

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

[WS-I Basic Profile 1.1]

http://www.ws-i.org/Profiles/BasicProfile-1.1.html

 


 

Appendix A. Acknowledgments

Special thanks to the Global Grid Forum’s Open Grid Services Infrastructure working group, which defined the OGSI v1.0 [OGSI] 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), David Martin (IBM), Samuel Meder (ArgonneNational 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), Matsunori Satomi (Hitachi), Igor Sedukhin (Computer Associates), Hitoshi Sekine (Ricoh Company, Ltd.), Frank Siebenlist (ArgonneNational Laboratory), Alex Sim (Lawrence Berkeley National Laboratory), David Snelling (Fujitsu), Latha Srinivasan (Hewlett-Packard), Jem Treadwell (Hewlett-Packard), Steve Tuecke (ArgonneNational 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:

 

Karl Czajkowski (Globus / USC/ISI), Donald F Ferguson (IBM), Ian Foster (Globus / Argonne), Jeffrey Frey (IBM), Frank Leymann (IBM), Nataraj Nagaratnam (IBM), Martin Nally (IBM), Tony Storey (IBM), Sanjiva Weerawarana (IBM)

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/rl-2.xsd

<?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-rl="http://docs.oasis-open.org/wsrf/rl-2"

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

elementFormDefault="qualified" attributeFormDefault="unqualified"

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

 

   <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 ScheduledResourceTermination ====

   -->

 

   <xsd:element name="CurrentTime" >

          <xsd:complexType>

                <xsd:simpleContent>

                       <xsd:extension base="xsd:dateTime" >

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

                       </xsd:extension>

                </xsd:simpleContent>

          </xsd:complexType>

   </xsd:element>

  

   <xsd:element name="TerminationTime" nillable="true">

   <xsd:complexType>

                <xsd:simpleContent>

                       <xsd:extension base="xsd:dateTime" >

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

                       </xsd:extension>

                </xsd:simpleContent>

          </xsd:complexType>

   </xsd:element>

 

 

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

   <xsd:element name="ScheduledResourceTerminationRP">

          <xsd:complexType>

                <xsd:sequence>

                       <xsd:element maxOccurs="1" minOccurs="1" ref="wsrf-rl:CurrentTime" />

                       <xsd:element maxOccurs="1" minOccurs="1" ref="wsrf-rl:TerminationTime" />

                </xsd:sequence>

          </xsd:complexType>

   </xsd:element>

 

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

   <xsd:element name="Destroy">

          <xsd:complexType />

   </xsd:element>

 

   <xsd:element name="DestroyResponse">

          <xsd:complexType />

   </xsd:element>

 

   <xsd:complexType name="ResourceNotDestroyedFaultType">

          <xsd:complexContent>

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

          </xsd:complexContent>

   </xsd:complexType>

   <xsd:element name="ResourceNotDestroyedFault" type="wsrf-rl:ResourceNotDestroyedFaultType" />

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

   <xsd:element name="SetTerminationTime">

          <xsd:complexType>

                <xsd:choice>

                       <xsd:element name="RequestedTerminationTime" nillable="true" type="xsd:dateTime" />

                       <xsd:element name="RequestedLifetimeDuration" type="xsd:duration" />

                </xsd:choice>

          </xsd:complexType>

   </xsd:element>

         

   <xsd:element name="SetTerminationTimeResponse">

          <xsd:complexType>

                <xsd:sequence>

                       <xsd:element name="NewTerminationTime" nillable="true" type="xsd:dateTime" />

                       <xsd:element name="CurrentTime" type="xsd:dateTime" />

                </xsd:sequence>

          </xsd:complexType>

   </xsd:element>

   <xsd:complexType name="UnableToSetTerminationTimeFaultType">

          <xsd:complexContent>

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

          </xsd:complexContent>

   </xsd:complexType>

 

   <xsd:element name="UnableToSetTerminationTimeFault" type="wsrf-rl:UnableToSetTerminationTimeFaultType" />

   <xsd:complexType name="TerminationTimeChangeRejectedFaultType">

          <xsd:complexContent>

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

          </xsd:complexContent>

   </xsd:complexType>

   <xsd:element name="TerminationTimeChangeRejectedFault" type="wsrf-rl:TerminationTimeChangeRejectedFaultType" />

 

 

   <!--

          ============= Notification Message Related  ==================

   -->

   <xsd:element name="TerminationNotification">

          <xsd:complexType>

                <xsd:sequence>

                       <xsd:element name="TerminationTime" type="xsd:dateTime" minOccurs="1" maxOccurs="1" nillable="true" />

                       <xsd:element name="TerminationReason" type="xsd:anyType" minOccurs="0" maxOccurs="1" />

                </xsd:sequence>

 

          </xsd:complexType>

   </xsd:element>

 

 

</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/rlw-2.wsdl

<?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="WS-ResourceLifetime"

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

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

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

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

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

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

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

xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">

 

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

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

   <wsdl:types>

          <xsd:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns="http://www.w3.org/2001/XMLSchema">

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

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

          </xsd:schema>

   </wsdl:types>

 

   <wsdl:message name="SetTerminationTimeRequest">

          <wsdl:part element="wsrf-rl:SetTerminationTime" name="SetTerminationTimeRequest" />

   </wsdl:message>

   <wsdl:message name="DestroyResponse">

          <wsdl:part element="wsrf-rl:DestroyResponse" name="DestroyResponse" />

   </wsdl:message>

   <wsdl:message name="SetTerminationTimeResponse">

          <wsdl:part element="wsrf-rl:SetTerminationTimeResponse" name="SetTerminationTimeResponse" />

   </wsdl:message>

 

   <wsdl:message name="DestroyRequest">

          <wsdl:part element="wsrf-rl:Destroy" name="DestroyRequest" />

   </wsdl:message>

   <wsdl:message name="ResourceNotDestroyedFault">

          <wsdl:part element="wsrf-rl:ResourceNotDestroyedFault" name="ResourceNotDestroyedFault" />

   </wsdl:message>

 

   <wsdl:message name="UnableToSetTerminationTimeFault">

          <wsdl:part element="wsrf-rl:UnableToSetTerminationTimeFault" name="UnableToSetTerminationTimeFault" />

   </wsdl:message>

   <wsdl:message name="TerminationTimeChangeRejectedFault">

          <wsdl:part element="wsrf-rl:TerminationTimeChangeRejectedFault" name="TerminationTimeChangeRejectedFault" />

   </wsdl:message>

   <wsdl:portType name="ImmediateResourceTermination">

          <wsdl:operation name="Destroy">

                <wsdl:input name="DestroyRequest" message="wsrf-rlw:DestroyRequest" />

 

                <wsdl:output name="DestroyResponse" message="wsrf-rlw:DestroyResponse" />

                <wsdl:fault message="wsrf-rlw:ResourceNotDestroyedFault" name="ResourceNotDestroyedFault" />

                <wsdl:fault name="ResourceUnknownFault" message="wsrf-rw:ResourceUnknownFault" />

                        <wsdl:fault name="ResourceUnavailableFault" message="wsrf-rw:ResourceUnavailableFault"/>

          </wsdl:operation>

   </wsdl:portType>

   <wsdl:portType name="ScheduledResourceTermination"

                          wsrf-rp:ResourceProperties="wsrf-rl:ScheduledResourceTerminationRP">

          <wsdl:operation name="SetTerminationTime">

                <wsdl:input name="SetTerminationTimeRequest" message="wsrf-rlw:SetTerminationTimeRequest" />

                <wsdl:output name="SetTerminationTimeResponse" message="wsrf-rlw:SetTerminationTimeResponse" />

 

                <wsdl:fault message="wsrf-rlw:UnableToSetTerminationTimeFault" name="UnableToSetTerminationTimeFault" />

                <wsdl:fault name="ResourceUnknownFault" message="wsrf-rw:ResourceUnknownFault" />

                        <wsdl:fault name="ResourceUnavailableFault" message="wsrf-rw:ResourceUnavailableFault"/>

                <wsdl:fault message="wsrf-rlw:TerminationTimeChangeRejectedFault" name="TerminationTimeChangeRejectedFault" />

          </wsdl:operation>

   </wsdl:portType>

</wsdl:definitions>

Appendix D. Revision History

[This appendix is optional, but helpful. It should be removed for specifications that are at OASIS Standard level.]

Rev

Date

By Whom

What

wd-01

2004-05-21

Latha Srinivasan

Initial version created from submission by contributing companies. Minor modifications made to reflect OASIS formatting and the following issues: WSRF2, WSRF3, WSRF14, WSRF33.

wd-02

2004-06-01

Latha Srinivasan

Modification to Acknowledgments section to reflect TC list as per WS-RP draft spec. v 1.2

Wd-03

2004-06-08

Latha Srinivasan

Fixed namespaces to reflect 2004/06; replaced rogue verdana fonts with Arial; updated Acknowledgments section; added ElementFormDefault and attributeFormDefault to schema and XSD files; updated references to point to pdf versions of files; Fixed reference for WS-BaseNotification and replaced references to “lifecycle” with lifetime

wd-04

2004-11-04

Latha Srinivasan

Addressed issues WSRF6, WSRF30, WSRF43,WSRF49, WSRF53 and WSRF56 in addition to changes suggested by Ian Robinson in email dated Nov 6, 2004

wd-05

2004-12-22

Latha Srinivasan

Addressed issues 84 and 85 to keep the doc in sync with the WSDL and XSD files of rev. 05. Also updated namespaces for WSRF-BF and WSRF-RP.

wd-05a

2005-02-15

Tim Banks & Latha Srinivasan

Reflects resolutions for Issues 19, 62, 63, 81, 84, 85, 86, 93 and 96

wd-06.a

2005-04-18

Tim Banks

Resolution of issue 99 (and corrections to examples), 92

wd-07

2005-05-11

Latha Srinivasan

Resolution of issues 91,101 and 103 and change of namespaces and document identifiers

wd-08

2005-05-17

Tim Banks

Resolution of issues 100,109,113

wd-09

2005-05-18

Latha Srinivasan

Resolution of issue #:114 and updated Acknowledgements section per Ian’s mail

cd-01

2005-05-19

Latha Srinivasan

First Committee draft

wd-10

2005-09-15

Tim Banks

Resolution of issues 127 141, 152, 147, 150.

pr-02.a

2005-11-18

Latha Srinivasan

Minor updates to references per Ian’s mail

cs-01

2006-01-10

Latha Srinivasan

Committee spec version

os

2006-04-01

Latha Srinivasan

Open Standard version

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.