OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsn message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [WS-BaseN]Proposed Requirements list



All:
I took the list of Goals and Requirements from the WS-Notification whitepaper and included a subset of those items that were specific to WS-BaseN.  Here is the proposed text to be included in the draft-02 of WS-BaseN.

sgg


1.1        Goals and Requirements

The overall objectives of WS-Notification is presented in [WS-Notification Whitepaper]. The specific subset of those objectives realized by WS-BaseNotification are listed here.

The goal of WS-BaseNotification is to standardize the terminology, concepts, operations, WSDL and XML needed to express the basic roles involved in Web services publish and subscribe for notification message exchange.

1.1.1        Requirements

In meeting these goals, the WS-BaseNotification specification must explicitly address the following requirements:

·        Must support resource-constrained devices. The specifications must be factored in a way that allows resource-constrained devices to participate in the Notification pattern. Such devices will be able to send information to, and receive information from Web services, without having to implement all the features of the specifications.
·        Must provide runtime metadata: There must be a mechanism that lets a potential Subscriber discover what elements available for subscription are provided by a NotificationProducer, and in what formats the subscription for notification can be made.

In addition, the WS-BaseNotification must allow for the following requirements to be met

·        WS-BaseNotification must be independent of binding-level details:  Transport protocol details must be orthogonal to the subscription and the delivery of the notifications, so that the specification can be used over a variety of different transports.
·        Must allow for Message Oriented Middleware implementations. The design of the WS-BaseNotification must allow a service that is acting as a NotificationProducer to delegate its implementation of WS-BaseNotification semantics to a Message Oriented Middleware provider.
·        Relationship to other WS-* specifications: WS-BaseNotification must be composable with other Web services specifications, in particular WS-Security, WS-Policy, WS-Federation, WS-Addressing, WS-Coordination, WS-ResourceProperties, WS-ResourceLifetime, WS-ReliableMessaging [WS-ReliableMessaging] and the WS-Resource framework [State Paper].
1.1.2        Non-Goals

The following topics are outside the scope of the WS-BaseNotification specification:

·        Defining the format of notification payloads: The data carried in NotificationMessage payloads is application-domain specific, and WS-BaseNotification does not prescribe any particular format for this data.
·        Defining any Events or NotificationMessages. The WS-BaseNotification specification does not define any “standard” or “built-in” notification situations, events or messages.
·        Defining the mapping between Situations and NotificationMessages. The WS-BaseNotification specification does not define the circumstances under which a potential producer of information should decide if and when it should actually notify the registered NotificationConsumers. However they do define how it performs the notification once it has decided to do so.

Defining the means by which NotificationProducers are discovered by subscribers It is beyond the scope of this specification to define the mechanisms for runtime discovery of NotificationProducers.


++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]