SOA architectures have matured well beyond simple request/response web services to provide a multi-protocol loosely coupled model for synchronous and asynchronous service invocation. However, even as services move to the cloud there is no architectural way to affect the behavior of services as they are used by potentially different consumers with different business contexts. In effect services remain closed and static providing only one set of response to one set of requests.

sense introduces a new concept of computing to extend SOA to the cloud – emotions. _emotions allow sense to enrich service requests (and responses) architecturally by introducing before and after service interrupts to which users can define and attach a rich set of evaluations, decisions and actions. Thus for a single service, sense can enrich the service depending on specific requirements of the business context for the specific call.  This allows the same service to respond to widely different consumer requirements using the single service implementation. An example might be assigning a specific priority or service level agreement (SLA) to the request before the call, or affecting the response with particular rendering for an iPhone while initiating a call to a micro-billing service to log the transaction. The same service, is enriched depending on the business context that needs to be filled.

sense emotions introduce an architectural component that can affect the status and overall behavior of any service, resource or asset managed by sense (including sense itself), with before and after triggers.

In the diagram above, a normal service request to the cloud would normally be satisfied by the service provider to which the request was addressed. In sense, emotions can be used to enrich the request and to route the service call to the service provider most able to satisfy the business SLA defined on the service at the lowest cost. Additionally for particular service requests (resource 2 in the diagram) other services may be triggered in parallel.

sense emotions introduce and architectural approach similar to _Aspect-oriented_ programming in code development. emotions ‘cut across’ the service requests/response model, guided by business SLAs, to provide an intercept  hook to any call before (or after) the call is made to enrich it with more processing. An emotioncan  act as a trigger and start calling other services available on the cloud orthogonally to the continuing execution of the service call or process.

emotions can enrich all sense components including services, feelings and business flows and enrichment can be synchronous or asynchronous. If enrichment is bound synchronously it can modify the behavior of the system through an orthogonal layer of computing; if it is bound asynchronously it simply notifies the orthogonal layer of computing that something is happening.

emotions can be bound only to a defined specific subset of service calls, and sense excludes other calls from the emotions management.

Within the concept of emotions sense introduces two specific classes:

Vital emotions

emotionsinfluence the behavior of the service provider systems. sense is itself a service provider and vital emotions offer a mechanism for sense receive emotions from the cloud and then self initiate a call to the underlying business components.

A vital emotion is an emotion that starts within the sense instance and that works:

• intimately with sense to perceive change within the cloud;
• intimately with other surrounding systems to  push information coming into the cloud.

A vital emotions pushes information to the cloud; a set of user defined emotions can subscribe as consumers of the information pushed in the cloud. This lets a sense cloud share information whenever available without stressing external applications on every call.

Health emotions

sense emotions can provide a way for sense assets, services and artifacts to communicate their state of ‘health’ to a federated domain within sense. In this way all aspects of sense can transmit important real-time information so that sense can evaluate and take appropriate decisions.  emotions can be implemented in either a push or pull method.  Push indicates the service or asset itself initiates the state broadcast, pull indicates that sense will periodically ping the asset to get its state.  In all cases emotions are used to influence the behaviour of sense within the management of a sense experience.

go to faq