The Federated Enterprise Service Bus Platform

Jonah Emeson Software Engineering, {Je3g13}@soton.ac.uk

Abstract Distributed applications coupled with the continuum of technology advances has resulted in an

unprecedented demand for service availability. The compromises taken during the architectural

phase of software development has been mitigated by the integration of an enterprise service bus

(ESB). This paper proposes concepts ranging from a model for performance prediction through an

ontology framework for semantics of distributed applications to an algorithm for services’ selection.

Experiments are presented, the results analysed and critiqued; and well used mechanisms and

methodological solutions are proposed for each problem space. This is all with a view towards

achieving a federated enterprise service bus.

1.0 Introduction An ESB is best defined by its roles and capabilities together with the variety of modes it can be

implemented. The first middleware providing ESB functionality was introduced in 2004 [1].

According to Gartner, an ESB is a new architecture that exploits web services, messaging

middleware, intelligent routing and transformation. ESB acts as a lightweight, ubiquitous integration

backbone through which software services and application components flow.

Figure 1: An Enterprise Service Bus [6]

The ESB is an architectural product pattern with a major component called the mediator – handles

routing, message transformation, message enhancement, protocol transformation, service

orchestration, transaction management and security - and its roles are addressed in this paper.

The challenge within the ESB is multifaceted. The solution lies in the merging of disparate

improvements made in the research that focus on each role(s) of an ESB. These solutions are taking

the forms of concepts, experiments, mechanisms and methodologies.

This paper looks at how the components within distributed applications integrate to an ESB, what

ESB roles those applications require and how ESB components service the request.

Figure 2 - A Federated ESB Diagram [7]

The prediction of performance levels of applications integrated to an ESB is examined and a

performance model is developed and compared against measured values from tested tools to

simulate actual performance levels. The model is then adapted to predict performance.

Secondly, the semantic similarities and differences of services within heterogeneous applications are

addressed. These collaborative challenges are mitigated by evaluating a proposal of a Semantic

Service Bus which handles application property definition enabling the ESB to adapt and configure

itself based on requirements.

The Federated ESB paradigm also considers the end users’ identity management. The paper

proposes a mechanism to enable the users of distributed applications to have a single sign on

experience, transitioning the paradigm of user and application simultaneously from predefined

collaborative sign on systems to allowing the application enable dynamic sign on service composition

when access is requested.

Finally, the algorithm used in processing the services for executing complex events at a service

implementation / orchestration level is evaluated. The established system currently deployed is

examined; a new algorithm is proposed with a different implementation and the results are

analysed.

As earlier stated, these problems in the various spaces have been collated and the proposed

solutions are critically evaluated. The aim of this paper is to present a holistic purview of the solution

space comprising the elements of each challenge. The paper concludes by evaluating the proposed

solution elements and targeting same at the actualisation of a Federated ESB.

2: REALIZATION OF A FEDERATED ESB

2.1 Capacity Testing and Performance Evaluation Overview. Predicting the performance of an ESB is different from prediction of traditional application servers,

for which many studies have been done [1]. ESB capacity planning demands a paradigm shift.

Whereas other components are load tested after deployment, the nature of an ESB’s role requires

that its capacity testing be done at an early planning phase in order to determine the integrated

applications’ absolute request handling limits. Given that an ESB is more easily understood by the

role it performs, it can be a client or server depending on the role at any given time. The complex

nature of its mediator also makes it impossible for its routing role to be compared to the simplistic

connection-oriented nature of the TCP-IP. Capacity planning in an ESB is crucial for the practical

reason of optimal resource requirements estimation to prevent the need for any significant

architectural changes on overestimation and mitigate the need for compromises from stakeholders

on underestimation.

Ken Ueno’s [1] approach to plan capacity is to deploy a real ESB on a machine and have a pseudo

environment created around it. Trend Analysis is carried out at this stage where the workload data

patterns of any similarly current or previously deployed architecture is examined to estimate future

resource utilization. His validates by ensuring an authentic ESB product and mediation module is

used on a large server, eliminating the servers’ ability to becoming a bottle neck to generated client

servlets’ requests to the ESB.

The components within this environment - a lightweight service provider (SP) and a lightweight

service client (SC) –are implemented, configuring the SP with real production service parameters

and the SC with a mock HTTP workload generator, several (SOAP over HTTP) requests are generated

with a view to measuring the accurate potential capacity of the ESB. The lightweight service provider

is set up to receive messages in form of requests and respond to as many requests as it is capable of

from the ESB which remains oblivious of this and treats the lightweight Service Provider as a

production service provider and the service client as a real client.

Figure 3: Mock Testing Environment for Capacity Testing [1]

Though Ken acknowledges that the complexity of an ESB’s routing role does not permit the TCP-IP

simplistic performance test approach [1], he goes ahead to posit the same means as his solution by

implementing a simple SOAP request which links to a URI endpoint and does not account for any

content-based, intelligent routing – a backbone of an ESB. This approach is flawed because an ESB’s

core component’s – the mediator – role is to perform, in addition to routing, service orchestration

which utilises the combination of a series of execution of atomic (individual) services to form an

implementation service. This is a basic feature, and the demonstration by Ken is an insufficient

microcosm of this feature’s scenario. It cannot be extrapolated accurately to stress test levels to

determine capacity of the ESB’s performance and at best evaluates the resource usage of an ESB’s

CPU.

This approach can be contrasted with Yan Liu’s [2] where a more holistic methodology is taken to

evaluate the performance of ESB architecture by constructing a standards based Service Oriented

Architecture (SOA) leveraging the benefits of an ESB backbone and utilizing benchmarking

techniques to measure performance. He argues two performance categories (I) the performance of

the individual services which encapsulate the distributed applications in an SOA space through

interfaces and (ii) the performance of the composite services which form the components of an ESB.

He further posits that since the individual (atomic) services connected to the SOAs have standard

performance measurement means such as instrument logging and capacity load testing, the

recursive nature of composite services require the design of a queuing network model to represent

the composite services within an ESB [2] and benchmarking techniques used to estimate the

components’ performance.

His integrates a real world application with an ESB depicting an accurate representative scenario

that can be mapped to an analytical model. The composite services which are required to enable

service orchestration are clearly delineated and a service mapping scenario – the translation of a

business service request to the corresponding set(s) of implementation services – is illustrated.

Figure 4 - Application Business Service Scenario [2]

The (business) process choreography – how the business services interact with one another – is also

captured in this scenario enabling adaptation of this model to other ESB-based applications.

Figure 5: Application Queuing Network Model [2]

He considers the model to be deployed for incoming load requests – between use of a closed and

open request system - and decides to use a combination of the two systems in phases. He uses the

closed request system at the initial phase of analysing and validating performance; the open request

system at the final phase of performance prediction while retaining the volume of input values and

the resource utilization.

Finally his model is calibrated and solved using a mean value analysis algorithm [2]. The elements are

represented as business service(s) or implementation (proxy) service(s). He deduces the value of

execution time of implementation services (integrated with the ESB) by proposing a set of linear

equations –which are simultaneously solved- populated with values taken from the round trip delay

time of a business request execution.

This accrues the time for constituent business and implementation services to perform the business

request operation; and on request manipulation several services can be triggered and their

execution time value taken.

These obtained (solved) values are compared against measured results from standard test tools for

validation and the model is adapted to predict performance by using an open request system.

2.2 HETEROGENEOUS DISTRIBUTED APPLICATIONS’ SEMANTICS This section examines some core roles of the ESB – message transformation, enhancement and

protocol transformation. The extra resource utilization required executing these roles and the

unnecessary complexity it brings to services’ integration, a more efficient expression of functional

and non-functional requirements will ensure the redundancy of these roles. The actualization of a

federated ESB requires an implementation of homogeneous semantics between the service

providers, consumers and the framework processor (ESB).

Ernesto [3] proposes an Ontology Driven Architecture (ODA) in the design of an ESB to realize

autonomic adaptation to changes in Service (Provider/Consumer) functional/non-functional

requirements’ expression. He argues that inconsistencies in implementation services’ naming can

cause the services’ omission during discovery even though the service has the same needed

functionality. He presents a Semantic Service Bus (SSB) to avail a new service with a higher Quality

of Service (QoS) to a request automatically.

Autonomic service adaptation is applied in a practical scenario- evaluating the flexibility of access

control, proposed by Layth [4]: Single Sign-On (SSO) processes and Federated identity management.

He proposes a way to transition from predefined - access, authentication - collaborations to dynamic

service composition scenarios where security policies become distributed and users have ‘federated’

access.

This can be achieved by first implementing the ODA earlier proposed by Ernesto [3]. In this scope

ontology makes it easy for the dynamic composition and re-composition of services and components

required for the Single Sign-On Process.

He illustrates the homogenous semantic concepts of the ontology allowing the services’ provider

and requesters to fully and explicitly express their provided or required functions.

Figure 6: Ontology Based Semantic Illustration [3]

His ontology outline expresses such concepts such as Service_Expression and its properties; he

asserts that dynamic discovery can be established.

He enhances the ESB model and proposes an augmented architecture with a Semantic plug-in with

an inherent ability and without predefined collaborative policies.

Layth [4] proposed a trust domain decentralizing authentication and authorization in such a way that

the trust chain can be established for a global service chain. He presents Security Assertion Mark-Up

Language (SAML) enables dynamic compositing services (semantically) to process –using a generally

accepted distributed security policy - a Sign-On. He argues a set of specifications in a ‘Circle of Trust’

where in consist frameworks for enabling Identity Federation of the users, interfaces and services.

He then proposes a solution to ensure dynamic service composition based on Shibboleth – an open

source project - and enables service security architecture which is essentially a component (with

specified services’ definition – messages transport security, access security ... ) plugged into an ESB.

This dynamic services’ composition enables a user or service to have different roles, use several

identities and define different QoP sets of requirements according to role, identity or context [4]

Figure 7: Federated Identity Model [4]

With the QoP implemented at the Semantic layer which is also made to process intercepted

exchanged messages by encryption, he achieves - by separation of authentication and authorization

management and mapping the (partners’) QoP requirements to authorization policies – Federated

Identity.

Finally he implements the architecture in another open source ESB – Petals – supervised by Dragon

[pg. 3 [4]] (a high-performance SOA Governance solution which enforces organizational

management and service runtime integration).

Figure 8: Ontology Framework Implementation [4]

He also proposes a Service Layer Security Mediation implementation for meeting the ESB QoP

requirements of Authentication and Information exchange security with subcomponents which

different –platform dependent - levels.

Criticism

The approaches deployed by Ernesto [5] and Layth [4] complement each other in their

implementation approach and where they are theoretically convincing also have that as a singular

non-software engineering limitation since the framework used is neither well known nor validated.

2.3 OPTIMIZATION OF ALGORITHM FOR COMPLEX EVENTS’ PROCESSING It has been established that an ESB is a complex- role dependent - infrastructure in the distributed

Service Oriented Architecture (SOA) space. Ding [5] leverages on the semantic-based research body

and focuses on the QoS-based service selection and binding problem which can occur as a result of

data reliability or queuing -unsuccessful service executions.

He posits failing services as related to the sematic limitations in expressing the dynamic composition

of services needed to process complex events. He identifies the inability of current ESB systems to

implement complex event processing such as filtering, aggregation and service choosing [pg. 2[5]].

He then proposes an optimized service selection algorithm for complex event processing named

Greedy Service Selection Algorithm. He defines the complex event as an arbitrary event

construction function with each (individual) event comprising an accumulation of atomic events’

occurrence. He argues that business services’ processing need complex services to be timely

selected and attempts to deduce the service execution time in order to pick the ‘optimal’ service to

further a request.

He outlines an algorithm, representing the service elements in relational algebra, based on the

greedy strategy called the Greedy Service Selection Algorithm where services are selected based on

the number of events they can execute.

For performance validation he conducts an experiment comparing this algorithm with a Naïve Set –

where services’ selection are chosen based on priority - and taking the uniform cost as resource

service execution time.

Figure 9 : Performance of Different Service Instance Number [5]

His experimental results show the Greedy Algorithm as having better values in performances on

Service instances, Event Processing Service Number, Probability of Successful Instances and mean

event processing services.

This approach based on the experimental results can be deduced as an implementation –dependent

augmentation showed a 75% less cost with a view to the actualization of the Federated ESB.

2.4 CONCLUSION This paper evaluated a critical area of the distributed application space – its backbone – the

Enterprise Service Bus and focuses on improvements in the area of Security, Performance and

Complex Event Processing towards achieving the practical concept of a Federated ESB. The disparate

solutions proposed by the reviewed papers while advancing the scope of the architecture they

focused on, collectively showed that there is no silver bullet or panacea for solving the distributed

problem space of achieving a Federated Enterprise Service Bus.

APPENDIX A

PERFORMANCE PREDICTION OF SERVICE ORIENTED APPLICATIONS

BASED ON AN ENTERPRISE SERVICE BUS.

RESEARCH AREA: This paper analyses the performance characteristics of an Enterprise Service Bus’ (ESB) services and

utilises the results to model a performance prediction of an Enterprise Service Bus – based

application.

CHALLENGE: The problem of maintaining acceptable performance thresholds for distributed applications’

(composite) services integrated on an ESB middleware.

Application of the performance analysis to a predictive performance model.

Proposed Solution The paper proposes the representation of ESB architecture in an analytical form which is

modelled, solved and its results used to form and predict the performance of an ESB based

application.

This approach, broken into the following steps, was depicted in modelling a real world loan

application based on the ESB

o The loan application’s services were represented by (performance) model elements

o The model inputs were represented by the workload patterns for the individual

service components

o The model was calibrated by providing parameters with values.

o The model was validated hence the performance could be predicted.

The component services’ execution times were calculated (using linear regression) by

measuring end-to-end time taken for a message flow as input for the total time.

These same times were measured using the Web Stress Application tools.

The errors in component services’ execution times were marginal hence the model was

validated and accepted as an accurate representation of the loan’s application services.

Requests rates of arrival for the different services in the application were scaled and the

response times taken till they reached maximum service capacity.

Conclusion The results show that the model, which has been validated as an accurate representation of

the enterprise service bus architecture can be analysed, and the maximum arrival rate of

service requests can be predicted.

It can be inferred that the performance prediction of services directly correlate to the better

predictive modelling of ESB enabled applications.

EARLY CAPACITY TESTING OF AN ENTERPRISE SERVICE BUS

RESEARCH AREA This paper focuses on the Enterprise Service Bus (ESB) at an infrastructure level, and its capacity

assessment particularly at the early stages of a project.

CHALLENGE The paper argues that an ESB is not strictly a server so certain (server-centric) capacity

planning methods do not apply.

The ESB is a complex system which a mediation module which can have multifaceted

configurations depending on non-functional requirements, so its performance cannot be

adequately represented in a model.

SOLUTION The paper proposes using lightweight clients and providers in a lightweight environment to

do capacity tests – invoking several web services- over a mock environment.

A HTTP workload generator is used to generate request SOAP messages over HTTP as a

lightweight client simulator using HTTP POST.

The lightweight Web service provider, preconfigured in a small server infrastructure,

responds with a response SOAP message responds to the ESB (represented by a real

production hardware / software since its capacity is being assessed.)

Three test scenarios – without an ESB, without a mediation module in an ESB, with a

mediation module in an ESB – were created.

Three test cases - Naïve Test System, Lightweight Test System, and Production System - were

created for each test scenario.

EVALUATION The results of the experiment showed that – when the server CPU usage is 100%

On the Service Provider side: The Production and lightweight service providers recorded

request levels of 4901 and 2028 requests per second, eliminating the third test case at 513

requests per second.

On the ESB Performance: The Production and lightweight systems had throughputs of 1272

and 1260 requests per second.

CONCLUSION The inference from this is that the lightweight environment can accurately simulate

production scenarios, hence should be deployed for early stage capacity planning.

Quality of Service (QoS) and Ontology Driven Autonomic Service Bus

RESEARCH AREA This paper looks at the semantics used by ‘partners’ – Service Consumers and Service Providers – to

define their services’ requirements / offers to an Enterprise Service Bus(ESB) platform

CHALLENGE The issue of heterogeneity of services at a semantic level can have a negative impact on the number

of services that can execute a request.

This directly induces another problem of best service selection in terms of QoS (context- based

execution).

A concrete world production problem – of a complex dynamic manufacturing network scenario - is

introduced.

SOLUTION An explicit services’ semantic that details the provision of offered features as well as their

properties is defined as a ‘Semantic Service Bus (SSB)’.

Two architectures – The Model Driven and the Ontology Driven – are defined and used in

the design of the semantically aware system.

o The Model Driven Architecture is in three further levels - Component Independent,

Platform Independent, and Platform Specific (automatically instantiated based on

partners’ needs and offers).

The Enterprise Service Bus (ESB) is evolved into an Autonomic Service Bus (ASB) which has

extended functionality of solving the problem of context – based execution.

The design principle is applied to the use-case defined in the problem section of a complex

dynamic manufacturing network defining a blueprint for an aircraft model comprising a

process of collaborative activities.

EVALUATION AND CONCLUSION Though this paper does not utilise the established scientific approaches of analytical

modelling and experiments, the detail and semantic concepts based on ontology introduced are very

key in the advancement of the seamless integration of distributed applications and (recognizable)

service availability within an enterprise service bus platform.

SINGLE SIGN-ON INTEGRATION IN A DISTRIBUTED ENTERPRISE

SERVICE BUS

RESEARCH AREA This paper addresses the area of security - the authentication, authorization processes and

identity management - of entities integrated to an Enterprise Service Bus.

CHALLENGE The problem is that heterogeneous applications need to be accessed by the same users.

Varying security policies have been defined by these heterogeneous applications’ providers.

In a distributed system requiring different applications from different providers to

collaborate their services to execute complex events when so required, a federated identity

management scheme is mandatory.

There is some static collaboration where composite services with predefined policy and trust

relationships allow access, but this has limited functionalities in terms of flexibility and on-

the-fly composition of services to grant access depending on the complexity of the event

scenario.

SOLUTION A trust domain is proposed by adapting the OASIS architecture trust model where ‘partners’

participate in predefined requirements based trust relationships.

These relationships are further abstracted to establish a global trust service chain wherein

security choices are passed and enforced across the chain.

The architecture imposes an XML based mark-up language – the Security Assertion Mark-up

Language (SAML) -for passing security tokens to assert security authorisation.

This adapts an open-source federated identity management system – Shibboleth – to enable

cross-organisation authentication and authorisation hence decentralising user credential

storage and allows resource access based on user requirements.

Based on a semantic security service infrastructure (a component implemented in Enterprise

Java Beans) the framework is implemented (at the semantic layer) in PETALS Enterprise

Service Bus (PETALS ESB) to provide secure end-to-end access for all actors (Providers and

Users).

CONCLUSION The semantic security layer separates authorisation of services (at the ESB) from

authentication so the requirements expressed by the user-partner is dynamically matched to

the authorisation policy demanded by the provider-partner enabling a dynamic federated

identity management .

This is an ideal approach for single sign on enterprise service bus architecture.

OPTIMIZATION OF SERVICE SELECTION ALGORITHM FOR COMPLEX

EVENT PROCESSING IN ENTERPRISE SERVICE BUS PLATFORM

RESEARCH AREA The paper addresses the area of enterprise service bus (ESB) architecture specifically the

algorithm that defines the selection of service instances that make up components used in

complex event processing in a loosely coupled environment to enable a more successful

application flow.

NP HARD PROBLEM OF COMPLEX EVENT PROCESSING The problems highlighted are that contrary to the assumed default success mode of service

instances selected to process an event, a portion of these services fail therefore compromising the

architectural flow and Quality of Service.

The de facto algorithm - Share algorithm – used to select these service instances is sub-

optimal.

Certain selected service instances fail on execution compromising the overall Quality of

Service.

The failure of the service bus platform to process complex events – such as filtering,

aggregation and service choosing - which are comprised of these selected service instances.

The problem is a shared filter queuing, NP-hard problem (non-deterministic).

SOLUTION: ALGORITHM FOR OPTIMAL SELECTION The paper proposed a more efficient algorithm - “Greedy Service Selection Algorithm” - to

optimize selection of service instances.

Using the set theory, complex event processing model and relational algebra; the atomic

Event was defined.

This definition was iterated using functions to define the Event, and the complex Event.

The Greedy Service Selection Algorithm was described and defined as one that select the

service instance that has the highest ‘benefit/cost’ ratio.

An experiment comparing the both algorithms’ performances – based on several criteria

– to determine which had a more successful service instance execution at lower cost was

conducted.

CONCLUSION The experiments showed on all criteria that the Greedy Service Selection algorithm

had a more efficient service selection in Enterprise Service Bus architecture than the

Share Algorithm.

APPENDIX B – Thoughts

Having previously interfaced with the Enterprise Bus technology the choice to select it was second

nature. The idea to build the review paper around a Federated ESB theme came together as the

research paper materials’ shortlist were being ingested. Once it became clear that the ESB

architectural framework is really humongous, the focus was centred on specific themes of security,

complex events and Performance, enabling a more directed search to select papers that spoke

towards the ‘thematic’ advancement.

There were a lot of uncertain moments, were a paper was considered too interesting to pass up but

had to be left out because it simply was not central to the federated concept. The bittersweet bit

was to actually read the paper and let it go.

The IEEE and Research gate websites were instrumental in providing a knowledge base plethora and

their intuitiveness enabled seamless navigation among papers’ references to source articles and

journals to further the primary papers’ idea.

The review experience, apart from being very involving, has revamped thirst for scientific knowledge

and its advancement. The federated Enterprise service bus ideal which is still in the works has

opened up other areas of interest in science and technology such as Semantics and Ontology, the

non-deterministic, NP – Hard Problem areas of statistical analysis in complex event processing and

rekindled an innate critical analytical gene.

Most importantly was the realisation that in the augmentation of the innovative thought process,

big information synthesis and critical evaluation, grit is a required attribute.

Bibliography

[1] M. T. Ken Ueno, “Early Capacity Testing of an Enterprise Service Bus,” Web Services, 2006. ICWS

'06. International Conference on, pp. 709 - 716, 2006.

[2] I. G. L. Z. Yan Liu, “Performance Prediction of Service-Oriented Applications based on an

Enterprise,” pp. 327 - 334, 2007.

[3] C. D. E. E. C. C. D. Jlidi, “QoS-aware and Ontology-driven Autonomic Service Bus,” Enabling

Technologies: Infrastructure for Collaborative Enterprises (WETICE), 2012 IEEE 21st International

Workshop on, pp. 417 - 422, 2012.

[4] L. a. B. Y. a. B. F. a. S. N. a. N. Z. Sliman, “Single Sign-On Integration in a Distributed Enterprise

Service Bus,” Network and Service Security, 2009. N2S '09. International Conference on, pp. 1-5,

2009.

[5] K. D. a. B. D. a. X. Z. a. L. Ge, “Optimization of service selection algorithm for complex event

processing in Enterprise Service Bus platform,” Computer Science Education, 2009. ICCSE '09. 4th

International Conference on, pp. 582-586, 2009.

[6] M. Dodani, ““From Objects to Services: A Journey in Search of Component Reuse Nirvana”, in

Journal of Object Technology,” September 2004. [Online]. Available:

http://www.jot.fm/issues/issue_2004_09/column5. [Accessed 4 December 2013].

[7] W. Wright, “Implementing SOA with multiple ESB,” Web Wrights Ltd, 2008. [Online]. Available:

http://www.webwrights.co.uk/service_oriented_architecture/federated_esb.php. [Accessed 5

Dec 2013].

WORD COUNT BODY: 2502

APPENDIX B: 251