Combining Service-Oriented and Event-Driven

Combining Service-Oriented and Event-Driven 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 conquer the crown of the standard paradigm for the implementation of complex 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 describe how this marriage could be leveraged in order to design new dependable 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 platformindependent application integration. SOA allows enterprises to unify business processes by decomposing large applications into services. Services are well defined and self-contained software modules, which expose a predefined interface; they provide a business functionality and are independent of the state or context 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, enterprises 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 challenges 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)).

2

Giorgia Lodi, Leonardo Querzoni, Roberto Beraldi, and Roberto Baldoni

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 appropriately 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, analyze, and respond. The sensing building block gathers data from within and outside the enterprise. Data is then analyzed in order to determine whether appropriate 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 availability, 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 identified 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 infrastructures, 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 unreliable interactions among heterogeneous players. This paper is structured as follows. Sections 2 and 3 discuss the level of dependability 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 application 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.

Title Suppressed Due to Excessive Length

2

3

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 services; the protocols are extensions of the Simple Object Access Protocol (SOAP) and independent of the underlying transport layer. In order to guarantee reliability 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 supporting 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 default asynchronous. WS-Coordination provides only context management: WSTransaction 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 support 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 multicast 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

4

Giorgia Lodi, Leonardo Querzoni, Roberto Beraldi, and Roberto Baldoni

group communication properties (e.g., total order, uniform reliable multicast, strong virtual synchrony). The WS-Security specifications [22] define how to extend the SOAP protocol 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 token 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 Mechanism [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 concerning services dependability (i.e., service availability, service reliability, and service response time) and disseminates this information among services customers dynamically. To summarize the above discussion, Table 1 shows how the research works we have analyzed can meet dependability requirements. In this Table, “+” represents an advantage of the investigated system. Associated with “+” we have reported the technique being used to achieve the specific dependability requirement. 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 publishers) 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-

Title Suppressed Due to Excessive Length

Reliability

WS Reliability

WS Trans- WS WS action Replication Security

WS FTM

UDDI Extensions

+ Msg Ack

+ Data consistency

+ Group comms.

+ Replication

+ UDDI metadata

Coordinator failures

+ Active replication

+ Tiered voting system

+ UDDI metadata

5

+ Msg QoS Availability

Security and Trust

Timeliness

Scalability

+ Digital signatures + XML encryption + Security tokens Coordinator failures - Single coordinator

+ Multiple replicas

- Voting

- 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 respectively, and notifying subscribers about events that satisfy the issued subscriptions. 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].

6

Giorgia Lodi, Leonardo Querzoni, Roberto Beraldi, and Roberto Baldoni

Java Message Service (JMS) [20] is a standard promoted by Sun Microsystems to define a Java API for the implementation of message-oriented middleware. The compliance to the specification allows JMS to guarantee portability 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 applications: 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 duplicate 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 commercial 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 enriches the set of features defined in JMS with reliability, availability, scalability, and security aspects. From the point of view of reliability, Gryphon allows administrators 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 interconnected through an overlay network. A peer-to-peer routing layer in Hermes maintains the dynamic overlay broker network for event dissemination. Such

Title Suppressed Due to Excessive Length

7

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 brokers to recover to a consistent system state after a failure occurs. In 2005, TIBCO [29] has released a new technology called TIBCO BusinessEvent that can help to detect threats and business opportunities in a real-time fashion. The BusinessEvents product uses a sophisticated event-processing engine 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

Reliability

JMS

+ Reliable data + Msg distribution persistence

Gryphon

Hermes

TIBCO BusinessEvents

+ Link clustering

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

+ Multiple agents

+ Broker clustering + SSL authentication + ACLs + Msg encryption

+ Overlay network

+ Durable subscriptions Availability Security and Trust

Timeliness

Scalability

+ Configurable + Msg priority QoS requirements + Topic + Msg aggregation expiration + Content filtering +Federated architectures

+ Real time notifications + Broker load balancing + Content filtering

+ Overlay network

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

8

Giorgia Lodi, Leonardo Querzoni, Roberto Beraldi, and Roberto Baldoni

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 investigated 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 scenarios, 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 interacting 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 enable 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 interactions 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 exchanged among different application processes. An ESB can apply dynamic routing (also content-based) and dispatch of requests to multiple destinations. 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 services;

Title Suppressed Due to Excessive Length

9

– discovery service: the discovery service included in ESBs let application processes to discover appropriate services to which interact; – mediation: the mediation service is fundamental for scopes of business integration. In fact, such a service is responsible for (i) transforming one communication 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 addition to transformations, a mediation service is in charge of dealing with both security issues that are crucial in inter-organization interactions and, in general, 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 infrastructures (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 communications that span multiple administrative boundaries and involve heterogeneous 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 mechanisms can be triggered in a timely fashion.

10

Giorgia Lodi, Leonardo Querzoni, Roberto Beraldi, and Roberto Baldoni

Fig. 1. Financial application scenario using ESB

Specifically, requirements to be met include sharing information between critical infrastructures (e.g., telco operators, power grids) and financial operators about the status of the infrastructures the operators use, early detection of failures 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 possible security attacks. To this end, SOA and EDA approaches can be used in conjunction in order 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 actors using the ESB, which might hide to the participants all the integration, interoperability, and reliability communication aspects. The ESB’s event service 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.

Title Suppressed Due to Excessive Length

6

11

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 security/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 information 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).

12

Giorgia Lodi, Leonardo Querzoni, Roberto Beraldi, and Roberto Baldoni

– 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 overcoming 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 research 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 interadministrative 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 performance 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 Approaches. 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. Baldoni 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 Society.

Title Suppressed Due to Excessive Length

13

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 dependable 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 EventDriven 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 Boundaries. 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.