Open Source Enterprise Service Bus Research Articles

Development of Middleware Applied to Microgrids by Means of an Open Source Enterprise Service Bus

The success of the smart grid relies heavily on the integration of Distributed Energy Resources (DERs) and interoperability among the hardware elements that are present as part of either the smart grid itself or in a smaller size deployment, such as a microgrid. Therefore, establishing an accurate design for software architectures that guarantee interoperability and are able to abstract hardware heterogeneity in this application domain, along with a clearly defined procedure on how to implement and test a solution like this, becomes a desirable objective. This paper describes the requirements needed to design a secure, decentralized and semantic middleware architecture for microgrids and the procedures used to develop it, so that the mandatory software components that have to be encased by the solution, as well as the steps that should be followed to make it happen, become clear for any designer, software architect or programmer that has to tackle similar challenges. In order to demonstrate the usability of the ideas put forward here, two successful pilots where middleware solutions were created according to these principles have been described.

Building integrated business environments: analysing open-source ESB

Integration and interoperability are two concepts that have gained significant prominence in the business field, providing tools which enable enterprise application integration (EAI). In this sense, enterprise service bus (ESB) has played a crucial role as the underpinning technology for creating integrated environments in which companies may connect all their legacy-applications. However, the potential of these technologies remains unknown and some important features are not used to develop suitable business environments. The aim of this paper is to describe and detail the elements for building the next generation of integrated business environments (IBE) and to analyse the features of ESBs as the core of this infrastructure. For this purpose, we evaluate how well-known open-source ESB products fulfil these needs. Moreover, we introduce a scenario in which the collaborative system ‘Alfresco’ is integrated in the business infrastructure. Finally, we provide a comparison of the different open-source ESBs available for IBE requirements. According to this study, Fuse ESB provides the best results, considering features such as support for a wide variety of standards and specifications, documentation and implementation, security, advanced business trends, ease of integration and performance.

Enterprise Service Bus: A Performance Evaluation

The flexibility offered by an Enterprise Service Bus (ESB) in enabling various applications to exchange data makes it a very important middleware layer that is responsible for transporting data in a Service-Oriented Architecture (SOA). The popularity of the ESB has given rise to a number of commercial off the shelf (COTS) products as well as open source ESBs. In this study, we evaluated three open source ESBs and compared them both qualitatively and quantitatively. The empirical results were statistically tested to determine the statistical significance of the results.

The Health Service Bus: an architecture and case study in achieving interoperability in healthcare.

Interoperability in healthcare is a requirement for effective communication between entities, to ensure timely access to up to-date patient information and medical knowledge, and thus facilitate consistent patient care. An interoperability framework called the Health Service Bus (HSB), based on the Enterprise Service Bus (ESB) middleware software architecture is presented here as a solution to all three levels of interoperability as defined by the HL7 EHR Interoperability Work group in their definitive white paper "Coming to Terms". A prototype HSB system was implemented based on the Mule Open-Source ESB and is outlined and discussed, followed by a clinically-based example.

How a service-oriented architecture may change the software development process

Introduction Software development practices have evolved substantially during the past decade. As so called "agile" approaches have gained more acceptance and applications have become progressively more distributed in terms of their physical execution and the development of components, the service-oriented approach to IT architecture has become an important alternative to traditional software development. Another impetus for the trend to a Service-Oriented Architecture (SOA) is provided by enterprise system vendors as they are incorporating the service-oriented paradigm into their products. Substantial efforts related to open standards (such as Web service standards) and open source products (such as open source enterprise service bus, development tools) are further driving a service-oriented approach for information systems. A key question is whether SOA adopters are going to be ready for this change and whether they can provide a technical and an organizational environment in which SOA-related technologies can be leveraged to their full potential. There is some indication that currently this may not be the case. In fact, some organizations that have embarked on SOA-related projects early have experienced disappointments. As with other technology waves, the important question is not whether SOA is inherently a good or a bad idea, but rather how it can be done right in a given context. This article tries to answer this question with respect to the software development process. While much of the literature, both in academia and industry, has focused on business implications of SOA, technological realization, architectural issues, and implementation guidelines, few publications have addressed the impact of SOA on the software development process and its methodology. As with any organizational change, modifications to software development processes or practices entail switching cost. Therefore, individuals as well as organizations are inclined to stay with "proven" methodologies, although adjustments based on task requirements and technology characteristics should be key drivers for the methodology choice and are needed to help adopters leverage the full potential of SOA. This article examines the differences and discusses which parts of development process and methodology may require adjustments to effectively leverage a SOA. It presents the results of a field study suggesting changes to software development practices that are necessary to accommodate the unique properties of the service-oriented approach.

Open Source ESB in Action

The author provides a book review of Open Source ESB in Action. This book as one of a few sources of information for IT architects as well as integration developers who wish to use an open source Enterprise Service Bus (ESB). The book provides the introduction to the two open source ESB’s - Mule and Service Mix ESBs - with plenty of examples. In this review we looked at the following points: 1. How the architecture of the ESBs and processing environment are treated, 2. Is the robustness or lack of it highlighted for both products, 3. Are there pointers to appropriate tooling for developers and, 4. Are there pointers and references to the on-line documentation

A multi-language service-oriented architecture using an enterprise service bus

An Enterprise Service Bus (ESB) provides developers a platform for the straightforward development of a multi-language Service-Oriented Architecture (SOA). Mule, an open source ESB, is presented as one such ESB that easily provides a multi-language SOA integration solution. This paper offers a Mule 1.4 ESB configuration allowing the communication between web services written in Java and Ada running on the Ada Web Server as an example. Additionally, the example demonstrates the use of SOAP and REST style messages within the SOA environment.