1

OASIS WS-Notification TC

Inaugural F2F meeting

Peter Niblett – convener

2

Pre-meeting agenda

• Appointment of Note Takers• Roll Call

– Inaugural members– Prospective members (sign-up sheet)– Observers + other OASIS members (no roll-call)

• Election of Co-chairs– William Vambenepe (HP)– Peter Niblett (IBM)– Any other nominations?

3

Proposed Agenda• Approval of Agenda • Welcome from OASIS staff Jamie Clark• Review of TC charter Peter Niblett• Overview of TC process William Vambenepe

– Follow-on meeting details– TC working practices

• Contributed work– Publish Subscribe Notification paper Steve Graham– WS-BaseNotification Steve Graham– WS-Topics Peter Niblett– WS-BrokeredNotification Dave Chappell

• Issues & First Steps– Review of spec authors' issues Sanjay Patil– New issues and clarifications – TC strategy William Vambenepe– Assign roles

• Wrap up

4

Timekeeping

• Breaks– 10.30 to 10.45– 12.00 to 13.00 (Lunch)– 15.30to 15:45

• End time– 17.00 (5 pm)

5

Charter sections

Name of the TC– OASIS Web Services Notification (WS-Notification) Technical

Committee

Statement of PurposeScope of Work

– Scope– Items to be specified– Starting points– Out of scope items

List of DeliverablesAnticipated AudienceLanguage

6

Statement of Purpose [1]• The purpose of the Web Services Notification (WS-

Notification) TC is to define a set of specifications that standardize the way Web services interact using the Notification pattern.

• The goal of this TC is to define a set of royalty-free, related, interoperable and modular specifications that allow this pattern to be modelled in an explicit and standardized fashion.

The benefits of such standardization include interoperation between application entities written by different authors, as well as interoperation between different publish/subscribe messaging middleware providers.

7

Statement of Purpose [2]• In the Notification pattern a Web service, or other entity, disseminates

information to a set of other Web services, without having to have prior knowledge of these other Web Services. Characteristics of this pattern include:1. The Web services that wish to consume information are registered with

the Web service that is capable of distributing it. As part of this registration process they may provide some indication of the nature of the information that they wish to receive.

2. The distributing Web service disseminates information by sending one-way messages to the Web services that are registered to receive it. It is possible that more than one Web service is registered to consume the same information. In such cases, each Web service that is registered receives a separate copy of the information.

3. The distributing Web service may send any number of messages to each registered Web service; it is not limited to sending just a single message.

• The Notification pattern has many applications, for example in the arenas of system or device management, or in commercial applications such as electronic trading.

8

Scope of Work• The scope of this work is to define a set of related, interoperable and

modular specifications that standardize the concepts, message exchanges, WSDL and XML schema renderings required to express the Notification pattern, as outlined in the previous section. These specifications will cover the basic Notification pattern along with additional functions that support the use of this pattern.

• The specifications produced by the TC will be independent of binding-level details. The method of registering for information, and the actual delivery of that information will be orthogonal to transport protocols, so that the specifications can be used over a variety of different transports.

• The specifications will 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.

• The specifications will be designed so that implementations of the specifications can map naturally onto traditional Messaging Middleware systems. The specifications will not describe or attempt to standardize the nature of this mapping.

9

Items to be specified [1]• The means by which one Web service can be registered with another

in order to receive notifications. It will be possible for this registration to be performed by a third party. This includes the means by which the registration indicates the kind of information that it covers.

• The means by which such registrations (subscriptions) can be modified or deleted.

• The means by which a Web service delivers information to those Web services that are registered with it. This includes the possibility of “bulk notification”, i.e. batching multiple pieces of information into a single message.

• The means by which a Web service can limit the amount of information that is being sent to it.

• The means by which a Web service can act as a “notification broker”. A notification broker can act as a intermediary between the producer of the information and the Web services that receive it.

• The means by which an entity which is not itself a Web service can use a notification broker to deliver information to Web services.

10

Items to be specified [2]• A language that can be used to describe a Topic information space,

and associated metadata.• Topics are used to categorize the kinds of information that can be

sent or subscribed to as part of a subscription registration. • One or more Topic Expression dialects, used to identify Topics or

sets of Topics, within a Topic information space. • The means by which a Web service can provide runtime metadata

showing what Topics it has available for subscription, and in what formats the subscription can be made.

• One or more Policy language(s) that express the policies that can be applied to a subscription (for example maximum message rate or quality of service) and to other roles and components within the scope of work of the TC.

• A list of the various roles that Web services, or other entities, can assume within the Notification pattern, along with a description of the function required in order to fulfill each role.

• Concepts and Terminology to support the above

11

Starting points• The WS-Notification TC takes, as its starting point, the Web Service Notification

specification documents recently published by Akamai Technologies, Computer Associates International, Fujitsu Laboratories of Europe, the Globus Alliance/Argonne National Laboratory, Hewlett-Packard, IBM, SAP AG, Sonic Software, and Tibco Software. These documents are:

– Publish-Subscribe Notification for Web services– Web Services Base Notification – Web Services Topics – Web Services Brokered Notification

• The TC will coordinate with the proposed WS-RF TC, and the standards produced by the WS-Notification TC will conform to the implied resource pattern specified by the WS-RF TC. Specifications produced by the WS-Notification TC will make use of specifications from the WS-RF TC concerning lifetime and properties of WS-Resources.

• Other contributions in addition to those listed above will be accepted for consideration without any prejudice or restrictions, and evaluated on their technical merit, as long as the contributions conform to this charter

12

Out of Scope1. The TC will not prescribe any particular format for the information transmitted in

a Notification (other than requiring it to be expressible as a WSDL message).

2. The TC will not define schemas for notification messages for use in particular application domains.

3. The TC will not define standard Topic information spaces.

4. The TC will not define the mapping to any particular programming language, or to any particular messaging middleware.

5. The TC will not attempt to provide specifications for things which have a wider applicability within Web Services. For example, the TC will not provide specifications for the following features:

Routing, Addressing, Policy Framework, Resource destruction, Resource properties, Reliable Messaging, Encryption, Message Integrity, Mechanisms to protect against corruption of an individual message, Authentication, Message Non-Repudiation, Transactions and Compensation

Where required, these features are provided by composing Notification with other Web Services standards.

13

List of deliverables• A revised set of WS-Notification specifications (WS-Base

Notification, WS-Topics, WS-Brokered Notification). Committee drafts due within 1 year of first meeting.

• A WS-NotificationPolicy specification detailing the policy language associated with Notification. Committee draft due within 1 year of first meeting.

• A primer introducing the above specifications, including use cases, scenarios and suggested best practices for domain experts, as appropriate. Committee draft due within 1 year of first meeting. These specifications will reflect refinements and changes made to, and by, contributions to the TC that are identified by members for additional functionality and semantic clarity within the scope of the TC charter. The TC may choose to vary the number of the specification documents and their titles.

14

Remaining charter sections

The anticipated audience for this work includes:– other specification writers that need the notification

pattern for Web services; – vendors offering web service or message oriented

middleware products; – software architects and programmers who design and

write distributed applications requiring notification.

Language– All business will be conducted in English.

15

Proposed TC process

• Teleconference schedules– Bi-weekly one-hour calls Monday, noon US Eastern time– Starting May 10th

• Face to Face Meetings– Week of July 26th - UK– Week of October 11th or 18th – USA

• Decision making– Consensus, backed up by OASIS ballots– Use issue list to drive process

• No formal subcommittees (initially)• Liaisons

16

TC strategyPriority

– Stable versions of the specifications that can be used by other groups (e.g. WSDM)

– Initial focus is on WS-BaseNotification

Approach– First-pass committee draft focussing on issues that be resolved

quickly• Typographical problems and corrections• OASIS namespace and URLs• Simple clarifications

– More profound issues (e.g.new functions, restructuring) to be handled in subsequent passes.

– Sequence: WS-BaseNotification, WS-Topics, WS-BrokeredNotification

Other work– NotificationPolicy spec– Primer– Interoperability Fest

17

Roles

• Secretary• Issues secretary

– Sanjay Patil has volunteered

• Lead and supporting editors for the first drafts– Base Notification– Topics– Brokered Notification

• Webmasters– William and Peter

• Liaison focal point– WSDM– WSRF