Events and service-oriented architecture: The OASIS Web Services Notification specifications.

The OASIS Web Services Notification (WSN) family of specifications defines a standard interoperable protocol through which Web services can disseminate events. We present here a summary of three WSN specification documents that are currently available: WS-Base Notification, WS-Topics, and WS-Brokered Notification. We conclude with a brief discussion on the use of the notification pattern in the Enterprise Services Bus, a service-oriented infrastructure for mediating requests among cooperating Web services.

INTRODUCTION

Many service-oriented architecture (SOA) implementations are based upon the request/response interaction pattern, where a service requestor identifies a service that it wishes to use and then sends it a request message. A second entity, the service provider, accepts the request message, processes it, and then sends a response message. This is a pattern that is familiar to any programmer who has made a procedure or function call in a procedural programming language or who has invoked a method in an object-oriented language or distributed object system. Indeed this pattern is so familiar that programming interfaces and tools (for example, those used with Web services) often hide the underlying message exchange; these tools present a programming model that looks like a simple procedure call.

Event-based programming, which has been around for many years and has been applied in many areas, is frequently used in user-interface systems, for example the Smalltalk Model-View-Controller (MVC) paradigm (1) or the X Window System, (2) where a change in a model can be reflected in various views, or where components react to user interactions such as mouse clicks or key presses. Support for event-based programming is provided in publish/subscribe systems available from message-oriented middleware vendors. (3) Event-based programming is also used with distributed objects; Object Management Group, Inc. has published two CORBA ** (Common Object Request Broker Architecture) specifications that relate to event-based programming: the Event Service Specification (4) and the Notification Service Specification. (5)

Event-based programming features an entity that represents an occurrence (something that has happened). In object-oriented systems this is usually termed an event object; in message-oriented systems it is variously referred to as a message, event, or event message. In contrast to the request/response pattern where the request and response messages are frequently hidden from the programmer, in event-based programming the event (be it a message or object) assumes center stage. Applications explicitly produce and consume events, and the producing application has a relationship with the event that it produces, rather than a direct relationship with the applications that consume the event. A consumer of events indicates (through a registration process) the events in which it is interested, and it interacts with the event itself, rather than with the application that produced the event. We use the term notification pattern to refer to the interaction pattern that involves registration of consumers and subsequent dissemination of events.

The idea of using the event itself to decouple the event producer and consumer is a significant difference between the request/response pattern and the notification pattern. This decoupling supports one-to-many and many-to-one message exchanges, in addition to the one-to-one exchange found in the request/response pattern. In addition, it may have a more natural fit to the real-world scenario that is being modeled by the application architecture, and it allows further complex event processing to be added in a straightforward fashion. (6)

The OASIS Web Services Notification (WSN) (7) family of specifications defines a standard interoperable protocol through which Web services can disseminate events. These specifications are being developed by OASIS (the Organization for the Advancement of Structured Information Standards), a not-for-profit international consortium that drives the development, convergence, and adoption of e-business standards. The specifications are authored by an OASIS technical committee whose membership comes from a variety of software vendors, users, and other professionals.

The intent of WSN is to define a set of royalty-free, related, interoperable, and modular specifications that allow the notification pattern to be modeled 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. The WSN family is made up of four separate specification documents.

The WS-Base Notification specification (8) defines the Web Services interfaces for notification producers and notification consumers. It includes standard message exchanges to be implemented by service providers that wish to act in these roles, along with operational requirements expected of them. This is the base document on which the other WSN specification documents depend.

The WS-Topics specification (9) defines a mechanism to organize and categorize items of interest for subscription known as topics. These are used in conjunction with the notification mechanisms defined in WS-Base Notification. WS-Topics specifies an XML model for describing meta-data associated with topics, and it defines some topic expression dialects that can be used to refer to them.

The WS-Brokered Notification specification (10) defines the Web Services interfaces for notification brokers. A notification broker is an intermediary which, among other things, allows publication of messages from entities that are not themselves service providers. It includes standard message exchanges to be implemented by notification-broker service providers along with operational requirements expected of service providers and requestors that participate in brokered notifications.

The WS-Notification Policy specification defines a set of policy statements that can be used in conjunction with the other specifications in the family to request particular qualities of service or other behavior.

The first three of these specifications are currently available as drafts and will be the focus of this paper. The WS-Notification Policy specification is currently still at an early stage of development.

In the next section, "Web Services Notification," we present a summary of the first three WSN specifications. A discussion section follows in which how

event-based interactions can be used in SOA alongside interactions based on the request/response pattern is discussed. In particular, the use of events within the Enterprise Services Bus (ESB) (11) and in the context of Complex Event Processing (CEP) is discussed. (6)

WEB SERVICES NOTIFICATION

WSN specifications standardize the syntax and semantics of the message exchanges that establish and manage subscriptions and the message exchanges that distribute information to subscribers. An information provider, known as a notification producer, that conforms to WSN can be subscribed to by any WSN-compliant subscriber. If subscriber and producer are using a common Web-service binding--for example SOAP (Simple Object Access Protocol)/HTTP (HyperText Transfer Protocol)--and have appropriate network connectivity, they could in principle interoperate even if they had been designed by different people and were running in different organizations on different continents.

We start our review of WSN with a section on the terminology used in the specifications. Then, we describe in sequence WS-Base Notification, WS-Topics, and WS-Brokered Notification.

To illustrate aspects of the WSN specifications, we use two example scenarios. The first is a stock-trading scenario in which the service Stock Feed is provided to a number of stock-trading applications. The Stock Feed service supplies a stream of messages indicating a change of price in some traded stock or instrument. The trading applications (possibly automated, possibly involving a human trader) receive these messages and react to them. Our second example is from the systems-management world, where an organization has deployed some printer management software to manage and monitor the printers that it owns. The printers in the organization generate events when they encounter particular situations, both normal and abnormal, and these are monitored by the printer management software.

Terminology and concepts

WSN defines a set of terms, the most important of which we list in this section and use throughout the paper. The terms defined here are intended to eliminate certain inconsistencies that used to plague discussions related to events. For example, the term "subscriber" sometimes referred to the entity that received notifications, sometimes to the entity that set up the subscription, and sometimes even to the entity that paid for the service. The specifications avoid using the term event because this word is susceptible to multiple interpretations.

Situation--A situation is an occurrence (something has happened) that is noted by one party and is of interest to other parties. A paper jam in a printer and a sports result are two examples of situations. Often a situation reflects a change of state of some object, such as a stock-price change, a temperature change, or a change in the internal state of a running software program. Although the type of occurrence related to the situation is immaterial as far as WS Notification is concerned, it is important that information relating to it can be communicated to other services.

Notification--WS-Notification uses this term to refer to the one-way message that conveys information about a situation to other services. The sender of a notification message could choose to format this information in whatever way it sees fit and could even use a different representation for each time the situation occurs. To keep things simpler for receivers, the sender of information typically chooses a specific message type for each kind of situation that the receiver is interested in. The type of message specifies the information items that it contains; it may also specify the format of this information as a sequence of bytes. In WSN a message type is represented by an XML Schema (12) global element definition.

The association between a situation and the type of corresponding notification message is not necessarily one-to-one. It is possible that an application might associate several different notification message types with a given situation. This could be …