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.