SERVICE VIRTUALIZATION THROUGH FEDERATED ESB IN GRID-ENABLED
What is Service Virtualization?
Service virtualization is the ability to hide operating system, platform technology
and network connection or transport and helps the end-user to work with simplified
resources. In other words, one has to just know and implement business logic
without any knowledge of other underlying pieces. Polymorphism is best suited
example for code-level virtualization.
When implementing business services there are four things that one needs to
i. Business logic
ii. Deployment/runtime configuration
iii. Security/compliance configuration
iv. Messaging infrastructure details
Another aspect of what one needs to know is the reuse and repeatable code that
is churned out in development lifecycle of a product/project. In any given scenario
during development there will be larger code reuse applicable from deployment,
security and messaging standpoint. Such implementation shouldn't be duplicated
anywhere in a typical enterprise SOA model. Instead in the above scenario, the
set of configuration has to be coded only one time at one place. So in any example,
if there are three services that need to be developed and deployed separately,
then what is meant by "service virtualization" is that only business
logic (i) needs to be written for disparate services while (ii) (iii) (iv) needs
to be just configured and reused.
Characteristics and Benefits of Service Virtualization
1. Enables factory development model giving way for high productivity
2. Packaging & container deployment
3. Significant code reduction with reconfigure ability on service binding, security
4. Minimal effort on service administration & code release
5. Technology independence
So in any SOA Enterprise, what is meant by "service virtualization"
is developing service with keeping deployment and services management to minimum
Service Virtualization through Federated ESB
Enterprise Services Bus (ESB) is the backbone for any SOA enterprise. ESB helps
virtual zing the services. In a larger enterprise you may need multiple ESBs
based on LOBs to rollout huge SOA initiatives. This is because of growing demand
on performance and SLAs. Different ESBs emerge with different functions. These
ESBs might be similar or different based on one or multiple vendor selection.
In today's ESB evolution we see that ESB has come miles from foundational to
transformational and now with one that can adapt dynamically, called Federated
In transformational environment ESB would use service registry, do BPM service
orchestration, service activity and systems monitoring with or without using
computing appliance systems.
Federated ESB (FESB) would not only use the above features, but also have services
hosted on multiple ESBs. FESB may be owned by multiple LOBs. They are managed
separately but they work together as Single Golden Source for Enterprise Services.
These FESB need not proliferate from same vendor.
1. Single point of source for registry source
2. Autonomous manager managing and mediating service across FESB
3. How grid environments enables optimization of service virtualization in Federated
4. FESB enabled by grid enables high end performance based dynamically configurable
5. In a Federated ESB grid environment, the provider and consumer had to scale
and reconfigure based on runtime demand vs. supply footprint. The autonomous
manager would start or stop services across ESB. Know the health status of the
services on distributed grid environment across Federated ESB environments.
In other words, the services deployed in Federated ESB grid environment should
behave in manner of self-implied Artificial Intelligence System.
Here are the bases for any SOA infrastructure to attain maturity on Federated
i. Self managed autonomous domain
ii. Event driven application
iii. Service mediation
iv. Heterogeneous platform support
Self Managed Autonomous Domain
In Federated ESB grid environment, there will be one master ESB and several
other slave ESBs. Both master and slave will be workers except that the master
will also manage the services deployed in other ESB for throttling (slow consumer/fast
provider) or service recovery.
At the moment of master ESB failure, one of the slaves will be promoted as master
and would start managing until the original master comes back online. This entire
setup is called as self managed autonomous domain setup.
In an extreme transaction procession environment, this setup would ensure high
system performance, since the autonomous domain would manage the services in
such a manner that the least used ESB would be leveraged by scaling the services
Event Driven Application
Event driven application platforms support event-centric programming models
such as event handlers which are triggered by process business events. The service
application that is exposed as part of ESB should support event driven application
The ESB should able to intercept and modify service messages that are passed
between the services. It should process message based on primitive or complex
logic. It should able to transform, route or augment message within the grid
Heterogeneous Platform Support
Services that are hosed in the Grid enabled architecture should not be technology
agnostic. It should be able to support JAVA, .net, python, ecetera.
What Services Need to be Optimized?
Identification of services for optimization would be based on most used ones
in terms of number of hits or services that conform to SLA commitments. These
services would have to be configured and deployed on various ESBs. At runtime
these services would be dynamically scaled based on the policies written within
the grid environment. Services that need to process extreme transaction would
leverage this underlying grid-enabled FESB environment.
Fig 6. Federated ESB (FESB) in Grid Enabled Environment (click
on image to enlarge)
XTP is a complex problem and cannot be solved with one specific product or technology.
Organizations should follow an incremental approach by complementing established
and proven products with the appropriate combination of innovative technologies
as needed for supporting emerging business requirements, or adopt the riskier
and more disruptive technologies to grab greater business benefits and sustainable
competitive advantage. The combination of proven and advanced technologies is,
in many cases, the most pragmatic way to take advantage of innovation by keeping
risk at a tolerable level.
Fig 7. Roadmap for Hybrid Technology Adoption