SERVICE VIRTUALIZATION THROUGH FEDERATED ESB IN GRID-ENABLED ENVIRONMENT

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 look at:

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 and policy
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 and constant.

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 ESB (FESB).

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.

Dependencies
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 ESB?
4. FESB enabled by grid enables high end performance based dynamically configurable environment
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 ESB grid:

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 on it.

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 (EDA) models.

Service Mediation
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 environment.

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)

CONCLUSION

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

-1-

Explore Our Topics

• BPM & Enterprise Architecture
• BPM Standards
• BPM Implementation
• BPM Best Practices
• Cloud BPM
• Continuous Process Improvement
• BPM Governance
• Service Governance

• Business to Business (B2B)
• BPM for Customer Management
• BPM for Financial Services
• BPM for Government
• BPM for Healthcare & Insurance
• BPM for Supply Chain

• Business Activity Monitoring
• Event Processing
• Process Intelligence
• Business Rules Management
• Decision Management
• Operational Intelligence

• Workflow Automation
• BPM & Enterprise 2.0
• BPM & Web 2.0
• BPM & ECM
• Case Management
• Collaboration
• Enterprise Portals
• Social BPM

• BPM & Cloud Integration
• BPM Analysis & Optimization
• Business Process Simulation
• Process Visibility & Monitoring
• Process Orchestration
• Process Discovery
• Process Modeling

Home
Webinars
Blogs
ebizQ Forum
All Topics
Subscriptions
White Papers
Analyst Corner
Follow us on Twitter
Fan us on Facebook

Explore Our Topics

BPM Strategy
BPM Solutions
Event Processing Strategy
Content-Centric & Collaborative BPM
Process-Centric BPM

About Us
Editorial Submissions
Feedback
FAQ
Advertise With Us
Site Map
Privacy Policy
Unsubscribe