SOA embraces the idea to potentially mash up every service available and consume it locally for some result, irrespective if the service is within the direct control of the consumer/producer or with some external third party, or even an open community service. That is, a business producer and a business consumer interact through a collection of services to gain value. These kinds of services should be thought of with a legacy system mindset and their use must be governed within an application as much as any internal mission critical services. An architecture based on sense addresses, interacts, and governs these external services as feelings.

A ‘feeling’ allows sense to reach out and interact (intimately) with an external service, computing environment or resource by defining (and developing) an interface to the external asset with a standard interface and set of behaviors (methods) available to sense.  In effect a feeling turns any external service or resource into an accessible and managed service from sense‘s point of view, as if it were a service deployed directly into sense . All aspects of sense (emotion, SLA, experience, etc.) are then available to monitor and manage the external service/resource. feelings are the prime way in which sense see, talks to, and manages the external world of applications, services and hardware.

sense feeling

One common requirement of all feelings is to monitor  the health status of the service against the business service methods available from the service and to inform sense of this status. Exactly what the health of an external system is, and how it is managed, is delegated to the implementation of the feeling itself.

An SLA for a feeling declares how sense should load any of resources configured within the feeling itself and help the external system or service to stay in good health when operating under load. A sense feeling is an external service, thus sense will manage the SLA of a feeling by collecting and evaluating two kinds of information:

1. “Normal operation” – Performance while calling the feeling during its normal business execution. This can be thought as a performance indicator while the feeling is up and running and while it is required to provide business value. sense detects the status of each feeling and lets the feeling declare to the federation its own SLA status. This is done every time the feeling is finished consuming a business invocation to let other consumers of the feeling  address resources with better qualities (if necessary).
2. “Idle” – The health status while the feeling is not being called directly by consumers . This periodic check allows sense to maintain the health status of the relationship (between the external service/resource and sense) so that sense can make a correct determination of invocation the next time the feeling is called. Obviously, as the service/resource is external to sense there could be unknown issues with the network or other unknown (external) service consumers could have affected the state of the service. sense must be able to call the service periodically and to evaluate the health in order to set the appropriate SLA status level.

Based on the SLA status of the feeling (via either of the above strategies), sense can correctly assign in coming work requests to the requested service or redirect from the service if it is considered ‘suffering’.

The feeling SLA defines how to react when the system becomes overloaded. sense also addresses the case when all the resources configured within a feeling are suffering and are switching (or have switched) to an ‘off’ SLA level. This could be the case where the number of consumer calls is significantly different from the producer’s delivery capabilities. sense can manage this by configuring a mock strategy for the feeling. A mock strategy can reply to the request in a normal way with a pre-canned or derived response whenever the service is not available (avoiding any domino effect). The exact mock strategy can vary for each feeling and is thought as a business constraint when building complex SOA scenarios.

Benefits

The prime benefit of a sense feeling is that servcie consumers can receive the same level of quality of service for their external services and resources as they do for internally sense managed services. In fact the consumer request is not aware that the service is being satisfied from an external service or resource (unless you explicitly want to indicate this). sense can apply the the same intelligent business balancing across internal and external services and resources, thus adding a higher level of Quality and SLA to your internal, SOA or cloud solution.

Another benefit is seen when the external resource does not in fact respond or is not available. sense can provide a ‘mock’ response to avoid any error cascade or domino effect on the whole system and on the calling system.

For the service provider, sense can offer a way to scale your service delivery providing a measured increase in service level to your customers and consumers.  In the case of a service crash or non-availability, the incoming request can be rerouted to an available delivery platform, more resources could be automatically brought online, and the suffering service provider can be isolated and, if necessary, repaired with no impact to the service delivery.

Conclusion

In effect, feelings  give sense a way to talk meaningfully to external resource and services as if they were any other service deployed in sense, to understand their health status and manage resources or assets within the feeling. feelings also provide remote administration of the external resources (if such control is permitted in the external resource/service). sense feeling are developed to a published and supported set of sense APIs.

Sensible Cloud has already developed feelings for:

• Amazon EC2
• HP Virtual server
• Xen
• We are also working with external partners to continually extend the family of sense enabled services, platforms, and resources.