An application in the cloud is an application that virtually lives in an infinite space with an infinite amount of computing resources available. Service calls route inside the cloud and reach the target service with no real knowledge of where the service is or on what platform the service is running or how the service is performing. Services are dispersed in the cloud with no visibility of which services are best targeted for receiving calls.

Service calls fly into the cloud and sense routes them to the most reliable and performant service delivery node available in the federation to satisfy their specific _Business SLA. But, almost no services written today can vary their nature, or adapt their behavior or their underlying runtime infrastructure, depending on the consumer context they are being called with. In effect services are static, discrete and isolated, which is certainly part of their charm, but often not enough in complex business activities and processes.

In general SOA and cloud solutions today do not offer any way to adapt an incoming service request to match the specific context of the consumer (or class of consumers). For example, if you wanted to handle ‘Gold’ member requests in a better way than ‘Silver’ members, for exactly the same functionality, you would need to create two separate processes and/or services to satisfy the particular context of each group. Effectively, two services need to be created to provide exactly the same business function to the two different communities.

To remedy this intrinsic gap in SOA and Cloud applications, sense introduces the concept of ‘flock computing’ or ‘flocking’ to direct groups of ‘like minded’ incoming service requests to dynamically specified resources, based on a defined set of business rules. This is achieved by declaring, with simple tags, a set of services, deployed (somewhere) in the federation, as possible targets of certain types of service requests. Then, defining business oriented flocking rules that sense uses to route like calls to specific service delivery platforms (the specific platform is dynamically resolved for each incoming call).  So functionally identical services can be annotated with tags that are then used by sense‘s flocking rules to evaluate and direct incoming requests to the preferred service delivery node, called a flocking horizon, for that group of calls.

flock routing

Each sense call is balanced following these criteria:

• apply a flocking rule to the invocation to ascertain which is the target horizon for the possible flock
• load balance the call to the restricted subset of service delivery nodes on which the service is the most reliable

From a business point of view, flocking enables:

• the creation of business paths of computing where “special invocation groups” can follow a different path than others (VIP s could  have different hardware for the exact same functional service)
• the choice of what business service implementation is given to the caller. Services can be declared with the same name and purpose in the cloud, but one instance can be differentiated from another in terms of business. This let architects model a polymorphic SOA architecture, where the behavior can be changed on the cloud depending on the kind of flock.

Benefits

Benefits of flocking include:

• Automatic routing of certain classes of user request to preferred service delivery nodes for higher quality or faster performance – priority customer get priority treatment.
• A single service can be used adapted to respond to different business contexts of the requesting calls
• Architects and developers can implement the same service in different ways and direct context based traffic to the required service instance

Conclusion

sense introduces the concept of flocking to allow operational business context to affect the beahviour of what would otherwise be a static servcie call or a call to diferent services providing the same fucntionality to different groups.  flocking adds tags to service instances and flocking rules to evaluate and direct specific groups of calls to specific flocking horizons.  In this way static SOA is extended to provide business context routing to best match the required SLA of a business application.

go to faq