J. Software Engineering & Applications, 2009, 2: 295-300
doi:10.4236/jsea.2009.24038 Published Online November 2009 (http://www.SciRP.org/journal/jsea)
295
Research of Publish and Subscribe Model Based
on WS-Notification
Huilian FAN1, Guangpu ZEN1, Xianli LI2
1School of Mathematics and Computer Science, Yangtze Normal University, Fuling, China; 2Chongqing college of Electronic Engi-
neering, Chongqing, China.
Received August 14th, 2009; revised September 14th, 2009; accepted September 27th 2009.
ABSTRACT
WS-Notification bund le of standards, WS-BaseNotifica tion, WS-Topics, and WS -BrokeredNotific a tion, can b e used as a
general purpose publish/subscribe interface for Service Oriented Architectures. We provide an overview of the
WS-Notification specification and describe a modified publish and subscribe model based on WS-Notification. The
model is an adaptive policy-driven notification framework that can help enterprises to meet the flexibility and respon-
siveness requirements of the enterprise. With the modified publish/subscribe model, information consumers can dy-
namically and declaratively crea te and configure entities on their behalves to manage their distribution requirements.
Keywords: WS-Notification, Publish/Subscribe, Notification Broker Service, Notification Con sumer Proxy Service
1. Introduction
In a Service Oriented Architecture (SOA), there is often
a need to monitor situations. This occurs to a computer
management perspective or a much more broad scope of
keeping up to date on real world events such as weather,
financial transactions, etc. To monitor these events, a
client can poll status changes or subscribe for status
changes. In polling case, the client is configured to ac-
tively ask the resource for its latest state. The more fre-
quently the client polls state, the more likely the client
has an accurate resource representation. However, fre-
quent polling requires both of bandwidth and resources
to handle the connection. Thus polling is useful when
monitoring timeliness is not an issue or network and
hardware resources are abundant. But in the SOAP world,
polling is less common as a client typically receives re-
quests from the producer of events. With this peer to peer
style, a publish/subscribe system can be created. In this
system, the client requests that notifications be sent when
they occur. This reduces the latency between the event
occurring and the client processing.
WS-Notification has been standardized by OASIS and
it is a standard that can solve this business problem of
event distribution in heterogeneous complex event proc-
essing systems. It specifies an interface for consumer to
subscribe, filter notifications, and manage subscriptions.
It is also for publishers to send notifications. Further, it
describes a notificatio n broker to allow for scaling of the
system [1].
2. WS-Notification
Associated with the WS-Resource Framework, IBM,
Sonic, and other companies introduced a family of re-
lated specifications called WS-Notification. The basic
idea behind WS-Notification is to standardize the way
that a Web service can notify interested parties (other
Web services) that something of interest has happened . It
is not meant to replace all messaging infrastructure such
as low latency buses, industry standards, or existing in-
frastructure like JMS. However, WS-Notification sys-
tems should be able to integrate with these systems
through simple adapters.
Obviously, the key value to WS-Notification is its
ability as a standard to allow for greater interoperability
with a greater number of vendors and, thus, a lower cost
for implementation. The key features of WS- Notifica-
tions allow for it to be used as well in general purposes
publish/subscribe situations. It defines a unified message
format to achieve interoperability between kinds of sys-
tems, procedures and components in different platforms
and systems, and it defines a set of a standard Web ser-
vices approach using a topic-based publish/subscribe
notification pattern .
WS-Notification family is made up of the following
three components [2]: WS-Topics, WS-BaseNotification
and WS-BrokeredNotification. Figure 1 shows the rela-
tionship betwee n t hem.
Based on the WS-Notification, the publish/subscribe
model is needed to handle the real-world information

Research of Publish and Subscribe Model Based on WS-Notification 296
integration scenario by allowing a subscriber to specify
on behalf of an information consumer filtering rules and
policy constraints, not only to select what types of mes-
sages or contents the subscriber wants the consumer to
receive, but also to specify transformation, scheduling,
distribution, and other constraints to be applied to se-
lected messages before they reach the consumer. The
architecture must enable the generation (on behalf of
consumer) of a proxy service, or agent, which includes
the engines to enforce and manage these constraints at
run-time. The proxy service can receive the messages on
behalf of the information consumer and apply the speci-
fied constraints to the message before delivering it to its
consumer [3].
2.1 WS-Topics
The WS-Topics specification [4] defines a mechanism to
organize and categorize items of interest for subscription
known as "topics." This is achieved by associating each
notification with a topic, and means that subscribers can
define the specific category of event that they are inter-
ested in hearing about. A web service can publish a set of
topics used to organize and categorize a set of notifica-
tion messages that clients can subscribe, and receive a
notification whenever the topic changes.
WS-Topics are very versatile, as they even allo w us to
create topic trees, where a topic can have a set of child
topics. By subscribing to a topic, a client automatically
receives notifications from all the descendant topics
(without manual subscribing to each of them). As part of
the publication of a notification-message, the publisher
associates it with one or more topics.
WS-Topics also provide a coarse-grained filtering
mechanism which allows large sets of uninteresting noti-
fications to be excluded quickly. For example, in a sport
results scenario a subscriber can indicate that he or she is
only interested in receiving notifications about football,
which excludes any events about baseball or hockey.
More fine-grained control of filtering can be achieved
using other filtering mechanisms, such as the message
content filter defined in WS-BaseNotification. For ex-
ample, by selecting only those football games in which
the home team beat the away team. In many situations,
the topic does not actua lly appear in the body of the noti-
fication message itself since the classification of the noti-
fication is made at a higher level than the generation of
the notification content.
In order to avoid naming collisions, and to facilitate
interoperation between independently developed Notifi-
cation Producers and Subscribers, every WS-Notification
Topic is assigned to an XML Namespace. The set of
Topics associated with a given XML Namespace is
termed a Topic Namespace.
2.2 WS-BaseNotification
The WS-BaseNotification specification defines the stan-
dard Web services interfaces for Notification Producers
and Notification Consumers. It includes standard mes-
sage exchanges to be implemented by service providers
who wish to act in these roles, along with operational
requirements expected by them. Notification producers
have to expose a subscribing operation that notification
consumers can use to request a subscription. Consumers,
in turn, have to expose a notify operation that producers
can use to deliver the notification [5,6]. Figure 2, “A
typical WS-Notification interaction” shows that the five
primary entities how to work together to pass data
through the WS-BaseNotification. Initially, the sub-
scriber is responsible for setting up a subscription be-
tween the NotificationProducer Web service and a Noti-
ficationConsumer Web service. This subscription is
managed by the SubscriptionManager Web service
working on behalf of the producer. Subsequently, when a
Situation is observed by the Publisher, the Publisher cre-
ates a notification message and passes it to the Notifica-
tionProducer. It is the responsibility of the producer to
establish whether the notification message matches the
registered subscription or not, and, if so, send the notifi-
cation message to the consumer.
2.3 WS-BrokeredNotification
Even in the simplest publish/subscribe environment, the
amount of connections and boot strapping information
can grow very quickly. If there are only 2 publishers and
2 consumers, and each consumer wants to be notified
from each publisher, 4 connections need to be set up.
Figure 1. Relationship between WS-Topics, WS- aseNotifi-
cation and WS-BrokeredNotification
Figure 2. A typical WS-Notification interaction

Research of Publish and Subscribe Model Based on WS-Notification 297
Add one more consumer and you now have 6 connec-
tions. The number of connections starts to grow very
quickly as more distributors and consumers are added;
the required number of connections for m publishers and
n consumers are m×n connections. To simplify this to-
pology, WS-Notification standardizes a notification bro-
ker which acts as an intermediary between publishers and
consumers. Here, publishers and consumers are decoup-
led from each other and substitute only required boot
strap information to the broker. Therefore, in the scenario
of m publishers and n consumers, the required number of
connections is m + n.
The WS-BrokeredNotification specification extends
the definitions made in the WS-BaseNotification speci-
fication to define the concept of NotificationBroker,
which is an intermediary service to those producers and
consumers can connect in order to pass notifications.
Critically, the NotificationBroker is capable of accepting
subscription requests from consumers, as well as receiv-
ing notification messages from producers. The broker is
then responsible for matching the notifications with the
subscriptions and sending them to the consumer. In this
way, the broker takes on more painstaking functions of
the producer, freeing d evelopers of producer app lications
to concentrate on the business task of observing situa-
tions and generating the appropriate notifications without
worrying about the challenge but mechanical task of
managing subscriptions and matching them to notifica-
tions. Advantages of the brokered notification pattern are
as follows:
 Relieves the publisher of having to implement
message exchanges associated with the notification pro-
ducer. For example, managing subscriptions (Subscrip-
tionManager) and distributing notifications (Notifica-
tionProducer).
 Avoids the need for synchronous communications
between the producer and the consumer.
 Can reduce the number of inter-service connections
and references.
 Acts as a finder service. For example, if a new pub-
lisher is added that publishes notification x, a consumer
does not have to issue a new subscription if it has already
subscribed to the broker with x.
 Provides anonymous notification, which means that
publishers and consumers do not need to be aware of
each other’s identity.
In many scenarios, the NotificationBroker service is
implemented by a middleware provider, ensuring that the
brokering facilities are written to enterprise quality ex-
pectations and often provide additional value-add ser-
vices over and above the basic definition of the service,
for example, logging, transformation, or quality of ser-
vice enhancements above those required by the specifi-
cation [7]. As shown in Figure 3, “A typical brokered
WS-Notification interaction”, the producer must register
Figure 3. A typical brokered WS-Notification interaction
Figure 4. The Publish/Subscribe architectural model
with the broker and publish its topics there. The sub-
scriber must also subscribe through the broker, not di-
rectly with the producer. Finally, when a notification is
produced, it is delivered to the consumer through the
broker.
3. Publish/Subscribe Model Based on
WS-Notification
The modified publish/subscribe model is as shown in
Figure 4. It extends the basic publish and subscribe pat-
tern by extending the subscription capabilities to include
the specification of transformation, distribution, and
scheduling constraints as part of publish and subscribe
subscription [8].
Additionally, this architecture enables non-pub/sub-
enabled systems (that is, information consumers which
are not able to consume notification messages of the
pub/sub system) to participate in the pub/sub pattern by
allowing the model to dynamically create a proxy service
to receive pub/sub notifications on behalf of the con-
sumer. This is the Notification Consumer Proxy Service
(NCPS) shown in Figure 4, which also manages the dis-
tribution of notifications to the consumer based on the
transformation, distribution, and scheduling constraints
specified by the consumer upon subscribing.
As shown, t he model highli g hts the follo wi n g component s:

Research of Publish and Subscribe Model Based on WS-Notification 298
Notification producer: Contains information of inter-
est for consumer. Good examples of information produc-
ers are systems that manage business information for an
enterprise and include master data stores for customer,
product, order information, and so on, in addition to en-
terprise operational data stores.
Notification consumer: Depends on and must con-
sume information from an information producer. For
example, many enterprise business applications like or-
der fulfillment systems depend on data fro m the business
information sources.
Subscriber: Requests creation of a subscription. It
sends a subscribe request message to a notification bro-
ker (pub/sub broker). The subscribe request message
identifies a notification consumer. A subscription is an
entity that represents the relationship between an infor-
mation consumer and an information producer. It records
the fact that the consumer is interested in some or all of
the notifications that the producer can provide. It can
contain filter expressions, and may be long-running or
have a limited lifetime.
Publisher: Creates notification message instances. A
publisher receives information from entities in the infor-
mation producer that monitor and detect a situation. A
situation is an occurrence that is noted by one party and
is of interest to other parties. A notification is a one-way
message that conveys information about a situation to
other services.
Notification broker service: Performs a notification
broker function between notification consumers and no-
tification producers, and it is responsible for sending no-
tifications to the appropriate consumers. It also acts as a
subscription manager and manages requests to query,
delete, or renew subscriptions.
Notification Consumer Proxy Service (NCPS): Re-
ceives notifications from the notification broker on be-
half of the information consumer. Typically, the con-
sumer is not able to receive notification messages, hence
the need for this service to act on its behalf, collect the
notifications, perform some business logic (if the sce-
nario calls for it), enforce the transformation, scheduling,
and distribution constraints for the consumer, and then
send the results to the consumer.
Adapter: An entity that enab les the in teraction with an
information consumer.
To demonstrate the publish/subscribe model, event
distribution was applied to solve a situation of
teacher-student interaction. The situation occurs when
students have questions to ask teacher. WS-Notification
was used in the scenario for the notifications from the
student to the broker and from the broker to the teacher.
This was done through a number of different steps:
1) The teachers registered their interest with the bro-
ker.
2) The students were either configured to send notifi-
cations to the broker or config ured to register themselves
as a publisher to the broker.
3) If students registered themselves as a publisher to
the broker, the broker would ask for notifications from
the students.
4) The students would send question notifications to
the broker.
5) The broker would forward those question notifica-
tions to interested teacher.
In the situation, teacher is not only subscriber but also
information consumer, and student is information pro-
ducer. From user perspective, there are two interfaces:
the student and the teacher. The student interface is re-
sponsible for allowing students to ask questions. The
teacher interface allows teachers to monitor notifications
as they arrive. The interfaces of the publish/subscribe
model among the teacher, notificationbroker, NCPS and
one of the students are following:
1) Subscribe: A subscriber, on behalf of the notifica-
tion consumer, sends an XML subscription request mes-
sage to notification broker service. This subscription
message specifies transformation, distribution, and
scheduling constraints for the information consumer, as
well as the basic subscription constraints on information
content from the producer that the consumer is in terested
in.
For a Web service to act as a NotificationProducer it
must support the Subscribe message exchange – that is to
say the WSDL for the Web service must be included in
its portType definition an operation that contains the
subscribe request and response messages defined by the
WS-Notification specification. By implementing the
Subscribe exchange, the producer service is required to
send a notification to each notification consumer with a
subscription registered whenever the producer has a
message be sent and th e filter conditions exp ressed in the
subscription are satisfying. In the example, the teacher
subscription request is a message sent from the teacher to
the broker to request notifications be sent. It contains the
type id for a question that the teacher wishes to answer it.
In this subscription request, the Teacher requests for no-
tifications for question type with id C001, as shown in
the Listing 1.
Two of the elements of the above request message are
of particular interesting in the Publish/Subscribe envi-
ronment:
 The ConsumerReference is a WS-Addressing end-
point reference that identifies the location of the Notifi-
cation Proxy Service Consumer service to which match-
ing notification messages will be sent by the prod ucer.
 The Filter element, and in particular the TopicEx-
pression filter, is used to determine the specific sub set of
all available notification messages that should match this
new subscription. This is important because the majority
of notifications are of interest only for a small number of

Research of Publish and Subscribe Model Based on WS-Notification 299
Listing 1. SOAP body contents of a subscribe request for
notification delivery
consumers, so we improve the efficiency of the system
by avoiding sending unwanted notifications.
2) Notify: The publisher entity creates a notification
message when it receives information from entities in the
notification producer that monitor and detect a situation,
such as put new questions that are of interest for con-
sumers. The publisher sends the notification message to
notification broker so it can be distributed to the appro-
priate consumers that have subscribed to that message.
3) Notification brokering: The notify message sent by
the publisher is routed by the notification broker service
to the appropriate notification consumer proxy service.
The notification broker matches notification messages to
the consumers that are subscribed to these notifications.
The information consumer proxy service receives the
notification message and performs whatever business
logic it needs to do in order to create and aggregate the
appropriate response to the notification consumer. For
example, the consumer proxy service might need to ac-
cess additional information from the information pro-
ducers to get all the needed data associated with the
change. As a result of applying its specific business logic,
the notification consumer proxy service assembles a
message or a set of messages to be sent to the consumer.
A NotificationBroker may be a WS-Resource, and if it
is, it must support the required message exchanges de-
fined by the WS-ResourceProperties specification and
MUST also support message exchange s and may support
Resource Property elements defined by the following
interfaces:
 NotificationProducer
 NotificationConsumer
 RegisterPublisher
The NotificationBroker portType aggregates the three
portTypes and it is not the only way to imple ment a bro-
ker. A distributed broker implementation can be achieved
by hosting NotificationProducer, NotificationConsumer,
or RegisterPublisher portTypes at one or more physical
endpoints.
<wsnt:Subscribe xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2">
<wsnt:ConsumerReference>
<wsa:Address>
http://notify.yznu.cn:9080/Teacher/NCProxyServiceEndpoint
</wsa:Address>
</wsnt:ConsumerReference>
<wsnt:Filter>
<wsnt:TopicExpression Dialect="http://docs.oasis-
open.org/wsn/t-1/TopicExpression/Simple"
xmlns:typeID="http://www.ibm.com/xmlns/wsn/question/typeID">
typeID:C001
</wsnt:TopicExpression>
</wsnt:Filter>
<wsnt:InitialTerminationTime>P0Y0M0DT1H0M0S</wsnt:InitialTer
minationTime>
</wsnt:Subscribe>
4) Apply constraints:
Transformation constraints: The notification message
is applied against the transformation constraints to de-
termine what transformation module or modules to apply
to the message.
Scheduling constraints: The scheduling service applies
the scheduling policy con straints if any were specified as
part of the subscription. These constraints relate to the
specified delivery schedule for the information consumer.
Notifications that cannot be transmitted due to th e condi-
tions specified in the policy are queued by the scheduling
service for delivery d uri n g t he ne xt avail able window.
Distribution constraints: The distribution service ap-
plies the distribution policy constraints if any were speci-
fied as part of the subscription. One distribution policy
specifies the size limit of a notification message trans-
mitted to the consumer. If a notification message exceeds
this size, it will be broken into a sequence of pieces
which are smaller than the size limit and transmitted to
the consumer individually by the distribution service.
5) Deliver: Once the model satisfies the scheduling
and distribution constraints mentioned in the previous
step, it sends the message to the information consumer
through an adapter service.
4. Conclusions
This paper discusses how to implement a general purpose
publish/subscribe interface for a Service Oriented Archi-
tecture through the WS-Notification bund le of standards,
WS-BaseNotification, WS-Topics, and WS-BrokeredNo-
tification. We describe an adaptive, policy-driven notifi-
cation architectural model that can support a generalized
publish/subscribe interactio n pattern. This mod el is based
on the WS-Notification standards, a set of reusable inte-
gration services. We introduce the teacher-student inter-
active scenario to help to demonstrate the WS-Notifi-
cation features and explain that the publish/subscribe
model is the standard of choice for event distribution and
processing.
5. Acknowledgements
This work is supported by the Natural Scienc e Project of
Chongqing Municipal Education Commission (Project
No.KJ091305)
REFERENCES
[1] R. B. Chumbley and J. D. Eisinger, “Leveraging key
WS-notification features in your business applications,”
April 2009,
http://download.boulder.ibm.com/ibmdl/pub/software/dw/
webservices/ws-wsnotificationWAS7/ws-wsnotifi cation

Research of Publish and Subscribe Model Based on WS-Notification 300
WAS7-pdf.pdf.
[2] Sams Publishing, WS Notification and WS Topics in the
WS Resources Framework, July 2006,
http://www.devarticles.com/c/a/Web-Services/WS-Notific
ation-and-WS-Topics-in-the-WS-Resources-Framework/.
[3] K. Czajkowski, D. Ferguson, I. Foster etc., WS-Resource
Framework, 9th June 2004,
http://www.globus.org/wsrf/specs/ws-wsrf.pdf.
[4] W. Vambenepe, S. Graham, and P. Niblett, 9th October
2006,
http://wsn-ws_topics-1.3-spec-c,
http://docs.oasis-open.org/wsn/wsn-ws_topics-1.3-spec-cs.
[5] B. Sotomayor, “The globus toolkit 4 programmer’s tuto-
rial,” August 19th 2007,
http://gdp.globus.org/gt4-tutorial/multiplehtml/ch08s02.html.
[6] W. Vambenepe, S. Graham, and P. Niblett, August 9th 2006,
http://wsn-ws_base_notification-1.3-spec-cs.pdf,
http://docs.oasis-open.org/wsn/wsn-ws_base_notification-
1.3-spec-cs-01.pdf.
[7] W. Vambenepe, S. Graham, and P. Niblett, August 9th 2006,
http://wsn-ws_brokered_notification-1.3-spec-cs,
http://docs.oasis-open.org/wsn-/wsn-ws_brokered_notifica
tion-1.3-spec-cs-01.pdf.
[8] A. Bou-Ghannam and M. Roberts, “GPASS: A general-
ized publish and subscribe solution using WS-Notifi-
cation standards,” August 2007,
http://www.ibm.com/developerworks/websphere/library /t
echarticles/0708_boughannam/0708_boughan nam.html.