Michel Habert is a Senior Information Systems Consultant at Bull Services & Solutions. Michel obtained his degree at Supélec (Ecole Supérieure d’Electricité), a leading French engineering ‘grande école’ (university), and went on to obtain a PhD. He specializes in Service-Oriented Architectures (SOA) and associated technologies (SCA, ESB, Web Services).
In today’s open world, information systems flexibility is becoming an essential component of strategic advantage. This is leading many businesses to adopt an IT strategy built around a structure dividing into a number of major application and business services that are easily combinable and interoperable.
Nevertheless, to guarantee the success of this strategy, they need to be able to configure, connect and administer these services rapidly, whilst maintaining operational profitability.
Service-Oriented Architectures (SOA) are a new architectural model for applications designed to ensure that information systems are responsive, flexible and easy to run, to streamline deployments, and align technical solutions and business processes. Services are made available via interfaces that enable modular application software processing functions to be accessed and run.
The objective of an Enterprise Services Bus (ESB) is to provide the infrastructure needed to make technical and application-based services available – in a fully integrated and standards-based way – for the entire enterprise information system, or multi-enterprise ecosystem.
Following on seamlessly from the Enterprise Application Integration (EAI) concept, the ESB started to become popular at the end of the 1990s. Today, the approach is going much further towards providing simplification mechanisms – even if it does remain somewhat complex – and basing itself on Web services, application connectors, the XML language, transformation and intelligent message routing, and other standards. It’s the result of a professional and structured approach, which has resulted in lower implementation costs.
The advantages ESB brings are many and tangible: more effective application software integration, the possibility of multiplying access and operational modes, lower maintenance and development costs, better system performance, and many more.
The main areas of the ESB
What are the main components of an ESB? The leading ISV’s system integration suites all consist of six main areas:
Registry and repository
At the centre of the ESB, the registry and repository facilitate the management and implementation of, and access to, services; the administration of their life cycle and related tasks such as version handling, user notification about changes, and system governance through policy management. An integrated and standard solution is the ideal one when it comes to interoperability with several registries and repositories that will appear as a single virtual element.
The standards are currently ebXML (registry and repository) and UDDI (registry), under the overall umbrella of the ebXML registry standard.
The integrated development environment is an important plus point for the ESB because of its capacity to ensure in-build flexibility and responsiveness within the information system. This is the area that manages and facilitates, via IDE consoles, the development, integration, testing, deployment and lifecycle of services.
The systems management of SOA architectures is focused predominantly towards the functional rather than the technical. Technology must align itself to business processes, so that the information system’s ability to react to change becomes a reality.
The centralized management and administration system is essential to this governance: it is both functional and technical, automated by processes, preferably event-driven, and provides feedback via ‘dash-boards’ and regular status reports. Depending on the software publisher, the management systems can be integrated within the ESB suite or supplied as an external component, but in every case the ESB will be offered with such a system.
The security system is constructed around policies and processes, and can be deployed across a range of different organizations (for example, to enable identity federation). This tool is fundamental to governance, and must align with the relevant regulations (such as Sarbanes-Oxley). An ESB has its own individual security profile, so it can handle the risks to which it is likely to be exposed and to the needs of user security. It must have in-built mechanisms for handling network security, vulnerability management, content security, and identity and access management.
Workflow reduces coding in applications by enabling them to offload application code into behavioral code. It can be supported by a rules engine, to offload application code from business intelligence code. The workflow will also appear at the application software level of management and security systems, which execute processes that are increasingly event driven.
Orchestration of processes goes beyond the framework of application orchestration of Web services. An ESB contains an internal orchestration mechanism for the technical services involved in composing data flows. The aim is to ensure that the technical elements are as flexible and agile as the functional ones. The final objective is to be able to omit the programming stage altogether, composing data flows using a graphic console. In this area, we again encounter the unique aim of the SOA, to align technical and business aspects, and increase responsiveness whilst unifying the mechanisms.
Integration and transport
Component integration is achieved via a service bus acting as an interface, and standardizing messaging exchanges between integrated components. The components are of two types: either they provide operational or technical services, or they are connectors responsible for exchanges with the exterior: external services, mainframes, customers (humans or computer programs).
Exchanges reduction and standardization via a service bus
Transport, finally, plays an important role because it handles distribution when deploying a system on IP networks of the Intranet, Extranet, or Internet type. It also ensures scalability, by simply increasing the number of service buses to absorb the load, or to facilitate modular functional processing.
Reliability, performance, and service continuity – which in turn depend on persistence management, transaction support, load sharing and high availability – are all essential. An ESB supports different types of message-oriented transport: synchronous or asynchronous (MOM) with an event-driven publish/subscribe mode corresponding to strong, weak or zero coupling types between the communicating entities. Weak and zero couplings are the ideal ones for an ESB.
Note that the bus doesn’t just transport messages. It also provides intelligent routing services based on content and mediation services (translations and transformations). These services facilitate exchanges between components using different types of access and data formats. So a Cobol application that uses a structured messaging format plus MQSeries as its messaging system can communicate with the EJB of a Java application that handles data in XML format and uses JMS as messaging system. The construction of this type of flow taken together with its heterogeneous messaging systems, plus mediation for translating protocols and transforming Cobol data into XML and vice versa, will be performed without any need for coding, but with the aid of a graphic console.
Deploying an ESB: what are the alternatives? What are the current trends?
Faced with a growing need for IS flexibility, the ESB is developing rapidly. According to Gartner, more than half of large companies will have an ESB up and running by the end of 2006. Publishers and system integrators are not wasting any time: most of them have incorporated the ESB within their core range. Pioneer publishers like Axway, BEA, Cape Clear, Fiorino, Iona, Sonic Software, SeeBeyond, Tibco or Web Methods, have been joined by the major enterprise application publishers such as Oracle, SAP, IBM and others.
Players from the open systems world – including Apache, Codehaus, JBoss and ObjectWeb – are also entering this domain in force, with solutions such as Celtix, Mule, Petals, ServiceMix, Synapse and others, that are not only reliable and inexpensive, but also offer great flexibility to be adapted thanks to the free availability of code.
Confronted with multiple choices, enterprises can select integrated turnkey published solutions, or shop around to select individual components. There is a high degree of freedom that favors interoperability of numerous elements, and which can sometimes allow a ‘best of breed’ approach for certain domains. For example, the registry produced by SYSTINET is aligned with the UDDI standard, and is a benchmark in this area, distributed under OEM agreements by several publishers. In the same way, the current state of the art when it comes to integrated development environments (IDEs) is based on ECLIPSE, with plug-ins covering the whole range of technical and business service requirements. WTP (Web Toolkit Platform) and STP (SOA Toolkit Platform) are examples of IDEs from the open systems world. Finally, as we have seen, Open Source components are beginning to offer attractive alternatives.
So how do you choose between them? Over and above the technical parameters individual to each project and each context, there are two particularly important factors to consider: openness and interoperability. The rise in power of Open Source bears this out, even if free software solutions are still lagging behind the proprietary offerings in many areas of functionality.
Bull is heavily involved in this area, both as a contributor and an integrator. As a longstanding expert in middleware integration for complex projects, and then as major contributor to the development of free middleware (application servers, transactional monitors, workflow, Web service orchestration, etc.), Bull integrates the leading ESB solutions on numerous projects, and is also involved in the development of free software ESBs – on the one hand through R&D collaboration with various communities, and on the other hand through customers’ Open Source projects.
Over and above ESB platforms, experience also shows that increased professionalism and automation of developments itself plays a key role in the success of projects. An ESB project will often be an integral part of a global project, requiring dedicated application development. In this context, numerous elements must be managed with great care: quality control (management of testing, bug handling and patch systems, validation processes and back-up, etc.), re-use of existing elements (methodologies, processes and rules for re-using components, documentary repository, etc.) and effective sharing of information between participants (source handling, reporting, alerts, traceability of decisions taken, etc.).
This is why Bull has developed NovaForge™: a secured project management and integrated distributed development platform at the core of the Group’s global network of resources and service centers. The objective of NovaForge is to rationalize and share development resources for customers to improve productivity, quality and the maintainability of their applications.
As in most application software projects, the quality of the professionalism and structure in development industrialization is a key success factor, above and beyond the ESB tool chosen; and this needs to be taken seriously into account. The implications are huge, in terms of quality, timescales and cost, and it deserves a great deal of attention on every project.
More information about Bull’s contributions to the development of Open Source middleware
ESB (Enterprise Service Bus). SOA architecture middleware based on standards such as Web services. An ESB generally includes features such as adaptors (for example, JCA connectors) for integrating existing systems, use of a pivot XML format for messages, transformation and intelligent message routing, reliable messaging, a registry and a repository, process management engines (workflow, rules, orchestration), management and security functions and an integrated development environment. ESBs transport enterprise’s XML messages on a software bus that connects all the organization’s applications, making them accessible to all the information systems involved. ESBs are seen as the best way of implementing information systems that conform to an SOA.
SOA (Service-Oriented Architecture). Architectural integration and manipulation (composition, assembly) model for the various blocks and application software components making up an information system, including management of the relationships they handle. This approach is based on the reorganization of applications into processes that invoke services.
ebXML (Electronic Business using eXtensible Markup Language). A suite of specifications based on the XML language that defines a standard for e-commerce. In particular, ebXML defines the access interface to a repository and to a registry.
UDDI (Universal Discovery, Description and Integration). Access specification in XML to a catalogue of services provided by service providers, and enabling service consumers to locate and obtain the characteristics of the services they need, in order to be able to invoke the providers of these services.
EJB (Enterprise JavaBeans). Extension of JavaBeans enabling construction of components that are reusable on any Java platform.
MOM (Message Oriented Middleware). Messaging system for reliable message transmission between applications or machines.
JMS (Java Message Service). Standard Java interface providing access to a messaging system (ex-MOM) for reliable message exchange between applications or machines. Note that JMS does not standardize the message system used.
IDE (Integrated Development Environment). A series of tools supplied as a group of integrated consoles, enabling global management of the life cycle of the technical and functional components involved in the make-up of an information system designed to align with an SOA.