OASIS WS-Notification TC

Document Sample
OASIS WS-Notification TC Powered By Docstoc
					OASIS WS-Notification TC

    Inaugural F2F meeting

    Peter Niblett – convener

         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?

                    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
• Breaks
  – 10.30 to 10.45
  – 12.00 to 13.00 (Lunch)
  – 15.30 to 15:45

• End time
  – 17.00 (5 pm)

                 Charter sections
Name of the TC
   – OASIS Web Services Notification (WS-Notification) Technical
Statement of Purpose
Scope of Work
   –   Scope
   –   Items to be specified
   –   Starting points
   –   Out of scope items
List of Deliverables
Anticipated Audience

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

          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
   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
• The Notification pattern has many applications, for example in the arenas
  of system or device management, or in commercial applications such as
  electronic trading.                                                       7
                        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.                                                  8
          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.

         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
                          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
                             Out of Scope
1. 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.
                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.
   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.
  – All business will be conducted in English.

          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

                      TC strategy
   – Stable versions of the specifications that can be used by other
     groups (e.g. WSDM)
   – Initial focus is on WS-BaseNotification
   – First-pass committee draft focussing on issues that be resolved
       • 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-
Other work
   – NotificationPolicy spec
   – Primer
   – Interoperability Fest                                             16
• 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


Shared By: