An value-centric event driven model and architecture: A case study of adaptive complement of SOA for distributed care service delivery

Abstract

The Web is now evolving into a medium for providing a wide array of e-commerce and other information based services that are solely based on distributed software interactions for collaborative work. Service-oriented and event-driven architectures (SOA and EDA) are the complementary paradigms for building such distributed information systems based on software interactions as their characteristics of modularity, loose-couplings, and flexibility. However, given the rapid change of the web environment (including the dynamic behavior of the users), these paradigms are not yet able to empower a built system adapting its behavior according to the changes in its environment or in parts of the system itself. This paper presents an architecture of adaptive integration of EDA and SOA based on the novel concept of value-centric processing and communication of events grounded on value theory. This architecture has also been used on a case study of distributed care service delivery. In the architecture, value models are devised to represent events consumed and develop a value-centric mechanism for this adaptive integration. We have also implemented the system and simulated certain representative scenarios in order to justify the claimed values of this adaptive integration on the case study.

Introduction

The main goal of a distributed computing system is to connect users and resources in a transparent, open, and scalable way. Recently, there have been new paradigms of distributed system design unfolded such as the multiparty information system view (Levina, 2005). Among them, a new paradigm of service-orientation is currently emerging for distributed computing and e-business processing (Williams, Padmanabhan, & Blake, 2005). This new paradigm utilizes services (autonomous platform-independent computational elements that can be described, published, discovered and accessed over the Internet using standard protocols) as fundamental elements for developing distributed service systems. This way of reorganizing software applications into a set of interacting services is usually referred to as service-oriented architectures (SOA). Multiple service components can then be chained together through request/reply calls to create a larger composite application, for instance, a web-based education system in Canales, Peña, Peredo, Sossa, and Gutiérrez (2007).

On the other hand, an event-driven architecture (EDA) defines a methodology for designing and implementing applications and systems in which events transmit between loosely coupled service components. An event-driven system, in general, involves event consumers and event producers. Event consumers subscribe to an intermediary event manager, and event producers publish to this manager (Eugster, Felber, Guerraoui, & Kermarrec, 2003). When the event manager receives an event from a producer, the manager forwards the event to the consumer. If the consumer is unavailable, the manager can store the event and try to forward it later. This method of event transmission is referred to in message-based systems as store and forward. Building applications and systems based on event-driven architectures allows these applications and systems to be constructed in a manner that facilitates more responsiveness, since event-driven systems are more oriented to unpredictable and asynchronous environments.

The major difference between SOA and EDA is that in an SOA, all intermediate service components suspend their operation until the relevant request/reply call returns, while in an EDA architecture all service components continue to operate since their focus is on processing incoming messages and publishing outgoing messages; the EDA architecture is thus typically more efficient than the SOA architecture due to pipelined, concurrent processing of events by multiple software components chained together (as there is no waiting for blocked calls to return). Table 1 (Chau, 2004) manifests the detailed different features between SOA and EDA.

Accordingly, service-oriented and event-driven architectures are natural fits for distributed service systems since they share many of the same characteristics, such as modularity, loose-couplings, and flexibility. This is because EDA can trigger event consumers as events happen and loosely coupled services can then be quickly accessed and queried from those same consumers. For systems to be most responsive, they must be able to quickly determine the necessary actions when events are triggered. In other words, SOA interactions are typically synchronous in nature, while EDA is usually asynchronous; SOA is a passive architecture (because users need to actively make a request of services) and can take advantage of active event mechanism in order to enhance the entire performance of distributed systems (Fingar, 2005, Schulte, 2003, Schulte, 2004).

The benefits of combined SOA and EDA can be applicable to Business-to-Business (B2B) or Business-to-Customer (B2C) distributed applications. For instance, taking a supply chain example of the B2B model, the firms in a supply chain are often troubled by the bullwhip effect which may cause loss of revenues. In order to lower the influence of bullwhip effects, the firms’ systems must communicate with each other and enhance the transparency of information for appropriate actions (services invoked) in time. In this case, an event-driven architecture is a good approach to reach the end. In B2C model, a consumer can also benefit from individualized services and timely service combination. Examples are the users who reserve in-doors activities because the providers of weather forecast services actively provide to the users the events of bad weather information and the customers who change their flight schedules if the flight companies can actively provide events of cancelled flights to their customers.

Although EDA and SOA are natural fits to each other, existing methodologies (Krill, 2006, Niblett and Graham, 2005) of bridging EDA and SOA are the straightforward approach of combination. That is, the store-and-forward events are provided (e.g., through visual dashboards or enterprise service bus) via multiple channels (e.g., e-mail, SMS, phone, or fax) to event consumers that subsequently invoke loosely coupled services as required, or the events are statically mapped to certain actions (e.g., invoking designated service components). In order to reach a more responsive and customized combination of EDA and SOA, this study explores the opportunities of an architecture that can seamlessly bring out the benefits of both EDA and SOA so as to enable an effective, flexible and customized development of distributed service systems.

For the opportunities exploration of the new architecture, we examine the shortcomings of the present event-driven service systems:

• Lack of a mechanism of customized design from different users’ points of view: first, users emphasize different events due to their different needs which may vary as time goes by. Therefore, it is vital to provide a well-designed mechanism of event management in the present complex situation. Second, advanced event-mapped actions (e.g., service invocation) may be too complex to be applicable owing to occasions that events might not be independent. Third, it is not flexible enough for adopting static event-mapped actions (if there are new and even more appropriate actions of services).

• Lack of competence to filter events flexibly: for existing publish/subscribe models (Eugster et al., 2003), topic-based subscription is domain-dependent and only allows simple event descriptions that are consequently short of sufficient power to define precise events’ filtering rules. Content-based subscription, however, can provide more precise filtering rules, but easily makes filtering process more complex. Furthermore, this type of subscription is domain-dependent and thus the filtering rules cannot be applied to other domains. Similarly, complex events application (CEP) also provides domain-dependent event filtering functions. In short, the existing event filtering mechanisms needs to be advanced in order to be capable of identifying importance of events and engaging the filtering flexibly.

• Lack of competence to adapt events’ filtering rules: event subscribers’ preferences of events may change as time goes by. There exist no event-driven systems presently which can actively analyze users’ behavior patterns and adapt events’ filtering rules. That is, users are responsible of updating filtering rules in order to receive suitable events all by themselves.

• Lack of managerial mechanisms to automatically subscribe or cancel events: Current event-driven systems do not provide efficient and effective mechanisms to subscribe and cancel events. Once the amount of events accumulated extensively, it would burden the users with the management of events and thus reduce the users’ willingness to use the systems.

The aforementioned shortcomings, nevertheless, shed light on our design of a new event-driven architecture that features a responsive and customized mechanism of event management well bridging with the service-oriented architectures. Currently, this architecture is built on a case study of distributed electronic care service delivery. On filtering events, the architecture exerts value-centric models to evaluate the importance of events for a user. On adapting events’ filtering rules, the architecture employs an intelligent approach to learn the subscribed user’s behavior patterns from his/her historical event records so as to induce timely and customized events’ filtering rules. On an autonomous mechanism of subscribing and cancelling events, the architecture enables this autonomy based on the observed user’s behaviors of event adoption.

This paper is organized as follows. Section 2 describes our architecture from two levels of abstract (meta-architecture and architecture). Section 3 further details the behavioral views of the architecture. Section 4 then provides the simulation model and the performance analysis. Finally, conclusion remarks are provided in Section 5.