Semantic Modeling and Design Patterns for Asynchronous
Events in Web Service Interaction
Li Li, Wu Chou, Feng Liu, Dan Zhuo
Avaya Labs Research, Avaya Inc.
{lli5,wuchou,fliu1,dzhuo}@avaya.com
Abstract
This paper proposes a conceptual model for modeling
static and dynamic event sources by reusing the
information in WSDL. A set-theoretic semantics for event
subscription is introduced, based on which two metrics,
recall and precision, are proposed to measure the
accuracy of event subscriptions. We discuss the accuracy
of several event subscription strategies under the
framework of current web service event subscription
standard proposals (WS-Eventing and WS-Notification).
Four major types of event broker design patterns are
discussed based on two visibility/reachability factors: if
sink knows the source and if source can deliver events
directly to the sink. The implication on the broker state
and message routing is studied in this analysis. A
prototype implementation indicated that these design
patterns are feasible.
1. Introduction
Web service technologies have eliminated the dependency
on computing platforms, programming languages and
models by using XML technologies and standard
protocols. These technologies have been applied to
telecommunication services [1][2][7] where dynamic
resource and asynchronous events management are critical
to the usability and performance of the services. Two web
service event management standardization approaches,
WS-Eventing [4] and WS-Notification suite [5] are
proposed to address the asynchronous publish/subscribe
message patterns at web service level. These two proposals
are based on the following key concepts:
• Event Source: a web service that generates
events and accepts subscriptions.
• Event Sink: a web service that receives event
notification messages.
• Subscriber: a web service that subscribe to event
sources on behalf of event sink; they are usually
identical.
• Subscription Manager: a web service that
manages the subscriptions, such as renewal and
termination, on behalf of the Event Source; it can
be the same web service as Event Source.
IEEE International Conference on Web Services (ICWS'06)
0-7695-2669-1/06 $20.00 © 2006
Although these standard proposals provide general
frameworks for managing web service based event
subscriptions, we found in practice that there are some
important issues that need to be resolved in order for the
standards to be successfully applied to asynchronous web
services:
1. When and why should we use WS-Eventing or
WS-Notification instead of other simpler
methods, such as WS-Addressing, to manage
asynchronous messages?
2. If WS-Eventing or WS-Notification does apply,
how does a service represent and publish the
event source model to facilitate event
subscription and management?
3. With a chosen event source model, what are the
possible subscription strategies a service can
provide? What are the advantages and limitations
of each strategy?
4. How do we quantitatively measure the
effectiveness of an event service by the
subscription results?
5. If we move beyond point-to-point interactions,
what are the possible event proxy and broker
architectures? What functions do they provide
under what constraints?
To address these questions, we propose a conceptual
model that considers both static and dynamic event
sources based on WSDL standards. We define a protocol
independent formal semantics for event subscription so
that quantitative measurements on the effectiveness of
event model and subscriptions can be defined and
comparative analyses on various subscription strategies
can be provided. Based on two service visibility
parameters, we analyzed four event proxy/broker design
patterns and introduced techniques to support dynamic
message routing while minimizing state information.
The rest of this paper is organized as follows: Section 2
provides brief overview on some related work; Section 3
clarifies some confusions about asynchronous messages
with some formal definitions. Section 4 discusses the
conceptual event model based on WSDL. Section 5
 introduces a set-theoretic model of event subscription, and
two metrics, recall and precision. Section 6 analyzes the
strength and weakness of different event subscription
strategies. Section 7 is dedicated to discuss various
proxy/broker design patterns. We conclude the work of
this paper in the summary after a brief introduction to the
implementation techniques.
2. Related Work
WS-Eventing publishes static event sources by annotating
WSDL PortType with a special attribute. It does not
publish dynamic event sources in service WSDL but
allows such sources be referenced by WS-Addressing in a
subscription message. WS-Eventing has no concept of
event broker that publishes its own service interface.
WS-BaseNotification [5] publishes its static and dynamic
event sources in WSDL as topics of WS-Topic [5]. WS-
Topic allows definition of hierarchical topic trees that can
be grown dynamically. While WS-Topic serves its purpose
to model event bubbling and decouples event publishers
and subscribers, it has the following constraints: 1) WS-
Topic does not separate topic types and instances; and 2)
WS-Topic does not associate the topics with event
operations in WSDL, but defines its own event patterns for
each topic;
WS-BrokeredNotification [5] describes an event broker
service to support indirect event subscription, publication,
and delivery. Barros et al [6] describes several routing
patterns in business process management where an
intermediary party is involved in message exchanges
among other parties, such as Request with referral,
Delayed request, and Dynamic routing. Intermediary
messaging patterns, including Wire Tap, Detour and
Message Broker, are extensively discussed in EAI
(Enterprise Application Integration) [10].
Luckham et al [11] introduces several causal relationships
between events in distributed system, including temporal,
computational and probabilistic for the purpose of event
aggregation and viewing.
3. Analysis of Asynchronous Message
Asynchronous messages can be either events or responses
to some request. Events and asynchronous responses
sometimes appear to be identical and cause confusions in
web service development. In this section, we attempt to
clarify the issue with some analyses and formal definitions.
In general, web service events fall into two main
categories:
IEEE International Conference on Web Services (ICWS'06)
0-7695-2669-1/06 $20.00 © 2006
• Proactive: these events are generated as a result
of state change caused by environment. For
example, after a person signs on a travel assistant
service, it may receive weather alert events when
severe storm occurs. In CSTA [7], the service
provider may generate events when system status
changes.
• Reactive: these events are generated as a result of
state changes caused indirectly by service
invocations. For example in CSTA: after a call is
made to a device, a positive response will be sent
back if the call request is valid. After that, a
DeliveredEvent will occur if the call is received
by the called party; otherwise a FailedEvent will
occur.
Responses to a request can be synchronous or
asynchronous. Responses of a request are synchronous if
the responses immediately follow the request. In other
words, after a request was sent by the sender, the sender
will wait until the responses are received by the receiver.
Otherwise, the responses are asynchronous and the sender
will not block for responses. In asynchronous situation, the
sender can send other requests, and some other messages
may arrive at the receiver before the responses.
Reactive events appear to be identical to asynchronous
response in terms of temporal relationship, but their logical
relations to the request are different: a request is the
sufficient condition for its responses but a request is the
necessary condition for its reactive events. More formally,
from the service consumer perspective, the causal relations
between request, responses and events can be defined as
follows, where send(M,t) and receive(M,t) are two
primitive actions of sending and receiving a message at a
particular time over a transport connection respectively,
and situation(t) indicates the occurrence of a situation at
some time:
M j ∈ response( M i ) Ÿ
(∃ti ) send ( M i , ti ) → (∃t j )t j > ti ∧ receive( M j , t j )
M j ∈ reactive( M i ) Ÿ (∃t j ) receive( M j , t j ) →
(∃ti )(∃t k )t i < t j ∧ send ( M i , t i ) ∧ situation(t k )
M j ∈ proactive Ÿ
(∃t j )receive( M j , t j ) → (∃ti )ti < t j ∧ situation(ti )
The semantic difference between asynchronous responses
and proactive events leads to different mechanisms to
represent the message destination. Asynchronous
 responses are ascribed to a particular request. They can be
handled by WS-Addressing on a per-request basis. On the
other hand, proactive and reactive events should be
handled by subscribe/publish patterns as they are not
ascribed to any particular request.
It seems feasible sometimes to use WS-Addressing, or
other ad-hoc call-back mechanism, to subscribe to reactive
events in the initial request message. However, this
approach loses flexible control on event subscription, such
as lifecycle management, event filtering, and dynamic
change of delivery mode and destination.
4. Web Service Event Source Modeling
To facilitate subscription, an event service should publish
an event source model that clearly defines possible sources
for subscription. This model should include both the static
and dynamic event sources, and it should reuse
information in WSDL to increase interoperability and
avoid duplication.
The static model of an event source web service consists
of event types and interfaces as this information is
constant during the interactions. Events are modeled as
outbound operations, which are grouped into PortType
(WSDL 1.1) or Interface (WSDL 2.0) based on their
logical or functional relations. A common practice in
WSDL authoring is to assign event operations with
indicative names to separate them from non-event
operations. For instance, all event operation and message
names end with “Event.” There are three ways to organize
event operations: 1) a PortType/Interface mixes event with
non-event operations (for example ECMA-348); 2) a
PortType/Interface contains only events; and 3) a
PortType/Interface extends another PortType/Interface
with only events (extension is only possible in WSDL 2.0).
During service interaction, a web service may create and
destroy resources that generate events specified in the
static model. For example, a conference web service may
create and destroy conference and participant resources,
which can be regarded as event sources as well. A CSTA
web service may create and destroy call, connection and
monitor resources, which are all event sources [7].
Our event source model, considering both static and
dynamic event sources, is illustrated in Figure 1. Each Pi
denotes a PortType or Interface. Each Di denotes a type of
dynamic source. The service can create many instances
(not shown in the figure) for each Di during interactions.
A solid arrow points from a source to its event types Ei.
IEEE International Conference on Web Services (ICWS'06)
0-7695-2669-1/06 $20.00 © 2006
In the static model, a line with open arrow indicates
inheritance relationship between interfaces. For example,
since P2 inherits from P1, P2 contains event type E3.
In the dynamic model, the lines with open arrow indicate
event propagation relationships. Any event from a source
will fire from that source. An event can also bubble up or
drip down the path. For example, if bubble is permitted at
D4, any event from D4 will be propagated to D3 and D1.
On the other hand, any event from D1 may be propagated
to all its children if drip down is enabled at D1. Instances
of a source type Di are treated as the publishers of Di.
Static model is the minimal requirement for WSDL based
web services. The dynamic model can be explicitly
represented based on WSDL, WS-Resource Framework
and XML Link, or implicitly assumed between web
service agents.
Event Source Web Service
static
sources P1
P3
P2
event types
E1 E2 E3 E4 E5
dynamic
sources D1
D2 D3
D4
Figure 1: Web service Event Source Model
5. Subscription Semantics
An event subscriber expresses its interest in certain events
from the event source by subscribing to the event source in
the way prescribed by the event service. In this section, we
describe a protocol independent set-theoretic definition for
subscription so that we can define some metrics to
measure the accuracy of subscription, as well as analyze
 various subscription strategies within our event source
model.
For any subscription, we denote its intention as a set of
interested events: Interest(Subscription). Such intention
has to be realized by concrete protocol messages of WS-
Eventing and WS-Notification. The subscription message
of both WS-Eventing and WS-Notification consists of the
following key properties:
Subscription = (Source, Filter, Sink, Expiry)
where
• Source is an EPR representing the event source.
• Filter is an optional element for event filtering; it
can be based on X-Path, XSLT, XML Query, or
any other XML dialect; it can be modeled as a
function that maps any event to a Boolean value;
• Sink is an EPR representing the event sink;
• Expiry is an optional element indicating the
expiry time of the subscription; it can be regarded
as a point of time in general.
The success of this message entails the following
conditions hold:
1. Web service endpoint referenced by Source must
exist and be reachable.
2. Web service endpoint referenced by Sink must
exist and be reachable.
3. Filter is valid; this is an implementation
dependent test.
4. Expiry is semantically valid; for example, it
cannot be a time in the past.
Event types source event
space
subscription
Time
t0 TS
Figure 2: Subscription as query against source event
space
The conditions 1 and 2 above ensure that the transport
connectivity between the source and sink is valid at the
time of subscription. These tests cannot be delayed
because there is no provision in WS-Eventing or WS-
Notification to send faults to the subscriber after the
positive response has been issued. The source may
IEEE International Conference on Web Services (ICWS'06)
0-7695-2669-1/06 $20.00 © 2006
respond with an actual expiry time that is different from
expected Expiry. The subscription can be terminated by
the subscriber through unsubscribe message or by the
source prematurely. The subscriber can also renew any
subscription by resetting the Expiry property. Under this
scenario, a subscription can be modeled as a search
against a two-dimensional event space defined by the
event model and source lifetime illustrated in Figure 2.
More formally, a subscription with a lifespan from time t0
to TS defines a set of events as follows:
Definition 1
Event ( Subscripti on, t 0 , TS ) =
{e | (∃Source )(∃Sink )(∃E ∈ Model ( Source))
e ∈ E ∧ e ∈ Event ( Source, t 0 , TS ) ∧ Filter (C (e))}
where
• Model(Source) is the static model (WSDL) of the
source service.
• e is an event instance of type E and C(e) is a
event context for e that contains information
relevant to e;
• Event(Source,t0,TS) is the set of events generated
by Source before time TS. The t0 parameter
allows Source to ignore events before the
subscription;
• TS=min(TE, TU), where TE is the subscription
expiry time and TU is the subscription
termination time.
The accuracy of a subscription Si can be measured by
recall and precision [9]:
| Interest(S i ) ∩ Event(S i ,t0 , TS ) |
recall ( Si ) =
| Interest(S i ) |
| Interest(S i ) ∩ Event(S i ,t 0 , TS ) |
precision ( Si ) =
| Event(S i ,t0 , TS ) |
For example, if Interest(S)=E1 ∪ E2 and Event(S,t,T)=
E1 ∪ E2 ∪ E3, then recall(S)=1 but precision(S)<1 since
E3 falls out of our interest.
If recall is less than 1, it means some events interested by
event sink are not delivered to the sink. If the missing
events are critical, they may derail the system. On the other
hand, if precision is less than 1, it means some events
delivered to the sink are unsolicited. Such unwanted
events, if occurs in high volume, may flood the network
and system and impact the performance of the overall
service. The goal of service design is to achieve
Interest(S)=Event(S,t,T), so that precision and recall of
each subscription is 1.
 targets: dynamic source types and dynamic source
6. Subscription Strategies instances.

There are three subscription strategies within our event In our event source model, if a sink subscribes to a
source model and subscription semantics: dynamic source type, it receives all events published to
• Filtering Only: This strategy allows expression that type by its instances. More formally, we have:
of subscription interest only by the Filter; the Event ( Di , t0 , TS ) =  d ∈D Event (d ij , t 0 , TS )
ij i
recall and precision depend on the expressive
where dij is a dynamic source instance of type Di and t0 and
power of the filtering function.
TS are defined as in Definition 1.
• Targeting Only: This strategy allows expression
of interest only by Source. It indicates additional
A subscriber can also subscribe to a particular dynamic
source information as part of the WS-Addressing
instance. For example, if Interest(Subscription)={event
EPR. This strategy is most effective when we are
from source instance d3 of type D3 except events of type
interested in all events from a particular source.
E3 from D3} in Figure 1, we can express d3 as part of the
This method guarantees the recall in these
Source using Targeting Only:
situations. However, since no filtering is used, the
Subscription = (Service/d3, −E3[D3], Sink, Expiry).
precision may suffer in general.
• Targeting+Filtering: This strategy allows both
Alternatively, we can express d3 as part of the Filter using
Targeting and Filtering to take advantages of
Filtering Only:
both strategies;
Subscription = (Service, Any[d3]−E3[D3], Sink, Expiry).
Each strategy has impact on subscription accuracy,
Both subscriptions guarantee that recall=1 and
usability, and service implementation, which will be
precision=1.
discussed in more detail in the following subsections.

6.1. Static Model 6.3. Targeting vs. Filtering

Previous sections show that an event source can be

Static model provide three levels of subscription targets:
expressed as part of either targeted source or filter. It turns
service, interfaces, and event types.
out that different subscriptions may produce exactly same
event set (Definition 1) under an event source model. The
For example, if Interest(Subscription)={Event of type E1
main difference is that targeting subscription not only
or E2 but not E3} in Figure 1, we can use Filtering Only
insists that the source exists but also associates the
strategy by filtering on the events:
subscription lifecycle with that of the source (Definition 1)
Subscription = (Service, E1 ∪ E2 ∪ −E3, Sink, Expiry)
whereas filtering does not enforce these constraints. For
or more concisely by filtering on the Interface P2:
example, if we subscribe to dynamic source d3 by
Subscription = (Service, P2, Sink, Expiry).
targeting, resource d3 must exist for the subscription to
succeed and the subscription will be terminated as soon as
Alternatively, this interest can be expressed by Targeting
d3 is removed. On the contrary, putting d3 in the filter
Only by adding interface P2 to the Source EPR:
does not cause the subscription to fail or terminate when
Subscription = (Service/P2, Any, Sink, Expiry).
d3 is removed, since d3 may come to existence later on.
All these subscriptions guarantee that recall=1 and
precision=1.
Modeling a source by targeting in a SOAP message allows
the web service endpoint to dereference the source without
However, if Interest(Subscription)={event of type E1 or
looking at the SOAP message body. It is useful in case that
E3 but not E2} in Figure 1, the best we can do with
the web service does not provide any filtering mechanism
Targeting Only is:
(Filter is optional in both WS-Eventing and WS-
Subscription = (Service/P1, Any, Sink, Expiry).
Notification). On the other hand, filtering is useful for
It is obvious that recall=1 but precision<1 since E2 is a
complex and fine-grained subscriptions so that one
fallout event.
subscription message can target multiple sources.

6.2. Dynamic Model 7. Event Broker Architectures

In enterprise environment, an event sink may not interact
In addition to the information provided by the static
with the event sources directly. Instead, some SOAP
model, dynamic model provides two additional levels of

IEEE International Conference on Web Services (ICWS'06)

0-7695-2669-1/06 $20.00 © 2006
 intermediary nodes may act as proxy or broker to bridge It is clearly in this case the broker node can be completely
the sinks and sources. stateless as it performs content-based message routing.
The response to subscription can alternatively bypass
The design of event proxy/broker depends on two broker y (the dotted line) if sink x indicates so by r:x.
visibility/reachability factors: if the subscribers know the Broker y is not involved in the notification path. The
identity of the source, and if the event notification from constraint on this design is that the sinks and the sources
the source to the sink is direct or not. These four are directly aware of each other but sink cannot reach the
combinations are illustrated as a decision tree in Figure 3. source directly. This is useful in the situation where source
Link known means Subscriber knows the identity (EPR) of is inside a HTTP firewall where inbound connections are
the Source when subscribing. Link direct means the restricted but outbound ones are permitted.
notification messages can be delivered directly from
source to sink. To ensure broker stay in the subscription path, broker y
can modify the r:x property if necessary by inserting y’s
subscriber EPR before x’s EPR (Figure 5). In case of multiple
known unknown brokers y1, y2,…,yn, each broker yi can insert its EPR and
creates a stack of EPR when the message arrives at x:
r:yn/…y2/y1/x. The response message can be formulated
source source
by popping the stack at each node. It is tempting to
represent this stack as multiple r:yi elements except WS-
direct indirect direct indirect
Addressing does not permit this. A workaround is to store
this stack in wsa:ReferenceParameters of the reply EPR
sink sink sink sink of the subscribe message. The stack will be bound to the
response message according to WS-Addressing. The same
technique is employed by SIP [8] and Smart Proxy [10].
+k+d +k-d -k+d -k-d This way, the brokers can be stateless as the return path is
recorded in the response message. We will henceforth call
Figure 3: Combinations of source sink relations with this approach Theseusian technique after Greek mythology
proxy/broker intermediary that Theseus escaped from the Labyrinth following a
A key question in proxy/broker design is what state the thread he played out in the maze on his adventure to slay
SOAP intermediary has to keep. Ideally, we hope to keep Minotaur.
as little state information as possible. We will analyze each
case in more detail in the following subsections. To If y wishes to conceal the identity of x from z, it can
shorten the notation, we use to:z to indicate the encrypt x’s EPR, for example with Symmetric Key
destination EPR of a message, r:y to indicate the reply Encryption algorithms, and decrypt it before routing.
destination EPR of WS-Addressing, and n:x to indicates Alternatively, y can encode x’s EPR and decode it for
the sink EPR of WS-Eventing and WS-Notification. routing, for example with UUID. The encode/decode
scheme can be very secure but requires y to maintain a
dynamic codebook.
7.1. Known & Direct (+k+d)
If wsa:ReplyTo is not supplied in the original message, the
The message flow of this case is illustrated in Figure 4.
response has to be sent back in the same transport
connection. In this case, broker y needs to maintain
sink x broker y source z transaction state at the transport level. For example, y has
to hold the HTTP connection from x until it receives the
to:z, n:x to:z, n:x response from z.
subscribe subscribe
In this case, we assume source z is preconfigured to send
all notification messages to broker y. Broker y can be
to:x stateless in subscribe phase, because it can perform
notification
content-based message routing. Broker y is involved in
both subscription path and notification path since sink x is
Figure 4: Case +k+d message sequences with no totally transparent to source z.
message translation

IEEE International Conference on Web Services (ICWS'06)

0-7695-2669-1/06 $20.00 © 2006
 sink x broker y source z sink x broker y source z

to:z, r:x, to:z, r:y/x to:z, r:x, to:z, r:y/x,

n:x n:x n:x n:y/x
subscribe subscribe subscribe subscribe

to:x to:x to:y/x

notification notification notification

Figure 5: Case +k+d message sequences with message Figure 7: Case +k-d message sequences with message
translation translations

7.2. Known & Indirect (+k-d) sink x broker y source z

The message flow of this case is shown in Figure 6. to:t, n:x to:z, n:x
subscribe subscribe
sink x broker y source z

to:z, n:x to:z, n:x to:x

notification
subscribe subscribe

Figure 8: Case –k+d with no message translation

to:x to:x
notification notification
Figure 6: Case +k-d message sequences with no
message translation.
However, this setup does not allow the notification
messages to be redirected to a different broker
dynamically. One way to address this issue is to modify
the subscribe message so that the event notifications are
sent to broker y first. This is achieved with the Theseusian
technique in section 7.1. The EPR stack is now stored in
the sink EPR of subscribe message and bound to the
notification messages. As a result, broker y in the
notification phase can be stateless since route information
is recorded in the notification messages (Figure 7).
7.3. Unknown & Direct (-k+d)
The message flow is described in Figure 8. In this case, the
sink x does not know the identity of source y, only a
virtual source t, which is dynamically bound to z (or
multiple sources) by y at runtime. This dynamic binding
can be realized by a routing table, a web service registry
such as UDDI, or other mechanisms, such as Quality of
Service (QoS) and failover policies. Again we can ensure
broker stays in the subscription phase using the
Theseusian technique in section 7.1.
7.4. Unknown & Indirect (–k-d)
The message flow is depicted in Figure 9. In this setup,
sink x and source z are transparent to each other. The
virtual source t is bound to z (or multiple sources) by
broker at runtime. Broker y can perform sophisticated
event management tasks, such as subscription forking and
event aggregation [6].
Source z can be statically preconfigured to send messages
to broker y, or dynamically send messages to a different
broker using the Theseusian technique discussed before
(section 7.1) to make the broker stateless.
Another variation of this case is that broker y manages
subscriptions on behalf of source z, who acts as a
publisher that sends notifications to broker y. This design
pattern is the focus of Brokered Notification architecture
of WS-Notification (Figure 10).
The main differences between these two designs are 1) the
first architecture does not maintain any subscription
whereas the second one does; 2) the first architecture
allows y to subscribe to z without z registering on y first
whereas the second design requires such registration.

IEEE International Conference on Web Services (ICWS'06)

0-7695-2669-1/06 $20.00 © 2006

sink x broker y source z
to:t, n:x to:z, n:x
subscribe subscribe
to:x to:x
notification notification
Figure 9: Case –k-d with no message translation
sink x broker y source z
to:t, n:x
subscribe
to:x
to:t
notification notification
Figure 10: Case –k-d with subscription management
8. Implementation
A prototype of SOAP event broker has been implemented
that supports dynamic event model and the design patterns
discussed with WS-Addressing and WS-Eventing with
both “push” and “pull” event delivery modes. The main
technique used in the prototype is a Chain of
Responsibility design pattern consisting of Event
Producer, Message Translator, Subscription Manager and
Event Subscriber components that can be configured to
perform various message routing discussed in this paper.
The initial tests show that the performance of the
prototype on two-hop SOAP routing is satisfactory.
9. Summary
In this paper, we addressed some important issues in
manage event subscription and notification for web
services. We proposed a conceptual event model that can
represent dynamic resources and reuse information in the
WSDL file. In addition, a set-theoretic subscription model
was introduced. It is used to characterize and compare
various web service event subscription models and to
define the accuracy of event subscriptions. We analyzed
various broker architectures for web service event
processing following the web service interaction
specifications of WS-Addressing, WS-Eventing and WS-
Notification. We show that various broker architectures
IEEE International Conference on Web Services (ICWS'06)
0-7695-2669-1/06 $20.00 © 2006
can be stateless (except transaction state) with message
translations using Theseusian technique. We also show
that these proposed architectures are feasible in a research
prototype implementation. Future work is on going to
further develop the web service interaction conceptual
modeling framework and refine our broker
implementation.
10. Acknowledgement
The authors would like to thank anonymous reviewers for
their valuable comments and suggestions.
11. References
[1] W. Chou, et al., “Web Service Enablement of
Communications Services”, Proc. of ICWS’05, page
393-400, 2005
[2] L. Li et al., “Two-way Web Service Interaction from
Interface Design to Interface Verification”, Proc. of
ICWS’05, page 525-532, 2005
[3] Web Service Addressing (WS-Addressing 1.0 Core),
17 August, 2005, http://www.w3.org/TR/2005/CR-
ws-addr-core-20050817/
[4] Web Service Eventing (WS-Eventing), August, 2004,
http://msdn.microsoft.com/webservices/default.aspx?p
ull=/library/en-us/dnglobspec/html/ws-eventing.asp
[5] Web Service Notification (WS-Notification), OASIS
TC member public review, December 2005,
http://www.oasisopen.org/committees/tc_home.php?
wg_abbrev=wsn.
[6] A. Barros et al., “Service Interaction Patterns:
Towards a Reference Framework for Service-Based
Business Process Interconnection”, Proceedings of
BPM 2005, September 2005
[7] ECMA-348: Web Services Description Language
(WSDL) for CSTA Phase III, 2nd edition (June 2004).
http://www.ecma-
international.org/publications/standards/Ecma-348.htm
[8] SIP: Session Initiation Protocol,
http://www.ietf.org/rfc/rfc3261.txt?number=3261
[9] G. Salton. The SMART retrieval system. Prentice-Hall,
Englewood Cliffs, NJ, 1971
[10] G. Hohpe and B. Woolf. Enterprise Integration
Patterns: Designing, Building, and Deploying
Messaging Solutions. Addison-Wesley, 2003
[11] David C. Luckham and Brian Frasca. “Complex
Event Processing in Distributed System”, Stanford
University Technical Report CSL-TR-98-754, March
1998