atomsEIFLEX glueware

Glueware - why do you need it

There are numerous reasons in today's IT world where it becomes essential to join application islands together. New business alliances or takeovers will generally require disparate IT systems to be merged. Supply chain dominance by one party will enforce potentially unwanted technology choices on suppliers or consumers. Customer focused corporate policies and process automation will frequently imply building bridges between systems that were developed independently. Even where new technologies are adopted, these rarely replace old ones, they live in parallel for quite long periods. All these situations will result in incompatible IT systems needing to talk to each other. Then what hits you:

These are serious issues for the software engineer. The business decision makers will inevitably focus on functional requirements but the software engineer will recognise the challenges presented by the non functional aspects of glueing things together. EIFLEX helps you out here. EIFLEX provides distribution, medium term persistence, resilience, scalability, transactions, platform independence, adapters and wrappers, all as a given. On top you get a comforting OO framework for plugging in business logic wherever you need it.

The non functionals supplied by EIFLEX


The glue modules wrap pre-existing application islands, and it is often desirible to co-locate the wrappers with the wrapped. It is essential to partition glue objects into independent distributed co-operating units across threads and process and boxes, and for these business objects to interact through reliable RPC, publish subscribe, events, and messaging interaction styles. The EIFLEX middleware provides all this as a given.


The glue modules will often be implementing process models, and it is the nature of business to continuously strive for improved processes. Thus the need to easily change the business logic as demands or the environment evolve. The Eiflex application framework enables this.


It is essential that the glue can grow without degradation. The multiprocess, multithread, multibox EIFLEX architecture ensures this is achievable.

Persistence and Resilience

Perhaps the most important non functional. Glue modules will frequently contain "medium term data". That is data that is active within a business process, but which has not yet been committed to its target long term storage locations. In a traditional application a relational database might supply the long term storage, but a database is not the ideal location for this distributed intermediate data. However this "process data" is just a vital to the business, and the ability for the glue to continue processing without loss of data in the presence of hardware and software malfunction is essential. EIFLEX achieves this through transactions, persistence and optionally replication to hot standbys.


The glue needs an armoury of adapters to be able to talk to the variety of application islands that exist. EIFLEX has a small selection of common adapters that have been developed from previous deployments, but perhaps what is just as important, there is a framework to support adapters that makes it easy to integrate new ones.

Platform independence

The glue needs to be able to run on any hardware or software platform that the pre-existing applications run on. EIFLEX is pretty much completely platform independent.

EIFLEX - A Layered Architecture

EIFLEX glueware has 3 layers

The upper layer is generally the only layer that has to be developed for any particular deployment. The 2 lower layers provide the non functionals. They can be exploited directly, but complete glue solutions will normally only require the development of a top layer using items from the component model, plus possibly the development of a new adapter for some API/protocol that EIFLEX has not seen before

The clean separation of business logic from infrastructure means that the former is more understandable and more maintainable, so a system can evolve over time with less ‘scarring’. Staff carrying out business-level maintenance and enhancements do not have to be familiar with the architectural plumbing of the system.


Examples of Business objects (from finance)

Example Adapters (from finance)

Dynamic Data Types

The business data is carried around, persisted, replicated, published etc. in a common form not dissimilar to an XML DOM tree. The component model has a variety of manipulation rules for processing this common data format, and the EIFLEX runtime ensures datatype conformance between components, adapters, and inter business modules. Where a specific business rule has to be written there are ports for constructing OO objects from this common data format.


Two Example systems


At the height of the dotcom bubble, Swedish company OM introduced in London UK a retail equities exchange called Jiway. The OM Jiway exchange was looking for technology to automatically route hedge orders from its central OM CLICK based exchange to partners providing execution via the FIX protocol, and to return to the central exchange the results of the executions.

Superficially the functional aspects of this application are not particularly complex. Take some orders, break them down by price, farm them out to the execution providers, collect the results, and when all completed, return the results back to the central exchange.

However the non-functional aspects were very severe. It must handle the mismatch of data between OM CLICK and FIX. It must not fall over. It must never lose any of the intermediate data for partially executed orders, it must continue in the presence of broken connections, and continuously attempt to re-establish these connections using alternative routes and standbys.

Jiway approached a number of suppliers both internally and externally. They eventually chose EIFLEX as the solution because it was clear that its infrastructure provided the non-functional requirements as a given. At the time EIFLEX did not have adapters to talk to either OM CLICK nor FIX, but it was judged that adding these to EIFLEX was a far more cost effective approach than adding the resilience aspects to existing CLICK and FIX products.

The system had business objects for:

2. CBOT PRICES and Eprices

The Chicago Board of Trade were in fact the company that first commissioned the development of the EIFLEX infrastructure to underpin their floor trading PRICES system. The layered architecture was introduced precisely because they intended to use the infrastructure for other purposes. EIFLEX is now also used in the Electronic trading price dissemination, and in capturing pricing information into their long term Oracle relational database.


The core of EIFLEX is written in the Eiffel programming language, which many recognise as the most advanced, complete and secure Object Oriented programming language.

Eiffel was chosen over C++ and Java mainly because of the advanced engineering disciplines of the language (Design by Contract, Generics, Covariance), and the sophistication of the IDE ensure that complex and long lived systems like EIFLEX can be built and enhanced with shortest times to market, and with the most confidence in their reliability and future maintainability.

Eiffel is also completely platform independent targeting just about every hardware and software platform you might want to consider – Windows, most Unix’s, VMS, Linux etc., .NET

Any application specific business rules must plug into the framework, and today that means they too must either be written in Eiffel, or wrapped in Eiffel (note it is straightforward to wrap other languages in Eiffel), possibly using existing components.

EIFLEX is not a product. It is an evolving library of parts, from which specific glue or process automation transactional modules could be built. Eiflex had an intention to turn the channel library into open source, but this has yet to happen. Its latest state is described in this paper, and its associated highlights, which were presented in July 2006 to a conference on Eiffel concurrency at York University, UK (CORDIE06).


Eiflex is now just the hobby one person, Gordon Jones, who who is all that remains of the team that developed and evolved EIFLEX over the last 9 or so years. At its height some of the key names in the Eiffel community have been involved in the development of EIFLEX (Eric Bezault, Franck Arnauld, Roger Browne, and Rafael Simon amongst others have all been involved in some way).

If you want to know more about it, please contact