REASC: a pattern for constructing Composite Applications

The Web, as an  ubiquitous distributed computing platform, has changed dramatically the way we  build information systems evolving from monolithic applications to an open model  that enables real-time and federated information access, unifying the user  experience across business processes. The industry has coined a new term for  this latest evolution: Connected Systems. Unlike Distributed Systems,they are not just about distributing work load or ensuring fail-over, but  rather about leveraging connectivity to enable specialized software agents to  perform units of work cooperatively and opportunistically by exposing and  consuming each other’s services to fulfill a common goal.

To reach their  fullest benefits, Connected Systems require a new application model, a  Service Oriented Composite Application model, that relies exclusively on the  consumption and composition of autonomous services. SAP has been both a though  leader and a market leader with its Composite Application Framework, and more  recently, with the Service Component Architecture specification, co-published  with BEA, IBM and Oracle.

The goal of this  post is to introduce a pattern, the REASC pattern, to help you reason about and  design effectively Service Oriented Composite Applications. REASC stands for  Resource, Event, Activity, Service and Coordinator.

     
•      

  A resource is       a piece of information identifiable by a URI. It is under the control of a       single service, but can share representations with other services. A       resource has an identity, some content, one or more states, some policies       (such as a privacy or replication policy). It addition, it might keep track       of services that requested a resource representation based on their       replication policies. A resource representation may be as simple as its URI.      

     

•      

  A service       represents one service implemented by a software agent. Services follow       principles of autonomy and interact with other services, as peer, via the       exchange of messages, synchronously or asynchronously. Messages may contain       requests for resource representations and resource representations, as well       as events which may also contain resource representations. One major       difference between a service and an object for instance is the       conversational aspect supported by services. In other words, an object is       described by a class. Object technologies have the greatest difficulty to       deal with concurrency problems, and in general OO run-time are not equipped       to support multiple conversations between objects. On the contrary,       services, may have service types, as specified by the SCA specification, but       in addition and most often, a service implementation is capable of       supporting multiple simultaneous conversations as part of different units of       work.

     

•      

  Events       represents the occurrence of a particular state or content within a       resource. Events are issued by services upon state and/or content changes.

       

     

•      

  Activity       represent assemblies of services and coordinators (in the SCA sense) geared       towards the performance of specific type of unit of work. An activity may       expose a service interface and interact with other services and coordinators       as part of a broader activity. 

     

•      

  A coordinator       ensure supporting (technical) services necessary to the performance of       various types of units of work. Coordinators can provide services such as:       transaction management, transformation, message routing, publish/subscribe…      

Figure  1 Pattern Resource Event Activity Service  Coordinator (REASC)

In this model, user interactions are modeled  as services, i.e. a software agent acts as a user proxy, which provide services  on behalf of users.

We argue that all Composite Applications can  be decomposed in REASC elements.