Giorgia Lodi, Leonardo Querzoni, Roberto Beraldi, and Roberto Baldoni Universit` a di Roma “La Sapienza”, Dipartimento di Informatica e Sistemistica

Architectures for Designing Dependable Systems ^?

Giorgia Lodi, Leonardo Querzoni, Roberto Beraldi, and Roberto Baldoni Universit` a di Roma “La Sapienza”, Dipartimento di Informatica e Sistemistica

Via Ariosto 25, 00185, Rome, Italy

{lodi,querzoni,beraldi,baldoni}@dis.uniroma1.it

Abstract. Up to now Service Oriented Architectures and Event Driven Architectures have been considered as competing parties striving to con- quer the crown of the standard paradigm for the implementation of com- plex distributed applications. Todays we are witnesses of large efforts to merge both paradigms and give birth to a new generation of middleware platforms that will inherit the best of both worlds. In this paper we de- scribe how this marriage could be leveraged in order to design new de- pendable software systems.

Key words: Service Oriented Architectures, Dependability, Event Driven Architectures, Enterprise Service Bus

1 Introduction

As of today, Service Oriented Architecture (SOA) is a well-known approach, largely used by enterprises in order to enable standard-based and platform- independent application integration. SOA allows enterprises to unify business processes by decomposing large applications into services. Services are well de- fined and self-contained software modules, which expose a predefined interface;

they provide a business functionality and are independent of the state or con- text of other services. Services communicate with each other by means of a synchronous request-and-reply communication pattern, thus enabling a tightly coupling among application components.

However, in order to be truly competitive in a global market scenario, enter- prises are becoming more adaptive and flexible: they do not tend to predict the future; rather, they are currently moving toward so-called on-demand business, by looking for external markets with the aim of identifying new business chal- lenges and changing customer needs as they happen. In this context, the tightly coupling nature of SOA communications may limit the enterprise ability to be effectively adaptive and flexible [30], and a more loosely coupled communication approach is thus necessary.

?

This research has been partly funded by the EU project CoMiFin (Communication

Middleware for Monitoring Financial Critical Infrastructures (IST-225407)).

In an on-demand business, “sense-and-respond” capabilities are required as they can contribute to augment enterprise situation-awareness (i.e., augment the perceived knowledge of the global business scenario state), and respond ap- propriately to the changes that may occur in the environment. Event-Driven Architectures (EDAs) can be properly used in this case in order to enable those capabilities and react to unpredictable scenarios such as threats, new business opportunities, and any other kinds of situations that require timely responses.

An EDA provides a loosely coupling communication pattern among application components and is constructed out of three principal building blocks: sense, an- alyze, and respond. The sensing building block gathers data from within and outside the enterprise. Data is then analyzed in order to determine whether ap- propriate actions are to be timely undertaken (responding building block) in response to what has been sensed [5].

Key challenges in the provision of these distributed systems concern the need to both provide them with self-configuration and adaptivity functionalities and guarantee that they can dependably perform their functions. Dependability is a well-known concept that encompasses such non functional attributes as availabil- ity, reliability, safety, integrity, maintainability, and security [17]. In the context of this paper, with the term dependability we refer to a set of non functional application requirements that shall be properly met in order for mission critical applications to effectively carry out their functions. Specifically, we have iden- tified the following dependability requirements of interest, used throughout the paper; namely, reliability, availability, security, timeliness, and scalability.

The assessment of these requirements in both SOA and EDA contexts allows us to state and show that, in order to support modern critical business infras- tructures, the level of dependability currently offered by the SOA approach is not sufficient and has to be further enhanced by the level of dependability that an EDA approach can provide. This may lead to the birth of a new generation of middleware platforms whose principal benefit is to combine the two SOA and EDA approaches with the aim of constructing complex dependable and secure distributed systems. This convergence is today embodied by Enterprise Service Buses (ESBs). Even if ESBs are a great step ahead in the direction of middleware platforms for dependable large-scale applications, they still lack the adaptivity and self configuration capabilities that are fundamental to operate in complex scenarios spanning multiple administrative domains and characterized by unre- liable interactions among heterogeneous players.

This paper is structured as follows. Sections 2 and 3 discuss the level of de-

pendability that can be currently obtained by adopting SOA and EDA-based

solutions, respectively. Section 4 shows how a possible convergence between

service-oriented and event-driven architectures can be beneficial in the design

of dependable and secure middleware systems. Section 5 introduces an applica-

tion scenario and shows how the SOA and EDA convergence can be exploited in

that case, while outlining the limitations of current solutions. Finally, section 6

provides some future perspective in this research area.

2 Dependability in SOA

SOA is an architectural approach that allows applications to be decomposed in software functionalities presented in the form of services discoverable on the network. Web Services is the implementation technology of the SOA philosophy design. There is a large body of research devoted to dependability requirements in SOA and, more specifically, in Web Services. The Web Service community has provided a number of specifications that are related to the dependability that Web Service technologies can support. In particular, the specifications deal with reliable messaging, transaction management, replication, and security.

The WS-ReliableMessaging [11] and WS Reliability [7] are specifications whose purpose is to address reliability messaging requirements, which can be crucial in Web services-based B2B applications. The specifications are used to define the reliable messaging protocols for the communications among Web ser- vices; the protocols are extensions of the Simple Object Access Protocol (SOAP) and independent of the underlying transport layer. In order to guarantee relia- bility requirements, the specifications define the capabilities that Web Services should provide to the application level: message acknowledgements and quality of service levels for message delivery.

The WS-Transaction specification [10] defines the set of protocols for sup- porting short and long running transactions for the Web Service technology.

WS-Transaction differentiates from traditional transaction protocols as it does not include any synchronous request/response model: WS-Transaction is based on the WS-Coordination [9] protocol whose communications patterns are by de- fault asynchronous. WS-Coordination provides only context management: WS- Transaction uses the context management framework of WS-Coordination to create a transaction context and extend it with a number of additional services.

These services include atomic distributed transactions, based on the Two Phase Commit (2PC) protocol, and business agreement protocols that are used to sup- port long running transactions that span multiple enterprises. Note, however, that the 2PC protocol may suffer from availability and performance issues if the coordinator fails, thus preventing Web Service-based applications to meet timeliness and availability requirements.

In order to overcome these limitations of WS-Transaction, authors in [28]

propose a WS-Replication framework for WAN replication of Web Services. The framework embodies a group communication protocol named WS-Multicast, which enables communications among replicas of Web Services using SOAP and without requiring any change to the underlying Web Services protocols.

The WS-replication framework consists of two main component: the web service

replication and reliable multicast components. The multicast component takes

care of reliably multicasting in total order the web service invocations to all the

replicas, using the transport web service protocol. Upon reception of the mul-

ticast messages WS-Multicast enforces the delivery properties of the messages

(i.e., ordering and reliability properties). In particular, WS-Multicast discovers

members of a group, performs failure detection, sends unicast and multicast

messages to the members of a group, and performs other tasks in order to fulfill

group communication properties (e.g., total order, uniform reliable multicast, strong virtual synchrony).

The WS-Security specifications [22] define how to extend the SOAP proto- col with a set of end-to-end security mechanisms in order to provide integrity, confidentiality, and authentication. Integrity is guaranteed by attaching digital signatures within the context of the sender SOAP message; confidentiality is ensured by using XML encryption in order to encrypt all or part of the SOAP messages, and finally, authentication is provided by embedding a security to- ken in the message. WS-Security has been further extended with Web Services Trust (WS-Trust) [21], a specification that defines mechanisms for managing security tokens (e.g., renewal, verification, revocations) and trust relationships using security tokens.

In addition to these specifications, there exist other researches centered on dependability in Web Services. WS-FTM is a Web Service Fault-Tolerant Mech- anism [18] that implements the n-Version model. The n-Version model is a design pattern used to guarantee software fault-tolerance. The basic mechanism enables replication in order to cope with physical faults. For this purpose, the n-Version model uses n independent replicas of a software component that run in parallel.

The replicas have the same input data set and produce final results subject to a voting mechanism. WS-FTM leverages a majority voting scheme that allows the system to identify and eliminate individual failures in a component, thus increasing the integrity of the final result.

In [13] the authors propose to extend the UDDI Business Registry of the Web Service technology with dependability metadata. Specifically, the UDDI registry becomes an impartial judge that obtains trustworthy information con- cerning services dependability (i.e., service availability, service reliability, and service response time) and disseminates this information among services cus- tomers dynamically.

To summarize the above discussion, Table 1 shows how the research works we have analyzed can meet dependability requirements. In this Table, “+” rep- resents an advantage of the investigated system. Associated with “+” we have reported the technique being used to achieve the specific dependability require- ment. In contrast, “-” represents a drawback of the relative system. Finally, empty cells indicate that the specific requirement is not mentioned or addressed by the analyzed research work.

3 Dependability in EDA

Event-based communications have been introduced in middleware platforms to

provide an intuitive reactive communication paradigm that can be exploited to

implement asynchronous interactions. An event-based interaction assumes that

the interacting parties play the role of either event producers (often called pub-

lishers) or event consumers (i.e. subscribers). Consumers can define their interest

in a subset of all the produced events by issuing subscriptions that act as filters

on the stream of incoming events. A software component, the event notifica-

WS Reliability

WS Trans- action

WS Replication

WS Security

WS FTM UDDI

Extensions Reliability + Msg Ack + Data

consistency

+ Group comms.

+ Replication

+ UDDI metadata + Msg QoS

Availability -

Coordinator failures

+ Active replication

+ Tiered voting system

+ UDDI metadata

Security and Trust

+ Digital signatures + XML encryption + Security tokens

Timeliness -

Coordinator failures

+ Multiple replicas

- Voting

Scalability - Single

coordinator

- Multicast on WAN

- Voting

Table 1. Summary of dependability attributes in SOA

tion service, fully decouples the interaction between producers and consumers by receiving subscriptions and events, issued by subscribers and publishers re- spectively, and notifying subscribers about events that satisfy the issued sub- scriptions. The two most popular standards for event-based communications in middleware platforms are the Data Distribution Service (DDS) and the Java Messaging Service (JMS).

The OMG’s Data Distribution Service for Real-time Systems (DDS) [2] is an API specification and interoperability wire-protocol that defines a data-centric publish-subscribe (pub/sub) interaction paradigm [6]. DDS is based on a fully decentralized architecture, which provides an extremely rich set of configurable QoS policies to be associated with topics. A publisher can declare the intent of generating data with an associated QoS and writing the data in a topic.

Then, it is responsible for disseminating data (in either a reliable or best-effort

fashion) in agreement with the declared QoS, that has to be compatible with

that defined by the topic. The DDS also provides a set of QoS policies in order

to control the timeliness properties of distributed data. Specifically, it defines

the maximum inter-arrival time for data and the maximum amount of time

that should elapse for distribution of data from publishers to subscribers. As for

security and privacy, to the best of our knowledge, these issues are not specifically

addressed by the DDS specification. However, the standard offers the basis for

security and privacy: it supports the concept of administrative domains that

allow the system to separate and confine the distribution of different data flows,

limiting the visibility of publishers, subscribers, events, and subscriptions within

a single domain. Finally, note that the above mentioned DDS properties can be

effectively applied only when the DDS is deployed in a strictly controlled setting

(i.e., in a managed environment); in a large scale, unreliable and unmanaged

context, the performance obtainable by the DDS may become unpredictable [3].

Java Message Service (JMS) [20] is a standard promoted by Sun Microsys- tems to define a Java API for the implementation of message-oriented middle- ware. The compliance to the specification allows JMS to guarantee portabil- ity for Java applications in exchanging messages through products of different vendors. A JMS implementation represents a general-purpose message oriented middleware (MOM) that acts as an intermediary between heterogeneous appli- cations: the applications can choose the communication mode that better suits their specific needs (JMS supports both pub/sub and point-to-point modes).

Dependability in JMS is related to message delivery reliability. An application can require every message to be received once and only once or choose a more permissive (and generally more efficient) policy, which permits to drop and du- plicate messages. JMS supports various degree of reliability through different basic and advanced mechanisms. Basic mechanisms include: message persistence through which a JMS application can specify that messages are persistent, i.e., a message will not be lost in the event of a provider failure, message priority levels through which an application can define urgent messages, and, finally, message expiration through which an application can set a message expiration time in order to prevent duplicated messages. The most advanced mechanism consists in the creation of durable subscriptions that allow subscribers that are idle to receive messages as soon as they come back on-line. Durable subscriptions thus implement reliable queues within the pub/sub paradigm. Other features common in MOM products, like load balancing, resource usage control, and timeliness of messages are not explicitly addressed in the JMS specification; rather, they are considered provider-specific.

Besides these standards, there exist a number of research works and commer- cial products that fall into the category of event-driven middleware systems (e.g., Gryphon[31], Hermes [27], SIENA [4], TIBCO [29], IBM Tivoli [14]). For the sake of brevity, in the following we have summarized a subset of these systems, only.

Gryphon [31] is a pub/sub system that implements the JMS API, and en- riches the set of features defined in JMS with reliability, availability, scalability, and security aspects. From the point of view of reliability, Gryphon allows ad- ministrators to cluster sets of event brokers in cells that then act as a unique reliable and highly available logical broker. Also message transmissions among cells is replicated through independent links in order to avoid message losses. The possibility to cluster a large number of brokers with the aim of balancing the load imposed by clients among the brokers, let the Gryphon architecture scale to huge loads. Finally, security is addressed in Gryphon by adopting well-known approaches and standard solutions like SSL authentication, role enforcement through ACLs, support to message encryption, and cryptographic integrity.

Hermes [27] is an event-based wide-area middleware system that follows a

type- and attribute-based publish/subscribe model. In Hermes, there exist two

types of components: event clients (either publishers or subscribers) and event

brokers that constitute the event notification service. Event brokers are inter-

connected through an overlay network. A peer-to-peer routing layer in Hermes

maintains the dynamic overlay broker network for event dissemination. Such

routing layer ensures the autonomic management of the overlay and a scalable event dissemination. In addition, the routing algorithms used in Hermes include built-in fault-tolerance features for reliability purposes, which enable event bro- kers to recover to a consistent system state after a failure occurs.

In 2005, TIBCO [29] has released a new technology called TIBCO Busines- sEvent that can help to detect threats and business opportunities in a real-time fashion. The BusinessEvents product uses a sophisticated event-processing en- gine that can leverage rules and monitoring technology, and correlate potential issues through event aggregation and analytics to determine notification and resolution action. Tibco BusinessEvent provides high flexibility through the use of multiple event channels, reliability and scalability via multiple agents, and a distributed persistence of event history using a high-performance data grid.

Table 2 summarizes our EDA dependability assessment. This Table can be read in the same way as Table 1.

DDS JMS Gryphon Hermes TIBCO

Business- Events Reliability + Reliable data

distribution

+ Msg persistence

+ Link clustering

+ Built-in fault-tolerance features in routing algorithms (recover to consistent system state)

+ Multiple agents

+ Durable subscriptions

Availability + Broker

clustering

+ Overlay network Security and

Trust

+ SSL authentication + ACLs + Msg encryption Timeliness + Configurable

QoS requirements

+ Msg priority + Real time

notifications

Scalability + Topic aggregation

+ Msg expiration

+ Broker load balancing

+ Overlay network + Content

filtering

+ Content filtering +Federated

architectures

Table 2. Summary of dependability attributes in EDA

4 SOA and EDA convergence

From the dependability analysis of the major standards and research works on

SOA technologies we can state that reliability aspects are widely investigated

and met by the proposed solutions; rather, scalability, timeliness, and security are still crucial requirements that are not fully satisfied by the analyzed systems, as reported in Table 1.

From this point of view, a more loosely coupled communication approach than that applied by the SOA paradigm is required. To this end, we have in- vestigated how EDA-based standards and architectures can cope with those requirements; from our analysis we can argue that EDA can successfully deal with timeliness, scalability, and reliability, as shown in Table 2.

Therefore, from a dependability standpoint, SOA and EDA can be viewed as complementary approaches: merging the two together may be beneficial in order to provide complex distributed applications (e.g., finance application sce- narios, business process management, RFID, manufactory, military application scenarios) with a complete dependable and flexible middleware system. SOA is required for interoperability purposes in order to enable communications between possibly heterogeneous computing environments deployed by different interact- ing organizations; EDA is required for effectively enabling timeliness, real-time, and scalable communications.

In recent literature, issues concerning the merge of SOA and EDA paradigms are gaining particular attention. When speaking of SOA and EDA convergence, Enterprise Service Bus (EBS) middleware systems can be considered the most convenient solution to be used in order to realize this convergence. An ESB is a middleware that acts as an intermediate (or mediation) layer in order to en- able the communication and integration among large-scale and heterogeneous application processes. An ESB provides all the capabilities of both SOA and EDA approaches as it supports synchronous as well as asynchronous interac- tions among one or many stakeholders. It is not a standard nor a specification;

rather, there exist a large number of open source and commercial ESBs that are developed by many vendors and customized according to their needs.

Despite the wide availability of a variety of ESB implementations (e.g., Open ESB [26], Apache ServiceMix [12], JBoss ESB [16], IBM WebSphere ESB [15], Celtix by IONA and Objectweb [25]), it is a common practice to provide such middleware with the following set of services [19]:

– transport : the transport service guarantees the delivery of messages ex- changed among different application processes. An ESB can apply dynamic routing (also content-based) and dispatch of requests to multiple destina- tions. This allows ESB to enable load balancing techniques or fault-tolerance mechanisms;

– event : the event service allows ESB to process event, possibly analyzing and controlling the complex series of interrelated events. To this end, most ESB products provide implementations of WS-* specifications devoted to event management such as WS-Notification [24] and WS-Eventing [8];

– orchestration: the orchestration service is based on the use of BPEL [23]

technologies and allows ESB to orchestrate a number of interconnected ser-

vices;

– discovery service: the discovery service included in ESBs let application pro- cesses to discover appropriate services to which interact;

– mediation: the mediation service is fundamental for scopes of business inte- gration. In fact, such a service is responsible for (i) transforming one commu- nication protocol to another in order to make possible the communication between heterogeneous environments, (ii) transforming the content of any message, also enriching messages with further information so as any data that is in transit can be understandable by any application process. In addi- tion to transformations, a mediation service is in charge of dealing with both security issues that are crucial in inter-organization interactions and, in gen- eral, QoS requirements (e.g., quality measurement, caching, failure detection and recovery).

The main limitation of current ESBs deal with their applicability only in strictly controlled settings, where administrators can correctly configure, deploy and, finally, fine tune the middleware in order to obtain the best performance and the maximum dependability level. As soon as interactions must cross the boundaries of a controlled environment (maybe spanning multiple independent administrative domains), the capabilities of these platforms may unpredictably degrade and the overall service levels are no more easily controllable.

5 Application to Financial Critical Infrastructures

To further motivate our assessment, we present an application example that has gained particular attention over the last years and represents today a growing field of research: protection of critical financial infrastructures. The interest in this financial domain scenario is also proven by the existence of EC funded projects such as CoMiFin (Communication Middleware for Monitoring Financial CI) [1], which investigate this area.

The financial domain can be considered as a global unmanaged ecosystem, consisting of a set of numerous interconnected financial domains (e.g., banking, insurance, clearing house) and of interdependences with other critical infras- tructures (i.e., telecommunication and electricity supply). These domains are managed independently and may interact over either the Internet network or WAN-based dedicated channels. Their interactions originate cross-domain com- munications that span multiple administrative boundaries and involve heteroge- neous infrastructures and resources. In particular, resources can join and leave the entire ecosystem continually so that a truly high dynamic system is outlined in this context.

In order to carry out dependably financial transactions, it is essential to meet

dependability and timeliness non functional requirements as well as protect the

ecosystem from faults and malicious attacks. Each participant to the financial

ecosystem needs to raise its own levels of awareness of the global scenario state to

itself and its fellow players so that adequate local dependability-enabled mech-

anisms can be triggered in a timely fashion.

Fig. 1. Financial application scenario using ESB

Specifically, requirements to be met include sharing information between crit- ical infrastructures (e.g., telco operators, power grids) and financial operators about the status of the infrastructures the operators use, early detection of fail- ures in any financial player and notification of these events to anyone interested in them, and dissemination of security alerts in order to assess the state of pos- sible security attacks.

To this end, SOA and EDA approaches can be used in conjunction in or- der to address the above required functionalities. Figure 1 depicts a possible financial ecosystem in which ESB technology is deployed. In our example, ESB middleware is used to apply the SOA and EDA convergence and thus to facilitate the interworking among different financial organizations that are interested in receiving, for example, early virus warning notifications, for scopes of security.

As illustrated in Figure 1, two telecommunication companies provide financial applications with early warnings on viruses spreading. The services are shown in the form of legacy applications, which raise events concerning predictions of possible security attacks. The raised events can be sent to the interested ac- tors using the ESB, which might hide to the participants all the integration, interoperability, and reliability communication aspects. The ESB’s event ser- vice can elaborate the events it receives from legacy applications owned by the telecommunication actors, and send dependably the notifications to all financial participants (this function is carried out by using the services an ESB includes;

these services are partially drawn in Figure 1). Each financial actor can then

collect the received notifications so as to trigger local protection mechanisms in

a timely fashion. Although the ESB middleware technology can be an attractive

solution in this case, to the best of our knowledge, its current implementations

seem to be rather static and complex to configure. As we stated in the previous

section ESBs currently lack the ability to properly adapt to the heterogeneity

of the outlined scenario, thus preventing their effective usage in a large scale

dynamic unmanaged environment.

6 Future Perspectives

The assessment carried out in this paper has allowed us to derive important design principles for such forthcoming settings as those previously described.

To begin with, the SOA and EDA convergence is the convenient direction to follow in the development of new dependable middleware infrastructures for complex application scenarios (e.g., homeland security, supply chain, financial transactions) as these approaches, when combined together, can deliver mutually complementary dependability characteristics. In this sense, ESB technology may be deployed in order to realize this convergence; however, the lack of a standard and thus the existence of a plethora of vendor-specific ESB implementations, be they commercial or open source, leave the organizations in the difficult task of selecting the ESB that best suits specific deployment configurations. This may negatively impact on the flexibility provided by these solutions and required in an on demand business context.

Moreover, current ESBs are complex products that require strong efforts for configuration, deployment and tuning. This characteristic struck evidently with the large scale, the heterogeneity and strong dynamics that characterize the envisaged scenarios where the middleware must span multiple independently managed administrative domains. From this point of view current ESBs are rather static solutions lacking the flexibility obtainable via self-configuration, self-optimization, self-adaptation and self-protection functionalities. It is thus desirable that in the future a number of design directions will to be scoped out by ESBs with the aim of reaching new levels of flexibility also in complex application contexts.

These directions can be summarized as follows.

– Reliability: in the scenario previously outlined several autonomous networks interact and exchange messages through WAN-based links (possibly based on Internet) that are inherently unreliable and whose characteristics can vary over time; techniques based on self-healing and the maintenance of multiple independent paths could be employed to improve the overall reliability of these systems;

– Availability: in large scale unmanaged systems the number of services/users may be dramatically high, and components of those systems may arrive and depart continuously; advanced mechanisms based on the use of P2P overlays can be employed in this case so as to cope with frequent churn in the systems, and consequently guarantee availability of the system components;

– Security and Trust : in an environment with different administrative domains

that interact with each other, security and trust issues have to be carefully

dealt with. In this case, a possible direction can be that to integrate secu-

rity/trust mechanisms at both domain and information levels. At domain

level, proper role-based access control policies can be used to regulate the

access of the domain to the information exchanged in the ecosystem; at in-

formation level, trust-enhanced information and events can be exchanged in

the ecosystem (for this purpose, certificates might be piggybacked on the

information itself in order to attest the “value” of its content).

– Timeliness: the strong heterogeneity of components, devices and network resources constituting large-scale complex infrastructures plays against the enforcing of timeliness constraints for the distribution of events; continuous performance monitoring and self-adaptation techniques can help in over- coming current limitations from this point of view making it possible to implement timely services also in large scale settings;

– Scalability: scalability in large scale unmanaged environments is a hard re- search challenge. Yet again, one possible direction to cope with it can be to investigate the use of P2P overlays along with nature-inspired, probabilistic gossip-based dissemination protocols, and dynamic distributed membership protocols: the joint use of these techniques may result beneficial in terms of scalability, as they can enable members of the system to have partial views of overall membership.

References

1. Communication Middleware for Financial Critical Infrastructure. http://www.

comifin.eu, 2008.

2. OMG Data Distribution Portal, 2008. http://portals.omg.org/dds.

3. R. Baldoni, L. Querzoni, and S. Scipioni. Event-based data dissemination on inter- administrative domains: Is it viable? In FTDCS ’08: Proceedings of the 2008 12th IEEE International Workshop on Future Trends of Distributed Computing Systems, pages 44–50, Washington, DC, USA, 2008. IEEE Computer Society.

4. Mauro Caporuscio, Antinisca Di Marco, and Paola Inverardi. Run-time perfor- mance management of the siena publish/subscribe middleware. In WOSP ’05:

Proceedings of the 5th international workshop on Software and performance, pages 65–74, New York, NY, USA, 2005. ACM.

5. Mani K. Chandy. Event-Driven Applications: Costs, Benefits and Design Ap- proaches. Presented at the Gartner Application Integration and Web Services Summit, http://www.infospheres.caltech.edu/node/38, June 2006.

6. Angelo Corsaro, Leonardo Querzoni, Sirio Scipioni, Sara Tucci Piergiovanni, and Antonino Virgillito. Quality of service in publish/subscribe middleware. In R. Bal- doni and G. Cortese, editors, Global Data Management. IOS Press, 2006.

7. Collean Evans et al. Web Services Reliability (WS-Reliability) v. 1.0, 2003.

8. Don Box et al. Web Services Eventing (WS-Eventing). http://www.w3.org/

Submission/WS-Eventing/, 15 March 2006.

9. L. F. Cabrera et al. Web Services coordination. http://www.ibm.com/

developerworks/library/wscoor/, 2002.

10. L. F. Cabrera et al. Web Services transaction. http://www.ibm.com/

developerworks//library/wstranspec/, 2002.

11. R. Bilorusets et al. Web Services reliable messaging. http://www-128.ibm.com/

developerworks/webserices/library/ws-rm/, 2005.

12. Apache Software Foundation. ServiceMix. http://servicemix.apache.org/home.

html, 2008.

13. Anatoliy Gorbenko, Alexander Romanovsky, and Vyacheslav Kharchenko. How to

Enhance UDDI with Dependability Capabilities. In COMPSAC ’08: Proceedings

of the 2008 32nd Annual IEEE International Computer Software and Applications

Conference, pages 1023–1028, Washington, DC, USA, 2008. IEEE Computer Soci-

ety.

14. IBM. Tivoli Software. http://www-01.ibm.com/software/tivoli/, 2008.

15. IBM. WebSphere Enterprise Service Bus. http://www-01.ibm.com/software/

integration/wsesb/, 2008.

16. JBoss. JBossESB. http://www.jboss.org/community/docs/DOC-10326, 2008.

17. Jean-Claude Laprie and Brian Randell. Basic concepts and taxonomy of depend- able and secure computing. IEEE Trans. Dependable Secur. Comput., 1(1):11–33, 2004. Fellow-Algirdas Avizienis and Senior Member-Carl Landwehr.

18. Nik Looker, Malcolm Munro, and Jie Xu. Increasing web service dependability through consensus voting. In COMPSAC ’05: Proceedings of the 29th Annual International Computer Software and Applications Conference (COMPSAC’05) Volume 2, pages 66–69, Washington, DC, USA, 2005. IEEE Computer Society.

19. Jean-Louis Mar´ echaux. Combining Service-Oriented Architecture and Event- Driven Architecture using an Enterprise Service Bus. http://www.ibm.com/

developerworks/library/ws-soa-eda-esb/, 2006.

20. Sun Microsystem. Java Message Service (JMS). http://java.sun.com/products/

jms/, 2008.

21. Anthony Nadalin, Marc Goodner, Martin Gudgin, Abbie Barbir, and Hans Granqvist. Web-Trust 1.3. http://docs.oasis-open.org/ws-sx/ws-trust/

200512, 2007.

22. Anthony Nadalin, Chris Kaler, Ronald Monzillo, and Philipp H. Baker. Web Services Security: SOAP Message Security 1.1. http://www.oasis-open.org/

committees/wss/, 2006.

23. OASIS. OASIS Web Services Business Process Execution Language. http://www.

oasis-open.org/committees/tc\_home.php?wg\_abbrev=wsbpel, 2008.

24. OASIS. OASIS Web Services Notification. http://www.oasis-open.org/

committees/tc\_home.php?wg\_abbrev=wsn, 2008.

25. ObjectWeb. Celtix: The Open Source Java Enterprise Service Bus. http:

//celtix.objectweb.org, 2008.

26. OpenESB. The Open Source ESB for SOA & Integration. https://open-esb.

dev.java.net, 2008.

27. Peter R. Pietzuch and Jean Bacon. Hermes: A distributed event-based middleware architecture. In ICDCSW ’02: Proceedings of the 22nd International Conference on Distributed Computing Systems, pages 611–618, Washington, DC, USA, 2002.

IEEE Computer Society.

28. Jorge Salas, Francisco Perez-Sorrosal, no-Mart´ınez Marta Pati and Ricardo Jim´ enez-Peris. WS-replication: a framework for highly available web services. In WWW ’06: Proceedings of the 15th international conference on World Wide Web, pages 357–366, New York, NY, USA, 2006. ACM.

29. TIBCO. Introducing TIBCO BusinessEvents 3.0. http://www.tibco.com/

software/complex\_event\_processing/businessevents/default.jsp, 2008.

30. Jack van Hoof. SOA and EDA: Using Events to Bridge Decoupled Service Bound- aries. The SOA Magazine, (4), 2007.

31. Yuanyuan Zhao, Daniel Sturman, and Sumeer Bhola. Subscription propagation in highly-available publish/subscribe middleware. In Middleware ’04: Proceedings of the 5th ACM/IFIP/USENIX international conference on Middleware, pages 274–

293, New York, NY, USA, 2004. Springer-Verlag New York, Inc.