- Email: [email protected]
Analyzing the role of interfaces in enterprise service bus: A middleware epitome for service-oriented systems
Accepted Manuscript
Analyzing the Role of Interfaces in Enterprise Service Bus: A Middleware Epitome for Service-Oriented Systems Robin Singh Bhadoria , Narendra S. Chaudhari , Tharinda Nishantha Vidanagama PII: DOI: Reference:
S0920-5489(17)30052-1 10.1016/j.csi.2017.08.001 CSI 3228
To appear in:
Computer Standards & Interfaces
Received date: Revised date: Accepted date:
9 February 2017 13 June 2017 7 August 2017
Please cite this article as: Robin Singh Bhadoria , Narendra S. Chaudhari , Tharinda Nishantha Vidanagama , Analyzing the Role of Interfaces in Enterprise Service Bus: A Middleware Epitome for Service-Oriented Systems, Computer Standards & Interfaces (2017), doi: 10.1016/j.csi.2017.08.001
This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting proof before it is published in its final form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.
ACCEPTED MANUSCRIPT
Highlights
AC
CE
PT
ED
M
AN US
CR IP T
Investigate on software based interface through well-defined connectors available in Enterprise Service Bus (ESB). Discusses core design principle for ESB based Interface in facilitating middleware solution Comparison between non-ESB and ESB as interface usage in facilitating services over network/cloud. A mathematical formulation to driven the relationship between multiple services.
ACCEPTED MANUSCRIPT
Analyzing the Role of Interfaces in Enterprise Service Bus: A Middleware Epitome for Service-Oriented Systems Robin Singh Bhadoria Discipline of Computer Science & Engineering Indian Institute of Technology Indore, Madhya Pradesh, India [email protected]
Dept. of Computer Science & Engineering Visvesvaraya National Institute of Technology, Nagpur, Maharashtra, India [email protected]
Tharinda Nishantha Vidanagama
CR IP T
Narendra S. Chaudhari
AN US
Department of Computing & Information Systems, Faculty of Applied Sciences, Wayamba University of Sri Lanka, Kuliyapitiya, Sri Lanka [email protected]
ABSTRACT
ED
M
The modern era of computing is designed around service-oriented systems which integrates multiple services to deliver sophisticated services through well-known interfaces. It could efficiently be done by using features of Service-Oriented Architecture (SOA) like reusability, scalability and interoperability. SOA is an adaptive and flexible enough to acquire changes for dynamic environments but it is noted that it is limited with remote and distributed access to services in complex systems where interfaces are not recognized as common medium. This could be strengthened with adopting framework which not only meet such requirements but also provide varieties of interface between multiple services from different domains of applications. Enterprise Service Bus (ESB) is a middleware distributed kind of framework that extends the features of SOA systems and supports the deployment of end-to-end services through well-defined ‘interface’ called connector. The main contribution for this paper is building a deriving mathematical formulation that provide relationship with successfully chance for getting interface during interaction between multiple services. This paper also analysis and investigate the comparison for non-ESB and ESB as interface usage in facilitating services over networks.
PT
Keywords: Interface, service end-point, enterprise service bus, service integration, service-oriented architecture, Connector, middleware.
CE
1. INTRODUCTION
AC
Distributed computing can be termed as an IT service model/platform that provides on-demand or pay-per-use services over the internet. In today‟s modern era of computing, software architecture plays a vital role in delivering hassle free services across the networks. These services builds the business outline by supporting its client in significant manner to cumbersome requirement. The advancement of software technology was unable to keep up such requirements for dynamic business models and such requirements can only be completed through ESB. Here, ESB actually extends the feature of SOA system [13]. The most difficult issue is „interoperability‟ between multiple services which is also called Service integration in delivery and access of the service. This service integration means the amalgamation of multiple services on a common platform where it could exchange data and information through protocols. The second issue is “protocol conversion” between communicating services that support different underlying protocols. Such gaps could be bridged with the aid of ESB with its variety of connectors that forms welldefine interface to communicating with services from different domain of applications [1, 6].
ACCEPTED MANUSCRIPT
AN US
CR IP T
ESB is a middleware framework that supports the transport protocol conversion and message handing between multiple services. Usually, web services are deployed into component, called containers, which utilize the resource instance on-demand [7]. A “message” is a standardized format for exchanging information which might be containing a payload and header along with other attachments for data. This ESB framework is designed to transform messages and route it to its destination [42, 44]. It also extends the features for SOA which are reusability, scalability and service integration. The idea of ESB is related to Enterprise Application Integration (EAI) which not only envisioned the perception of service integration but also provide connectors that connecting different legacy application services to standard environment using service contract. This could be achieved through well-defined interface in ESB [10]. In traditional practices, service integration is achieved by point to point reconciliation. An individual platform is designed and developed to support each new application with the existing platform. This is an extremely tedious methodology and has to be replaced with a federated solution of service orchestration on common and shared platform. Service containers usually communicate with each other by sending messages and these messages need to be routed through a predefined path. ESB is efficient in handling such messages through wellknown dynamic routing algorithms. It supports in message authentication and validation during interaction between services. Security aspect uses digital signature and web service-security based authentication for better and assured delivery of messages in ESB. It also involves the access control on resources from their clients. ESB also act as a message based distributed integration bus for middleware solutions that provide interaction in distributed manner to build sophisticated, secure and reliable meditation [13].
AC
CE
PT
ED
M
ESB is designed to nurture integration methodology and handles resource provisioning between multiple services through interface. These containers are usually dynamic and plug-in to ESB [15]. The self-measurement principle of ESB to monitor and diagnose concurrent system resources is more efficient in delivering services across the networks. This efficiency could depend on multiple parameters that may influence the performance of cloud based ESB systems [4]. It is important to note that business interaction could be best implemented with essence of distributed behavior and dynamic need of services which is adaptable with ESB. It means that applications have to pursue certain rule to adapt to these new necessities.
Figure 1: Positioning of Enterprise Service Bus in relation to service components and infrastructural resources.
ESB supports a set of integration patterns which specifies the service recognition and message formats. Such a set of integration patterns are provided by each ESB manufacturer in the form of Enterprise Integration Patterns (EIP).
ACCEPTED MANUSCRIPT
During the communication between multiple services in the form of messaging, ESB helps in recognizing these message formats through known EIPs [8]. 1.1. NEED FOR ESB AS AN INTERFACE
AN US
CR IP T
An interface is a special kind of listener practice that have certain library classes which can utilize object contained in Java Messaging Service (JMS) message, SQL tables or some file. Establishing communication between multiple services need common platform which usually do not supported by simple SOA implementation that only provides the conversion of underlying protocols. ESB based interface also strengthen the connection between all invoked services. Such interfacing could be modeled with the aid of well-known „connectors‟ like J2EE connector [12] & [26]. ESB affords variety of connectors that offers message flows to connect and interact with from other services, e.g. Salesforce.com and twitter Inc. In fact, client can also create and customize the connectors according to their requirements. While creating and utilizing connectors, one has to add and enable it in the ESB instance for its full execution and functioning. This also facilitate the mediation between multiple services that resolves the issue of interoperability. Interoperability could be major hindrance in establishing interaction between client and services. This issue could be best handled with the help of interface in ESB through well-known connectors [26].
1.2. CREATING INTERFACE
M
An interface provide a mediation that offers platform through which interaction between client and legacy application could possible. This all could be possible with help of ESB. It also provide functionality and data to flow with ESB which connects to and interact through interface of legacy system like eBay, Salesforce Twitter and etc. This provide mediation through which message in ESB instance gets connect to receive data in the form of Spreadsheet [35]. These messages contains client information like name and password, log credentials for particular legacy application like Twitter account. Client can customize with the use of one or more connectors in aid to handle issue related to business demand.
PT
ED
A connector is a set of templates that describes the operations through which client can utilize and access specific business logic to execute messages [15]. This is a part to configure its ESB to established communication path between multiple services. Characteristically, connector is accustomed different APIs from external service and provide mediation to message flow. For example, ESB is initialize with a set of API which is termed as default connectors for any legacy application system like ebay, JIRA software and Twitter.
AC
CE
For creating interface using connector, following tasks are involved [18]: Customized desired set of APIs provided by the service provider like JIRA software support RESTful and Java API. For REST API, interface can be creates based on operations entirely which involves XML configuration files. Otherwise, Java API first create XML configuration files and then, proceed to Java classes which defines the operations. Use the connector core libraries to further define interface. After that, package all the files in a ZIP file which further can add to an ESB instance. There have been several files and sub-files associated with interface through connector. Each file has specific APIs to perform certain operations to produce desired task. One file could contains multiple sub files which defined by its component name and associated filter applied on it.
CR IP T
ACCEPTED MANUSCRIPT
Figure 2: List of file and sub-file for API call configuration in interface through connector
AN US
Here, pow.xml file as shown in figure 2, contains dependencies between connector core libraries and Synapse libraries along with associated „Maven‟ repositories. This could be for connector like JIRA Maven repositories along with its filter, template and icon files etc. Such dependencies are further shown in figure 5 as the dynamic mediation to support different connectors in ESB [14] & [34].
AC
CE
PT
ED
M
createFilter.xml Create new filter and sets permissions just using client default and common permissions deleteFilter.xml Delete a filter. getFilters.xml Returns the filters which is currently invoked by its log-in client. getFilterById.xml Returns a filter with specific id updateFilterById.xml Updates currently invoked filter, and returns its new value.
Figure 3: Java Script for component.xml file Here, component.xml file contains relevant information about different operation that could possible in particular category as shown in figure 3. This also presents the fact about different component for filters like, , , and many more.
ACCEPTED MANUSCRIPT
CR IP T
ent.wso2.paradise org.wso2.paradise.mediation.initializer ${project.version} org.wso2. paradise org.wso2.paradise.connector.core ${project.version} org.apache.synapse synapse-core
Figure 4: Java Script for dependencies file.
AN US
Here, dependencies file depicts the mapping of one connector in relation to principal libraries and build a relationship to derive the operation between them. The connector.xml file describe the information regarding created and invoked connect along with its name, package usage and different category of operations which are indulge by that particular connector.
ED
M
PT
Figure 5: Java Script for API calling configurations
CE
While creating filters for connector as shown in Figure 5, template defines the calling sequence for APIs which also defines steps essentials to invoke API as configuration in connectors. The assemble-connector.xml file as shown in figure 2 is used have all associated instructions to create connector as zip archive. 1.3. SCIENTIFIC CONTRIBUTIONS
AC
This paper investigates and implements the issue related to ESB that supports varieties of interface as connectors. When services are delivered into non-interface environment where recognition of service could not be possible with simple, tightly-coupled and isolated service [12]. This generate the need of dynamic, reusable and federated environment where recognition and interaction is possible with message handling routing and protocol conversion features of ESB. The main contribution of this paper could be as follows: Primarily, ESB extends the features of SOA systems as it reuses the existing service module called – component, and integrate to deliver fast and accessible service across the network [7]. Service integration could be possible with variety of pattern which are provided as enterprise integration pattern (EIP) from manufacturer of each ESB company. These patters help in amalgamate different services from different domain of applications [3].
ACCEPTED MANUSCRIPT
An interface is a special kind of listener practice that has certain library classes which could be utilized different objects contained in structured table or JMS message. An interface helps in establishing communication through interaction between multiple services. This job of interface is usually carried out by connectors in ESBs [18, 24, 39]. A mathematical formulation is derived for building relationship between services and their interface. This also helps in understanding the concept of reuse and recycle in distributed computing for handling messages in interaction among services [28, 36]. It also deduce a relationship with successfully chance for getting interface during interaction process with services and helps in reducing overall computation time during such processing and loading of CPU. Finally, simulation is tested to investigate the importance of interface in service-oriented systems where integration of multiple services are performed in controlled environment of ESB and Non-ESB [6, 33].
CR IP T
2. RELATED WORK
AN US
Using interface, services could easily be interact and integrate with other services and this could possibly be best handled in ESB. It is important to note that service-oriented system could also implement the fundamentals of service integration but messaging during interaction among services could not be routing efficiently, organized managed and doesn‟t supports underlying protocols. All mentioned features are added in ESB and that does loose coupling, execute on plug-in mode with the multiple services [41]. In [4], Cloud based enterprise application integration approaches were analyzed and tested for concrete cloud service bus named as “JTangCSB”. It implements the practice for interfacing cloud based services that provides the storage for data in multitenancy-aware execution of services. This is limited approaches for handling cloud based services and provides partial connector/adaptor like SOAP web services.
ED
M
In [5], a lightweight service bus named- LISA, is proposed that supports heterogeneous and distributed services. It provides API called interface to support Internet of Things (IoT) platform and facilitates interoperability among multiple services. LISA build to serve embedded resources like sensor nodes which provides features of ESB. Java API could be created and implemented in this model but no provision for code optimization is identified. Data Authentication using checksum is implemented in LISA.
PT
In [17], a multi-tenant based ESB that support caching of data is proposed namely- cloud data access for ServiceMix (CDASMix) that enables accessibility of data transparently using well-known API - interface. This model is combination and extension for ESBMT [25] and Apache ServiceMix [46]. It supports Java Business Interface (JBI) for recognition of services from different domain of applications. It does not support GUI based client interaction and don‟t provide debugging toolset for analyzing flaw in service delivery.
AC
CE
In [25], an ESB that is based on multi-tenancy proposed namely- ESBMT which involves different services and utilizes multiple resources simultaneously. This model provides secure data authentication with its remote access that supports sophisticated GUI for interaction. It also supports different web interface with several administration and management clients via standardized interfaces provided by every ESB manufacturer. In [29], a cloud based manufacturing model is proposed namely – CManufacturing that supports on-demand access to multiple resources via network. This model is designed to semantic structuring of enterprise using APIs which implements the logic for service-oriented systems. It also comprises of production, implementation design, experimental and communication capabilities associated with data exchange during service execution. This model is capable for debugging and assessment for data through its client GUI. There could be several parameters for evaluating performance, efficiency and outcome for any service-oriented systems [2]. Different services need different interface (connectors) to facilitate interaction between them and could be improved with adding superfluous features like data authentication, code optimization, remote debugging,
ACCEPTED MANUSCRIPT
resource provisioning and interoperability. The above mentioned models are metaphorically compared in Table 1 that depicts the relationship between mentioned parameters. Table 1: Comparison for different domain-specific and general-purpose interface framework designs ESBMT
CManufacturing [29]
CDASMix [17]
LISA [5]
JTangCSB [4]
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
System Usability GUI based support
✓
✓
✘
✘
✘
Remote Coordinator
✓
✓
✘
✘
✘
Resource Provisioning Software Abstraction
✓
✘
✘
✘
✓
✓
✓
✘
✓
✘
✘
✘
✓
✘
✘
✓
✘
✘
✓
✓
AN US
ED
Debugging & Testing Tool System Efficiency Code Optimization & Validation Security Support Data Authentication
M
Interoperability Communication Protocol Support Connector Support
CR IP T
[25]
3. ESB INTERFACE AS A VIBRANT MIDDLEWARE SOLUTION
AC
CE
PT
The primary aim of ESB is to provide interaction between different clients and services. It must support the reusability of services published by another legacy application and this could be implemented with the help of welldefined interface [23]. This functionality also increase the reliability associated with distributed service which support different platforms through connectors. ESB provides multiple interface that facilitate monitor, develop and handle messages to interact and flow with other services in legacy applications. It enables the capability of recognizing and supporting different message formats via a set of known EIPs. In [30] & [35], discussion on multiple service integration from heterogeneous system using ESB architecture are made. This heterogeneous system is provided with critical programming methodology, which does not support an integrated development environment through interface. ESB must be designed in keeping parameters related with adaptability and common underlying protocols between multiple services [30]. There are several open-source ESBs existing in the market that offers features such as observability, agility and robustness with security authentications. The behavior of ESB is different from a conventional application server. Whenever, ESB is installed on a cloud based server, its performance could be measured on basis of time and space complexity. ESB also works as an interface for clients as well as service providers. Its performance could be assessed and compared to simple intermediaries like TCP/IP network routers for getting mutual dissimilarity in handling services. This is the reason, why every large organization is moving their architectural support towards ESB. It can be designed and developed using legacy environments like DotNet, Java Enterprise Edition through Java Messaging Services (JMS) [26].
ACCEPTED MANUSCRIPT
While picking an ESB product which exists in the market, numerous points need to be kept in mind and these points are important for performance and execution environment for SOA which include – costs related to installation, Return On Investment (ROI), planning & designing, documentation and features affecting operational infrastructural resources. These points build federated solutions to form QoS based parameterized analysis which could help consumer/client in ESB production selection [24].
AN US
CR IP T
Table 2: Attribute requirement for Interface configuration [18, 39, 40, 41] Attribute Required Description Endpoint class Yes Defines the name of your endpoint class like in endpoint references (EPR) which used to establish link between two different domains of application. Connector Yes Variety of connectors are provided by serving ESB, client could customize the connector with convenience. Default connector is initially mounted with ESB deploy. Template Yes Defines the calling sequence for APIs which also defines steps essentials to invoke API as configuration in connectors. Message Type No Message interface for connector. Initially not choose/customize, ESB would guess based on Endpoint classes. Transacted No Automatically, it set to true. Whether invoked message within the J2EE transaction.
PT
ED
M
It is important to note that interoperability scenario especially for those services which are not familiar with ESB environment could be best handled by adopting interface through connectors. Such interface are capable in transforming messages from known services to unknown services and vice-versa [23] & [25]. Table 2 depicts the interface requirement and its configuration that includes endpoint to establishes connection between two parties, election of connector, call sequence of API, type of message based on its end-point classes and invocation of J2EE connector in execution. EPR is simply justified as user device like PCs or equipment which are directly in connected to distributed network like service-oriented systems [17, 18]. If messages are coming from non-ESB clients, then ESB enables the interface to accept such messages and route it to corresponding destination. This all could be supported with endpoint references (EPR) which are collection of web services through components in ESB that too describes the resources handing in ESB [18].
3.1. CORE PRINCIPLE FOR ESB DESIGN
AC
CE
The core functionalities for an ESB depends on unique perspectives Service provider plays a vital role in delivering these functionality and must be committed to its service client as shown in Figure 6 [41]. There could be following principles on which ESB replies: a.
Transport protocol conversion: ESB helps in adaptability and understanding the under laying communication protocol that is governed by a particular application service. This feature of ESB provides connectivity with legacy systems to new modern computing systems [16].
b.
Mediation and Message transformation: This functionality translates message format between communication service components that is necessary to deliver federated service to different systems on common platform. This also supports inbound and outbound protocol transformation [21].
ACCEPTED MANUSCRIPT
Message routing: This is one of most striking features in ESB that changed the mood of market and business to shift their commerce through ESB. It enables the service provider to send its message through a designated path [43].
AC
CE
PT
ED
M
AN US
CR IP T
c.
Figure 6: Relationship of Infrastructural Resources and Web Service Consumers with ESB Middleware
d.
Message enhancement: This feature enables service provider to put additional or missing information needed at time of communication. It not only improves the communication overhead, but also categorizes demand at time of resource access. This is possible with the help of Enterprise Integration Pattern (EIP) that have been provided by every ESB manufacturer [44].
ACCEPTED MANUSCRIPT
Security Aspect: With this functionality, ESB could enable service providers to handle security parameters. Security should be featured on every web service for its integrity, confidentiality and availability of that particular web service. Information should not be disclosed via „connectors‟ used in computing systems which may be used by a malicious party during transaction process [25].
f.
Monitoring and management: This feature enables service provider to improve efficiency and flexibility by providing a monitoring tool in management console of a particular ESB. This is best supported by Java Management Extension (JMX). It is a powerful monitoring tool that helps a particular ESB in detecting mediation flaw, message flow, and trace the client pattern [15].
g.
Interface: This feature provides multiple interfaces to different versions of a service from multiple domain of applications. It also allows for multiple channels path to support underlying implementation for service integration. This requirement might involve multiple interfaces formats that could also support interface for web service standards like SOAP/XML, WSDL, etc [18].
h.
Direct proxy: This feature has the capability to transfer received messages into specific type of service that could help in building federated service. Several ESB products have been fitted with service proxy capabilities. Such capabilities makes it easier to integrate (federate) multiple systems in SOA [41].
AN US
CR IP T
e.
AC
CE
PT
ED
M
Workflow for services enables mediation through which communication could establish between client and service provider [6], [27] & [28]. Initially, service provide receive resource demand from client and it first check the availability for requested resource and response back with allotment of resource if available. With the help of connector, it links through ESB so that it supports all possible route for message delivery with potential route handler. This methodology is shown in Figure 7.
ACCEPTED MANUSCRIPT
Figure 7: Service workflow from Service Provider to client using ESB Interface Client could add properties to enhance their interface like jca-connector for java based system [20]. A message itself may contain information related to primitives such as integer, byte or a data structure such as an array, a record or an object. The command message and document message specifies the event occurrences between its sender and corresponding receiver [9], [21] & [22].
CR IP T
4. ESB INTERFACE WITH MATHEMATICAL EVALUATION To understand the concept of reuse and recycle in distributed computing paradigm for handling messages through interface, a mathematical formulation is beneficial to detail its fidelity and agility with service request-response methodology in ESB. The word „Reuse‟ in messaging governs with a piece of code that is used in implementing service integration via well-defined „interface‟. This methodology not only reduces the load of reforming message schema to each new arrived message, but also trims down the overhead involved in handling [19]. This could be evaluated with the help of mathematical probability of mass distribution function and with interface in the ESB; the cumulative distribution function could be expressed as [36]:
AN US
Yi1,2,.......,N
N p Yi i 1 p (Yi ) p (Yi1 Yi2 ) ..... i1 i2
.....
p(Y
i1
i1 i2 .....ik
Yi2 ........ Yik ) ....
M
i
Now, service,
will utilize by ' n ' service through well-known connector and that can be with probability of
PT
Yi
ED
... (1) N 1 p(Yi1 Yi2 ........ Yik )
n
CE
Therefore, p(Y ) N 1 i N
Also, for two different interface Yi and Yi which utilizes nth services with probability of:
AC
N 2 p(Yi1 Yi2 ) N
1
2
n
Same could be possible for general equation into different interface: N k p(Yi1 Yi2 ..... Yik ) N
n
For successful interface, above equation could be deduced as:
( N 1) N for
ACCEPTED MANUSCRIPT
N 1 N N 2 N N 3 N ... N 2 N 3 N n
n
n
n N 1 ..... (1) N 1 N N
(Eq. 1)
N 1 N N i i 1 (1) i 1 i N n
CR IP T
(Eq.2)
AN US
It is interested to note that ESB must possessed with policy in order to provide the guidelines to its client for secure use. This must be a part of service contract that must be followed by clients for best manageability, accessibility and observability of its services. However, such policies need thorough consideration of ESB requirement with its features. Several experts are doing their research to reconnoiter the quality perspective for ESB and could benefit the society in selecting best available ESB. Determining the service interaction through well-defined interface is a significant architectural verdict that could be adopted by researchers in order to align the need for business goals [3] & [29]. Therefore, simulation of these available ESBs is important to segregate parametric evaluation on cloud based systems.
5. CLOUD BASED PARAMETRIC ANALYSIS FOR ESB INTERFACE
ED
M
The goal of this paper is to investigate and analyze cloud based ESB performance through connectors as interface to facilitate services. This implementation is done on Window 7 with AMD x64 architecture by installing different ESB at remote cloud location. Parameter analysis on received and sent messages, time of execution, overall bytes utilized, message counts, and memory utilization is performed. These ESBs mediate service flow at remote cloud servers. Results were tested using two open source ESBs – Adroit UltraESB and WSO2 ESB.
PT
AdroitLogic UltraESB is full and light-weight open source ESB that provides multiple message/data formats and transport protocol conversions. UltraESB supports “Zero-Copy proxy” service which ensures its delivery to its designated network with non-blocking I/O capabilities. It also enables with WS-Security and features to build ESB with dynamically loading (reloading) & deployment of services across the networks with well-defined connectors (interface) [38].
AC
CE
WSO2 ESB is an open source ESB that provides better compatibility and high performance in terms of service accessibility. This may be the finest option in the available class of ESBs as it supports almost all variety of connectors in ESB with multiple service stack support like - Service governance, monitoring and management, virtual environment and many more. According to eBay Inc., for online shopping, it uses WSO2 Enterprise Service Bus for executing and processing transactions, which is more than 1 billion per day [37]. Message count in ESB briefs about the total number of sent and received messages during interaction among multiple service components. Messaging is a strong parameter that enables the communication between distributed co-located services. This interaction supports in delivering end-to-end services through messaging across the network. It also justifies the message counts which include success and failure of these messages at remote ends [9]. The minimum time period to process these messages could be calculated using mathematical formulations as depicted below:
ACCEPTED MANUSCRIPT
Atr
Atr 1 (r 1) tr r
(Eq. 3)
Here,
r is number of messages, i.e. Total message count.
tr is time taken to process the rth message through proper mediation channel.
CR IP T
Atr is average time to process each byte that have been used in messaging.
AN US
While enabling interaction between multiple services, data transfer is mediated through ESB with time computation complexity and such data represents the state, value and behavior of a particular service using distribution function as mentioned above. This build a relationship with successfully chance for getting interface during interaction between these services. It also helps in reducing overall computation time for processing and loading of CPU data [6]. Here, Equation 2 and Equation 3 are interrelated as one is depended on other. For example, if chance for getting successful interface is higher, then time computation for processing would be lesser. Each service has its well defined pattern format and these patterns are provided by ESB manufacturer that develop and design service component architecture. Service integration is possible due to these patterns and it supports the messaging between multiple services over cloud [4] & [17].
3500
Memory Allocated Non-ESB Interface ESB Interface
M
2500
ED
2000
1500
1000
PT
Memory Allocated (Mega Bytes)
3000
500
CE
0
12:10
12:25
12:40
12:55
01:10
01:25
01:40
Time (Hour : Minutes)
AC
Figure 8: Shows statistics for used and allocated memory in regards to time for WSO2 ESB.
Memory is always a crucial matter of concern in terms of execution and overall processing of messages. This is monitored by “heap memory” section in ESB framework. Figure 8 depicts the statistics for such memory assignment and usage with respect to unit of time [22]. The allocated memory to system is used in handling resources, creating instances and buffer requests from different clients. ESB plays important role in this scenario which almost utilizes nearly half memory as compared to non-ESB solutions. This is implemented using WS02 ESB and for non-ESB interface like simple SOA [23]. Table 3: Statistics for WSO2 ESB
ACCEPTED MANUSCRIPT
Total Message Count Total Fault Count Maximum Response Time Minimum Response Time Average Response Time Memory Allocation
581 581 576 0 62 ms 8 ms 19.594 ms 498.50 MB 248.02 MB
Description Number of request made by multiple service components Number of response made to corresponding request Communication Messages float among service components Gives the failure count Maximum time incurred in process and response back Minimum time incurred in process and response back Average time incurred in process and response back Total allotment of memory Actual Usage of Memory
AN US
Memory Usage
Value
CR IP T
Parameters Total Request Count Total Response Count
There are different parameters which need to be analyzed whenever any service component request access to a particular resource instance. This scenario is well depicted in Table 3 for WSO2 ESB that involves the monitoring of several parameters like total message count, total request/response time, time incurred in response to a particular message and most important part is memory assignment [32] & [33].
PT
ED
M
The same pedagogy is experimented with Adroit Logic UltraESB that displayed in Table 4. This follows Open Service Gateway initiative (OSGi) specification as mentioned in Apache ServiceMix integration platform. It also supports Java Business Integration (JBI). This UltraESB also experiments to find “Daemon Thread Counts” that determine supporting tasks for providing services to the user threads at background. It is not dependent on provider‟s server thread and its life span is associated with user thread completion. This is the reason why JVM dismisses the daemon thread when no user thread is determined.
Table 4: Experimental Statistics for Adroit Logic Ultra ESB
CE
Parameters
Value 429
Message Count (Failed) Message Count (Total)
0 429
Active Threads Counts
46
Daemon Thread Counts
8
Minimum Response Time
6 ms
Average Response Time
15 ms
Maximum Response Time
240 ms
Memory Allocation
700.55 MB
AC
Message Count (Successful)
Description Communication Messages float among service components Number of failed Messages Total number of messages Supports in concurrency and integration of services Background supporting tasks Minimum time incurred in process and response back Average time incurred in process and response back Maximum time incurred in process and response back Total allotment of memory
ACCEPTED MANUSCRIPT
Memory Usage
243.65MB
Actual Usage of Memory
Figure 9: Show statistics for average loading of CPU (in percentage)
AN US
Non-ESB Interface ESB Interface
140
100
80
60
40
20 12:25
12:40
12:55
01:10
01:25
M
Load Average (%)
120
12:10
CR IP T
CPU load is calculated to justify the performance of ESB. The average load is summarized for all the requests and responses made for service interaction through interface. The distributed system determines the load information using CPU queue length and load balancing techniques. Figure 9 depicts the average load of CPU varies between from 100% to 150% bearing capacity that ensure the performance of system in delivering service using UltraESB. Here, ESB Interface works better as compared to non-ESB interface which are implemented using simple SOA features. With non-ESB interface, there is steep growth in CPU loading and this continues to global and local maxima, but ESB interface get stabilizes after specified time. This shows ESB interface could better handle services over network/cloud [31].
01:40
ED
Time (Hour : Minutes)
CE
PT
Work presented in [2], focuses on service accessibility for disabled school that supports service architecture to improve its fidelity with neighboring environment. When such interaction is occurred between multiple service components, data has to be carried into some formatted file. These files are created to handle data and can be cached for better communication. File cache gives the number of files created by particular instance using UltraESB. This functionality is facilitated by well-known connectors which is supported by ESB over network/cloud. This is well depicted in Figure 10 in which file cache count goes up to maximum of 80,000 for non-ESB interface and count got stable for ESB interface after approx. 57,400 files
AC
Figure 10: Show statistics for overall file cache usage
ACCEPTED MANUSCRIPT
Non-ESB Interface ESB Interface
60000
40000
20000
CR IP T
File Cache Usage (Count)
80000
0
12:10
12:25
12:40
12:55
01:10
01:25
01:40
Time (Hour:Minutes)
M
AN US
ESB supports Java Virtual Machine (JVM) that is based on File usage from cache memory. This cache usage also avoid garbage collection of files in heap memory that occurred due to overwhelming generation of messages. This helps in improving performance and reliability of cloud based systems [19]. When processing multiple messages simultaneously, runtime (heap) memory is needed to maintain the concurrency of threads. This all could be implemented through ESB interface that remediate the effect of heap exhaust. This is well depicted in Figure 11 that shows allocated heap memory from 500 MB to 700 MB. It also presents the fact that services which are handling using UltraESB, are stable after specific period of time and whereas non-ESB interface need increasing heap storage as shown in black line.
688
Non-ESB Interface ESB Interface
PT
602 559 516 473 430
CE
Heap Usage (Mega Bytes)
645
ED
Figure 11: Shows statistics for heap memory usage.
AC
12:10
12:25
12:40
12:55
01:10
01:25
01:40
Time (Hour:Minutes)
CONCLUSION & FUTURE PLAN Interface provide convenient solutions for problem associated with interoperability in services integration for service-oriented systems. ESB supports the variety of interface through well-defined “connector” like J2EE which plays important role in handling data for legacy applications. Connectors are design to support flexibility and reusability of services and enables ESB to unleash with business processes migration. This paper investigate and analyze the services through different connectors in ESB that works as interface to multiple services. ESB is a
ACCEPTED MANUSCRIPT
message-oriented distributed integration bus that supports integration services for data/message handling, logging & auditing of data, underlying protocol support and security essence through well-defined interfaces.
CR IP T
This paper advises the successful utilization resources over network where ESB is deployed and act as mediator to interface services in an organized manner. It also presents the performance evaluation to monitor the different parameters like message count, active thread counts, request & response time, allotment heap memory. Testing for such parameters is done using two different open-source ESBs namely – AdroitLogic UltraESB and WSO2 ESB. Interaction of multiple services can be best handled by ESB as its supports varieties of interface (connector) to serve federated solution for interoperability, reusability and accessibility. This paper also deduces the mathematical formulation that build a relationship with successfully chance for getting interface during interaction between multiple services. This formulation is also extended to derive correlation for finding time computation complexity incurred in processing and loading of CPU data. It also reduces the overall computation time for processing and loading of CPU data once interface is recognized.
AN US
In future, this ESB architecture could be good solution for edge computing solutions where real-time streaming of data is needed. This ESB interface could be used for streaming data applications like sensor network, video data streaming, and weather forecasting, where recognition of service is important to data services.
REFERENCE
M
[1] Ferreira, A. Pereira, N. Rodrigues, J. Barbosa, & P. Leitao, Integration of an agent-based strategic planner in an enterprise service bus ecosystem, 13th IEEE International Conference on Proceedings of Industrial Informatics (INDIN 2013), pp. 1336-1341. [2] N. RajKumar, V. Vinod, Integrated Educational Information Systems for Disabled Schools via a Service Bus using SOA, Indian Journal of Science and Technology, 8 (13) (2015) 1-7.
ED
[3] S. Kumari, SK, Rath, Performance comparison of SOAP and REST based Web Services for Enterprise Application Integration, IEEE International Conference on Advances in Computing, Communications and Informatics (ICACCI 2015), pp. 1656-1660.
PT
[4] J. Yin, X. Lu, C. Pu, Z. Wu, H. Chen, JTangCSB: A cloud service bus for cloud and enterprise application integration. IEEE Internet Computing, 19 (1) (2015), 35-43
CE
[5] Negash, A.M. Rahmani, T. Westerlund, P. Liljeberg, H. Tenhunen, Lisa: lightweight internet of things service bus architecture, Procedia Computer Science, 52 (2015), 436-443.
AC
[6] T. Hedlund, Design and Proof-of-Concept Implementation of Proxy-based Stream Handling for an Enterprise Service Bus, [Master Thesis] Institutionen för datavetenskap (2104), Department of Computer and Information Science, Linköpings universitet, Sweden. [7] H. Chenhao, Design and Realisaton of Active-Active System for Enterprise Service Bus, Computer Applications and Software, 1 (2014) 1-27. [8] Orłowski, E. Szczerbicki, J. Grabowski, Enterprise service bus architecture for the big data systems. Management and Production Engineering Review, 5(1) (2014) 28-31. [9] G. Yu, Enterprise service bus and message processing method thereof. (2014) U.S. Patent No. 8,805,938.
ACCEPTED MANUSCRIPT
[10] L. González, J. L. Laborde, M. Galnares, M. Fenoglio, R. Ruggia, An adaptive enterprise service bus infrastructure for service based systems. Springer International Workshop on Service-Oriented Computing (ICSOC 2013) pp. 480-491. [11] W. He, L. Da Xu, Integration of distributed enterprise applications: a survey. IEEE Transactions on Industrial Informatics, 10(1) (2014) 35-42. [12] D. Lizcano, G. López, J. Soriano, J. Lloret, Implementation of end-user development success factors in mashup development environments, Computer Standards & Interfaces, 47 (2016) 1-18.
CR IP T
[13] P. M. Widener, Data Fusion as an Enterprise Service, IEEE International Conference on Services Computing (SCC 2014), pp. 838-839. [14] Pan, L. Zhang, Z. Wu, S. Li, L. Yang, M. Lin, Y. Shi, Pervasive Service Bus: Smart SOA Infrastructure for Ambient Intelligence, IEEE Intelligent Systems, 29 (4) (2014), 52-60. [15] W. H. Utomo, T. Wellem, The Implementation of Enterprise Service Bus (ESB) in Graduation Business Process Integration, Journal of Theoretical & Applied Information Technology, 62 (2) (2014) 364-370.
AN US
[16] S. T. Shenoy, A. Mohapatra, R. Swamy, A Multi-Dimensional Testing Approach for an ESB, International Journal of Software Engineering and Technology, 1 (2) (2014) 26-32. [17] S. G. Sáez, V. Andrikopoulos, F. Leymann, S. Strauch, Evaluating caching strategies for cloud data access using an enterprise service bus, IEEE International Conference on Cloud Engineering (IC2E 2014), pp. 289-294.
M
[18] A. Navarro, A. da Silva, A Metamodel-based definition of a conversion mechanism between SOAP and RESTful web services, Computer Standards & Interfaces, 48 (2016), 49-70.
ED
[19] Z. Siddiqui, A. S. Alghamdi, SOA based C4I common-view interoperability model. Journal Science International, 26(1) (2014) 175-180. [20] P. Lalanda, D. Morand, S. Chollet, Autonomic Mediation Middleware for Smart Manufacturing. IEEE Internet Computing, 21 (1) (2017), 32-39.
PT
[21] B. Hulse, C. P. Jackson, Adaptive enterprise service bus (ESB) runtime system and method. US Patent No. 8,570,905. (2013).
CE
[22] K. M. Mahmoud, A Unified Messaging-Based Architectural Pattern for Building Scalable Enterprise Service Bus, ACM International Conference on Information Integration and Web-based Applications & Services (IIWA 2013) p. 697.
AC
[23] T. Szydło, K. Zieliński, Adaptive enterprise service bus, Springer New Generation Computing, 30 (2-3) (2012), 189-214. [24] M. Psiuk, T. Bujok, K. Zielinski, Enterprise service bus monitoring framework for SOA systems, IEEE Transactions on Services Computing, 5(3) (2012), 450-466. [25] S. Strauch, V. Andrikopoulos, F. Leymann, D. Muhler, ESBMT: Enabling Multi-Tenancy in Enterprise Service Buses, 4th IEEE International Conference on Cloud Computing Technology and Science (CloudCom 2012), pp. 456-463. [26] A. Ouni, R.G. Kula, M. Kessentini, T. Ishio, D.M. German, K. Inoue, Search-based software library recommendation using multi-objective optimization, Information and Software Technology, 83 (2017) 5575.
ACCEPTED MANUSCRIPT
[27] L. Chen, Integrating cloud computing services using Enterprise Service Bus (ESB). Business and Management Research. 1 (1) (2012) 1-26. [28] L. González, J. L. Laborde, M. Galnares, M. Fenoglio, R. Ruggia, An adaptive enterprise service bus infrastructure for service based systems, Springer International Conference on Service-Oriented Computing (SoC 2013), pp. 480-491 [29] X. V. Wang, X. W. Xu, An interoperable solution for Cloud manufacturing. Robotics and computerintegrated manufacturing, 29 (4) (2013), 232-247.
CR IP T
[30] K. Mannaro, G. Destefanis, M. Di Francesco, The enterprise service bus as integration architecture in heterogeneous systems. 11th WSEAS international conference on Software Engineering, Parallel and Distributed Systems, and 9th WSEAS International Conference on Engineering Education, 2012, pp. 184187 [31] D. Muhler, Extending an open source enterprise service bus for multi-tenancy support focusing on administration and management, [Master Thesis] Institute of Architecture of Application Systems, University of Stuttgart, Germany (2012).
AN US
[32] K. G. Brown, R. D. Callaway, R. A. Robinson, A. F. Rodriguez, I. Viniotis, Protocol for enabling dynamic and scalable federation of enterprise service buses. U.S. Patent No. 8,095,670 (2012). [33] W. Roshen, Enterprise service bus with usb-like universal ports, In 9th IEEE European Conference on Web Services (ECOWS 2011), pp. 177-183. [34] E. B. Fernandez, N. Yoshioka, Two patterns for distributed systems: enterprise service bus (ESB) and distributed publish/subscribe, 18th ACM Conference on Pattern Languages of Programs (2011), p. 1-8.
M
[35] D. Morand, I. Garcia, P. Lalanda, Autonomic enterprise service bus, 16th IEEE Conference on Emerging Technologies & Factory Automation (ETFA 2011), pp. 1-8.
ED
[36] R Sheldon, A first course in probability. [Book] Pearson Education India 2002. [37] WSO2 ESB. Retrieved From: http://www.wso2.com/products/enterprise-service-bus/ [Viewed on 05.06.17]
AC
CE
PT
[38] Adroit Logic UltraESB. Retrieved From: http://www.adroitlogic.org/products/ultraesb.html [Viewed on 05.06.17] [39] D. Lavin, D. Jones, T. Landrum, Common adapter/connector architecture, U.S. Patent Application 09/734, 714, filed December 13, 2000. [40] L. J. Payne, M. Frederick Schulz, Java implementation of the batched iLab shared architecture, In IEEE 10th International Conference on Remote Engineering and Virtual Instrumentation (REV), 2013, p. 1‐3. [41] R. S. Bhadoria, N. S. Chaudhari, G. S. Tomar, The Performance Metric for Enterprise Service Bus (ESB) in SOA System: theoretical underpinnings and empirical illustrations for information processing, Information Systems, 65 (2017), 158-171. [42] P. Xu, W. Du, ERDSR: Efficient and Reliable Dynamic Service Routing in Enterprise Service Bus, In: 3rd IEEE International Conference on Intelligent System Design and Engineering Applications (ISDEA), (2013). p. 712 – 715. [43] B. Wu, S. Liu, L. Wu, Dynamic Reliable Service Routing in Enterprise Service Bus, In: IEEE Asia-Pacific Services Computing Conference, (2008) p. 349–354. [44] X. Bai, J. Xie, B. Chen, S. Xiao, DRESR: Dynamic Routing in Enterprise Service Bus, In: IEEE International conference on e-Business Engineering (ICEBE), (2007). p. 528–531. [45] K. A. Alam, R. Ahmad, A. Akhunzada, M. H. N. Md Nasira, S. U. Khan, Impact analysis and change propagation in service-oriented enterprises: A systematic review. Elsevier Information System, 54(2015): 43-73. [46] Apache ServiceMix 4.3 JBI, http://servicemix.apache.org/ [Viewed on 05.06.17]
Analyzing the Role of Interfaces in Enterprise Service Bus: A Middleware Epitome for Service-Oriented Systems Robin Singh Bhadoria , Narendra S. Chaudhari , Tharinda Nishantha Vidanagama PII: DOI: Reference:
S0920-5489(17)30052-1 10.1016/j.csi.2017.08.001 CSI 3228
To appear in:
Computer Standards & Interfaces
Received date: Revised date: Accepted date:
9 February 2017 13 June 2017 7 August 2017
Please cite this article as: Robin Singh Bhadoria , Narendra S. Chaudhari , Tharinda Nishantha Vidanagama , Analyzing the Role of Interfaces in Enterprise Service Bus: A Middleware Epitome for Service-Oriented Systems, Computer Standards & Interfaces (2017), doi: 10.1016/j.csi.2017.08.001
This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting proof before it is published in its final form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.
ACCEPTED MANUSCRIPT
Highlights
AC
CE
PT
ED
M
AN US
CR IP T
Investigate on software based interface through well-defined connectors available in Enterprise Service Bus (ESB). Discusses core design principle for ESB based Interface in facilitating middleware solution Comparison between non-ESB and ESB as interface usage in facilitating services over network/cloud. A mathematical formulation to driven the relationship between multiple services.
ACCEPTED MANUSCRIPT
Analyzing the Role of Interfaces in Enterprise Service Bus: A Middleware Epitome for Service-Oriented Systems Robin Singh Bhadoria Discipline of Computer Science & Engineering Indian Institute of Technology Indore, Madhya Pradesh, India [email protected]
Dept. of Computer Science & Engineering Visvesvaraya National Institute of Technology, Nagpur, Maharashtra, India [email protected]
Tharinda Nishantha Vidanagama
CR IP T
Narendra S. Chaudhari
AN US
Department of Computing & Information Systems, Faculty of Applied Sciences, Wayamba University of Sri Lanka, Kuliyapitiya, Sri Lanka [email protected]
ABSTRACT
ED
M
The modern era of computing is designed around service-oriented systems which integrates multiple services to deliver sophisticated services through well-known interfaces. It could efficiently be done by using features of Service-Oriented Architecture (SOA) like reusability, scalability and interoperability. SOA is an adaptive and flexible enough to acquire changes for dynamic environments but it is noted that it is limited with remote and distributed access to services in complex systems where interfaces are not recognized as common medium. This could be strengthened with adopting framework which not only meet such requirements but also provide varieties of interface between multiple services from different domains of applications. Enterprise Service Bus (ESB) is a middleware distributed kind of framework that extends the features of SOA systems and supports the deployment of end-to-end services through well-defined ‘interface’ called connector. The main contribution for this paper is building a deriving mathematical formulation that provide relationship with successfully chance for getting interface during interaction between multiple services. This paper also analysis and investigate the comparison for non-ESB and ESB as interface usage in facilitating services over networks.
PT
Keywords: Interface, service end-point, enterprise service bus, service integration, service-oriented architecture, Connector, middleware.
CE
1. INTRODUCTION
AC
Distributed computing can be termed as an IT service model/platform that provides on-demand or pay-per-use services over the internet. In today‟s modern era of computing, software architecture plays a vital role in delivering hassle free services across the networks. These services builds the business outline by supporting its client in significant manner to cumbersome requirement. The advancement of software technology was unable to keep up such requirements for dynamic business models and such requirements can only be completed through ESB. Here, ESB actually extends the feature of SOA system [13]. The most difficult issue is „interoperability‟ between multiple services which is also called Service integration in delivery and access of the service. This service integration means the amalgamation of multiple services on a common platform where it could exchange data and information through protocols. The second issue is “protocol conversion” between communicating services that support different underlying protocols. Such gaps could be bridged with the aid of ESB with its variety of connectors that forms welldefine interface to communicating with services from different domain of applications [1, 6].
ACCEPTED MANUSCRIPT
AN US
CR IP T
ESB is a middleware framework that supports the transport protocol conversion and message handing between multiple services. Usually, web services are deployed into component, called containers, which utilize the resource instance on-demand [7]. A “message” is a standardized format for exchanging information which might be containing a payload and header along with other attachments for data. This ESB framework is designed to transform messages and route it to its destination [42, 44]. It also extends the features for SOA which are reusability, scalability and service integration. The idea of ESB is related to Enterprise Application Integration (EAI) which not only envisioned the perception of service integration but also provide connectors that connecting different legacy application services to standard environment using service contract. This could be achieved through well-defined interface in ESB [10]. In traditional practices, service integration is achieved by point to point reconciliation. An individual platform is designed and developed to support each new application with the existing platform. This is an extremely tedious methodology and has to be replaced with a federated solution of service orchestration on common and shared platform. Service containers usually communicate with each other by sending messages and these messages need to be routed through a predefined path. ESB is efficient in handling such messages through wellknown dynamic routing algorithms. It supports in message authentication and validation during interaction between services. Security aspect uses digital signature and web service-security based authentication for better and assured delivery of messages in ESB. It also involves the access control on resources from their clients. ESB also act as a message based distributed integration bus for middleware solutions that provide interaction in distributed manner to build sophisticated, secure and reliable meditation [13].
AC
CE
PT
ED
M
ESB is designed to nurture integration methodology and handles resource provisioning between multiple services through interface. These containers are usually dynamic and plug-in to ESB [15]. The self-measurement principle of ESB to monitor and diagnose concurrent system resources is more efficient in delivering services across the networks. This efficiency could depend on multiple parameters that may influence the performance of cloud based ESB systems [4]. It is important to note that business interaction could be best implemented with essence of distributed behavior and dynamic need of services which is adaptable with ESB. It means that applications have to pursue certain rule to adapt to these new necessities.
Figure 1: Positioning of Enterprise Service Bus in relation to service components and infrastructural resources.
ESB supports a set of integration patterns which specifies the service recognition and message formats. Such a set of integration patterns are provided by each ESB manufacturer in the form of Enterprise Integration Patterns (EIP).
ACCEPTED MANUSCRIPT
During the communication between multiple services in the form of messaging, ESB helps in recognizing these message formats through known EIPs [8]. 1.1. NEED FOR ESB AS AN INTERFACE
AN US
CR IP T
An interface is a special kind of listener practice that have certain library classes which can utilize object contained in Java Messaging Service (JMS) message, SQL tables or some file. Establishing communication between multiple services need common platform which usually do not supported by simple SOA implementation that only provides the conversion of underlying protocols. ESB based interface also strengthen the connection between all invoked services. Such interfacing could be modeled with the aid of well-known „connectors‟ like J2EE connector [12] & [26]. ESB affords variety of connectors that offers message flows to connect and interact with from other services, e.g. Salesforce.com and twitter Inc. In fact, client can also create and customize the connectors according to their requirements. While creating and utilizing connectors, one has to add and enable it in the ESB instance for its full execution and functioning. This also facilitate the mediation between multiple services that resolves the issue of interoperability. Interoperability could be major hindrance in establishing interaction between client and services. This issue could be best handled with the help of interface in ESB through well-known connectors [26].
1.2. CREATING INTERFACE
M
An interface provide a mediation that offers platform through which interaction between client and legacy application could possible. This all could be possible with help of ESB. It also provide functionality and data to flow with ESB which connects to and interact through interface of legacy system like eBay, Salesforce Twitter and etc. This provide mediation through which message in ESB instance gets connect to receive data in the form of Spreadsheet [35]. These messages contains client information like name and password, log credentials for particular legacy application like Twitter account. Client can customize with the use of one or more connectors in aid to handle issue related to business demand.
PT
ED
A connector is a set of templates that describes the operations through which client can utilize and access specific business logic to execute messages [15]. This is a part to configure its ESB to established communication path between multiple services. Characteristically, connector is accustomed different APIs from external service and provide mediation to message flow. For example, ESB is initialize with a set of API which is termed as default connectors for any legacy application system like ebay, JIRA software and Twitter.
AC
CE
For creating interface using connector, following tasks are involved [18]: Customized desired set of APIs provided by the service provider like JIRA software support RESTful and Java API. For REST API, interface can be creates based on operations entirely which involves XML configuration files. Otherwise, Java API first create XML configuration files and then, proceed to Java classes which defines the operations. Use the connector core libraries to further define interface. After that, package all the files in a ZIP file which further can add to an ESB instance. There have been several files and sub-files associated with interface through connector. Each file has specific APIs to perform certain operations to produce desired task. One file could contains multiple sub files which defined by its component name and associated filter applied on it.
CR IP T
ACCEPTED MANUSCRIPT
Figure 2: List of file and sub-file for API call configuration in interface through connector
AN US
Here, pow.xml file as shown in figure 2, contains dependencies between connector core libraries and Synapse libraries along with associated „Maven‟ repositories. This could be for connector like JIRA Maven repositories along with its filter, template and icon files etc. Such dependencies are further shown in figure 5 as the dynamic mediation to support different connectors in ESB [14] & [34].
AC
CE
PT
ED
M
Figure 3: Java Script for component.xml file Here, component.xml file contains relevant information about different operation that could possible in particular category as shown in figure 3. This also presents the fact about different component for filters like
ACCEPTED MANUSCRIPT
CR IP T
Figure 4: Java Script for dependencies file.
AN US
Here, dependencies file depicts the mapping of one connector in relation to principal libraries and build a relationship to derive the operation between them. The connector.xml file describe the information regarding created and invoked connect along with its name, package usage and different category of operations which are indulge by that particular connector.
ED
M
PT
Figure 5: Java Script for API calling configurations
CE
While creating filters for connector as shown in Figure 5, template defines the calling sequence for APIs which also defines steps essentials to invoke API as configuration in connectors. The assemble-connector.xml file as shown in figure 2 is used have all associated instructions to create connector as zip archive. 1.3. SCIENTIFIC CONTRIBUTIONS
AC
This paper investigates and implements the issue related to ESB that supports varieties of interface as connectors. When services are delivered into non-interface environment where recognition of service could not be possible with simple, tightly-coupled and isolated service [12]. This generate the need of dynamic, reusable and federated environment where recognition and interaction is possible with message handling routing and protocol conversion features of ESB. The main contribution of this paper could be as follows: Primarily, ESB extends the features of SOA systems as it reuses the existing service module called – component, and integrate to deliver fast and accessible service across the network [7]. Service integration could be possible with variety of pattern which are provided as enterprise integration pattern (EIP) from manufacturer of each ESB company. These patters help in amalgamate different services from different domain of applications [3].
ACCEPTED MANUSCRIPT
An interface is a special kind of listener practice that has certain library classes which could be utilized different objects contained in structured table or JMS message. An interface helps in establishing communication through interaction between multiple services. This job of interface is usually carried out by connectors in ESBs [18, 24, 39]. A mathematical formulation is derived for building relationship between services and their interface. This also helps in understanding the concept of reuse and recycle in distributed computing for handling messages in interaction among services [28, 36]. It also deduce a relationship with successfully chance for getting interface during interaction process with services and helps in reducing overall computation time during such processing and loading of CPU. Finally, simulation is tested to investigate the importance of interface in service-oriented systems where integration of multiple services are performed in controlled environment of ESB and Non-ESB [6, 33].
CR IP T
2. RELATED WORK
AN US
Using interface, services could easily be interact and integrate with other services and this could possibly be best handled in ESB. It is important to note that service-oriented system could also implement the fundamentals of service integration but messaging during interaction among services could not be routing efficiently, organized managed and doesn‟t supports underlying protocols. All mentioned features are added in ESB and that does loose coupling, execute on plug-in mode with the multiple services [41]. In [4], Cloud based enterprise application integration approaches were analyzed and tested for concrete cloud service bus named as “JTangCSB”. It implements the practice for interfacing cloud based services that provides the storage for data in multitenancy-aware execution of services. This is limited approaches for handling cloud based services and provides partial connector/adaptor like SOAP web services.
ED
M
In [5], a lightweight service bus named- LISA, is proposed that supports heterogeneous and distributed services. It provides API called interface to support Internet of Things (IoT) platform and facilitates interoperability among multiple services. LISA build to serve embedded resources like sensor nodes which provides features of ESB. Java API could be created and implemented in this model but no provision for code optimization is identified. Data Authentication using checksum is implemented in LISA.
PT
In [17], a multi-tenant based ESB that support caching of data is proposed namely- cloud data access for ServiceMix (CDASMix) that enables accessibility of data transparently using well-known API - interface. This model is combination and extension for ESBMT [25] and Apache ServiceMix [46]. It supports Java Business Interface (JBI) for recognition of services from different domain of applications. It does not support GUI based client interaction and don‟t provide debugging toolset for analyzing flaw in service delivery.
AC
CE
In [25], an ESB that is based on multi-tenancy proposed namely- ESBMT which involves different services and utilizes multiple resources simultaneously. This model provides secure data authentication with its remote access that supports sophisticated GUI for interaction. It also supports different web interface with several administration and management clients via standardized interfaces provided by every ESB manufacturer. In [29], a cloud based manufacturing model is proposed namely – CManufacturing that supports on-demand access to multiple resources via network. This model is designed to semantic structuring of enterprise using APIs which implements the logic for service-oriented systems. It also comprises of production, implementation design, experimental and communication capabilities associated with data exchange during service execution. This model is capable for debugging and assessment for data through its client GUI. There could be several parameters for evaluating performance, efficiency and outcome for any service-oriented systems [2]. Different services need different interface (connectors) to facilitate interaction between them and could be improved with adding superfluous features like data authentication, code optimization, remote debugging,
ACCEPTED MANUSCRIPT
resource provisioning and interoperability. The above mentioned models are metaphorically compared in Table 1 that depicts the relationship between mentioned parameters. Table 1: Comparison for different domain-specific and general-purpose interface framework designs ESBMT
CManufacturing [29]
CDASMix [17]
LISA [5]
JTangCSB [4]
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
System Usability GUI based support
✓
✓
✘
✘
✘
Remote Coordinator
✓
✓
✘
✘
✘
Resource Provisioning Software Abstraction
✓
✘
✘
✘
✓
✓
✓
✘
✓
✘
✘
✘
✓
✘
✘
✓
✘
✘
✓
✓
AN US
ED
Debugging & Testing Tool System Efficiency Code Optimization & Validation Security Support Data Authentication
M
Interoperability Communication Protocol Support Connector Support
CR IP T
[25]
3. ESB INTERFACE AS A VIBRANT MIDDLEWARE SOLUTION
AC
CE
PT
The primary aim of ESB is to provide interaction between different clients and services. It must support the reusability of services published by another legacy application and this could be implemented with the help of welldefined interface [23]. This functionality also increase the reliability associated with distributed service which support different platforms through connectors. ESB provides multiple interface that facilitate monitor, develop and handle messages to interact and flow with other services in legacy applications. It enables the capability of recognizing and supporting different message formats via a set of known EIPs. In [30] & [35], discussion on multiple service integration from heterogeneous system using ESB architecture are made. This heterogeneous system is provided with critical programming methodology, which does not support an integrated development environment through interface. ESB must be designed in keeping parameters related with adaptability and common underlying protocols between multiple services [30]. There are several open-source ESBs existing in the market that offers features such as observability, agility and robustness with security authentications. The behavior of ESB is different from a conventional application server. Whenever, ESB is installed on a cloud based server, its performance could be measured on basis of time and space complexity. ESB also works as an interface for clients as well as service providers. Its performance could be assessed and compared to simple intermediaries like TCP/IP network routers for getting mutual dissimilarity in handling services. This is the reason, why every large organization is moving their architectural support towards ESB. It can be designed and developed using legacy environments like DotNet, Java Enterprise Edition through Java Messaging Services (JMS) [26].
ACCEPTED MANUSCRIPT
While picking an ESB product which exists in the market, numerous points need to be kept in mind and these points are important for performance and execution environment for SOA which include – costs related to installation, Return On Investment (ROI), planning & designing, documentation and features affecting operational infrastructural resources. These points build federated solutions to form QoS based parameterized analysis which could help consumer/client in ESB production selection [24].
AN US
CR IP T
Table 2: Attribute requirement for Interface configuration [18, 39, 40, 41] Attribute Required Description Endpoint class Yes Defines the name of your endpoint class like in endpoint references (EPR) which used to establish link between two different domains of application. Connector Yes Variety of connectors are provided by serving ESB, client could customize the connector with convenience. Default connector is initially mounted with ESB deploy. Template Yes Defines the calling sequence for APIs which also defines steps essentials to invoke API as configuration in connectors. Message Type No Message interface for connector. Initially not choose/customize, ESB would guess based on Endpoint classes. Transacted No Automatically, it set to true. Whether invoked message within the J2EE transaction.
PT
ED
M
It is important to note that interoperability scenario especially for those services which are not familiar with ESB environment could be best handled by adopting interface through connectors. Such interface are capable in transforming messages from known services to unknown services and vice-versa [23] & [25]. Table 2 depicts the interface requirement and its configuration that includes endpoint to establishes connection between two parties, election of connector, call sequence of API, type of message based on its end-point classes and invocation of J2EE connector in execution. EPR is simply justified as user device like PCs or equipment which are directly in connected to distributed network like service-oriented systems [17, 18]. If messages are coming from non-ESB clients, then ESB enables the interface to accept such messages and route it to corresponding destination. This all could be supported with endpoint references (EPR) which are collection of web services through components in ESB that too describes the resources handing in ESB [18].
3.1. CORE PRINCIPLE FOR ESB DESIGN
AC
CE
The core functionalities for an ESB depends on unique perspectives Service provider plays a vital role in delivering these functionality and must be committed to its service client as shown in Figure 6 [41]. There could be following principles on which ESB replies: a.
Transport protocol conversion: ESB helps in adaptability and understanding the under laying communication protocol that is governed by a particular application service. This feature of ESB provides connectivity with legacy systems to new modern computing systems [16].
b.
Mediation and Message transformation: This functionality translates message format between communication service components that is necessary to deliver federated service to different systems on common platform. This also supports inbound and outbound protocol transformation [21].
ACCEPTED MANUSCRIPT
Message routing: This is one of most striking features in ESB that changed the mood of market and business to shift their commerce through ESB. It enables the service provider to send its message through a designated path [43].
AC
CE
PT
ED
M
AN US
CR IP T
c.
Figure 6: Relationship of Infrastructural Resources and Web Service Consumers with ESB Middleware
d.
Message enhancement: This feature enables service provider to put additional or missing information needed at time of communication. It not only improves the communication overhead, but also categorizes demand at time of resource access. This is possible with the help of Enterprise Integration Pattern (EIP) that have been provided by every ESB manufacturer [44].
ACCEPTED MANUSCRIPT
Security Aspect: With this functionality, ESB could enable service providers to handle security parameters. Security should be featured on every web service for its integrity, confidentiality and availability of that particular web service. Information should not be disclosed via „connectors‟ used in computing systems which may be used by a malicious party during transaction process [25].
f.
Monitoring and management: This feature enables service provider to improve efficiency and flexibility by providing a monitoring tool in management console of a particular ESB. This is best supported by Java Management Extension (JMX). It is a powerful monitoring tool that helps a particular ESB in detecting mediation flaw, message flow, and trace the client pattern [15].
g.
Interface: This feature provides multiple interfaces to different versions of a service from multiple domain of applications. It also allows for multiple channels path to support underlying implementation for service integration. This requirement might involve multiple interfaces formats that could also support interface for web service standards like SOAP/XML, WSDL, etc [18].
h.
Direct proxy: This feature has the capability to transfer received messages into specific type of service that could help in building federated service. Several ESB products have been fitted with service proxy capabilities. Such capabilities makes it easier to integrate (federate) multiple systems in SOA [41].
AN US
CR IP T
e.
AC
CE
PT
ED
M
Workflow for services enables mediation through which communication could establish between client and service provider [6], [27] & [28]. Initially, service provide receive resource demand from client and it first check the availability for requested resource and response back with allotment of resource if available. With the help of connector, it links through ESB so that it supports all possible route for message delivery with potential route handler. This methodology is shown in Figure 7.
ACCEPTED MANUSCRIPT
Figure 7: Service workflow from Service Provider to client using ESB Interface Client could add properties to enhance their interface like jca-connector for java based system [20]. A message itself may contain information related to primitives such as integer, byte or a data structure such as an array, a record or an object. The command message and document message specifies the event occurrences between its sender and corresponding receiver [9], [21] & [22].
CR IP T
4. ESB INTERFACE WITH MATHEMATICAL EVALUATION To understand the concept of reuse and recycle in distributed computing paradigm for handling messages through interface, a mathematical formulation is beneficial to detail its fidelity and agility with service request-response methodology in ESB. The word „Reuse‟ in messaging governs with a piece of code that is used in implementing service integration via well-defined „interface‟. This methodology not only reduces the load of reforming message schema to each new arrived message, but also trims down the overhead involved in handling [19]. This could be evaluated with the help of mathematical probability of mass distribution function and with interface in the ESB; the cumulative distribution function could be expressed as [36]:
AN US
Yi1,2,.......,N
N p Yi i 1 p (Yi ) p (Yi1 Yi2 ) ..... i1 i2
.....
p(Y
i1
i1 i2 .....ik
Yi2 ........ Yik ) ....
M
i
Now, service,
will utilize by ' n ' service through well-known connector and that can be with probability of
PT
Yi
ED
... (1) N 1 p(Yi1 Yi2 ........ Yik )
n
CE
Therefore, p(Y ) N 1 i N
Also, for two different interface Yi and Yi which utilizes nth services with probability of:
AC
N 2 p(Yi1 Yi2 ) N
1
2
n
Same could be possible for general equation into different interface: N k p(Yi1 Yi2 ..... Yik ) N
n
For successful interface, above equation could be deduced as:
( N 1) N for
ACCEPTED MANUSCRIPT
N 1 N N 2 N N 3 N ... N 2 N 3 N n
n
n
n N 1 ..... (1) N 1 N N
(Eq. 1)
N 1 N N i i 1 (1) i 1 i N n
CR IP T
(Eq.2)
AN US
It is interested to note that ESB must possessed with policy in order to provide the guidelines to its client for secure use. This must be a part of service contract that must be followed by clients for best manageability, accessibility and observability of its services. However, such policies need thorough consideration of ESB requirement with its features. Several experts are doing their research to reconnoiter the quality perspective for ESB and could benefit the society in selecting best available ESB. Determining the service interaction through well-defined interface is a significant architectural verdict that could be adopted by researchers in order to align the need for business goals [3] & [29]. Therefore, simulation of these available ESBs is important to segregate parametric evaluation on cloud based systems.
5. CLOUD BASED PARAMETRIC ANALYSIS FOR ESB INTERFACE
ED
M
The goal of this paper is to investigate and analyze cloud based ESB performance through connectors as interface to facilitate services. This implementation is done on Window 7 with AMD x64 architecture by installing different ESB at remote cloud location. Parameter analysis on received and sent messages, time of execution, overall bytes utilized, message counts, and memory utilization is performed. These ESBs mediate service flow at remote cloud servers. Results were tested using two open source ESBs – Adroit UltraESB and WSO2 ESB.
PT
AdroitLogic UltraESB is full and light-weight open source ESB that provides multiple message/data formats and transport protocol conversions. UltraESB supports “Zero-Copy proxy” service which ensures its delivery to its designated network with non-blocking I/O capabilities. It also enables with WS-Security and features to build ESB with dynamically loading (reloading) & deployment of services across the networks with well-defined connectors (interface) [38].
AC
CE
WSO2 ESB is an open source ESB that provides better compatibility and high performance in terms of service accessibility. This may be the finest option in the available class of ESBs as it supports almost all variety of connectors in ESB with multiple service stack support like - Service governance, monitoring and management, virtual environment and many more. According to eBay Inc., for online shopping, it uses WSO2 Enterprise Service Bus for executing and processing transactions, which is more than 1 billion per day [37]. Message count in ESB briefs about the total number of sent and received messages during interaction among multiple service components. Messaging is a strong parameter that enables the communication between distributed co-located services. This interaction supports in delivering end-to-end services through messaging across the network. It also justifies the message counts which include success and failure of these messages at remote ends [9]. The minimum time period to process these messages could be calculated using mathematical formulations as depicted below:
ACCEPTED MANUSCRIPT
Atr
Atr 1 (r 1) tr r
(Eq. 3)
Here,
r is number of messages, i.e. Total message count.
tr is time taken to process the rth message through proper mediation channel.
CR IP T
Atr is average time to process each byte that have been used in messaging.
AN US
While enabling interaction between multiple services, data transfer is mediated through ESB with time computation complexity and such data represents the state, value and behavior of a particular service using distribution function as mentioned above. This build a relationship with successfully chance for getting interface during interaction between these services. It also helps in reducing overall computation time for processing and loading of CPU data [6]. Here, Equation 2 and Equation 3 are interrelated as one is depended on other. For example, if chance for getting successful interface is higher, then time computation for processing would be lesser. Each service has its well defined pattern format and these patterns are provided by ESB manufacturer that develop and design service component architecture. Service integration is possible due to these patterns and it supports the messaging between multiple services over cloud [4] & [17].
3500
Memory Allocated Non-ESB Interface ESB Interface
M
2500
ED
2000
1500
1000
PT
Memory Allocated (Mega Bytes)
3000
500
CE
0
12:10
12:25
12:40
12:55
01:10
01:25
01:40
Time (Hour : Minutes)
AC
Figure 8: Shows statistics for used and allocated memory in regards to time for WSO2 ESB.
Memory is always a crucial matter of concern in terms of execution and overall processing of messages. This is monitored by “heap memory” section in ESB framework. Figure 8 depicts the statistics for such memory assignment and usage with respect to unit of time [22]. The allocated memory to system is used in handling resources, creating instances and buffer requests from different clients. ESB plays important role in this scenario which almost utilizes nearly half memory as compared to non-ESB solutions. This is implemented using WS02 ESB and for non-ESB interface like simple SOA [23]. Table 3: Statistics for WSO2 ESB
ACCEPTED MANUSCRIPT
Total Message Count Total Fault Count Maximum Response Time Minimum Response Time Average Response Time Memory Allocation
581 581 576 0 62 ms 8 ms 19.594 ms 498.50 MB 248.02 MB
Description Number of request made by multiple service components Number of response made to corresponding request Communication Messages float among service components Gives the failure count Maximum time incurred in process and response back Minimum time incurred in process and response back Average time incurred in process and response back Total allotment of memory Actual Usage of Memory
AN US
Memory Usage
Value
CR IP T
Parameters Total Request Count Total Response Count
There are different parameters which need to be analyzed whenever any service component request access to a particular resource instance. This scenario is well depicted in Table 3 for WSO2 ESB that involves the monitoring of several parameters like total message count, total request/response time, time incurred in response to a particular message and most important part is memory assignment [32] & [33].
PT
ED
M
The same pedagogy is experimented with Adroit Logic UltraESB that displayed in Table 4. This follows Open Service Gateway initiative (OSGi) specification as mentioned in Apache ServiceMix integration platform. It also supports Java Business Integration (JBI). This UltraESB also experiments to find “Daemon Thread Counts” that determine supporting tasks for providing services to the user threads at background. It is not dependent on provider‟s server thread and its life span is associated with user thread completion. This is the reason why JVM dismisses the daemon thread when no user thread is determined.
Table 4: Experimental Statistics for Adroit Logic Ultra ESB
CE
Parameters
Value 429
Message Count (Failed) Message Count (Total)
0 429
Active Threads Counts
46
Daemon Thread Counts
8
Minimum Response Time
6 ms
Average Response Time
15 ms
Maximum Response Time
240 ms
Memory Allocation
700.55 MB
AC
Message Count (Successful)
Description Communication Messages float among service components Number of failed Messages Total number of messages Supports in concurrency and integration of services Background supporting tasks Minimum time incurred in process and response back Average time incurred in process and response back Maximum time incurred in process and response back Total allotment of memory
ACCEPTED MANUSCRIPT
Memory Usage
243.65MB
Actual Usage of Memory
Figure 9: Show statistics for average loading of CPU (in percentage)
AN US
Non-ESB Interface ESB Interface
140
100
80
60
40
20 12:25
12:40
12:55
01:10
01:25
M
Load Average (%)
120
12:10
CR IP T
CPU load is calculated to justify the performance of ESB. The average load is summarized for all the requests and responses made for service interaction through interface. The distributed system determines the load information using CPU queue length and load balancing techniques. Figure 9 depicts the average load of CPU varies between from 100% to 150% bearing capacity that ensure the performance of system in delivering service using UltraESB. Here, ESB Interface works better as compared to non-ESB interface which are implemented using simple SOA features. With non-ESB interface, there is steep growth in CPU loading and this continues to global and local maxima, but ESB interface get stabilizes after specified time. This shows ESB interface could better handle services over network/cloud [31].
01:40
ED
Time (Hour : Minutes)
CE
PT
Work presented in [2], focuses on service accessibility for disabled school that supports service architecture to improve its fidelity with neighboring environment. When such interaction is occurred between multiple service components, data has to be carried into some formatted file. These files are created to handle data and can be cached for better communication. File cache gives the number of files created by particular instance using UltraESB. This functionality is facilitated by well-known connectors which is supported by ESB over network/cloud. This is well depicted in Figure 10 in which file cache count goes up to maximum of 80,000 for non-ESB interface and count got stable for ESB interface after approx. 57,400 files
AC
Figure 10: Show statistics for overall file cache usage
ACCEPTED MANUSCRIPT
Non-ESB Interface ESB Interface
60000
40000
20000
CR IP T
File Cache Usage (Count)
80000
0
12:10
12:25
12:40
12:55
01:10
01:25
01:40
Time (Hour:Minutes)
M
AN US
ESB supports Java Virtual Machine (JVM) that is based on File usage from cache memory. This cache usage also avoid garbage collection of files in heap memory that occurred due to overwhelming generation of messages. This helps in improving performance and reliability of cloud based systems [19]. When processing multiple messages simultaneously, runtime (heap) memory is needed to maintain the concurrency of threads. This all could be implemented through ESB interface that remediate the effect of heap exhaust. This is well depicted in Figure 11 that shows allocated heap memory from 500 MB to 700 MB. It also presents the fact that services which are handling using UltraESB, are stable after specific period of time and whereas non-ESB interface need increasing heap storage as shown in black line.
688
Non-ESB Interface ESB Interface
PT
602 559 516 473 430
CE
Heap Usage (Mega Bytes)
645
ED
Figure 11: Shows statistics for heap memory usage.
AC
12:10
12:25
12:40
12:55
01:10
01:25
01:40
Time (Hour:Minutes)
CONCLUSION & FUTURE PLAN Interface provide convenient solutions for problem associated with interoperability in services integration for service-oriented systems. ESB supports the variety of interface through well-defined “connector” like J2EE which plays important role in handling data for legacy applications. Connectors are design to support flexibility and reusability of services and enables ESB to unleash with business processes migration. This paper investigate and analyze the services through different connectors in ESB that works as interface to multiple services. ESB is a
ACCEPTED MANUSCRIPT
message-oriented distributed integration bus that supports integration services for data/message handling, logging & auditing of data, underlying protocol support and security essence through well-defined interfaces.
CR IP T
This paper advises the successful utilization resources over network where ESB is deployed and act as mediator to interface services in an organized manner. It also presents the performance evaluation to monitor the different parameters like message count, active thread counts, request & response time, allotment heap memory. Testing for such parameters is done using two different open-source ESBs namely – AdroitLogic UltraESB and WSO2 ESB. Interaction of multiple services can be best handled by ESB as its supports varieties of interface (connector) to serve federated solution for interoperability, reusability and accessibility. This paper also deduces the mathematical formulation that build a relationship with successfully chance for getting interface during interaction between multiple services. This formulation is also extended to derive correlation for finding time computation complexity incurred in processing and loading of CPU data. It also reduces the overall computation time for processing and loading of CPU data once interface is recognized.
AN US
In future, this ESB architecture could be good solution for edge computing solutions where real-time streaming of data is needed. This ESB interface could be used for streaming data applications like sensor network, video data streaming, and weather forecasting, where recognition of service is important to data services.
REFERENCE
M
[1] Ferreira, A. Pereira, N. Rodrigues, J. Barbosa, & P. Leitao, Integration of an agent-based strategic planner in an enterprise service bus ecosystem, 13th IEEE International Conference on Proceedings of Industrial Informatics (INDIN 2013), pp. 1336-1341. [2] N. RajKumar, V. Vinod, Integrated Educational Information Systems for Disabled Schools via a Service Bus using SOA, Indian Journal of Science and Technology, 8 (13) (2015) 1-7.
ED
[3] S. Kumari, SK, Rath, Performance comparison of SOAP and REST based Web Services for Enterprise Application Integration, IEEE International Conference on Advances in Computing, Communications and Informatics (ICACCI 2015), pp. 1656-1660.
PT
[4] J. Yin, X. Lu, C. Pu, Z. Wu, H. Chen, JTangCSB: A cloud service bus for cloud and enterprise application integration. IEEE Internet Computing, 19 (1) (2015), 35-43
CE
[5] Negash, A.M. Rahmani, T. Westerlund, P. Liljeberg, H. Tenhunen, Lisa: lightweight internet of things service bus architecture, Procedia Computer Science, 52 (2015), 436-443.
AC
[6] T. Hedlund, Design and Proof-of-Concept Implementation of Proxy-based Stream Handling for an Enterprise Service Bus, [Master Thesis] Institutionen för datavetenskap (2104), Department of Computer and Information Science, Linköpings universitet, Sweden. [7] H. Chenhao, Design and Realisaton of Active-Active System for Enterprise Service Bus, Computer Applications and Software, 1 (2014) 1-27. [8] Orłowski, E. Szczerbicki, J. Grabowski, Enterprise service bus architecture for the big data systems. Management and Production Engineering Review, 5(1) (2014) 28-31. [9] G. Yu, Enterprise service bus and message processing method thereof. (2014) U.S. Patent No. 8,805,938.
ACCEPTED MANUSCRIPT
[10] L. González, J. L. Laborde, M. Galnares, M. Fenoglio, R. Ruggia, An adaptive enterprise service bus infrastructure for service based systems. Springer International Workshop on Service-Oriented Computing (ICSOC 2013) pp. 480-491. [11] W. He, L. Da Xu, Integration of distributed enterprise applications: a survey. IEEE Transactions on Industrial Informatics, 10(1) (2014) 35-42. [12] D. Lizcano, G. López, J. Soriano, J. Lloret, Implementation of end-user development success factors in mashup development environments, Computer Standards & Interfaces, 47 (2016) 1-18.
CR IP T
[13] P. M. Widener, Data Fusion as an Enterprise Service, IEEE International Conference on Services Computing (SCC 2014), pp. 838-839. [14] Pan, L. Zhang, Z. Wu, S. Li, L. Yang, M. Lin, Y. Shi, Pervasive Service Bus: Smart SOA Infrastructure for Ambient Intelligence, IEEE Intelligent Systems, 29 (4) (2014), 52-60. [15] W. H. Utomo, T. Wellem, The Implementation of Enterprise Service Bus (ESB) in Graduation Business Process Integration, Journal of Theoretical & Applied Information Technology, 62 (2) (2014) 364-370.
AN US
[16] S. T. Shenoy, A. Mohapatra, R. Swamy, A Multi-Dimensional Testing Approach for an ESB, International Journal of Software Engineering and Technology, 1 (2) (2014) 26-32. [17] S. G. Sáez, V. Andrikopoulos, F. Leymann, S. Strauch, Evaluating caching strategies for cloud data access using an enterprise service bus, IEEE International Conference on Cloud Engineering (IC2E 2014), pp. 289-294.
M
[18] A. Navarro, A. da Silva, A Metamodel-based definition of a conversion mechanism between SOAP and RESTful web services, Computer Standards & Interfaces, 48 (2016), 49-70.
ED
[19] Z. Siddiqui, A. S. Alghamdi, SOA based C4I common-view interoperability model. Journal Science International, 26(1) (2014) 175-180. [20] P. Lalanda, D. Morand, S. Chollet, Autonomic Mediation Middleware for Smart Manufacturing. IEEE Internet Computing, 21 (1) (2017), 32-39.
PT
[21] B. Hulse, C. P. Jackson, Adaptive enterprise service bus (ESB) runtime system and method. US Patent No. 8,570,905. (2013).
CE
[22] K. M. Mahmoud, A Unified Messaging-Based Architectural Pattern for Building Scalable Enterprise Service Bus, ACM International Conference on Information Integration and Web-based Applications & Services (IIWA 2013) p. 697.
AC
[23] T. Szydło, K. Zieliński, Adaptive enterprise service bus, Springer New Generation Computing, 30 (2-3) (2012), 189-214. [24] M. Psiuk, T. Bujok, K. Zielinski, Enterprise service bus monitoring framework for SOA systems, IEEE Transactions on Services Computing, 5(3) (2012), 450-466. [25] S. Strauch, V. Andrikopoulos, F. Leymann, D. Muhler, ESBMT: Enabling Multi-Tenancy in Enterprise Service Buses, 4th IEEE International Conference on Cloud Computing Technology and Science (CloudCom 2012), pp. 456-463. [26] A. Ouni, R.G. Kula, M. Kessentini, T. Ishio, D.M. German, K. Inoue, Search-based software library recommendation using multi-objective optimization, Information and Software Technology, 83 (2017) 5575.
ACCEPTED MANUSCRIPT
[27] L. Chen, Integrating cloud computing services using Enterprise Service Bus (ESB). Business and Management Research. 1 (1) (2012) 1-26. [28] L. González, J. L. Laborde, M. Galnares, M. Fenoglio, R. Ruggia, An adaptive enterprise service bus infrastructure for service based systems, Springer International Conference on Service-Oriented Computing (SoC 2013), pp. 480-491 [29] X. V. Wang, X. W. Xu, An interoperable solution for Cloud manufacturing. Robotics and computerintegrated manufacturing, 29 (4) (2013), 232-247.
CR IP T
[30] K. Mannaro, G. Destefanis, M. Di Francesco, The enterprise service bus as integration architecture in heterogeneous systems. 11th WSEAS international conference on Software Engineering, Parallel and Distributed Systems, and 9th WSEAS International Conference on Engineering Education, 2012, pp. 184187 [31] D. Muhler, Extending an open source enterprise service bus for multi-tenancy support focusing on administration and management, [Master Thesis] Institute of Architecture of Application Systems, University of Stuttgart, Germany (2012).
AN US
[32] K. G. Brown, R. D. Callaway, R. A. Robinson, A. F. Rodriguez, I. Viniotis, Protocol for enabling dynamic and scalable federation of enterprise service buses. U.S. Patent No. 8,095,670 (2012). [33] W. Roshen, Enterprise service bus with usb-like universal ports, In 9th IEEE European Conference on Web Services (ECOWS 2011), pp. 177-183. [34] E. B. Fernandez, N. Yoshioka, Two patterns for distributed systems: enterprise service bus (ESB) and distributed publish/subscribe, 18th ACM Conference on Pattern Languages of Programs (2011), p. 1-8.
M
[35] D. Morand, I. Garcia, P. Lalanda, Autonomic enterprise service bus, 16th IEEE Conference on Emerging Technologies & Factory Automation (ETFA 2011), pp. 1-8.
ED
[36] R Sheldon, A first course in probability. [Book] Pearson Education India 2002. [37] WSO2 ESB. Retrieved From: http://www.wso2.com/products/enterprise-service-bus/ [Viewed on 05.06.17]
AC
CE
PT
[38] Adroit Logic UltraESB. Retrieved From: http://www.adroitlogic.org/products/ultraesb.html [Viewed on 05.06.17] [39] D. Lavin, D. Jones, T. Landrum, Common adapter/connector architecture, U.S. Patent Application 09/734, 714, filed December 13, 2000. [40] L. J. Payne, M. Frederick Schulz, Java implementation of the batched iLab shared architecture, In IEEE 10th International Conference on Remote Engineering and Virtual Instrumentation (REV), 2013, p. 1‐3. [41] R. S. Bhadoria, N. S. Chaudhari, G. S. Tomar, The Performance Metric for Enterprise Service Bus (ESB) in SOA System: theoretical underpinnings and empirical illustrations for information processing, Information Systems, 65 (2017), 158-171. [42] P. Xu, W. Du, ERDSR: Efficient and Reliable Dynamic Service Routing in Enterprise Service Bus, In: 3rd IEEE International Conference on Intelligent System Design and Engineering Applications (ISDEA), (2013). p. 712 – 715. [43] B. Wu, S. Liu, L. Wu, Dynamic Reliable Service Routing in Enterprise Service Bus, In: IEEE Asia-Pacific Services Computing Conference, (2008) p. 349–354. [44] X. Bai, J. Xie, B. Chen, S. Xiao, DRESR: Dynamic Routing in Enterprise Service Bus, In: IEEE International conference on e-Business Engineering (ICEBE), (2007). p. 528–531. [45] K. A. Alam, R. Ahmad, A. Akhunzada, M. H. N. Md Nasira, S. U. Khan, Impact analysis and change propagation in service-oriented enterprises: A systematic review. Elsevier Information System, 54(2015): 43-73. [46] Apache ServiceMix 4.3 JBI, http://servicemix.apache.org/ [Viewed on 05.06.17]