Project Freegate
Market Survey of Open Source EAI Software
September, 29th, 2006
FOSS Innovation Platform
Free and Open Source Software
Innovation Platform
Centre de Recherche Public Henri Tudor
29, Avenue John F. Kennedy
L-1855 Luxembourg–Kirchberg
libre.tudor.lu
Phone: (+352) 42 59 91-250
Fax:
(+352) 42 59 91-251
www.tudor.lu
Fachhochschule Trier
UNIVERSITY OF APPLIED SCIENCES
Schneidershof
D-54293 Trier
Phone: (+49) 0651 / 8103 - 0
Fax: (+49) 0651 / 8103 – 333
www.fh-trier.de
Project Freegate: Market Survey of Open Source EAI Software
CRP Henri Tudor
Authors. Oechsle, Donak
Date: September, 29th, 2006
Page 2/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
TABLE OF CONTENT
1
INTRODUCTION ........................................................................................................... 5
1.1
1.2
1.3
2
INFORMATION INTEGRATION ........................................................................................ 5
COMMERCIAL EAI SOLUTIONS..................................................................................... 8
THE FREE AND OPEN SOURCE APPROACH ................................................................... 10
PREPARATION ............................................................................................................ 11
2.1 APPROACH ................................................................................................................. 11
2.2 EVALUATION CORE CRITERIA ..................................................................................... 12
2.2.1 Architecture........................................................................................................ 12
2.2.2 Licence ............................................................................................................... 12
2.2.3 Documentation ................................................................................................... 12
2.2.4 Project state ....................................................................................................... 12
2.3 EVALUATION DETAIL CRITERIA .................................................................................. 13
2.3.1 General............................................................................................................... 13
2.3.2 Architecture........................................................................................................ 14
2.3.3 Features.............................................................................................................. 16
2.3.4 Security............................................................................................................... 20
2.3.5 Support ............................................................................................................... 21
2.3.6 Usability ............................................................................................................. 23
2.3.7 Project state ....................................................................................................... 25
2.4 CHECK LIST ................................................................................................................ 26
3
EVALUATION .............................................................................................................. 29
3.1 SYSTEM IDENTIFICATION ........................................................................................... 29
3.2 EVALUATION PHASE I................................................................................................. 30
3.2.1 Business Integration Engine (BIE)..................................................................... 30
3.2.2 Clover.ETL ......................................................................................................... 30
3.2.3 Conductor DocSOAP XDK ................................................................................ 31
3.2.4 connectorWorks.................................................................................................. 31
3.2.5 DataServer ......................................................................................................... 32
3.2.6 elemenope........................................................................................................... 33
3.2.7 it.gim................................................................................................................... 34
3.2.8 jEngine ............................................................................................................... 34
3.2.9 mec-eagle ........................................................................................................... 35
3.2.10
Message Forge................................................................................................ 35
3.2.11
Mirth ............................................................................................................... 36
3.2.12
NaradaBrokering ............................................................................................ 37
3.2.13
Net Kernel ....................................................................................................... 37
3.2.14
Octopus ........................................................................................................... 38
3.2.15
OpenEAI.......................................................................................................... 39
3.2.16
OpenQueue ..................................................................................................... 39
3.2.17
OpenSymphony ............................................................................................... 40
3.2.18
Orbeon PresentationServer ............................................................................ 41
3.2.19
OSMQ ............................................................................................................. 42
3.2.20
ServiceMix ...................................................................................................... 42
3.2.21
S-integrator ..................................................................................................... 43
3.2.22
SolAce ............................................................................................................. 44
3.2.23
Tambora.......................................................................................................... 44
3.2.24
Xineo XIL ........................................................................................................ 44
CRP Henri Tudor
Page 3/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
3.2.25
XMLBlaster ..................................................................................................... 45
3.3 EVALUATION PHASE II ............................................................................................... 46
3.3.1 Babeldoc............................................................................................................. 47
3.3.2 JyRetic ................................................................................................................ 53
3.3.3 Mule.................................................................................................................... 59
3.3.4 openadaptor ....................................................................................................... 67
3.3.5 Proteus ............................................................................................................... 75
3.3.6 xBus .................................................................................................................... 79
4
EVALUATION MATRIX............................................................................................. 86
5
CONCLUSION .............................................................................................................. 92
ANNEXE A: GLOSSARY................................................................................................... 93
ANNEXE B: REFERENCES .............................................................................................. 97
ANNEXE C: TABLE OF FIGURES ................................................................................ 100
ANNEX D: LICENSES...................................................................................................... 101
5.1
5.2
5.3
5.4
5.5
5.6
APACHE LICENSE, VERSION 1.1............................................................................... 101
GPL ......................................................................................................................... 102
LGPL....................................................................................................................... 105
OPENADAPTER LICENSE ........................................................................................... 110
MULE LICENSE ........................................................................................................ 111
XBUS LICENSE ......................................................................................................... 112
CRP Henri Tudor
Page 4/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
1 Introduction
1.1 Information integration
Nowadays companies and organizations implicate an IT-infrastructure that involves a
multiplicity of different subsystems. These subsystems serve common tasks like accounting,
enterprise resourse planning or human resource management. In addition to these common
systems there is a number of subsystems that is specialized to the needs of the company’s
core business. The systems itself may be independent, but in order to avoid redundancy, the
data stored within these systems have to be exchanged.
Some approaches to exchange the information between the subsystems are
•
Multiple input of information
•
Point to point connection between subsystems
•
Use of an enterprise application integration system
Multiple input of information
The information will be manually entered into the different subsystems even if it is already
available in another subsystem. If data has to be transferred from one system to another, it is
printed out from the delivering system and manually be entered in the receiving system.
Figure 1 Multiple input of information with media conversion
The approach of the manual entering of redundant information is the most ancient and
inefficient way of information “exchange”. It leads to redundant data management and thus is
vulnerable to data inconsistencies.
Advantages
•
Works directly with every subsystem
•
No programming necessary
Drawbacks
•
Very error prone (typing error during input, loss of the printout during delivery)
•
Takes quite a long time for data input
•
Quite expensive due to the need of human resources
CRP Henri Tudor
Page 5/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Point to point connection
For all applications that need to exchange information, a separate interface for every flow of
information will be created. This is individually done for the different interfaces of the
involved subsystems and the different protocols and message formats.
Figure 2 Point to point connection
This approach results into many point-to-point connections that grow up across an
organisation. Dependencies are added on an ad-hoc basis, resulting in a tangled
unmaintainable mess, commonly referred to as spaghetti, a comparison to the programming
equivalent known as spaghetti code.
The number of n connections needed to have a fully-meshed point-point connections is given
by n∗ (n− 1) . Thus for just 10 applications to be fully integrated point-to-point, 10 ∗ (10 − 1) or 45
2
2
point-to-point connections are needed.
That as well means if just one application interface is changed (e.g. due to an upgrade or the
use of another product) n-1 point-to-point connections have to be changed. In the example
indicated above this would result into the recreation of 9 point-to-point connections if one
application interface changes.
Advantages
•
Can be relatively easy to implement for small IT-infrastructures
•
Cheap in the acquisition phase
•
Automatic and quick transfer of information
•
No errors due to human interaction
Drawbacks
•
No means to administrate the resulting information exchange network
•
Hard to track down errors
•
No monitoring
•
Becomes quickly very complex
•
No scalability
CRP Henri Tudor
Page 6/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
•
Immense implementation effort for larger IT-infrastructures
•
High adjustment needs if interface of a subsytem changes (upgrade, different vendor)
Enterprise application integration system (EAI)
Enterprise application integration is the use of software and architectural principles to
integrate a set of enterprise computer applications. This represents the chronologically
youngest approach of application integration.
EAI is related to middleware technologies such as message-oriented middleware (MOM) and
data representation technologies such as XML. Newer EAI technologies involve the use of
web services as part of service-oriented architecture (SOA) as a means of integration.
Figure 3 EAI system structure example
Current thinking is that the best approach to EAI is to use a message bus to connect numerous
separate systems together. Other approaches like connecting at the database level or at the
user-interface level have been explored. However, the message bus approach has generally
been adopted as the strategic winner. Individual applications can publish messages to the bus,
and also subscribe to receive certain messages from the bus. The bus itself consists of
distributed software components and a central repository that contains the business rules.
Figure 4 Topological comparison between Hub & Spoke (left) and Bus structure (right)
CRP Henri Tudor
Page 7/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Another widespread approach is the so called Hub & Spoke or message broker architecture. It
reflects the first generation of EAI systems and involves a central hub, all external appli
cations are connected to it like the spokes of a wheel that handles the transfer of all
information. That factor can lead to a performance bottleneck at high workload if the system
is not scalable and is normally based on proprietary solutions whereas the ESB architecture is
based on plugable components and open standards. Furthermore, the ESB structure with its
intellegent connectors normally provides an advanced framework for security, transaction,
tracking, monitoring and logging.
With EAI each application only requires one connection, which is from the attached
application to the EAI system. Attending to EAI involves looking at a system of systems.
Such message bus approaches can be extremely scalable, and also highly evolvable.
Advantages
•
Just one interface for every application
•
Easy to maintain
•
Monitoring and Administration of the whole infrastructure available
•
High scalability
•
Use of open standards
•
Additional features like transaction, tracking, logging and security framework
Drawbacks
•
Normally high initial costs
•
Trained personal needed
•
Single point of failure (for Hub & Spoke)
1.2 Commercial EAI solutions
Because of the above mentioned advantages over the other information exchange methods,
enterprise application integration systems are an important topic in the software industry.
This results in a number of vendors, who are providing commercial solutions like:
•
Ascential: Enterprise Integration Suite
•
IBM: WebSphere Business Integration Server
•
Inubit: Integration Server
•
Microsoft: BizTalk
•
SAP: NetWeaver
•
SeeBeyond: eGate Integrator
•
SoftProject: X4
•
TIBCO: Business Works
•
VITRIA: BusinessWare
•
webMethods: Integration Server
CRP Henri Tudor
Page 8/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Many of these systems are having a high-potential for solving the interconnection problems
within companies and organizations.
But with these systems as well implicate some drawbacks that shouldn’t be concealed:
•
Initial costs
The costs for the dedicated hardware and especially the licences are quite high and
thus often not affordable for SMEs. The most common model is that a licence fee has
to be paid for the core system and additional fees for every connecter that is used to
connect the EAI system to an application of the customer.
•
Support costs
The costs for the support contracts are as well usually quite high (e.g. 25% of the
licence costs). This is mainly linked to the proprietary nature of the solution: as the
source code is secret, there can be no concurrence on high level support due to the
induced monopoly.
•
Support quality
Especially for SMEs this issue can become a problem as the paid support is in the
grand majority of the systems just given from the vendor. Should any incident occur,
the vendor will usually set his priorities to the most important customers which means
the biggest ones. The smaller customers are normally served afterwards. Especially in
domains like Healthcare or the financial sector, it is quite important that the response
times and especially the “problem solving”-times are quite low. As the experience of
the CRP Henri Tudor and some Luxembourgish hospitals shows, this requirement can
not be fulfilled by this support model. Furthermore, because of the closed source, the
customer (or a 3rd party supporter) does not have the possibility to fix a system bug
himself or alter the system if needed.
•
Skilled staff
Because of the complexity of such systems and lack of direct access to information,
staff with special skills, that are normally not present in the IT-department of the
customer, is needed in order to integrate the IT-systems and maintain the integrated
IT-landscape of the company later on. These kinds of special skills are usually
dependent of specific expensive trainings only given by the vendor of the proprietary
solution. This results into costs for training that has to dedicate a majority of its
working resources to the EAI-system. Alternatively this task can be given over to 3rd
party consultants who might have to be paid as well and most surely have higher
response times than internal competences.
•
Product life cycle
A vendor has to continuously enhance his product in order to stay competitive on the
market. He is doing so by releasing new versions of the product in certain intervals.
As the vendor has limited capacity (or even, sometimes, interests) for supporting the
increasing numbers of different versions and also wants to push the sale of the new
product versions, he stops the support for older versions some time after the new one
has been released. In order to profit by the crucial support, the customer has to
migrate to the newer software version. That comes along with a diversity of costs for
licences customizations, user trainings and downtimes.
CRP Henri Tudor
Page 9/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
1.3 The free and Open Source approach
Because of the drawbacks of commercial products described in the last paragraph, this paper
gives an overview about free and Open Source alternatives for EAI solutions. The free and
Open Source approach holds the potential to avoid some of the disadvantages listed under
“Commercial EAI solutions” in paragraph 1.2. On one hand they are completely free of
charge which helps to drastically reduce the costs especially in the acquisition phase.
On the other hand the source code of these systems is public and explicitly allowed, and
therefore can be freely modified and extended by anyone. This circumstance avoids the
vendor dependence in terms of support and product life cycle, as the consumer does not
simply buy a licence of the product but gets a full set of rights linked to it, including having
access to the source code.
Aside from this high potential, one has to keep in mind the fact that even though a system is
an Open SourceOpen Source EAI-system, it doesn’t automatically imply a high quality
product. Thus, once the Open SourceOpen Source EAI-systems have been identified, they
will be evaluated against criteria catalogues in order to determine if Open SourceOpen Source
solutions could be as well from a technical point of view an alternative to commercial EAIsystem.
Clearly, Open Source licenses tend to favour the user of a solution whereas proprietary
software tend to favour the supplier: with an Open Source Software Product, the consumer
will have access to the source code and most importantly will have the right to modify this
code. Advantages are real and tangible in terms of finances (ability to distribute freely a well
tweaked solution, for example, among as many partners as needed without buying new
licences), knowledge and training (because of the ability to study the source code), security
and quality (as the user can modify himself the code or have it modified by anyone that can).
The outline of the paper is as follows: The next section describes the approach for this survey.
The third section lists all the systems that were not investigated in-depth, whereas section 4
describes the systems that have been analyzed more deeply. All the systems described in
section 4 are compared against each other in section 5. Based on this comparison we finally
draw some conclusions and present our results in section 6.
CRP Henri Tudor
Page 10/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
2 Preparation
2.1 Approach
The approach of this survey is based on five main steps:
1. System identification
Gathering of free and Open SourceOpen Source EAI-projects from the web
2. Core criteria evaluation
Check of the found systems against some “must have” criteria – first validation phase
3. In-depth evaluation
In-depth check of the EAI-systems that passed the first validation-phase against the
detailed check list – second validation phase
4. Validation matrix
Creation of a matrix like presentation grid, that faces the characteristics of the
different systems against each other
5. Conclusion
The recommendations resulting of the survey
The understanding of EAI can differ widely. This results in a multiplicity of systems that are
announced under the flag of EAI but don’t match to the definition of EAI systems this survey
is based on (please see section 2.2.1 on page 12 and section 2.3.2 on page 14 for further
details).
In order to pay respect to this circumstance a two-phase evaluation approach has been used in
this survey.
CRP Henri Tudor
Page 11/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
2.2 Evaluation core criteria
The first evaluation phase includes four main criteria to filter the EAI-candidates:
2.2.1 Architecture
This criteria examines the system architecture at a meta-level, i.e. the basic structure of the
system. Detailed information about the wanted system structure can be found in the following
paragraph 2.3 “Evaluation detail criteria” under 2.3.2 “Architecture” on page 14.
Here the features, that are interesting for the meta-level architecture rating:
•
Connectors
that provide the link to the interfaces of external systems (outbound and inbound).
•
Transformers
that are able to receive messages from and send messages to connectors. Furthermore
they have to have the ability to map messages from one format to another.
•
Component based architecture
that allows to easily exchange or add components to the system.
2.2.2 Licence
The system itself has to be free of charge. There have to be no hidden charges for the use of
the system, like for the transactions going through the system or for the number of concurrent
transactions.
Furthermore it must be legal to modify or extend the system code and to add own modules,
use the system for other projects and hand the modified or extended system on to 3rd parties.
2.2.3 Documentation
A reasonable documentation have to be available for free. This documentation should give an
overview about the system structure and instructions for installation and configuration.
It should explain how external systems can be connected and how messages can be modified
and mapped.
2.2.4 Project state
It is absolutely necessary that the project is already in a technically mature state. This is even
more important, if the project is not in development anymore. A “technically mature state”
has been reached if the architecture requested under 2.2.1 has been realized, there is an
appropriate number of connectors and transformers available and the system is usable for
application integration. The components have to be configurable and there have to be
interfaces, that allow to extend the framework.
CRP Henri Tudor
Page 12/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
2.3 Evaluation detail criteria
In order to be able to rate the remaining EAI-systems, a checklist containing the evaluation
detail criteria has to be created. This evaluation detail criteria define the fields of interest that
will be examined and rated and as well the weight that will be put onto them.
The projects, that passed the first evaluation run were checked against a detailed evaluation
matrix.
The following sections describe the different sections of the checklist:
2.3.1 General
System abstract
This section provides the general information about the tested system. This includes an
abstract of the system features and highlights mainly adopted from the introduction page of
the system webpage and the link to the system webpage.
License
The license itself can be found in the annex. The licence should allow the (free of charge) use
of the EAI-system within other projects and allow the enhancement and modification of the
system.
Requirements & OS support
The minimum system requirements should be as low as possible in order to have as many
resources left for the traffic handling itself. On the other hand the system should be able to
run under as many environments (Operating Systems) as possible to assure, that it can be fit
into the existing IT infrastructure of the user.
3rd party software
3rd party software that is either mandatory needed to run the system or can optionally be used
to extend the system use will be listed here.
General check:
Check
CRP Henri Tudor
Importance
license
High
OS support
High
System abstract
Medium
System requirements
Medium
3rd party software
low
Page 13/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
2.3.2 Architecture
The chosen architecture has to assure that the system can easily be extended in terms of
features as well as in terms of scalability and will thus be able to pay respect to growing
needs as the system environment expands.
Component based architecture
A system with a component based architecture allows the easy exchange or addition of
different modules (=components) without the need of touching the whole EAI system. This
allows a relatively easy and fast adjustment to changing requirements and thus enables a
future-proof system. Examples of EAI components are connectors, processing units, message
structure templates or queues that will be explained in the following paragraphs.
Defined module interface (API)
An application programming interface (API) including well defined component interfaces
provides a standardized way to access the internals of the EAI system. The use of an API
assures the possibility to quickly understand the functionalities needed to integrate a custom
made component in a framework and to access its resources. This facilitates the creation and
extension of modules. Furthermore it reduces the development and deployment time of
additional components and adjustments of existing ones.
Connectors
Connectors enable the communication with different kinds of external systems as they
“speak” the language of the external system (e.g. FTP or SMTP). Connectors should be able
to act as servers (inbound connector) that listens for messages coming from external systems
and as clients (outbound connector) that actively send messages to external systems.
Furthermore a (inbound) connector should provide polling abilities to actively scan an
external system for new messages in configurable intervals. This is especially necessary if the
external system is unable to actively send its messages to the EAI system. Than the polling
connector has to fetch the messages e.g. from a file system, a ftp account or from the export
tables of a database.
Message container
The information coming from and going to the external systems are treated as messages. A
message fetched from an external system usually has a certain structure. The elements of this
structure have to be accessible for reading, writing and modifying. In order to support these
tasks, so called message containers are useful. These containers represent the structure of the
message. After the message has been parsed into the container, it’s element contents and
states (like the query if a field is optional or not) are easily accessible by function calls.
Synchronous/asynchronous
The synchronous communication describes the direct delivery of messages from the sending
component to the receiving component. That means the sending component retries sending
until the message reached the receiving component. This direct communication is faster than
the use of queues and it is known to the sending component that the message reached its
target. Unfortunately this message transfer approach also implicates some drawbacks like the
blocking of the sending component in case of reduced transmission reliability and the lacking
possibility to promote a message to a pool of receivers where either all or the first available
receiver (load balancing) picks it up.
CRP Henri Tudor
Page 14/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
The contrary behaviour reflects the queue based behaviour an so called asynchronous
communication. That means that the receiving component hasn’t to be available at that point
of time at which the sending system or component likes to transfer a message This
mechanism can be compared to a postman (sending component) who puts a letter into the
post-box (queue) of the receiver (receiving component). The receiving part picks it up from
the post-box as soon as he is available. This asynchronous behaviour is especially helpful for
distributed systems, where it can’t be assured, that the receiving system or component is
available at the time of sending. Either approach has its justification and applications. Thus it
would be optimal if both modes are supported.
Processing unit
Processing units accept one or more message types on a time and change their content in a
certain way. This can start with simple format transformation of the message content (like the
transformation from one date format to another) over the mapping from one message structure
to another up to advanced functionalities like digital signing and encryption. The result of
these operations will be sent back for the processing by additional processing units or to
connectors to be sent to an external system.
Predefined processing units have a fixed functionality that is slightly configurable by
parameters. These processing units are normally shipped with the EAI system and observe
standard functionalities like compression or decompression of content, the transformation to
or from xml or encryption.
Besides the predefined processing units exist custom processing units. Their functionality
can completely defined by the user. He can usually determine the functionality graphically
(e.g. for the mapping of message formats). For more sophisticated tasks this can alternatively
be accomplished by the use of a programming or scripting language like C++, Java, Perl or
Python. An established standard language is reasonable as the coding skills for these
languages are wide-spread and libraries for many occasions are already available.
Routing
After a processing unit finished the message modification, the message has to be routed to
another element either following a predefined workflow or dynamically depending on the
content of the message. The support of the combinations of both approaches guarantees the
most flexible application of the EAI system. The element, the message is routed to, can be
either a connector if the resulting message is determined for an external system or to another
processing unit, if further message modifications are needed.
Scalability
The capability of parallel processing of messages together with distributed EAI-components
provides a maximum of scalability and assures that the system will be suitable even if the
capacity requirements are steadily growing.
CRP Henri Tudor
Page 15/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Architecture check:
Check
Importance
Component based architecture
High
Connector as client (outbound connector)
High
Connector as server (inbound connector)
High
Custom processing units (Transformation)
High
Dynamic message routing
High
Message container
High
Predefined message routing
High
Scalability
High
Synchronous communication
High
Asynchronous communication
Medium
Connector polls messages (inbound connector)
Medium
Defined module interface (API)
Medium
Predefined processing units (Transformation)
Medium
2.3.3 Features
Connectors
Connectors enable the EAI-system to dock to external systems and exchange messages. A
diversified number of connectors to different external systems guarantees the connectivity of
the EAI system and thus its usability. Connectors can be in principle divided into three
categories: file-based, message-based and database-based.
File-based
The file-based connectors are especially important for the access of legacy systems, which
often only provide a file import/export as interface. For this connectors a polling mechanism,
which scans the file-folder in definable intervals for new files is fundamental. As well the
handling of the processed files should be configurable (e.g. move, delete, rename). The filehandling should be supported for multiple operating systems.
Database based
Quite similar to the file-based connectors are the database connectors. These are also mainly
used for legacy systems or for the connection to a data warehouse. In case of a “kind of”interface the connector regularly accesses in defined interval or triggered by certain events
defined import/export tables in the database. If such tables doesn’t exist, the connector has to
access directly the database model. This case can turn out to become quite intricate especially
for write access if the data model is not known and inconsistencies have to be avoided.
Message-based
CRP Henri Tudor
Page 16/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Message-based connectors are the most commonly used interfaces in the field of EAI. They
allow to pass a message directly from the interface of an application through the EAI-system
to a receiving external application. The connector handles the particularities of the used
protocols (like TCP/IP, SMTP, JMS or SNA) and provides the message either in
alphanumeric or binary format to the EAI system for further processing. These connectors
should support besides synchronous communication as well the asynchronous (post box)
communication model (as described under section 2.3.2). The asynchronous information
exchange is tolerant against network failures and can provide a more flexible message flow.
This message flow can be divided into three different models. These first model is the active
delivery to exactly one recipient, the second one is the delivery to just one recipient by the
request of the recipient and the last one is the subscriber pool. That means one or more
receivers are subscribing for a message and it will be sent to every prescribed receiver (one to
many approach).
Transaction support
For all these models the delivery of the message and the consistency of the involved systems
has to be guaranteed. Thus a transaction support, which rolls back all changes in case of an
error is helpful. This enables the system to define e.g. a database access together with a
message transfer as an atomic operation that can be completely undone if needed.
Application connectors
Apart from the technical connector view (file-, message-, database-based connectors) another
view, the so called application view of the connectors, is important. The so called application
connectors provide special interfaces not for certain protocols but for particular applications
like SAP, Siebel, Baan, Navision or Oracle.
These Adapters should provide besides the connectivity to the special interface and as well
come with a set of already predefined message structures (message library) for this interface.
This allows to just read or fill the required field of a wanted message (e.g. for an inventory
update) instead of creating the structure by hand.
CRP Henri Tudor
Page 17/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Message split/concatenation
Especially in case of the data exchange through files, it can not always be assured that an
export file contains just one message. This means the connector has to be able to split-up the
file content and generate multiple messages of it. The resulting messages are fed to the EAI
system for processing. On the outbound side, it can be necessary to gather multiple messages
and concatenate them to one output file that will somehow be exported to an external
application.
Decomposition/Recomposition
Depending on how the needed information are distributed within the system infrastructure of
the enterprise, it can be necessary to reformat information coming from different systems to
one message that will be routed to a target system. This process is called recomposition. On
the other hand, the decomposition describes the ability to trigger multiple activities by the
receiving of one message.
Programmable transformation
If the message arrived at the business logic, usually its content will be modified (e.g. date
conversion) and mapped to another message format. The most flexible way to accomplish this
task is the provision of a programming interface that allows to easily access the structures of
the incoming as well as targeted message format. By the use of a programming or scripting
language the user gains the highest degree of flexibility. Besides that he has the possibility to
integrate already existing libraries of the used language to ease the work even more.
It is important to use an established and wide spread language. This assures on one hand the
availability of support libraries and a big community that is able to give support in case of
problems. On the other hand the use of a well known programming language lowers the
obstacle of learning a new programming language before the user is able to accomplish the
actual work.
Exception handling
If an error occurs during the processing of a message (e.g. an invalid message structure) the
system should be able to trigger an appropriate exception handling. That can be the storage of
the erroneous message to a database or a file. The reason of the error should be logged to a
logfile and some additional actions like the creation of a notification email, that informs an
administrator about the occurred error should be triggerable. Advanced error handling
systems store the erroneous messages in a queue or database and provide a frontend that
allows to view and edit these messages. The modified messages can be fed back to the EAI
system for processing.
Compression
For the transmission of messages containing a large amount of data (e.g. graphics), it can be
effective to compress the message before sending it to the external system (e.g. by ftp),
especially if the connection bandwidth is low. On the sending side some applications (e.g.
webserver) exist that are sending their messages compressed (e.g. GZIP). In order to gain
access to the actual message content, the EAI-system has to be able to handle the
compression/decompression of the used algorithms in order to process the message and route
it depending on its content.
Workflow support
CRP Henri Tudor
Page 18/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
A workflow support represents another integration layer on top of the message based
integration layer. This layer extends the system integration to the level of business processes.
Workflow support allows to route the messages on the basis of well defined business
processes. This approach has the advantage that the workflows can be easily adjusted or
extended as the business workflows change.
Command line control
As an EAI system should consist of different components, it is able to control these
components separately. Their state can be requested, queues can be emptied and the
components can be started up or shut down as needed. This usually happens through an
administration frontend, if such a frontend exists for the system. Besides that it can be
necessary to perform these tasks automatically in respect to external events (e.g. to
temporarily shot down a database connector to allow a database backup). This can be
accomplished through issuing the needed commands form the command line or through a
batch script if such a possibility is supported by the EAI system.
Features check:
Check
CRP Henri Tudor
Importance
Exception handling
High
File-based connectors
High
Programmable transformation
High
Message-based connectors
High
Application-connectors
Medium
Decomposition
Medium
Recomposition
Medium
Database-based connectors
Medium
Transactional support
Medium
Workflow support
Medium
Command line control
Low
Compression support
Low
Page 19/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
2.3.4 Security
Communication channel encryption
Especially for the communication with external systems, that are not located within a
encapsulated intranet, it is important to secure the transmission against intervention of 3rd
parties. An encryption of the communication channel like https for the webserver
communication, SFTP for an ftp-connection or a general traffic encryption via VPN can
provide the required security level. This is a crucial requirement of some vertical markets like
the healthcare or banking sector in order to assure the privacy of sensitive information.
Message encryption
If the interface of the external system does not support the communication channel
encryption, the data itself can be encrypted. The most common standards like PQP or
S/MIME for email including the respective public key infrastructure should be supported by
the EAI system.
Authentication
Remote clients that allow the remote administration or monitoring, access the EAI-system via
an interface. This access has to be secured to avoid the intrusion into and modification of the
system by non-authorized users. Also the access to and from external systems (that are e.g.
not located in the secured intranet) can be secured by the use of authentication techniques. A
possibility is the authentication by username and password. A check of the requester’s IP
address can secure the access even more. An advanced authentication mechanism will
provide a permission management that allows the distinction between different user roles.
Message tracking
In some vertical markets like the healthcare or the banking sector, it is important to provide a
possibility to reproduce the change and transfer of system information, because of legal
reasons. That means that information concerning the traffic over the EAI-system like
transaction date, time, source, destination, message type and in some cases even the messages
themselves should be recordable within the system.
This can happen by log file messages or even the storage of the information in a database. As
the storage location is the central place of all message information and thus most probably
contain quite sensitive data, the encryption should here be an issue as well.
Security check:
Check
CRP Henri Tudor
Importance
Authentication
Medium
Communication channel encryption
Medium
Message encryption
Medium
Message tracking
Medium
Page 20/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
2.3.5 Support
Consulting
Open Source software does not mean that there has not to be commercial support available.
For companies and institutions that do not have an IT-department or their core business in the
IT sector, it can be crucial to have a consulting company at hand that provides timely and
competent support at the deployment phase or in case of problems. Especially if the company
that likes to introduce an EAI system has its core business in a sensitive domain like the
healthcare or in the banking sector this aspect can quickly become important. Support that is
provided by several different companies guarantees the independence of the user.
Documentation
The documentation is especially for Open Source projects the most important means of
support. The minimum requirement here is a user manual that describes the structure of the
system including the involved components and their usage. A plus are examples that clarify
the use of the system. From the developers point of view, the system should provide a
development manual describing the main techniques that where used for the development of
the system, the interfaces of the involved classes (e.g. in form of a JavaDoc document) and
the structure of the used protocols.
FAQ
A helpful part of the documentation is the list of frequently ask questions (FAQ) that provides
a quick help to the most frequent problems and questions usually occurring during the first
use of the EAI-system.
Forums
Forums provide an interactive support possibility for the users as well as for contributors who
like to develop additional features for the system or report bugs. If a forum is well populated,
it is a good source of information and can establish the contact to other users or even the
developers who are able to help in case of problems or questions. Topics that have already
been handled can also be viewed by browsing the forum or by using the search function. If
the activity in the forum is low, a mailing list would be the better alternative, because the
community has to actively enter the forum in order to recognize new requests.
Mailing lists
The advantage of mailing lists against forums is proactive delivery of new posts to the
mailbox of the registered user. But if there is too much activity in a mailing list, this can lead
to spam, as to much information is no information. The list-server of the mailing list should
provide an archive of the mailing list. This feature allows the access of older information that
not longer exists at the users side or were spread before the user joined the mailing list. A
sophisticated search functionality is here crucial.
Chat channels
A chat channel could be a useful mean for clearing up questions and problems that occur
during the use of the system, as it provides “realtime” feedback if somebody with the needed
competences is available on the other end. This synchronous communications unfortunately
as well presents a drawback as it is not guaranteed that somebody is available at the time help
is needed.
CRP Henri Tudor
Page 21/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Tutorials
Tutorials should explain at least the most basic & common functionalities of the EAI-system
by a step by step creation of examples. This helps to become fastly confident with the most
important features of the system. Especially for graphical frontends, the supply of training
movies that show in a graphical way what to do in order to accomplish a task is a plus.
Support check:
Check
CRP Henri Tudor
Importance
Consulting
High
Documentation
High
Forums
High
FAQ
Medium
Mailing lists
Medium
Tutorials
Medium
Chat channels
Low
Page 22/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
2.3.6 Usability
Graphical user interfaces
The usability is one of the key-factors of an EAI-system, as it will mostly be deployed in
quite heterogeneous and thus complicated IT-infrastructures. As easier a system is to use, as
less time and training has to be invested until the IT department is able to execute the
integration of the IT-infrastructure subsystems.
The most common way to increase usability is the provision of graphical user interfaces
(GUI). The GUI-interfaces allow a comfortable, remote change and control of the system
parameters. The GUIs for an EAI-system can be divided into three categories: Configuration,
administration frontends at one side and monitoring frontends at the other side.
GUIs should be clearly and logically structured and the handling should be intuitive (e.g.
meaning of buttons should be obvious, most important features should be accessible from the
main panel).
The configuration frontend should preferably allow the access to all configurable system
components and features. It should be possible to define message structures including multi
level delimiters for delimited messages and fixed length fields for non delimited messages. A
graphical programming interface for dynamic processing units and a drag & drop mapping
possibility for messages round up the configuration tool.
The administration frontend should provide access to all configurable components. The
status of the components should be checkable through the administration frontend and it
should be possible to start and stop components either directly or scheduled.
The monitoring frontend should provide a clear overview about the state of the different
components (connectors, queues, processing units) and should allow to stop, shutdown or
startup a component. A graphical representation of the system components and the routing
amongst them is a useful extra. The messages, currently located in the queues and in an
optimal manner as well the messages already taken from the queues, should be viewable.
Some commercial systems also providing a possibility to change the content of the messages.
The monitor should provide the possibility to change the log-level of the components and
view their logfiles.
Configuration
The structure of the configuration files have to be consistent and coherent. The naming of the
parameters should be as self explaining as possible. Sample configurations and detailed
explanations of the configuration parameters including information about default values and
obligation help the user to quickly find his way through the EAI configuration. The use of a
well established notation like XML additionally supports the user with his configuration
approach.
CRP Henri Tudor
Page 23/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Test schema
462
chief secretary 2271,21
FTP Message
54,Myers,Michael,1962/04/
01,comptable,4773,04
32874senior sales manager10783,74
54
comptable 4773,04
FTP
System A
System C
File
Merger
54,Myers,Michael,01.04.
1962,comptable,4773,04
Date modifier
54,Myers,Michael,1962/04/
01,comptable,4773,04
TCP/IP
Michael|Myers|01.04.1962
Jean|Réno-Didier|25.09.1954
Hanna|Häusel-Hansen|21.07.1984
eMail
System B
For the testing of the system usability from the users point of view, a test schema has been
developed, that covers some classical requirements for an EAI system:
•
External system A sends messages in file-format (one message per file). The elements
of the message have fixed length. The message itself has the following structure:
<id(5)> <function(20)> <salary(7)>
•
External system B sends messages over a TCP/IP interface. The elements of the
message are separated by delimiters. The message itself has the following structure:
<given name>|<family name>|<birth date(DD.MM.YYYY)>
•
A processing unit has to wait until one message from both systems came in. It then has
to merge the two messages. The resulting message is separated by delimiters and has
the following structure:
<id>,<family name>,<given name>,<birth date>,<function>,<salary>
•
The date in one field of the messages coming from external system B is in the format
“DD.MM.YYYY” and has to be changed to the format “YYYY/DD/MM”
•
The resulting message is written to a file on an external ftp account of a system C.
•
In parallel an email will be created that holds the content “Message number XXX has
been sent to YYY”.
XXX stands for the ID-field found in the messages coming from System A. YYY
stands for the name fields found in the messages coming from System B.
Usability check:
Check
CRP Henri Tudor
Importance
Administration frontend
High
Configuration frontend
High
Configuration files
High
Monitoring frontend
High
Test schema
High
Page 24/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
2.3.7 Project state
Number of installations / References
This is a parameter that is quite hard to determine for an Open Source project. Due to its
characteristic it is available to the public and can be – unlike a commercial system –
downloaded without signing a contract with the vendor. Thus, the author of an Open Source
project receives much viewer feedback about who is using his product and the way it is used
(test, production, for further development). Other sources, besides the direct feedback, for
the estimation of the number of installations/users are the support forums. Because of the
points mentioned earlier, it should not be put too much weight onto this parameter, but a list
of known references (especially bigger companies) can nevertheless permit a conclusion
about the support of and the experience with the product.
Time on market
The period, the system is already available on the market can be an indicator of the stability
of the system. The assumption is based on the fact that the stability and variety of features
increases with its lifetime.
Community
An indicator for the quality and as well the expectation of lifetime of a system is the size and
the feedback of the community that is using the system. Furthermore the community can be a
great source for help in case of any problems with the chosen EAI-system.
Number of coders/contributors
As more people actively working on a project, as faster the project evolves. Further it
increases the probability of fast fixing if a bug has been found. The coders are working
officially on a regular base on the project whereas the contributors are providing occasionally
the changes, additions and new features that resulted as a side-effect from their
customizations for a local deployment, to the project team.
Project state check:
Check
CRP Henri Tudor
Importance
Community
Medium
Number of coders/contributors
Medium
References
Low
Time on market
Low
Page 25/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
2.4 Check list
General
Importance
License
High
OS support
High
System abstract presentation
Medium
System requirements
Medium
3rd party software
low
Architecture
Importance
Component based architecture
High
Connector as client
(outbound connector)
High
Connector as server
(inbound connector)
High
Custom processing units
(Transformation)
High
Dynamic message routing
High
Message container
High
Predefined message routing
High
Scalability
High
Synchronous communication
High
Asynchronous communication
Medium
Connector polls messages
(inbound connector)
Medium
Defined module interface
(API)
Medium
Predefined processing units
(Transformation)
Medium
CRP Henri Tudor
Page 26/112
Project Freegate: Market Survey of Open Source EAI Software
Features
Importance
Exception handling
High
File-based connectors
High
Programmable
transformation
High
Message-based connectors
High
Application-connectors
Medium
Decomposition
Medium
Recomposition
Medium
Database-based connectors
Medium
Transactional support
Medium
Workflow support
Medium
Command line control
Low
Compression support
Low
Security
Importance
Authentication
Medium
Communication channel
encryption
Medium
Message encryption
Medium
Message tracking
Medium
CRP Henri Tudor
Authors. Oechsle, Donak
Date: September, 29th, 2006
Page 27/112
Project Freegate: Market Survey of Open Source EAI Software
Support
Importance
Consulting
High
Documentation
High
Forums
High
FAQ
Medium
Mailing lists
Medium
Tutorials
Medium
Chat channels
Low
Usability
Importance
Administration frontend
High
Configuration frontend
High
Configuration files
High
Monitoring frontend
High
Test schema
High
Project state
Importance
Community
Medium
Number of
coders/contributors
Medium
References
Low
Time on market
Low
CRP Henri Tudor
Authors. Oechsle, Donak
Date: September, 29th, 2006
Page 28/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
3 Evaluation
3.1 System identification
The first step consists of the screening of the internet and the characteristic websites for Open
SourceOpen Source EAI-projects.
The following sources have been of great help for the gathering Open SourceOpen Source
EAI-solutions:
• EAI User Group - Open Source EAI technologies (www.eaiusergroup.com/modules.php)
• Manageability – Open Source EAI systems written in Java (www.manageability.org)
• Ebizq -The Non-Vendor Source of EAI systems (www.ebizq.net)
• SourceForge – Platform for Open Source projects (sourceforge.net)
• FreshMeat – Information platform for Open Source projects (freshmeat.net)
31 Open SourceOpen Source EAI-projects could be identified during the screening phase:
• 1060 NetKernel
• MessageForge
• Proteus
• Babeldoc
• Mirth
• Retic / JyRetic
• Business Integration Engine
• Mule
• ServiceMix
• Clover.ETL
• NaradaBrokering
• S-integrator
• Conductor DocSOAP XDK
• Octopus
• SolAce
• ConnectorWorks
• OpenAdaptor
• Tambora
• DataServer
• OpenEAI
• xBus
• elemenope
• OpenQueue
• Xineo XIL
• it.gim
• OpenSymphony
• XMLBlaster
• Jengine
• Orbeon
PresentationServer
• mec-eagle
• OSMQ
Because the understanding of EAI can differ widely, a two-phase evaluation process is
required.
Thus the first evaluation phase is primarily used to filter the EAI systems that match to the
definition of EAI this survey is based on (as described under 2.2.1) and fulfil some other core
criteria before it comes to a in-depth testing in phase 2 where the remaining systems will be
checked against the detailed check list.
CRP Henri Tudor
Page 29/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
3.2 Evaluation phase I
This evaluation phase checks the systems identified under “3.1 System identification” at page
29 against the core criteria as described at page 12.
In the following an overview about the systems that didn’t pass the first evaluation phase.
This overview consists of the project name, a link to the systems website, a short description
of the system and the reason why it didn’t pass the evaluation.
The systems that passed the first phase are discussed in section 3.3 beginning at page 46.
3.2.1 Business Integration Engine (BIE)
Name:
Business Integration Engine
Web Site :
www.brunswickwdi.com/features
Description
:
Business Integration Engine
(BIE) is designed to help
organizations exchange data
created in different applications
on various platforms with
partners,
suppliers,
and
customers in order to streamline
processes
and
improve
efficiency. It includes a map
builder and dashboard, supports
multiple protocols like SOAP,
EDI X12, HIPAA etc.
Reason:
The documentation (about 200 pages) costs $195. Because there was no other
documentation available, the project BIE could not be evaluated any further.
3.2.2 Clover.ETL
Name:
Clover.ETL 1.1.6 (xx.10.2005)
Web Site :
cloveretl.berlios.de
CRP Henri Tudor
Page 30/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Description
:
Clover.ETL is a Java based ETL (Extraction, Transformation, and Loading)
framework which can be used to transform structured data. While using JAVA
technology it allows for platform independence. It can be used standalone - as
an application run from command line or can be embedded into applications.
Reason:
The system is purely based on files and databases as connectors (ETLsolution).
3.2.3 Conductor DocSOAP XDK
Name:
Conductor DocSOAP XDK
Web Site :
www.commerceone.com/developers
Description
:
Commerce One Conductor DocSOAP XML Development Kit (XDK).
Reason:
The system is not a framework consisting of connectors and transformers.
This Open-Source Java
Web Services SOAP, and
XML Development Kit
provides an effective and
efficient way of developing
Web services solutions
where the emphasis is on
making it easy to do
document Style SOAP.
Commerce One tests show
that the DocSOAP XDK
supports more features of
the XML schema and
processes larger XML
documents over twice as
fast as any other solution
available.
3.2.4 connectorWorks
Name:
ConnetorWorks 1.0
Web Site :
www.connectorworks.org
CRP Henri Tudor
Page 31/112
Project Freegate: Market Survey of Open Source EAI Software
Description
:
Authors. Oechsle, Donak
Date: September, 29th, 2006
The 1.0 release provides an open-source framework for implementing XML
document-centric interactions with an enterprise information system that:
•
Works with JAXM, JAXP, SAX, DOM, JAXB, XSLT, XML
filters/pipeline, and JMS messaging (Interoperability)
•
Leverages JMX-based management and monitoring capabilities for
EIS interactions (Manageability)
Supports the transformation to/from a canonical business markup language
like OAGIS BOD using XSLT and SAX filter chains to/from internal EIS data
structures/APIs such as an SAP R/3 IDoc (Reusability)
Reason:
The connectorWorks project is a small project (52 Java source code files)
whose functionality is not clear, because the documentation is nearly not
existent. There is a single web page with a single internal link in order to
download a ZIP file. The downloaded ZIP file contains a PDF file whose
relation to connectorWorks is not clear. In addition, the downloaded version is
1.0 Beta from April 2003. There are no mailing lists or forums. The project
seems to be dead.
3.2.5 DataServer
Name:
DataServer 2.0
Web Site :
www.mii.ucla.edu/DataServer
Description
:
DataServer is an Open Source XML gateway, specially tailored for the
medical domain. Built upon the high-performance Apache Cocoon framework
and J2EE platform, DataServer provides an enterprise-quality platform for
aggregating XML-based patient medical records, in both clinical and research
applications.
DataServer is a middleware, situated between clients and traditional Health
Information Systems (HIS), Radiology Information Systems (RIS) and Picture
Archive and Communication Systems (PACS). It supports relational (SQL),
SOAP, and HTTP data sources out of the box, but is highly extensible for
custom types. A suite of web-based tools allows for the centralized
management of distributed data sources, and the rapid deployment of new
services.
Reason:
CRP Henri Tudor
At first sight the system is not a framework consisting of connectors and
transformers. The only external interface to the system is by sending XML
requests to it. But because of the possibility of running Cocoon as standalone
Page 32/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
system with different generators, the system may well be used for general
application integration. We excluded it, however, from further investigations
because at first sight its architecture is not based on the connector-transformer
paradigm.
3.2.6 elemenope
Name:
Elemenope 4.2rc2
Web Site :
elemenope.org
Description
:
elemenope is an Enterprise Application Integration [EAI], Service Oriented
Architecture [SOA], and general messaging framework.
•
elemenope provides the capability for massive decoupling of an
enterprise's components through standardized interfaces for
communications.
•
elemenope provides complete abstraction of both transmission
protocol and functional components.
•
A project may connect components via a particular protocol or
messaging standard, and not be stuck with that technology, as they
may completely change the messaging technology deployed with a
simple change to a configuration file, i.e. no code changes.
•
elemenope allows an organization to easily create a large scale multiplatform application to conduct messaging or transaction processing.
•
elemenope abstracts away most connectivity issues and promotes
integration of new software with legacy applications through
simplification of connections.
•
elemenope simplifies architecture of large systems by standardizing
functional components and message pathways. One can very easily
trace problems or collect metrics at multiple levels, as every unit of
application functionality implements the same interface, and all
requests follow a similar path.
•
elemenope implements the following connector/transport sets:
o Java Message Service [JMS]
o Web Services (SOAP, XML-RPC)
o Direct Call
o Native IBM MQSeries (WebSphereMQ)
o Built-in mainframe connectivity classes for use when
connecting to a mainframe running IBM MQSeries with the
IMS Adapter or IMS Bridge
elemenope™ has been in development since 1999. It and some of its
precursors are currently in production use within several organizations large
and small.
Reason:
CRP Henri Tudor
We could not find any documentation except the Javadoc files. The project is
Page 33/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
a smaller project consisting of 44 Java source code files. The project seems to
be inferior to other projects like Babeldoc, Mule, and OpenAdaptor.
3.2.7 it.gim
Name:
It.gim 0.9
Web Site :
www.it-financial.de
Description
:
it.gim is an Enterprise Application Integration tool, which includes reliability,
scalability, security, error tolerance, availability and platform independence.
Reason:
It was not possible to get more information on it.gim. There are no additional
web pages.
3.2.8 jEngine
Name:
JEngine 2.0.1
Web Site :
www.jengine.org
Description
:
jEngine is an Open Source, standards-compliant, enterprise integration engine
implemented in Java. The server framework, based on Java 2 Platform
Enterprise Edition (J2EE), provides a robust standard for deploying a multitier enterprise integration engine. By utilizing the J2EE standard, a complete
framework of standardized components, services, and interfaces will be
developed while maintaining the promise of portability across operating
systems.
jEngine is a co-development
effort by two independent
software development firms.
Both firms have long-time
roots in the integration
business in healthcare. Their
goal is to bring a measure of
power, freedom and cost
savings to hospital systems by
building a publicly owned
message brokering system.
jEngine uses JBoss’ core for database persistence, transaction support,
messaging and integration of components based on Java Management
Extensions (JMX) specification. jEngine’s JMX components currently include
TCP/IP HL7 2.x client and server components. Due to the adoption of the
HL7 2.x standard within healthcare organizations and the singular focus of the
HL7 organization on the interface requirements of the entire health care
industry, these components were the first to be developed.
CRP Henri Tudor
Page 34/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Internal jEngine messaging uses
the Java Message Service
(JMS), which provides a
reliable
means
for
the
asynchronous exchange of data
within the healthcare enterprise.
The jEngine core utilizes
standards-based
XML/XSLT
transformations for message
structure manipulation.
Reason:
The project seems to be no longer alive; the latest version 2.0.1 was released
in October 2003. The documentation is not very elaborated and comprises
three thin PDF files: a white paper (2,5 pages), a figure, and an administration
manual (7 pages). There are no forums or mailing lists. The only contact
information is an e-mail address. The jEngine project is a rather small project
– the source code consists of less than 30 Java files, half of them dealing with
HL7.
3.2.9 mec-eagle
Name:
mec-eagle
Web Site :
www.mec-eagle.org
Description
:
m-e-c eagle is the first Open
Source, OS independent, Java,
XML and XSL based B2B
integration software, which
gives you the right tool for it.
It has an high basic
functionality
with
many
components, which give you a
set of integrated tools, which
make it possible to create any
business
solutions
for
integrating different systems
with each other.
Reason:
The project seems to have died. The mailing list is turned off, CVS is turned
off, and the last post on the forum is from May 2003.
3.2.10 Message Forge
Name:
Message Forge
Web Site :
messageforge.sourceforge.net
CRP Henri Tudor
Page 35/112
Project Freegate: Market Survey of Open Source EAI Software
Description
:
Authors. Oechsle, Donak
Date: September, 29th, 2006
The framework was conceived and created during the development of an online
trading system for a major bank on Wall Street. The project made heavy use of
TIBCO/RV. Features include transparent message definitions, automatic
generation of JAVA classes from XML definitions, a type-safe messaging
JAVA API, run-time message validation, services to marshal/unmarshal
messages, uniform message definitions across all tiers and high performance.
XML Message
Specifications
Class
Code Generator
JAVA Source
Compile
Class
JAVA Source
Class
JAVA Source
Reason:
The system is not a framework consisting of connectors and transformers, but a
code-generator which creates classes from message specifications.
3.2.11 Mirth
Name:
Mirth 1.1
Web Site :
www.mirthproject.org
Description
:
Mirth is an Open Source
cross-platform HL7 interface
engine, based on Mule, that
enables
bi-directional
sending of HL7 messages
between
systems
and
applications over multiple
transports.
Furthermore, it provides
tools and interfaces for
developing, deploying and
monitoring of the system.
Handled messages are encrypted and stored to an internal database. These
messages can be browsed and even exported to a file by the use of the
administration frontend.
Professional support is provided by the US company WebReach Inc.
Reason:
CRP Henri Tudor
The system is based on Mule, which will be detailed examined in section 3.3.3
at page 59. Mirth solely focuses on the exchange of HL7 messages, which
strongly restricts its use as general EAI system.
Page 36/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
3.2.12 NaradaBrokering
Name:
NaradaBrokering 1.1.2
Web Site :
www.naradabrokering.org
Description
:
The NaradaBrokering project
at the Community Grids Lab
is an Open Source project that
researches fundamental issues
pertaining
to
distributed
middleware systems.
These include, among others,
issues of efficient routing,
support
for
complex
interactions,
robustness,
resilience, ordering, security
and trust. NaradaBrokering
aims to provide a unified
messaging environment that
integrates grid services, web
services,
peer-to-peer
interactions and traditional
middleware operations.
The NaradaBrokering project has been in the Open Source domain for the past
3 years.
NaradaBrokering is a distributed messaging infrastructure and provides two
closely related capabilities.
First, it provides a message oriented middleware (MoM) which facilitates
communications between entities (which includes clients, resources, services
and proxies thereto) through the exchange of messages.
Second, it provides a notification framework by efficiently routing messages
from the originators to only the registered consumers of the message in
question.
Reason:
The system is not a framework consisting of connectors and transformers, but
an event brokering system designed to run on a large network of cooperating
broker nodes. Its main purpose is the support of grid and P2P computing.
3.2.13 Net Kernel
Name:
Net Kernel 2.0.6
Web Site :
www.1060research.com/netkernel/index.html
Description
:
NetKernel is an XML Application Server built on a microkernel with a
functionality set including Web-service SOAP1.1, SOAP1.2 and REST
infrastructure, XML language runtimes, powerful libraries of XML
technologies, developer tools, documentation and a web management
interface.
CRP Henri Tudor
Page 37/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
The NetKernel microkernel manages URI address spaces and schedules URI
requests into these spaces. It embodies a set of simple self-consistent concepts.
Reason:
•
All software components are services
which are addressed by URI.
•
A component's URI is published in an
internal URI Address Space.
•
URI Address Spaces are encapsulated
in modules which can be layered into
larger virtual URI address spaces.
•
Software components may be clients
which issue URI requests against the
Virtual URI Address Space.
The system is not a framework consisting of connectors and transformers.
3.2.14 Octopus
Name:
Octopus 3.4-1
Web Site :
octopus.objectweb.org
Description
:
Octopus is a Java-based
Extraction, Transformation, and
Loading (ETL) tool. It may
connect to any JDBC data
sources
and
perform
transformations defined in an
XML file.
A loadjob-generator is provided to generate Octopus
loadjob skeletons (and even
DODS DOML files!) from an
existing
database.
Many
different types of databases can
be mixed (MSSQL, Oracle,
DB2, QED, JDBC-ODBC with
Excel and Access, MySQL,
CSV-files, XML-files,...).
Four special JDBC drivers come with Octopus to support JDBC access to
CSV-files (CSV-JDBC), MS-SQL (FreeTDS), XML (XML-JDBC) and
property files (i18n-JDBC).
Octopus provides a very generic way to transform data. Transformations can
be defined by implementing transformer interfaces or using JavaScript code
(directly in a load job XML file).
Reason:
CRP Henri Tudor
There is no framework for general connectors. Databases and files are the only
sources, databases are the only sinks.
Page 38/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
3.2.15 OpenEAI
Name:
OpenEAI 3.0 build 5
Web Site :
www.openeai.org
Description
:
The purpose of the OpenEAI Project is to discover and document the
controlling dynamics, principles, and practices of enterprise application
integration and to present, implement, and promote those findings. The
OpenEAI Project presents findings in the form of the OpenEAI methodology
and OpenEAI software for implementing integrations.
The OpenEAI Project is comprised of six distinct, but closely-related
departments, which address
•
OpenEAI Methodology,
•
Application Foundation APIs,
•
Message Object API,
•
Message Definitions,
•
Reference Implementations,
and Deployment and Administration.
Reason:
The system is not a framework consisting of connectors and transformers. The
source code comprises 130 Java file which deal primarily with XML messages
and message sending and receiving. A citation from the document “API
Introduction” says:
The heart of the the OpenEAI API is the OpenEAI Message Object API,
referred to as the MOA. OpenEAI Java Message Objects know how to build
themselves from XML and serialize themselves to XML. They know how to
build all the messages specified by the OpenEAI Message Protocol and send
them using a JMS provider. They know how to translate the applicationspecific values for data fields for application X and translate them to
enterprise values. They know how to take enterprise values and translate them
to appropriate application-specific values for application Y. The Java Message
Objects that must be developed for an organization’s own MOA can be
programmatically generated from XML message definitions by an MOA
generation application provided by the OpenEAI Project.
Moreover, the web pages announces more than there is really available. For
example, the web pages for the six departments all lead to the same resource
web page which contains 7 documents.
All these documents are from January 2003. One of the documents called
“OpenEAI Message Definitions”, that does not have any relevant content, still
says: “We anticipate availability toward the end of February 2003.
3.2.16 OpenQueue
Name:
OpenQueue
Web Site :
openqueue.sourceforge.net
CRP Henri Tudor
Page 39/112
Project Freegate: Market Survey of Open Source EAI Software
Description
:
Reason:
Authors. Oechsle, Donak
Date: September, 29th, 2006
OpenQueue is an open protocol for publish-andsubscribe message queuing. This enables languageindependent,
loosely-coupled,
asyn-chronous
communication between applications running on
different machines.
The system is not a framework consisting of connectors and transformers, but
an Open Source alternative to message queuing products such as MQSeries.
3.2.17 OpenSymphony
Name:
OpenSymphony 2.7.0
Web Site :
www.opensymphony.com
Description
:
OpenSymphony is a Java Open
Source project designed to
provide application developers
with a suite of components for
rapid development of enterprise
class Java applications.
These components are loosely
coupled, allowing the application developer to use one or
more of them in a single application.
The components are:
CRP Henri Tudor
•
OSCore: a set of utility-classes useful in any J2EE application
•
XWork: command pattern framework
•
OSWorkflow: components to allow construction of applications based
around organization workflow; models entity versioning system, states
(e.g. draft, approved, published) and rules (e.g. user X may change this
version to the approved state)
•
Quartz: an enterprise level job scheduling system that can be
integrated with, or used along side virtually any J2EE or J2SE
application
•
OSUser: user-management system; contains tools for storing,
managing, verifying and authenticating users including web-based
applications; uses J2EE standards for authentication
•
OSAccess: Entitlement Security Engine; this module uses a pluggable
provider system for fine grain access control; this completes the
security that is left out of the J2EE standard
•
WebWork: an MVC framework that stresses simplicity and
interoperability
Page 40/112
Project Freegate: Market Survey of Open Source EAI Software
Reason:
Authors. Oechsle, Donak
Date: September, 29th, 2006
•
SiteMesh: presentation layer that sits on top of existing webapplication; will take simple pages produced by server (static, JSP
generated, CGI, anything) and provide customized presentation
•
OSCache: page caching mechanism to greatly improve the
performance of your site
•
ClickStream: utility to show the current users on your site, and where
they've been in detail; this allows you to track 'click streams' or 'traffic
paths' across your site
None of the components constitute a framework consisting of connectors and
transformers.
3.2.18 Orbeon PresentationServer
Name:
Orbeon PresentationServer 3.0.1
Web Site :
www.orbeon.com/software
Description
:
Orbeon PresentationServer (OPS) is an Open Source J2EE-based platform for
XML-centric web applications. OPS is built around XHTML, XForms, XSLT,
XML pipelines, and Web Services, which makes it ideal for applications that
capture, process and present XML data.
Unlike other popular web application frameworks like Struts or WebWork that
are based on Java objects and JSP, OPS is based on XML documents and
XML technologies. This leads to an architecture better suited for the tasks of
capturing, processing, and presenting information in XML format, and often
does not require writing any Java code at all to implement your presentation
layer.
While similar to Apache Cocoon, OPS benefits from standards-based forms
processing using XForms, richer controller semantics, and full-featured XML
pipelines described with XPL, the XML Pipeline Language.
Reason:
CRP Henri Tudor
The system is not a framework consisting of connectors and transformers, but
a system which is comparable to Apache Cocoon. Although there is an
extremely valuable tutorial and other types of documentation, and although
there is support for querying data from an SQL database or an LADP server,
we do not consider the Orbeon PresentationServer as a general EAI solution.
Page 41/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
It has similarities with DataServer.
3.2.19 OSMQ
Name:
OSMQ 2.0.4
Web Site :
www.osmq.org
Description
:
Open Source Message Queue (OSMQ) is an advanced asynchronous message
router, message broker and message middleware framework developed by
MQue Systems. The product and client adapters are 100% Java based, with an
open and published message interface to support non-Java clients. OSMQ was
designed for high performance, high reliability, and ease of use, with a Java
interface that is significantly less complex than JMS. OSMQ supports a
publish-subscribe and point-to-point message architecture, employing a
queue-based store-and-forward model of message distribution.
Reason:
The system is not a framework consisting of connectors and transformers, but
a message queuing system.
3.2.20 ServiceMix
Name:
ServiceMix 3.0
Web Site :
servicemix.org
Description
:
Apache ServiceMix is an
Enterprise Service Bus (ESB)
that
combines
the
functionality of a Service
Oriented Architecture (SOA)
and
an
Event
Driven
Arthitecture (EDA) to create
an agile, enterprise ESB.
ServiceMix is an Open
Source distributed ESB built from the ground up on the Java Business
Integration (JBI) specification JSR 208 and released under the Apache license.
The goal of JBI is to allow components and services to be integrated in a
vendor independent way, allowing users and vendors to plug and play.
Reason:
CRP Henri Tudor
ServiceMix provides an infrastructure that is quite similar to Mule and also
supports the same technologies like ESB, JBI (even for the core API), SEDA
and SOA (see also section 3.3.3 at page 59). But unlike Mule, it does not
provide an infrastructure to simply configure a schema that allows to integrate
applications and route information between these.
Page 42/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
3.2.21 S-integrator
Name:
S-integrator 1.06
Web Site :
www.s-integrator.org
A
service-oriented
integration server that
hosts Service Stores
which
authorize,
monitor, manage and
run
services
while
making them available
through web services,
HTTP
and
other
protocols.
Included
listeners and inbound
adapters support address
banning,
content
filtering and a virus
detection filter. Included
outbound
adapters
integrate
databases,
mainframes
(APPC),
web servers, FTP, mail
Description
:
and other technologies.
Administration is performed using a web browser or cell phone that accesses
the embedded web server. Service Flows provide process automation and hot
deployment is supported. S-integrator is single-source, small footprint and
only requires JRE 1.2 and a database with JDBC driver.
The system has been deployed at American Express, one of the three leading
credit card companies.
Reason:
CRP Henri Tudor
The system neither provides a sufficient documentation nor any examples that
would allow to implement a test schema & actually use the system. The
community could also not used as source for information, as none seems to
exist.
Page 43/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
3.2.22 SolAce
Name:
SolAce Secure Wire 1.2
Web Site :
www.snapinhipaa.com/ss/
Description
:
SolAce Server is a secure and
reliable messaging server which
supports point-to-point and huband-spoke topologies. It can
securely transfer EDI and other
types of files over any IP-based
network without VPNs or other
software. The protocol is based on
concepts in IETF's AS2 protocol,
including features such as signed
and authenticated receipts.
A Web interface serves as an
administration and mailbox portal to let users maintain their own mailboxes
and files. SolAce Server was designed for the proposed HIPAA Security Rule,
which was stricter than the final rule.
Professional support is provided by the main developing company named
Vertex.
Reason:
The web page says: “SolAce Server has been discontinued as of 12/15/2004
due to lack of interest and for being a personal money pit”.
3.2.23 Tambora
Name:
Tambora 3.0
Web Site :
tambora.zenplex.org
Description
:
A leading edge Enterprise Application Integration (EAI) tool specifically
created for the printing and publishing industries. Tambora can adapt to any
organization's internal processes and requirements. At the heart of Tambora is
a world class workflow engine which will allow Tambora to seamlessly
integrate into any existing enterprise.
Reason:
Neither the web page nor the application seem to be available. Thus the
system will be mentioned but excluded from further investigation.
3.2.24 Xineo XIL
Name:
Xineo XIL 1.1.0
Web Site :
software.xineo.net/xil.jspx
Description
:
Xineo XIL (XML Import Language) defines an XML language for
transforming various record-based data sources into XML documents, and
provides a fully functional XIL processing implementation. This
implementation has built-in support for relational (via JDBC) and structured
CRP Henri Tudor
Page 44/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
text (like CSV) sources, and is extensible thanks to its public API, allowing
dynamic integration of new data source implementations.
Reason:
The focus of Xineo XIL is more on the transformation part, and less on the
connectors part. Currently, the only data sources are files and databases,
although other source types can be implemented by the users of the system.
3.2.25 XMLBlaster
Name:
XMLBlaster 1.0.6
Web Site :
www.xmlblaster.org
Description
:
XmlBlaster is a publish/
subscribe and point to point
MOM
server
which
exchanges messages between publishers and subscribers. The message is
described
with
XMLencoded meta information
Messages may contain
everything, GIF images,
Java
objects,
Python
scripts, XML data, a word
document, plain text.
Communication with the
server is based on CORBA (using JacORB) or RMI or XmlRpc, clients are
free to choose their preferred protocol. Other protocols like email, socket or
SOAP may be plugged in. Subscribers can use XPath expressions to filter the
messages they wish to receive.
XmlBlaster uses the Sun XML parser for XML parsing, and XT from James
Clark for XSL parsing. The XmlBlaster server is pure Java. PHP, Perl,
Python, C, C++, C#, Visual Basic.net and Java (applications, servlets, applets)
client samples are delivered in the XmlBlaster distribution.
Reason:
CRP Henri Tudor
At first sight the system is not a framework consisting of connectors and
transformers, but a message queuing system. The message queuing server can
be accessed by special APIs in different languages. But because of the
possibility of developing different plugins, the system may well be used for
application integration. It was however excluded from further investigations
because its main purpose is not application integration.
Page 45/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
3.3 Evaluation phase II
The second evaluation phase checks in-depth the systems that passed the first evaluation
phase described in section 3.2 by the use of the check list as described under “Evaluation
detail criteria“ at page 13.
CRP Henri Tudor
Page 46/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
3.3.1 Babeldoc
Babeldoc is a document processing system that claims to be especially suited for Business-toBusiness (B2B) environments and similar integration projects. Babeldoc has a flexible and
reconfigurable processing pipeline through which documents in any format, binary or text
based, flow. These pipelines transform the document. Additionally, Babeldoc has a
sophisticated and extensible journaling system so that documents may be reprocessed and
resubmitted as well as tracked through the system.
Its goal is to be a lean tool that provides sufficient functionality for system integration in an
easy to use way.
Architecture
The Babeldoc system consist of the following main elements:
• Scanner
scans external sources frequently for messages and feeds them as documents into a
pipeline.
• Document
consists of the data coming from the external applications and additional meta information
called attributes e.g. filename in case of data coming from a file.
• Ticket
a unique id that will be assigned to a document if it enters the pipeline. This id allows to
identify the document at any stage of the pipeline.
• Pipeline stage
the smallest step of a pipeline that applies business logic to the document, routes it to a
different step depending on certain conditions or sends the file to an external application.
• Pipeline
a series of pipeline steps.
• Journal
coordinates the processing of a document, logs processing information and allows to feed
a document back to any stage of a pipeline, if needed.
In the following, the interaction between these components will be explained:
Figure 5 Babeldoc architecture schema
CRP Henri Tudor
Page 47/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Scanner
A scanner
regularly examines the interfaces of external applications . If the scanner
fetches data from the interface, it forwards it to the attached pipeline for processing. Scanners
are stand alone processes that perform the scanning of the different external sources like a
FTP account or a database.
They are able to feed the fetched data either synchronously one after another to the pipeline
or to fetch and provide all messages at once through the use of parallel threads (asynchronous
processing). Optionally a thread pool may be used in the asynchronous mode.
Pipeline
A pipeline consists of a set of processing steps that are linearly arranged, the so called
pipeline stages. A pipeline has a defined entry point to which an incoming message is fed.
As soon as a binary or text message arrives at the pipeline , a document will created that
contains the actual data as workload and additional meta information, so called attributes.
Before the document enters the first pipeline stage, the system assigns an unique id
document, a so called ticket, which allows its identification within the pipeline.
to the
The document will be processed and altered by the different pipeline stages
. Babeldoc
provides a multiplicity of pipeline stages. Even the use of JavaScript within a pipeline stage is
possible in order to gain the highest flexibility possible.
After the pipeline processing, the resulting document is sent to external target systems
a database or a SMTP server.
like
It is a little strange that the message sinks that link to the external target applications are
integrated into the pipeline whereas the message sources are separate processes outside the
pipeline.
Journal
All pipeline processing information about a processed document are stored in the journal .
–
After the document processing of a pipeline stages, the journal assigns a new ticket step
a combination of the document id and a pipeline stage id – to the document and determines
that way the pipeline stage that will process the document next.
It is also possible to store document as it looks like at certain pipeline stages in the journal.
This can especially during the setup of a new pipeline be very helpful for debugging
purposes.
All journal information can be stored either in the file system or in a database . This allows
persistence of document processing, which allows to continue the document processing e.g.
after a power outage at the same pipeline stage it has been interrupted before. It is also
possible to manually reefed a document from the journal to any pipeline stage. E.g. if a
processing error occurred.
The error handling itself is unfortunately quite weak as it just allows to define if the
processing of a document should go on or not in case of a processing error. Advanced
features like a mechanism that allows to store erroneous messages to a database or at leas to
send an email notification of an administrator, are missing.
Runtime environments
Babeldoc is flexible so that it can run standalone, in a web container or in a J2EE container
(currently tested on Jboss 2.4.x and JBoss 3.0.x).
CRP Henri Tudor
Page 48/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
The system can be run synchronously what leads to a serial processing of all documents. For
higher performance requirements the system can also be run asynchronously, which allows
the parallel processing of multiple documents. In this mode it is also possible to a threadpool
to increase the performance even more.
Features
Babeldoc features connectors for the most common protocols and channels like JMS, SMTP,
HTTP, databases, FTP, files, sockets and SOAP.
For the active polling of external sources, Babeldoc provides scanners that examine the
interfaces for new messages and feed them to a pipeline. Scanners are available for files, mail,
FTP, databases and HTTP.
For the actual document processing Babeldoc provides a comparably huge collection of
predefined message transformation and modification modules. The span reaches from the
transformation of text messages to the XML format – that by the way supports fixed length
and multi-level delimited messages – over the use of the Velocity template engine up to the
generation of RSS channels. Even the generation of SVG images and FOP documents is out
of the box possible.
Similar to JyRetic, Babeldoc also works with metadata that can be dynamically attached to
documents and can be used to e.g. influence the configuration and behaviour of pipeline
stages.
For occasions for which no predefined pipeline stage exists, an additional pipeline stage
comes into play that allows the use of JavaScript to define a business logic that corresponds
to the users need. Besides JavaScript, the obligatory, powerful XSL transformation is possible
as well.
Routing, within a pipeline or to a different pipeline, can be either predefined or dynamically,
depending on the message content or the metadata of the document. Transactions are
supported via the journal, which also features a replay option that allows to reprocess a
document.
Message encryption support including digital signing seems to be available. At least Babeldoc
provides pipeline stages to cipher and sign a message but their use is nowhere documented.
The use of encrypted communication channels is not yet implemented, which hampers the use
for sensitive data and in insecure environment.
Support for the compression and decompression of messages is available, which is especially
useful for the processing of larger data amounts like graphics or even film footage. Also
exists a pipeline stage that allows to add a document content to an existing zip archive.
The configuration of the components can be accomplished in java properties or XML style. It
can be complicated and confusing to configure a pipeline because of the many different
configuration files that have to be used and that are not always logically separated. Please
consult the “Test schema” paragraph further below to learn more about this issue.
Support
The documentation comprises a User Guide, a Developer Guide and a White Paper. The
documents are well structured but incomplete. There exists a user and developers guide in a
pseudo XHTML format which is just viewable in the xml representation. Obviously has
Babeldoc a build in pipeline that should be able to generate a viewable, well formatted
document out of these files. Unfortunately this pipeline neither works nor is it mentioned
anywhere.
CRP Henri Tudor
Page 49/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Very important issues like detailed information about the available pipeline stages, scanners
and their parameters are completely missing and have to be gathered as far as possible from
the examples. Fortunately Babeldoc features a lot of examples regarding the configuration of
pipelines and scanners. The explanation in the readme files is very minimalistic but the
examples are usually self explaining and thus the best entry point for the creation of own
pipelines.
The only available additional support are the forums on the sourceforge site of Babeldoc.
They contain some helpful information about the obstacles and “think-abouts” of the system
and it is possible to gain help from other users and even the developers. The only drawback
here is that they are not very frequented recently.
Usability
Trying to ease the life, Babeldoc provides a multiplicity of graphical tools to create a new
project or to configure and control pipelines and scanners.
Figure 6 Babeldoc Pipeline configurator
This seems at the first glance very ideal but the configuration code generated by these tool is
incomplete and some parameters configured in the frontends do not appear at all in the
configuration. This results in not working components. The structure of the generated
configuration is furthermore random. This makes it hard to complete or change it by hand
afterwards.
The frontends are started as a parameter when the Babeldoc core engine is executed. This is
mentioned nowhere in the documentation. Finally, it is not comprehendible why seven
different frontends are existing that have do be started all separately. Several of these
frontends are redundant or performing work at the same component. It would have been more
reasonable to provide one frontend that allows to configure and control the components.
For the viewing and control of the journal provides Babeldoc an additional frontend:
CRP Henri Tudor
Page 50/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Figure 7 Babeldoc journal viewer
This frontend allows to view the different processing steps of a message and also enables the
user to view a stored message or feed it back to the pipeline. The message can just be fed
back to the begin of the pipeline. The feed to a certain pipeline stage has to be triggered from
the command line. If a message is viewed, the journal viewer displays its attributes and the
message content. As the message content is displayed as cryptic figures, this is less helpful to
view the message structure at a certain pipeline stage.
Test schema
Babeldoc provides neither a TCP/IP connector nor the possibility of message recomposition.
Thus the schema had to be cut down on simple processing of a message coming from the file
system. The remaining parts of the test schema could be realized by the means of Babeldoc.
Babeldoc features two different approaches for the schema definition, property based and
XML. As XML is widely used as a configuration standard and can be imported by many tools
and applications, this variant was chosen for the configuration of the test schema.
In order to configure a test schema, several configuration files have to be created:
• Scanner configuration
• Pipeline configuration
• Pipeline definition
• Flat file to XML definition
• XSLT transformation style sheets
Even if XML has been chosen for the test schema, some of the configuration files had to be
created in property style others had to be always in XML style. Besides that, this multiplicity
of configuration files can be quite confusing at the beginning, especiall, as some of them seem
to be unnecessary. It is not obvious why a pipeline needs besides its definition file also a
configuration file that just describes the pipeline type (simple or XML). Also, the definition
of polling sources is done in separate files (scanner configuration) whereas the sinks are
defined within the pipeline.
After the start of the schema, Babeldoc indicated an error during the message processing at a
certain pipeline stage. Unfortunately it didn’t provide any useful error message – neither in
the log file nor in the journal – that would help to track down the cause of the problem.
CRP Henri Tudor
Page 51/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Thus the tester had to implement the same configuration in property style which run
flawlessly. Obviously Babeldoc still has some problems with the XML-representation of
configuration files.
Conclusion
Without question, the main advantage of Babeldoc is its huge library of pipeline stages. That
way, the requirements of the most scenarios can be quickly fulfilled out of the box. The
project contains an impressive number of connectors and transformer including FOP and
SVG.
The possibility to use, besides XSLT, JavaScript extends the application possibilities for
exotic and complex message modifications requirements.
TheJournal is as well a nice concept for pipeline control and tracking and a means that allows
persistence during the document processing.
On the other hand, the architecture also has some inconsistencies. There is a distinction
between scanners (which are source connectors) and pipeline stages, but there is no
distinction between sink connectors and pipeline stages. Moreover, regarding routers as
normal pipeline stages results in some odd configuration entries.
The documentation is incomplete, which states a major obstacle for potential users. There is
virtually no information about the tools that come with Babeldoc. Also to other, even more
important facets, like the available scanners and pipeline stages, are not paid regard in the
documentation.
There documentation for developers is little useful. The majority of the needed information
have to be extracted from the source code. This bears the risk to the scare potential
contributors. The only way to gain support are the forums that are very low frequented.
CRP Henri Tudor
Page 52/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
3.3.2 JyRetic
JyRetic is an EAI Server that has been significantly inspired by the OpenAdaptor project,
which is decribed under section 3.3.4 at page 67. Thus the architecture and the naming of the
components are quite similar. The goal of the JyRetic project is to create a system with the
proven architecture of OpenAdaptor but which is easier to use than the model system.
The project started under the name Retic and was initially developed in Python. Unfortunately
Python lacks connectivity with databases and MOMs. In order to be able to provide as well
this often needed connectivity, Retic was translated from Python to Jython and relabelled as
JyRetic.
Jython is an implementation of the high-level, dynamic, object-oriented language Python
written in 100% Pure Java,, and seamlessly integrated with the Java platform. Jython is
provided in the release of JyRetic. So all that is needed is Java 1.3 or higher.
Due to the lack of resources, the development of the Python-based Retic version had
officially been stopped.
Architecture
As OpenAdaptor has served as model for JyRetic, the architecture is similar:
• Adaptor
A one way link between one origin and one or more destinations
• Source
This component fetches the message from the delivering external system or a messaging
system that delivers a message from another adaptor.
• Pipe
This component modifies the message data
• Sink
This component delivers the message to the receiving external system or a messaging
system that interconnects adaptors in order to further process the message by another
adaptor.
In addition to the primary components listened above, JyRetic provides some optional
components that not directly affect the message processing but are nevertheless quite helpful:
• Metadata dictionary
allows the exchange of meta information between different components and the dynamic
component configuration.
• Preprocessor
executes only once during adaptor execution, before polling begins. This component can
be used for adaptor initialization.
• Postprocessor
executes only once after all polls have terminated
• Logger
enable local and remote logging for an adaptor
CRP Henri Tudor
Page 53/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Adaptors are tree-like structures that could be pictured this way:
Figure 8 JyRetic adaptor structure example
The complete logic and all components are contained in a so called adaptor. The Adaptor has
a nesting structure which corresponds to a tree structure as shown in the sample structure in
Figure 8. It is possible to attach multiple sinks at every stage of the adaptor. Every think that
is attached to a state, receives the currently processed message at this point. This mechanism
allows a basic, restricted form of static routing but no dynamic routing depending on message
contents or any other conditions. As the architecture is similar to OpenAdaptor, it has the
same pitfall of unidirectional messaging. This results into the inability of the support of
systems that use connection based messages that require an acknowledgement like HL7 or
DICOM which are the two most widespread protocols in the healthcare sector.
Message
JyRetic does not define a certain message format or provides certain message containers. But
it features several possibilities to transform a message coming from an external system to and
from the XML-format. As to message mapping and the metadata dictionary access also
requires a XML-formatted message, this form of representation is recommended.
Metadata dictionary
Information coming from messages can be extracted and stored in a so called metadata
dictionary that acts as a global information repository. These stored information can be used
by other components of the adaptor. Moreover, this mechanism also allows the dynamic
configuration of components. Such an scenario could be an email address that is extracted
from a message and afterwards stored in the metadata dictionary. Later on as the message
reaches an email sink, the email address can be fetched from the metadata dictionary and
dynamically be set as the recipient address in the sink configuration.
Pre- / Postprocessors
Pre- and postprocessors do not process any message content but can be used to initialize or
finalize the adaptor before the source polling starts, respectively after adaptor execution,
when all polls are terminated. These components are also able to access the metadata
dictionary.
Through the use of XMLRPC services, a distributed system canc be set up and it is possible
to start an adaptor instance on a remote system. Therefore its XML-specification is sent to the
remote instance as a JMS message.
CRP Henri Tudor
Page 54/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Logging
Local logging with rotating log files as well as remote logging via Jabber, socket or email is
possible.
Features
One of the most important considerations of an EAI system is its connectivity. JyRetic covers
with the support of flat files, FTP, HTTP, SQL, SMTP, SOAP and different messaging
systems like JMS, XMLBlaster or Jabber the majority of the usually needed interfaces. In
addition to that it features advanced connectors like the tree-like representation of related
SQL requests that can as well be placed on different databases. Last but not least it also
supports the XML-database Xindice of the Apache project.
Even if this interface list should already meet the majority of usual requirements, some
additional interfaces like a email source and interfaces for a simple socket connection would
still increase the pleasure.
Besides the interfaces themselves, the system comes also with a variety of pipelines for the
message processing and modification. Flat message strings can be transformed to XML and
back, the XML structures can be accessed, altered and copied to the metadata repository.
The generation of different file formats from message contents like Excel sheets, Postscript
and PDF are supported as well. For messages with a large workload exists compression
support. These messages can be compressed or decompressed by the use of the ZIP algorithm.
On the security side exists still a lot of space for optimization. Unfortunately, so far does not
exist any support for encryption of message data or communication channels. This prevents
the application of JyRetic - especially as distributed system - in insecure environments and
with sensitive data. This circumstance is even more emphasized through the absence of
transaction support.
The configuration of the system is done via an XML file that holds all configuration
parameters of an adaptor and its components. It is possible to define variables as
configuration values. The values for these variables can be stored in a separate parameter file.
This mechanism allows to start the system with different parameter files that reflect different
environments like development, testing or production in case of a staged system.
The second option of dynamic configuration that can even depend on the particular message
contents is the use of variables coming from the metadata dictionary. This mechanism is
further described under the paragraph “Architecture” of this section.
The error handling is not that sophisticated. If an error occurs during message processing, the
message can be saved to a configurable path & an error message can be sent to an
administrator if the SMTP-logger is enabled. The possibility to remotely view and modify the
erroneous message or even feed the altered message back to the adaptor does not exist.
Support
The web site contains several HTML pages, which shortly but clearly describe the main
concepts of JyRetic, its components and their configuration. A detailed description is often
missing, incomplete or obsolete. Especially the non-existent API-documentation could
prevent JyRetic from gaining external contributors. The documentation for the Retic
administrator tool, is as well out of date but a set of flash animations show descriptively the
main functionalities of the tool and their application.
CRP Henri Tudor
Page 55/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
The sourceforge site hosts two forums, one for support and one for open discussions, which
contain nearly no postings. Mailing lists do not exist but the contact address of the main
developer is provided on the website.
A particularity are the five RSS feeds that deliver different information from project news
over release info up to documentation. Unfortunately these feeds do not seem to be
maintained anymore.
Usability
JyRetic comes with a pretty configuration, administration and monitoring interface called
Retic Administrator. Through a XMLRPC interface the frontend is able to remotely
communicate and control adaptors. The configuration of the adaptors is very detailed and
clear. Components can be chosen from select boxes and added by buttons with graphical
symbols. The different sections like configuration, monitoring and administration are
separated by panels.
Figure 9 JyRetic configuration and administration frontend
This results into a very high and intuitive usability of this tool. This is as well crucial, because
the frontend lacks of documentation or any other kind of support like hints or a help section.
The documentation that comes with JyRetic is outdated and covers just a tiny part of the
features. There are some Flash animations at the website that show some of the major tasks
which can be accomplished by this tool.
Alone the XSL-stylesheet definition for the message transformation and mapping and the start
or shut down of a server instance can not be managed by the GUI. A XSL-stylesheet
generator and validator for the mapping or transformation of messages would be a very handy
extension of the frontend.
CRP Henri Tudor
Page 56/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Nevertheless, with Retic Administrator, JyRetic provides the most advanced graphical
frontend of the tested EAI-Systems. This tool fulfils nearly every requirements toward such a
tool in a comfortable way.
Test schema
Like the huge majority of the tested systems, JyRetic does not support recomposition. Thus
the test scenario had to be altered. Both messages (System A and System B) have been joined
to one delimited message that was fetched by a file source.
Thanks to the graphical frontend, the creation of the schema was very comfortable and easy to
accomplish.
The absolute contrary to that was the effort to start and test the generated schema. The
attempt to start the adaptor via the frontend led to a connection refused error without further
explanations, neither in the frontend nor on the website. The start of the adaptor via command
line was also not as easy as described in the documentation. Before the system was able to
start anything, the start scripts had to be heavily altered. The Jython start script used a fixed
path for java runtime environment and the paths for the required java libraries were wrong
and incomplete. The creation of an install script would drastically lower the entry barrier for
potential users and developers.
Some smaller issues can also become a big obstacle if it comes to running the schema. One is
the proper use of the crucial pipes which convert a flat string to XML and the other way
round. For the transformation from XML to a flat string, one or more ASCII characters have
to be set as delimiters. For the transformation from a flat string (e.g. CSV) to XML, a
delimiter has to be defined by setting the numeric value for the wanted ASCII character. This
particularity is mentioned nowhere and leads to strange but not helpful error messages at
runtime.
If the particularities are figured out and the system configuration is adjusted, the adaptor
works stable and fast.
Conclusion
The architecture of JeRetic is very clear and simple. So is the structure of the configuration
files. The Retic Adminstration tool further simplifies the generation and management of
adaptors. The system comes with a notable number of components that should be sufficient in
the most cases. The available documentation is well structured and fosters a quick adaptation
process.
JyRetic is based on Jython. As this is not a widespread coding language, it can be hard to
write own components and to find contributors. The missing API and developer
documentation intensify this effect even more. An installation package would notably lower
the entry barrier as it is not possible to run the system using the scripts it is coming with.
The second weak point is the security as the application in its current state does not support
any security features starting from transaction support up to the encryption of messages or
communication channels.
Finally, due to the similar architecture to OpenAdaptor, the communication through the
adaptors is only unidirectional. This prevents the implementation of acknowledgement
orientated protocols.
Nevertheless, JyRetic is one of the most mature EAI systems on the Open Source market.
Besides the view issues described above it is quite quickly and easily possible to establish a
working integration schema. This is especially enabled through the clear architecture, the
intuitive configuration frontend and the availability of many useful sources and sinks.
CRP Henri Tudor
Page 57/112
Project Freegate: Market Survey of Open Source EAI Software
CRP Henri Tudor
Authors. Oechsle, Donak
Date: September, 29th, 2006
Page 58/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
3.3.3 Mule
Mule is an Enterprise Service Bus (ESB) messaging framework with the goal to provide a
unified method of interacting with data from disparate sources through a transparent data and
protocol handling.
Mule was designed around the Enterprise Service Bus (ESB) architecture, which stipulates
that different components or applications communicate through a common messaging bus,
usually implemented using JMS or some other messaging server. Mule goes a lot further by
abstracting JMS and any other transport technology away from the business objects used to
receive messages from the bus.
The system is java-based and thus can be deployed on any operating system that provides
support for JDK 1.4.
Architecture
The primary goal of Mule is to enable integration between applications using standards, open
protocols and well-defined patterns. To achieve this goal, Mule implements the architecture
and terminology described in the book “Enterprise Integration Patterns” by Gregor Hohpe.
Figure 10 Mule architecture
•
Mule manager
It handles and coordinates the different components of the Mule EAI system (see
Figure 11 and Figure 12) which are used to control the message flow and to process
the messages.
•
Mule model
The SEDA-based model is the container in which the components are managed and
executed. It controls message flow between the components, manages threading,
lifecycle and pooling.
•
UMO component
Universal Message Objects (UMO) are the business objects of the mule system. They
are standard JavaBeans that execute business logic on incoming messages. Routing
and transformation of events to and from UMOs are handled transparently based on
the component’s configuration.
CRP Henri Tudor
Page 59/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
•
Endpoint
Endpoints define communication channels between two or more components,
applications or repositories. They allow the Mule objects to talk over any protocol in
a unified way.
•
External application
External applications can be anything from application servers to legacy payroll
systems, to mainframe trading applications or a client application.
The Mule model defines a set of components that are used to perform the major part of the
work necessary to make disparate applications and services communicating.
Figure 11 Mule architecture detailed
Stages
The following schema explains the different involved components and stages more detailed:
Figure 12 Mayor Mule components & stages
Figure 12 shows the main components within a Mule schema and their chronological order.
1
Endpoint
As explained above.
2
Router
Routers control the flow of messages between components and can re-sequence,
aggregate or filter incoming messages.
CRP Henri Tudor
Page 60/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
3
Interceptor
Interceptors are used to intercept message flow into a service component. They are very
helpful to trigger events or interrupt the flow of a message. They can in example be used
for security features to ensure that the current request has the correct credentials to
invoke the service or to monitor the message flow.
4
Transformer
Transformers are used to transform the messages from the format of the external systems
that are attached to the EAI to a format that is needed by the internal Service components
(UMO) of the Mule system and visa versa.
5
Service invocation
The service is the business logic. The business logic itself is always encapsulated into a
Universal Message Object (UMO) as described in the paragraph above.
Communication
A mule application is intended to consist of many mule instances across the network whereas
each instance is a light-weight container. Every containers host one or more UMO component
that are connected through endpoints either to external applications or other UMOs.
Figure 13 Schematic example of a Mule configuration
The architecture of Mule claims to be highly scalable, using ideas from the staged eventdriven architecture (SEDA) design pattern.
SEDA is intended to support massive concurrency demands and simplify the construction of
well-conditioned services. In SEDA, applications consist of a network of event-driven stages
connected by explicit queues. This architecture allows services to be well-conditioned to load,
preventing resources from being overcommitted when demand exceeds service capacity.
Event processing can thus be performed asynchronously according to the SEDA design
pattern as shown in Figure 14.
Figure 14 Asynchronous event processing
CRP Henri Tudor
Page 61/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
A synchronous way of event processing is optionally also available:
Figure 15 Synchronous event processing
The connectors extend messages fetched from a external system with meta information. These
meta information contain entries like the message type, message origin or the file name in
case of a fetched file. The message itself will be unaltered attached as workload. A negative
side effect of this approach is missing ability to access or validate the message structure. The
transformation into an uniform format like XML or a Java container would make things easier
here.
Features
Mule endpoints are in principle bidirectional. Thus it must not be differed between sending
and receiving endpoints. A large number of connectors for the interaction with the most
common protocols are provided:
• Flat files
enables the reading and writing of binary and text files from the file system.
• Socket
different socket-based protocols like TCP, UDP, IP multicast, streams as well as mail
protocols like SMTP, IMAP, POP3 and web protocols like HTTP, FTP, HTTP, SOAP,
WSDL are supported.
• Database
access to relational databases through JDBC.
• RMI
support of remote method invocation over JRMP.
• Messaging
JMS v1.02b & v1.1, Jabber (XMPP)
• Other
servlet provider to enable the system to send and listen for servlet requests, EJB
connector to allow EJB invocation and Intra VM connector for the communication
between components running in the same virtual machine.
Besides these generic protocol connectors exist some specific application connectors
• AS400 data queue
for synchronous or asynchronous communication with AS400 RPGs.
• Quartz
a chron like free software based scheduling application.
Mule provides a variety of means to secure the information exchange between the attached
systems. It provides a security manager that allows, in combination with the interceptors (see
Figure 12), the authentication of requests. Even a method-level authentication for single
UMOs can be configured. The current security implementation supports
• JAAS
Java Authentication and Authorization Service
CRP Henri Tudor
Page 62/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
• LDAP
Lightweight Database Access Protocol
• CAS
Central Authentication Server
• DAO
Data Access Objects
Furthermore it provides different encryption algorithms for the communication channels like
• SSL
• TLS
• HTTPS
and PGP for the encryption of the transferred data itself.
For the internal processing, the messages will be enriched with meta information like message
type, message origin and message specific information like the file name of a message
coming from a file connector. Unfortunately the message itself will just be added as workload
in its raw format. This circumstance avoids a comfortable access to the different message
field. Parsing the message into a XML structure or nested JavaBeans would have been more
feasible. For bandwidth reduction, the messages can be compressed by the GZIP algorithm.
Another drawback of the missing capability to parse a message into a message container like
XML is impossibility to map a message from one format to another or to change or enrich the
message content through configuration.
Indeed Mule provides the possibilities to alter XML messages by XSL transformers as well as
the transformation of XML files to Java objects and visa versa. But the possibility of parsing
a delimited or “fixed length field” into a XML structure or Java object is missing so far.
Figure 16 Transformer chaining
The existing transformers can be freely chained up (e.g. like shown in Figure 16) to provide
the highest possible flexibility during message transformation.
Mule realizes the error handling trough so called exception strategies which are defined in the
configuration file of a Mule instance. Exception strategies are used to handle exception
conditions when an error occurs processing an event.
Figure 17 Mule exception strategies
Exception strategies can be applied at three points:
CRP Henri Tudor
Page 63/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
• Connectors
handles exceptions thrown during sending or receiving messages
• Components
handles exceptions during the execution of the business logic of a component
• Model
the default exception strategy for the whole model in case of exceptions during the
business logic execution
In terms of the exception strategies, the exceptions and also the messages that caused the
exception will be send to an error queue for further processing.
Mule's transaction framework support different transaction types
• JDBC
• XA
• JMS
• Message acknowledgment
All transaction are handled the same way. Endpoint can be configured to start a new
transaction or join an existing one.
The system is configured through a XML file. This configuration file contains all information
regarding the configuration of the involved elements and their interaction. Thus the
configuration can become very complex. Furthermore for a distributed system, a separate
configuration file for every mule instance has to be created. Thus it can become hard to
identify the general information flow between the involved components. A means for the
central configuration of all involved instances would be helpful to gain the required overview
about the dependencies and workflows.
Mule doesn’t provide any graphical interface for Administration and monitoring of the
involved components. But it provides a JMX interface that can be used in combination with a
Mbean-server to locally or remotely perform the following tasks:
• View the configuration state of the MuleManager
• Stop and start the Mule instance
• Stop and start the model
• Stop, start, pause and resume components
• Query event processing and endpoint routing stats on individual components
• Query event processing and endpoint routing stats for the whole server instance
Support
The documentation comprises a
• User Guide with examples,
• Architecture Guide
• Programmers guide
• Javadoc of the Mule API
• Configuration Reference
• Cookbook with examples
Besides that it provides a link list to background information about the underlying
technologies.
CRP Henri Tudor
Page 64/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
The documentation is structured and features many examples but often it is hard to find
needed information concerning a certain issue. Furthermore some parts of the documentation
are incomplete and just marked as “to do”.
The website provides several mailing lists for developers, users and announcements of new
features or mule versions. These mailing lists are quite frequented and help in case of
problems is usually provided fast.
Even faster help and realtime exchange can be accomplished through the Mule IRC channel
that allows the direct contact with the developers and other users.
Finally, the website provides a very structured bug tracker that shows detected bugs of the
particular Mule elements and their status. In addition to that it features several test cases for
the reproduction of bugs.
Professional support is offered by SymphonySoft, the main developing company, located in
the United Kingdom and Malta.
Usability
Mule provides a rudimentary tool for the configuration and start of mule configuration files.
Figure 18 Mule IDE
This application is still in an early state. During the tests it just could be used to assign an
existing configuration to a mule instance, configure the start parameters and start the instance.
Furthermore exists a tool called “Config Graph” that visualizes a mule configuration and
eases the understanding of the component dependencies and interactions. Unfortunately this
tool currently just supports single instances and does not show the dependencies amongst
distributed Mule systems.
As mentioned before, Mule doesn’t provide any graphical interface for Administration and
monitoring of the involved components. Through the JMX interface although, it is possible to
connect a MBean server to the mule instance. This approach allows the control of the
component, the monitoring of the instance and the generation of statistics.
Test schema
The whole test schema could be realized with Mule. At the beginning it was hard to master
the configuration because of its quite complex and not always clear structure. For example the
transformers that can be configured for inbound and outbound endpoint can either be
explicitly defined or directly be set within the endpoint URI.
CRP Henri Tudor
Page 65/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
The mapping logic of the schema had to be coded in Java by hand. This had been complicated
trough the absence of message parsers. Parsers split the incoming messages into their
elements and allow an easy access to these message elements. Without this capability the
business logic for message parsing has to be implemented by hand for every UMO. This can
fastly become nontrivial as the message structure becomes more complex.
Besides these issues the message processing including the configured polling worked fast and
flawlessly.
Conclusion
The Mule architecture is based on a sound theoretical background and quite open structured.
This allows to add missing features and connectors quite easily. Besides that possibility Mule
already provides a large variety of connectors, which include all major protocols.
Because of its architecture, the system is highly scalable and distributable. This assures the
availability if the needs in terms of performance and reliability are growing.
On the down side are the missing message parsers and containers that would ease the access
to the message elements and would enable the ability to validate the message structure.
Furthermore is the configuration file a little confusing because of its complex structure and
the amount of involved elements. A usable graphical frontend would be helpful to increase
the usability at this point. Also the documentation is structured but sometimes confusing,
sometimes incomplete. Restructuring and completion would lower this obstacle.
From the technical point of view, Mule represents a mature system with lots of features,
connectivity and scalability. In terms of usability the system still has a lot of optimization
potential, especially in terms of configuration and error management.
CRP Henri Tudor
Page 66/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
3.3.4 openadaptor
The openadaptor framework is developed and used by the “Dresdner Bank”, a major German
bank. It is a Java/XML-based software platform which targets a rapid business system
integration with little or no custom programming. It claims to be highly extensible and
provides already many ready-built interface components.
The framework is java-based and can thus be deployed on any operating systems that
provides at least a JDK 1.2 implementation although the use of JDK 1.4 is highly
recommended.
Architecture
Openadaptor comes with a framework that provides out of the box numerous beneficial
functionalities like :
•
•
•
•
•
Error Logging and Notification
Process Management and Monitoring
Exception/Repair Queues
Message Compression and Security
Benchmarking and Regression Testing
Figure 19 OpenAdaptor Structure
The architecture and terminology of openadaptor are pleasantly simple. The terminology
comprises the terms adaptor, source, sink, and pipe:
•
Adaptor
A one way link between one or more origins and one or more destinations
•
Source
This component fetches the message from the delivering external system or a
messaging system that delivers a message from another adaptor.
CRP Henri Tudor
Page 67/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
•
Pipe
This component modifies the message data
•
Sink
This component delivers the message to the receiving external system or a messaging
system that interconnects adaptors in order to further process the message by another
adaptor.
Every adaptor consists of at least one source and one sink. Pipe elements are optional and not
always needed as the remaining components are as well able to do minor message formatting.
An adaptor can contain an unlimited number of all components.
DataObject
If a source component of an adaptor receives a message from an external system, the message
will be transformed into a so called DataObject. A DataObject is a XML-structure that
describes the message structure, the naming of the fields and their cardinality.
DataObjects are the fundamental data structure that is internally used by the adaptors to
access an alter the messages. The DataObject structures can be nested by arrays of other
DataObjects in order to build up more complex message structures.
The advantage of this methodology is the easy access and modification of the message
elements.
Example
Figure 20 Openadaptor configuration example
The sample system consists of one source and two sinks. The messages are fetched over a
JDBC connector from a Sybase database. After the conversion to the data object format, the
messages are distributed to two separate branches.
The first branch starts with a pipe that performs conversion operations on the message (e.g.
field transformation, mapping to a different format or enrichment with additional fields). The
result is sent to a JMS-queue via a JMS-sink.
The second branch consists just of a file sink that writes the message to a text file on the file
system.
CRP Henri Tudor
Page 68/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Controller
The controller fulfils three main tasks:
• Start of the source component threads
• Coordination of the communication between the components
• Management of the transactions
Figure 21 Functional schema of the openadaptor controller
Each component runs in a separate thread. The component threads are started by the
controller after they have been initialized.
The source component fetches the messages from an attached external system (whether this is
based on polling, listening or call-backs). Then it requests the next available transaction from
the controller.
Afterwards, the source component passes the message to the controller. The controller in turn
passes the message to the next component that has been configured in the configuration file of
the adaptor. After this component has modified the message, it sends it back to the controller,
which forwards it to the next component until the message reaches a sink component. After
the transformation to the needed protocol, the sink component sends it to an external system
or a queuing system.
The message forwarding within the adaptor is done by a synchronous, local method
invocation that will eventually return to the source, if the message is successfully processed.
Otherwise an exception will be thrown.
If the source component receives an exception it will rollback the transaction, otherwise it
will commit the transaction. The controller is responsible for propagating calls to begin,
commit and rollback transactions.
Unfortunately the system accomplishes only one transaction at a time. That leads to the effect
that if one source component begins a transaction and a second source component attempts to
begin as well a transaction, the second source component will be blocked until the first one
commits or rolls back its transaction.
CRP Henri Tudor
Page 69/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Features
Openadaptor provides sources and sinks for the interaction with the most common protocols:
• Flat files
support of delimited files, fixed width formatted files, file reading from URLs and
reading of the openadaptor specific DataObject XML format
• Sockets
support of the FTP, SOAP, MAIL, LDAP and generic socket connections including
multithreading. Message splitting is supported as described under “Flat Files”
• JDBC
specific support for Sybase, Microsoft SQL Server, Oracle, Informix, MySQL, MSAccess and MS-Excel
• RMI
either provides a RMI service or registers to an existing one
• Messaging
JMS, Jabba instant messaging
Furthermore sources and sinks for the interaction with specific middleware products of
• TIBCO
for communication with the TIBCO Rendezvous system
• MQ Series
a queue-based middleware product of IBM
are supported. These special components ease the interaction with well established
commercial systems that can often be found in the integration environment.
In addition to the sources and sinks, which are already providing some functionality for
changing the message content, openadaptor provides pipes for the mapping and modification
of messages. Besides the possibility of coding own pipeline components, the following two
alternatives are available:
•
Attribute mapping
Java property like configuration of the affected fields and the activities upon them.
•
XSLT
As the internal representation of the messages is a XML format, a XSL style sheet can
be used to transform and modify the message contents.
The framework also provides means to assure the privacy of sensitive information during the
transfer through unsecured networks. Digesting, encryption and digital signing of message
data is supported by the use of the Java Cryptography Extension (JCE). Thus, all encryption
variants provided by this framework are also available for message encryption under
openadaptor.
For the internal processing, messages will be transferred into DataObjects, an ASCII based
XML representation of the messages. This can result into big messages, especially if an
binary message has to be ASCII encoded, e.g. by the use of the base64 algorithm. In order to
limit the required bandwidth the message can be compressed by the ZIP algorithm.
Openadaptor provides a framework for the handling of erroneous messages - the so called
Message Hospitals. An openadaptor Message Hospital is an interface to a repository, which
holds messages that could not be processed by an adaptor component.
CRP Henri Tudor
Page 70/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
It is important to note that there is no single central Message Hospital - each project must
deploy its own Message hospitals. Openadaptor simply provides the framework that allows to
implement a hospital for the user’s messages.
Figure 22 Openadaptor error handling example
Adaptors can be configured to send messages to a hospital, by inserting a HospitalPipe into
the component chain.
In case of an error occurring during the message processing as shown in C3 of Figure 22, the
raised exception will be escalated to the preceding components until a component is able to
handle the error.
If no component is able to do so, it finally reaches a source component (C1) and the
transaction will be rolled back.
If a hospital pipe has been included into the process it will catch the exception and create a
patient message. This patient message includes the message that caused the exception and
additional meta information like the reason and the source of the exception.
The patient message will be delivered to the Message Hospital database where it will be
stored for further processing. After modification, it can be fed back to the process.
The system also provides a tracking mechanism that stores information about the processed
messages including the detection of duplicate messages. In addition to that, as well
benchmarking components are available that allow to measure the processing efficiency. This
helps to find performance bottlenecks of the configuration.
Every adaptor is configured by java properties like or alternatively a XML configuration file
that defines the behaviour of the adaptors component and the structure of the adaptor. All
components can be controlled and monitored over a command line interface that allows the
use of scripting and automated startup and shutdown of adaptors. Alternatively exists a
remote monitoring and logging interface that allows to control the system via HTTP or RMI.
Support
The documentation comprises the
• White paper,
• Programmers guide,
• FAQ,
• DataObjects tutorial,
• Use Case description and the
• Javadocs of the openadaptor API.
CRP Henri Tudor
Page 71/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
The programmers guide is well structured and quite detailed. On the downside it is not up to
date and some information are missing. In example the configuration by XML files is
mentioned but not explained and the possibility of XSLT transformations is not mentioned at
all.
The distribution includes a cookbook directory with many sample configuration files. These
examples can help the user to work himself into the material. The only blemish is the fact that
they are neither commented, nor described elsewhere.
The openadaptor community provides a frequently visited forum and six different mailing
lists for different topics concerning users and developers. The response times to both are
usually quite short.
The search function of the web page is simple but works well and presents the search results
clearly arranged and separated by forum topics, mailing list messages, HTML pages and bug
tracker issues.
Professional training, consulting or support for openadaptor couldn’t be found to be provided
by any company.
Usability
The Adaptor Framework Editor is a GUI editor simplifies the whole process of constructing a
properties file and running an adaptor.
Figure 23 The Adaptor Framework Editor
The Adaptor Framework Editor covers all supported openadaptor components. The
components are separated by Sources, Pipelines and Sinks. In addition to that, the
components are categorized (e.g. encryption, XML, mail, ftp). The GUI displays the usable
elements at the left hand side of the window in an explorer style.
The remaining part is cut into a graphical representation of the configured schema on the
upper half and a list of the configurable parameters of the involved components divided by
tabs on the lower half of the window.
Tooltips with a short description of each component and property ease the understanding. In
addition to that, a detailed html help that is actually the same as the openadaptors
programmers guide, supports the user with the configuration of the schema.
CRP Henri Tudor
Page 72/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
The GUI uses text based configuration files in order to make it simple to add descriptions of
new components including user custom components. Unfortunately these comments will not
be preserved if the properties will be opened with the editor after the modification.
More meaningful are the validation checks with visual feedback that the editor performs if the
user likes to start or save the configuration. This feature clearly indicates the mandatory
parameter that still have to be configured in order to successfully run the configured schema.
Figure 24 The HAT message management frontend
The Hospital Administration Tool (HAT) is a graphical user interface to manage openadaptor
DataObjects, which have caused an exception as they passed through an Adaptor and have
therefore been rejected and collected in a data sink called "the hospital". The HAT provides a
means of viewing these "failed" messages (Patients) and, depending on the security
privileges, modify the attributes/structure that caused the problems in the first place.
Alternatively, Patients can be simply deleted from the hospital. The HAT comes as an
independent standalone application with a swing GUI.
Test Schema
The major part of the test schema could be realized with opadaptor. The composition of two
different message types, coming from two different systems, had to be left out because it was
not supported by the framework and it’s mapping approach. Thus just one source was used
that picked up already merged messages from flat files.
The tester has been unable to establish the polling for input files as the FileSource component
does not support polling. If the input file did not exist, the application terminated with an
error. If an input file could be found, it is read once and OpenAdaptor terminates. There are
more sophisticated file reader components that allow the polling of a directory. But these
could not be properly combined with the input readers for delimited strings that is needed to
parse the messages.
Besides these issues the test schema could be implemented without major issues.
Conclusion
CRP Henri Tudor
Page 73/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Due to the queue concept of openadaptor, a synchronous message processing is not possible.
Furthermore omits the unidirectional concept the bidirectional communication between
attached systems.
This is needed for certain protocols like HL7 or DICOM, which are the most used protocols
in the healthcare sector. This kind of protocols needs to establish a TCP/IP connection
between the communicating partners and to exchange a message and a response through the
same channel. This kind of communication is so far not possible in this framework.
The documentation is not up to date as at the time of testing, openadaptor version 1.7.1 has
been out but the documentation was still responding to version 1.7.0.
The file connectors miss needed functionalities like renaming, moving or removing a file,
coming from a file source, after it has been processed. During the tests it was not possible to
poll a directory continuously for new files.
On the other hand, openadaptor provides a clearly structured and documented integration
framework. In practice, the little outdated documentation should not lead to any serious
problems as the version change is minor. The existing documentation is very clear and well
structured.
The system already features many different connectors that should be suitable in the most
cases. Furthermore is provides many advanced features like sophisticated exception handling,
encryption, compression, graphical frontends and even exotic features like benchmarking and
remote logging & monitoring.
CRP Henri Tudor
Page 74/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
3.3.5 Proteus
Proteus is a framework for creating messaging applications and a message broker built upon
that framework. Proteus has adapters that allow databases, message queues, ftp servers, email
and other message sources and sinks to be addressed in a simple, uniform fashion. It differs in
approach from most other toolkits in supporting both centralized and point to point
implementations with a minimal footprint.
The system is java-based and thus can be deployed on any operating system that provides
support for JDK 1.1.
Architecture
As there is very little documentation of the architecture available, it can just be adumbrated.
The terminology of Proteus is quite similar to the one of openadaptor.
The main components are the following:
• Message source
This component fetches the message from the delivering external system. It is able to use
the communication channel and protocol of the external system.
• Message sink
This component delivers the message to the receiving external system. Also routers can act
as message sinks in order to implement branching.
• Filter
Transforms an incoming message into zero or more outgoing messages.
• Mapper
Maps a message onto another sort of object like a prepared statement for a JDBC
(database) connection or a JMS topic.
• Router
Brings a message on a certain path depending on a routing condition or regarding to a
predefined routing path.
• Broker
It can contain all elements listed above and their interactions. It represents the integration
schema of the scenario.
As a particularity of the Proteus architecture, the system can be run either as a centralized
structure (hub and spokes) or as a decentralized bus structure. That allows to use the
advantages of the respective topologies referring to ones needs.
On the opposite side of the coin there is no further explication how to set up the two
described topologies.
Messages
Proteus does not provide support for message containers. Usually a message is handled as
string, but other objects are possible as well.
The procession of a string representation of a message makes it hard to access particular
message fields and to validate the message structure. Support of message containers or at
least the possibility of a generic transformation to a XML representation of the message
would add notable comfort to the message handling.
Features
CRP Henri Tudor
Page 75/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
The feature list of Proteus is quite narrow. This on one hand allows to quickly understand and
use the system. But on the other hand this circumstance also limits the applications and the
flexibility of the system.
In terms of connectivity Proteus supports different messaging systems, the connection via
FTP and to databases. For the FTP and database connectivity, polling is supported.
The lack of support for additional crucial standard protocols like file access, email or socket
will rapidly drive the system application to its limits. The coverage of at least the most widely
used protocols and interfaces should be, besides a satisfying documentation, the next item on
development roadmap of Proteus.
Proteus uses XSLT for message transformation - if the message is available in XML-format.
This provides a satisfying degree of transformation flexibility for the most common cases.
Due to the lack of message containers, format descriptions and transformation possibilities
from string to XML, this is only applicable if the external system already provides the
message in XML format.
The only transformer that is available for string messages is called “UpCaser” and does
exactly what its name suggests, namely setting the message content to upper case.
Furthermore some mappers are available. These mappers prepare message data for the
processing through certain sinks by transforming them to the appropriate Java objects.
Mappers are available for database and Tibco sinks.
The routing capabilities of Proteus are quite powerful. It supports predefined routing paths as
well as dynamic routing depending on certain routing conditions. These routing conditions
can be set up in three different ways:
• XMLSwitch
these routing conditions are used for XML-based messages. The value of certain tags will
be used for routing decisions.
• RegexSwitch
allows routing through the use of regular expressions. Regular expressions allow very
complex routing conditions and thus enable the system to establish highly flexible routing
paths.
• SubstringSwitch
depending on the value of a certain part (substring) of the message, the routing path will
be chosen.
The system seems to support transaction handling. This is indicated by the implementation of
the transactional interface for the particular components. The documentation whereas does
not mention this important functionality.
In contrast to the transaction support is an error handling strategy neither documented nor
implemented. Especially as a transaction support already exists, it would be reasonable to
provide as well an error strategy that cares about the handling of malformed messages and the
reporting of occurring processing errors.
The absence of encryption possibilities of communication channels and message content
makes the system inapplicable to unsecured environments and for the handling of sensitive
information.
Support
CRP Henri Tudor
Page 76/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
The documentation of Proteus is quite basic. It consists of a user guide and a API
documentation.
The user guide contains a short installation instruction, a basic description of the components
and a description of the structure of their XML configuration. There are no additional
information, e.g. about architecture, security or error handling strategies. Thus there is still a
lot of work that has to be put into the documentation of the project – an aspect that is
underestimated in the majority of FOSS projects.
The API documentation just consists of the JavaDoc generated files without any additional
description of the functions, parameters or return values. This states a high entry barrier for
developers who like to join the project.
The link to the forums at the Proteus website is dead but there are reachable Proteus forums at
the sourceforge site where Proteus is hosted. It comprises a support forum and another one for
feature requests and discussions. There are just a view topics and the forums are very rarely
frequented.
The possibility of professional support or a mailing list does not exist.
Usability
There is neither a graphical frontend for configuration, administration or monitoring of the
system nor an interface (e.g. JMX) that allows to easily attach one. The system is configured
through a XML file that is clearly structured and easy to understand.
Test schema
As the Proteus system neither supports recomposition nor file sources or sinks, the test
schema had to be altered. The two systems at the incoming side have been replaced by one
FTP-system that provides the information of both messages within one XML-message. The
XML-format has been necessary to enable the system to change the message format. Since
Proteus only uses XSLT for message mapping and does not provide means for string to XML
transformation, this has been the only feasible way to do the job.
It seems that Proteus states a good example for the often existing gap between theory and
practice. According to the documentation, the use of the limited number of components is
easy and intuitive.
Unfortunately, during the test, it emerged more and more that this was absolutely not the case.
Some mandatory parameters of the component configuration are not documented at all or
wrong.
For instance the configuration of a simple ftp source held some obstacles in store. The
mandatory parameter “getMask” should describe a pattern for the filename of the files to
fetch for processing. Unfortunately the tag is spelled wrong as “getmask” with a lower case
“M” in the documentation. Because of that, the system throws an error message that is
everything but obvious. Furthermore this tag does not describe the file pattern as intended and
shown in the examples but the subdirectory on the FTP-server containing the files. Other,
mandatory tags like “tmpDir” are not documented at all but lead to cryptic error messages not
set.
Finally it was possible to run the test schema without receiving an error immediately. The
system fetched the files from the import FTP-directory and put them to a temporary directory
where they remained. It seemed like the defined routers did not route the messages at all.
Conclusion
CRP Henri Tudor
Page 77/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Proteus comes with a very small footprint. The architecture of the system is very simple as is
the configuration of the components. That leads to fast achievements and a quick
implementation of simple system interconnections. Technically, it was unfortunately
impossible to get the – already altered – test schema up and running.
If it comes to more sophisticated system integration or transformation requirements the
system quickly meets its limitation. This is also fostered through the lack of support for some
essential protocols and interfaces.
Furthermore the lack of encryption, error handling and any control and monitoring tools or
interfaces eliminate the use of Proteus for the integration of critical systems and information.
Proteus is well applicable for a quick integration of non-critical systems that provide the
interfaces that are supported by this EAI system. The missing features and interfaces could
surely be implemented as the architecture itself seems to be solid and open.
But, in order to reach that state, the support infrastructure has to be revised, e.g. by creating a
complete documentation and an easily reachable discussion forum.
CRP Henri Tudor
Page 78/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
3.3.6 xBus
xBus is an, initially by Xenium AG developed, Open Source EAI system that claims to be
very slim and efficient. The philosophy of the project is to integrate and use existing tools to
reduce the development effort. The system has two substantial tasks:
• Routing
fetch messages from different sources and passing through to different target systems.
• Transformation
convert data between different formats and transform the content.
The system provides different operation modes and is built on a consistent layer architecture.
Its reliability has been proven in production environments of commercial projects e.g. for the
trader net of the BMW AG.
Architecture
The xBus system is based on a layer architecture that consists of four different layers.
Figure 25 xBus layer architecture
The layers are composed as follows
• Service layer
third party programs that are running in the background and provide additional
functionality to xBus, like servlet engines, message queue servers, mail servers or
databases. These components are exchangeable because of the use of standardized APIs.
Furthermore, services are optional and thus helpful but not necessary to run xBus.
• Technical layer
this layer is responsible for the communication with the external systems attached to xBus.
It receives the data from and sends it to the external systems by the use of the protocol that
is understood by the external system. Services of the service layer can be used to
accomplish this task.
CRP Henri Tudor
Page 79/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
• Protocol layer
parses the incoming data, stores it in a structured XML format and gathers the needed
routing information. In addition to that, the protocol layer accomplishes the
transformation of data structures into data structures of another format. This is done by
the use of XML transformation.
• Application layer
responsible for the data routing. The routing path is decided based on the message source,
content and information. The decision parameters are fetched from the configuration file.
Components
The xBus system consist of five main components
• Receiver
handles the communication with the interface of the external system and fetches the
messages coming from the external system. This can be accomplished in two ways, either
as server process that waits for requests from the external system or actively by fetching
the information from the external system.
• Router
forwards the messages to the appropriate destinations, depending on their meta
information.
• Transformer
maps data from the message format of the external source system to the one of the external
destination system.
• Sender
as counterpart of the receiver, the sender handles the communication with the interface of
the external destination system.
• Message
parses the data coming from a external system and reformats it from the representation of
the external system to the internal XML representation and back. Furthermore it extracts
meta information that are necessary for routing.
Because of the hot plug support, components can be added and exchanged during the system
is operating. The components will be dynamically loaded as required. This behaviour is
especially helpful for the development of custom component as the system does not have to
be restarted for functionality tests.
CRP Henri Tudor
Page 80/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Message processing
The message processing approach of xBus affects the three major layers and optionally as
well the service layer as support of the technical layer.
Figure 26 xBus message processing
1
The data coming from an external system will be fetched by a receiver.
2
A receiver can either be run as a service and wait for requests of an external system or can
be triggered to fetch data from an external system (polling). The receiver does not alter the
message content in any way.
3
The message module understands the structure of the data format, parses the data and
restructures it to a XML representation. This XML representation is important for the later
data transformation. In addition to that it stores some meta-information that are important
for the message routing.
4
The router sends the message, depending on the meta-information, to one or more
destination paths. The router is able to work in two different modes:
• Invoke
Sending the message to the destinations and wait for a response of the external
destination systems. This response will be send back to the source from where the
message origins. This behaviour is useful for protocols that require acknowledgement
like HL7 or DICOM.
• Distribute
Sending the message to the destinations and without waiting for an acknowledgement of
the external destination systems.
The transformer restructures the message content to the format that is required by the
destination system. This is usually accomplished by a XML transformation.
Afterwards the message module brings the transformed message from the XML
representation to the format that is expected by external destination system, e.g. email or
CSV format.
5
CRP Henri Tudor
Page 81/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
The sender as counterpart of the receiver is responsible for the communication with the
external destination system.
It as well receives the response of the external system after sending the data, if any, and
returns it to the xBus system.
The system supports four different operating modes:
• Single transfer
xBus can be run by a shell script for single data transfers. Optionally the scripts can be
triggered by a scheduler like Cron under Unix or Scheduler under Windows
• Background service
xBus can be run as a standalone background service
• Servlet engine
xBus can be run inside a servlet engine
• Integration
xBus can be integrated in a Java application
Features
xBus comes with receivers and senders that allow to connect to applications via the most
common protocols like File, HTTP, FTP, Message Queue, Email (POP3 for receiver and
SMTP for sender) and AS400. Some protocols like LDAP, database or socket are only
supported for data sinks (senders). The support of receivers for these protocols would
drastically enlarge the field of possible applications. Especially the database access is in
practice often needed for legacy systems that do not provide an interface or use import/export
tables as interface.
Various transformers open up a variety of possibilities for message conversion and mapping:
• RecordType
transforms one RecordTypeMessage into another one.
• XMLWrapper / XMLUnwrapper
wraps a string into a XBUSXMLMessage respectively the other way round.
• XMLParser / XMLSerializer
transforms a string into a Document object (org.w3c.Document) and back.
• XSLT
uses an XSL processor to transform a message from one format to another.
• Java
calls a method of a Java class to transform the source into the destination format, which
method and which class is defined by the configuration.
The lack of compression support can lead to performance bottlenecks if higher amounts of
large messages e.g. messages containing images or reports, have to be handled.
The configuration of xBus is handled through several property files and also some XML
formatted files. The parameter naming and the distributed locations of the configuration files
can be confusing and reduce the clarity.
xBus supports transaction handling for senders and receivers which cover communication
channels that usable for transaction based data transfer:
• File
• FTP
• Message Queue
• Database
CRP Henri Tudor
Page 82/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
• POP3
• AS400
The protocols mentioned above are supported by transaction commit and rollback.
On the security level, the system supports HTTPS and for the system access through the JMX
interface authentication via HTTP. This circumstance refuses the distributed use of xBus if it
exceeds a closed and secured environment. Even if it is used in a closed environment like a
corporate intranet, communication channel and message encryption support would be
desirable for sensitive contents.
The handling of erroneous messages is comparably advanced. If transaction is available and
activated for the used receiver and senders, the transaction will be rolled back. The message
itself will be deleted and can be copied to a dedicated directory called “Deleted Message
Store”. The JMX administration frontend can be used to feed the message back to the system
later on. The frontend does not provide the possibility to alter the message before it is fed
back.
An error message describing the source and cause of the error will be written to the log file
and the journal. Finally a error notification email is generated and sent to the administrators.
Support
The documentation contained in several web pages is excellent. The documentation describes
the architecture, the API and the usage of the system (installation, configuration, starting,
administration, examples).
A developer documentation is missing. This, however, should not be a big problem for
developers because the architecture is well described.
For direct help, a help forum is located at the sourceforge page (sourceforge.net) of xBus.
Additionally an “Open Discussion” forum can be used to request new features. The forums
are not very frequented but feedback is usually posted fast.
Usability
Figure 27 xBus administration frontend
If xBus is run inside a servlet engine, a web-based administration frontend is available.
This frontend can be used to view and control the state of the components, refeed messages
from the “Deleted Message Store” back to the system and to view the configuration, journal
and log file.
CRP Henri Tudor
Page 83/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
The same functionality is provided by the JMX interface that is available if xBus runs in
service mode or inside a servlet engine. The access to the system is protected by
user/password authentication.
As for the vast majority of Open Source EAI systems, does not exist any graphical frontend
for the configuration of the system.
Test schema
As xBus does not provide a socket receiver, the test schema had to be altered to test at least
some functionalities. Because of the fact that xBus neither supports message composition, just
the file receiver part had been established.
In order to be able to implement the altered test schema, the property based main
configuration file had to be created. This file contains all component and routing information.
In addition to that, three XML files had to be created. They describe the data structures of the
incoming message format, the message format of the message that has to be sent to the FTPserver and the format of the message that is sent by email.
Finally, two XSL style sheets that transform the incoming messages to the appropriate output
format are needed.
The altered test schema could be implemented but some obstacles had to be mastered during
the implementation:
The “FinalResolution” parameter, is responsible for the input file handling after a transaction
have been committed. If this parameter is set to preserve the input file, the file should be
processed every time the receiver fetches new messages. After the first processing of the file,
the receiver throws an exception, indicating a wrong number of fields in the message. This
seems to be an implementation bug of the file receiver.
Another bug seemed to occur during the tests if a wildcard was used in the filename for the
files fetched by the file receiver. In the test configuration the receiver threw an exception
whereas everything went fine with wildcards used in the examples shipped with xBus.
Writing the XSL style sheets was a little bit confusing. The internal XML-representation of
the incoming messages that is as well used for the XSL transformation is not consistent with
the XML definition of the message structure. The records have been named “employee” in the
definition but after parsing the incoming message the records are named “record” instead of
the expected “employee”. Thus a XSL mapping of “employee” leads to an exception.
Conclusion
The architecture of xBus is very well structured. Furthermore reduces the integration of well
established third party systems the load for the xBus development and thus could lead to a
more stable system with well developed and tested components. This impression is rounded
by an excellent and well structured documentation that helps to understand the usage of the
system very quick.
xBus supports many operation modes like integration into existing applications, a servlet
engine or the operation as a standalone service. This makes the system quite flexible in terms
of application.
The administration over the remote interface even through a website makes it easy to retain
the control over the system once it is in production.
CRP Henri Tudor
Page 84/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
More advanced features like support of message or communication channel encryption
(besides HTTPS) or compression support for large messages are missing. But as well at the
side of the basic features there are some gaps to fill. Especially receivers for database and
socket connections would be a feasible extension for the future.
An additional threat is the fact that just one developers fosters the projects. That results in a
quite slow progress and can lead to a stall if the developer e.g. due to the lack of time or
interest abandons the project.
XBus is an absolutely usable EAI system that comes with a small footage. Because of its
clear structured architecture it is fast to understand and can quickly be brought into
production. On the other hand, the absence of some basic as well as advanced features and
connectors and eventually the missing scalability support restrict its range of application to
smaller projects that do not need a highly sophisticated and scalable middleware.
CRP Henri Tudor
Page 85/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
4 Evaluation matrix
System
Babeldoc
JyRetic
Mule
Openadaptor
Proteus
xBus
sourceforge.net/projects/b
abeldoc/
retic.sourceforge.net
mule.codehaus.org
www.openadaptor.org
www.info-scape.com/proteus
xbus.sourceforge.net
1.2.1
1.0 July 2004
1.2 / November 2005
1.7.1 / November 2005
0.6 / September 2003
1.6 / November 2005
License
Apache Software License
Apache Software License
Mule licence
Non-copyleft free
software variant of the
MIT licence
GNU GPL
Derived from the Apache
software license
OS support
Java-based
Java/Jython-based
Java-based
Java-based
Java-based
Java-based
System
requirements
Java compliant operating
system
Java compliant operating
system
Java compliant operating
system
Java compliant operating
system
Java compliant operating
system
Java compliant operating
system
3rd party software
JRE 1.4
JRE 1.3
Jython 2.1
wxPython 2.4
JRE 1.4
JRE 1.4
JRE 1.1
JMS server
JRE 1.4
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Website
Version
Architecture
Component based
architecture
Scanner
Pipeline stages
Pipeline
Journal
Ticket
Source
Pre-/Postprocessor
Pipe
Sink
Metadata dictionary
Connector
Transformer
Router
Filter
Endpoint
Interceptor
Source
Pipe
Sink
Transformer
Source
Transformer
Mapper
Sink
Receiver
Sender
Message
Router
Transformer
Connector as client
(outbound
connector)
Yes
Yes
Yes
Yes
Yes
Yes
Connector as
server
(inbound
connector)
Yes
Yes
Yes
Yes
No
Yes
Custom processing
units
(Transformation)
Yes
Yes
Yes
Yes
Yes
Yes
CRP Henri Tudor
Page 86/112
Project Freegate: Market Survey of Open Source EAI Software
System
Authors. Oechsle, Donak
Date: September, 29th, 2006
Babeldoc
JyRetic
Mule
Openadaptor
Proteus
xBus
Dynamic message
routing
Yes
No
Yes
Yes
Yes
Yes
Message container
• XML
• XML
No
• XML
No
• XML
Predefined
message routing
Yes
Yes
Yes
Yes
Yes
No
Scalability
Yes
Yes
Yes
Yes
No
No
Synchronous
communication
Yes
Yes
Yes
Yes
Yes
Yes
Asynchronous
communication
Yes
No
Yes
No
Yes
Yes1
•
•
•
•
•
• FTP
• JDBC
• File
• File
• FTP
• FTP
• JDBC
Yes2
Yes
No
Yes
Yes
Yes
Yes
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
• UpCaser
• StringMapper
•
•
•
•
•
Connector polls
messages
(inbound connector)
Defined module
interface (API)
Predefined
processing units
CRP Henri Tudor
File
FTP
HTTP
SMTP
SQL
Cipher
Compress/Decompress
Domify
Enrich
ExternalApplication
FlatToXml
FtpWriter
JavaXmlDecoder
Jtidy
Reader
RSSChannel
Scripting
Signer
SmtpWriter
SqlEnrich
Excel
FOP
ToXML
Unzip
XMLToFlat
XPath
XPathMetadata
XSLT
Zip
• File
Base64
ByteArray2Serializable
ByteArrayToString
DoomToXml
DQMessageToXml
Gzip
JXPath
Object2XML
Serializable2ByteArray
SGML
StringToByteArray
UU
XML2Object
XmlToDoom
XmlToDQMessage
Append
LowerCase
Prepend
RegularExpression
UpperCase
Page 87/112
RecordType
XMLParser
XMLSerializer
XMLUnwrapper
XMLWrapper
Project Freegate: Market Survey of Open Source EAI Software
System
Authors. Oechsle, Donak
Date: September, 29th, 2006
Babeldoc
•
•
•
•
•
•
•
•
•
•
JyRetic
Mule
Openadaptor
Proteus
xBus
SqlQuery
SqlWriter
SvgTranscode
VelocityTemplatize
XlsToXml
XpathExtract
XpathSplitter
XslFoTransform
XslTransform
ZipArchiveWriter
Features
Exception
handling
File-based
connectors
Message-based
connectors
CRP Henri Tudor
Yes3
Yes3
Yes
Yes
No
Yes
• File
• Ftp
• File
• FTP
• File
• FTP
• File
• FTP
• File
• FTP
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
• JMS
• MQ
•
•
•
•
•
•
HTTP
JMS
SMTP
Soap (sink)
Socket (sink)
SQL
HTTP
Jabber (sink)
JMS
SMTP (sink)
SOAP (source)
XMLBlaster
HTTP
HTTPS
IMAP
Intra VM
IP multicast
JMS 1.1 & 1.02
JRMP
POP3
RMI
Servlet
SMTP
SOAP
SSL
Streams
TCP
TLS
UDP
Xmpp
JMS
RMI A
MQ Series
Sockets
Page 88/112
HTTP
LDAP
Message queue
POP3
SMTP
Socket
Project Freegate: Market Survey of Open Source EAI Software
System
Authors. Oechsle, Donak
Date: September, 29th, 2006
Babeldoc
JyRetic
• JDBC
•
•
•
•
• JavaScript
• XML
• XSLT
Application-based
connectors
Mule
Openadaptor
Proteus
xBus
• JDBC
• JDBC
• JDBC
• JDBC
• XSLT
•
•
•
•
• Java properties file
• XSLT
• Java
• XSLT
• XSLT
• Java
• Property files
No
No
• AS400
• MQ Series
• Tibco
• Tibco
• AS400
Decomposition
Yes
Yes
Yes
Yes
Yes
Yes
Recomposition
No
No
Yes
Yes
No
No
Transactional
support
Yes
No
Yes
Yes
Yes
Yes
Workflow support
No
No
No
No
No
No
Command line
control
Yes
Yes
Yes
Yes
Yes
Yes
Compression
support
Yes
Yes
Yes
Yes
No
No
Authentication
No
No
Yes
Yes
No
Yes
Communication
channel encryption
No
No
• SSL
• TLS
• HTTPS
• SFTP
No
• HTTPS
Message
encryption
Yes4
No
• PQP
JCE
No
No
Message tracking
Yes
Yes
Yes
No
No
Yes
Database-based
connectors
Programmable
transformation
SQL
SQLTree (source)
SQLTreePlus (source)
Xindice
Groovy
Java
PHP
XSLT
Security
Support
CRP Henri Tudor
Page 89/112
Project Freegate: Market Survey of Open Source EAI Software
System
Babeldoc
Authors. Oechsle, Donak
Date: September, 29th, 2006
JyRetic
Mule
Openadaptor
Proteus
xBus
No
No
SymphonySoft
www.symphonySoft.com
No
No
No
• White paper
• User guide
• Developer guide
• User guide
• Component description
• GUI manuel
•
•
•
•
•
• Programmers guide
• White paper
• API documentation
• User guide
• API documentation
•
•
•
•
Forums
Yes
Yes
No
Yes
Yes
Yes
FAQ
No
No
Yes
Yes
No
No
Mailing lists
No
No
•
•
•
•
•
• Developer
• User
• 4 others
No
No
Tutorials
No
Yes
Yes
Yes
No
Yes
Chat channels
No
No
Yes
No
No
No
Administration
Frontend
Yes
Yes
No1
Yes
No
Yes
Configuration
frontend
Yes
Yes
No
Yes
No
No
• Java property files
• XML
• XML
• XML
• XML
• Java property files
• XML
• XML
• Property files
Monitoring
frontend
Yes
Yes
No1
Yes
No
Yes
Test schema
Partially
Partially
Yes
No
Partially
Consulting
Documentation
User guide
API documentation
Architecture guide
Programmers guide
Cookbook
Developer
User
Issues
Announcements
ICM
Architecture guide
User guide
Configuration guide
API documentation
Usability
Configuration files
Partially
Project state
CRP Henri Tudor
Page 90/112
Project Freegate: Market Survey of Open Source EAI Software
System
Babeldoc
Authors. Oechsle, Donak
Date: September, 29th, 2006
JyRetic
Mule
Openadaptor
Proteus
xBus
Community
Little active
Little active
active
Very active
Virtually inactive
Little active
Number of coders/
contributors
13 developers
2 developers
10 developers
1 company
(Dresdner Bank)
3 developers
1 developer
1 company
www.symphonySoft.com
Different occasional
contributors
References
No known references
Bank of New York
www.bankofny.com
National Bank of Serbia
www.nbs.yu
Time on market
5 years (since 2002)
4 years (since 2003)
(originally Xenium AG)
Different occasional
contributors
• Atos Origin
www.de.atosorigin.com
• CitiBank
www.citibank.de
• Deutsche Bank
www.db.com
• HP
www.hp.com
• Sony
www.sony.com
• Abbey
www.abbey.com/index
• Deutsche Bank
www.db.com
• Dresdner Kleinwort
Wasserstein
www.drkw.com
• HP
www.hp.com
4 years (since 2003)
6 years (since 2001)
No known references
4 years (since 2003)
• BMW AG
www.bmwgroup.com
3 years (since 2004)
Architecture
Features
Security
Support
Usability
Project state
Overall rating
1
by the use of message queues
CRP Henri Tudor
2
by the use of external tools like Chron
3
just very basic support
Page 91/112
4
could not be tested because of missing documentation
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
5 Conclusion
The analysis of the available Open Source enterprise application integration systems has
shown that there is a high potential on the Open Source market but there are as well many
projects that claim to be EAI projects, that are not appropriate for general EAI requirements.
The remaining systems are very applicable but also reveal some issues that have to be taken
into respect.
Especially in terms of usability there is in many cases still a high demand for optimization.
Some projects are already in a technical very mature state but it is obvious that the focus has
been set on features instead of usability. This circumstance hampers the application of these
systems by potential users because it levers the barrier to entry.
A further point is the support of specialized, industrial protocols and interfaces. Nearly no
project provides the support for special, in the enterprise environment widespread
applications like e.g. SAP, Peoplesoft or Baan. The same applies to special protocols like e.g.
EDIFACT in the automotive sector or HL7 and DICOM in the healthcare sector. Also does
none of the in-depth tested systems provide workflow support.
Finally is quite often the support an issue that prevents the use of Open Source EAI solutions
in a professional environment. The often weak, incomplete or outdated documentation makes
it hard get familiar with the chosen system. The absence of professional support and training
could prevent decision makers from introducing the systems in their companies and feeding
sensitive date to it.
Nevertheless, there are some projects that are to a surprisingly high degree mature and
already proven in a production environments.
A definite recommendation can not be given here as the selection of the system highly
depends on the requirements.
For large projects with many attached systems Mule and Openadaptor are a good choice as
they provide a high scalability and are designed for highly distributed, high performance
requirements. Especially Mule provides here the most connectivity and state of the art
concepts like ESB, SEDA and JBI. Also, both have already proven to be applicable in the
outlined environments through their application in large companies. In addition to that, Mule
provides professional support that is a main factor for the use with sensitive systems and data.
Openadaptor provides a graphical configuration frontend that makes it easy to define new
schemes. If it comes to bidirectional protocols that require an acknowledgement transfer back
to the sender, openadaptor meets its limits.
For smaller projects that need a quick implementation and do not have such a high
requirements in terms of distribution, scalability and connectivity Babeldoc, JyRetic and xBus
could be the means of choice. Babeldoc provides a huge pool of out of the box message
processing and manipulation functionalities, which however not very well documented.
JyRetic provides the most advanced frontend for the generation, administration and
monitoring, which highly increases the usability and allows to easily build and control new
integration schemes. xBus is highly integrable e.g. in existing applications or a servlet engine.
Unfortunately the weak or not existing encryption support disqualifies these three systems for
the use for sensitive information in a unsecured environment.
CRP Henri Tudor
Page 92/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Annexe A: Glossary
Term
Meaning
Explanation
API
Application
Interface
Programming A set of routines, protocols and tools for
building software applications. A good API
makes it easier to develop a program by
providing all the building blocks. A
programmer puts the blocks together.
APPC
Advanced Program to Program Protocol developed by IBM that enables
Communication
computer programs to communicate via a
network. This protocol is available on all IBM
mainfraime systems.
SCII
American Standard Code for A character encoding based on the English
Information Interchange
alphabet.
BPEL
Business Process
Language
BPM
Business Process Management
Execution Enables users to describe business process
activities and define how they can be
connected to accomplish specific tasks.
The automation and coordination of the
countless assets and tasks that make up
business processes. These assets and tasks can
be internal or external to organizations.
Effective BPM requires the coordination of
people and information technology assets both
inside your business and in your network of
customers and partners.
CAS
Central Authentication Server
Provides a trusted way of user authenticate for
an application.
CSV
Comma-separated values
A delimited data format.
DAO
Data Access Objects
Enables transparent access to the data source
through abstraction of the underlying data
access.
DICOM
Digital
Imaging
and A comprehensive set of standards for
Communications in Medicine
handling, storing, printing, and transmitting
information in medical imaging.
DOXML Data Object eXtensible Markup A XML format for describing serialized Java
Language
objects.
EAI
Enterprise
Integration
Application The use of software and architectural
principles to bring together (integrate) a set of
enterprise computer applications.
Typically, an enterprise has existing legacy
applications and databases and wants to
continue to use them while adding or
migrating to a new set of applications that
CRP Henri Tudor
Page 93/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
exploit the Internet, e-commerce, extranet, and
other new technologies.
EAI may involve developing a new total view
of an enterprise's business and its applications,
seeing how existing applications fit into the
new view, and then devising ways to
efficiently reuse what already exists while
adding new applications and data.
EDA
Event-Driven Architecture
Defines a methodology for designing and
implementing applications and systems in
which events transmit between loosely
coupled software components and services.
An event-driven system is typically comprised
of event consumers and event producers.
Event consumers subscribe to an intermediary
event manager, and event producers publish to
this manager. When the event manager
receives an event from a producer, the
manager forwards the event to the consumer.
If the consumer is unavailable, the manager
can store the event and try to forward it later.
This method of event transmission is referred
to in message-based systems as store and
forward.
EII
Enterprise
Integration
ESB
Enterprise Service Bus
Category of middleware infrastructure
products or technologies, based on Web
services standards, that enable a serviceoriented architecture via an event-driven and
XML-based messaging engine (the bus). An
enterprise service bus generally provides an
abstraction layer on top of an Enterprise
Messaging System which allows integration
architects to exploit the value of messaging
without writing code.
ETL
Extract, Transform and Load
Processes that enable companies to move data
from multiple sources, reformat and cleanse it
and load it into another database, a data mart
or a data warehouse for analysis, or on another
operational system to support a business
process.
FOP
Formatting Objects Processor
XSL driven output independent formatter for
the generation of formatted documents.
CRP Henri Tudor
Information Approach to information integration that
provides users with a real-time, single view of
information from disparate data sources across
and beyond the enterprise.
Page 94/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
GUI
Graphical User Interface
A interface based on graphical elements for
the handling of an application.
HL7
Health Level 7
Protocol standard for the interfacing of clinical
data in healthcare applications.
HTTP
Hypertext Transfer Protocol
Main protocol that is used to transfer
information on the World Wide Web.
HTTPS
HyperText
Secure
JAAS
Java
Authentication
Authorization Service
LDAP
Lightweight
Protocol
MOM
Message-Oriented Middleware
Transfer
Protocol Allows a secure connection between client
(mainly browser) and webserver
and Enables Java applications to access
authentication and access control services
without being tied to those services
Database Access Networking protocol for querying and
modifying directory services running over
TCP/IP
Message-oriented middleware (MOM) is a
client/server infrastructure that increases the
interoperability, portability, and flexibility of
an application by allowing the application to
be distributed over multiple heterogeneous
platforms.
It reduces the complexity of developing
applications that span multiple operating
systems and network protocols. This is
accomplished by insulating the application
developer from the details of the various
operating system and network interface-APIs
that extend across diverse platforms and
networks.
PDF
Portable Document Format
Very widespread format and open standard for
electronical documents.
RSS
Rich Site Summary
A format for so called web feeds. With an
appropriate viewer it is possible to subscribe
to a webpage and periodically receive new
content as soon as available.
SEDA
Staged Event Driven
Architecture
An extention of EDA that divides the tasks
into subtasks and every subtask will be
accomplished in an own thread. This method
allows to sustain enormous variations in load.
SOA
Service Oriented Architecture
A service-oriented architecture is essentially a
collection of services. These services
communicate
with
each
other.
The
communication can involve either simple data
passing or it could involve two or more
services coordinating some activity. Some
means of connecting services to each other is
CRP Henri Tudor
Page 95/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
needed.
The first service-oriented architecture for
many people in the past was with the use
DCOM or Object Request Brokers (ORBs)
based on the CORBA specification.
SSL
Secure Socket Layer
Certificate based communication
encryption of the transport layer.
SVG
Scalable Vector Graphics
XML markup language for describing twodimensional vector graphics
TLS
Transport Layer Security
The successor of SSL based on SSL 3.0
URI
Uniform Resource Identifier
Identifies uniquely a digital resource.
XML
eXtended Markup Language
A general
description.
XMLRPC
eXtended Markup Language – A remote procedure call protocol which uses
Remote Procedure Call
XML to encode its calls and HTTP as a
transport mechanism.
XSL-FO
Extensible Stylesheet Language A unified presentational language that
– Formatting Objects
describes a computer driven layout of a
document.
CRP Henri Tudor
purpose
language
channel
for
data
Page 96/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Annexe B: References
[01]
Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions;
Gregor Hohpe, Bobby Woolf;
Addison-Wesley, October 2003;
ISBN 0321200683
[02]
SEDA: An Architecture for Well Conditioned, Scalable Internet Services;
Matt Welsh, David Culler, Eric Brewer; fmdw,culler,[email protected];
Computer Science Division; University of California, Berkeley
[03]
An Architecture for Highly Concurrent, Well-Conditioned Internet Services;
Matthew David Welsh; Fall 2002
B.S. (Cornell University) 1996, M.S. (University of California, Berkeley) 1999
[04]
EAI User Group - Open Source EAI Technologies,
www.eaiusergroup.com/modules.php?s=&name=Sections&sop=viewarticle&artid=2,
accessed 2005/06/16
[05]
Manageability – Open Source EAI Written in Java,
www.manageability.org/blog/stuff/open-source-messaging-integration-transformation-routing-java/view,
accessed 2005/06/16
[06]
Ebizq -The Non-Vendor Source of EAI Apps,
www.ebizq.net/topics/eai/features/1459.html,
accessed 2005/06/16
[07]
Wikipedia – The free Encyclopedia,
en.wikipedia.org,
accessed 2005/09/30 - 2006/09/30
[08]
SourceForge,
http://sourceforge.net,
accessed 2005/04/01 - 2006/09/30
[09]
Babeldoc,
sourceforge.net/projects/babeldoc/
accessed 2005/06/24
[10]
Business Integration Engine,
www.brunswickwdi.com/features,
accessed 2005/03/30
[11]
Glover ETL,
cloveretl.berlios.de,
accessed 2005/10/11
[12]
Conductor DocSOAP XDK,
www.commerceone.com/developers,
accessed 2005/06/22
[13]
ConnectorWorks,
www.connectorworks.org,
accessed 2005/04/04
[14]
DataServer,
www.mii.ucla.edu/DataServer,
accessed 2005/05/19
[15]
Elemenope,
elemenope.org,
accessed 2005/08/29
[16]
it.gim,
www.it-financial.de,
accessed 2005/03/28
[17]
JEngine,
www.jengine.org,
accessed 2005/05/12
CRP Henri Tudor
Page 97/112
Project Freegate: Market Survey of Open Source EAI Software
[18]
JyRetic,
retic.sourceforge.net,
accessed 2005/08/08
[19]
mec-eagle,
www.mec-eagle.org,
accessed 2005/07/5
[20]
Message Force,
http://messageforge.sourceforge.net,
accessed 2005/04/14
[21]
Mirth,
www.mirthproject.org,
accessed 2006/09/18
[22]
Mule,
mule.codehaus.org,
accessed 2005/11/23
[23]
NaradaBrokering,
www.naradabrokering.org,
accessed 2005/06/30
[24]
Net Kernel,
www.1060research.com/netkernel/index.html,
accessed 2005/06/21
[25]
Octupus,
octopus.objectweb.org,
accessed 2005/07/29
[26]
Openadaptor,
www.opendaptor.org,
accessed 2005/12/12
[27]
OpenEAI,
www.openeai.org,
accessed 2005/10/13
[28]
OpenQueue,
openqueue.sourceforge.net,
accessed 2005/09/16
[29]
OpenSymphony,
www.opensymphony.com,
accessed 2005/11/08
[30]
Orbeon PresentationServer,
www.orbeon.com/software,
accessed 2006/04/07
[31]
OSMQ,
www.osmq.org,
accessed 2005/07/26
[32]
Proteus,
www.info-scape.com/proteus,
accessed 2006/03/14
[33]
ServiceMix,
servicemix.org,
accessed 2005/07/24
[34]
S-Integrator,
www.s-integrator.org,
accessed 2005/04/14
[35]
SolAce Secure Wire,
www.snapinhipaa.com/ss/,
accessed 2005/10/
[36]
Tambora,
tambora.zenplex.org,
accessed 2005/04/18
CRP Henri Tudor
Authors. Oechsle, Donak
Date: September, 29th, 2006
Page 98/112
Project Freegate: Market Survey of Open Source EAI Software
[37]
xBus,
software.xineo.net/xil.jspx,
accessed 2006/01/16
[38]
Xineo XIL,
xbus.sourceforge.net,
accessed 2005/06/21
[39]
XML Blaster,
www.xmlblaster.org,
accessed 2005/09/28
[40]
FreshMeat,
freshmeat.net,
continuously
CRP Henri Tudor
Authors. Oechsle, Donak
Date: September, 29th, 2006
Page 99/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Annexe C: Table of figures
Figure 1 Multiple input of information with media conversion................................................ 5
Figure 2 Point to point connection ............................................................................................. 6
Figure 3 EAI system structure example ..................................................................................... 7
Figure 4 Topological comparison between Hub & Spoke (left) and Bus structure (right)........ 7
Figure 5 Babeldoc architecture schema ................................................................................... 47
Figure 6 Babeldoc Pipeline configurator ................................................................................. 50
Figure 7 Babeldoc journal viewer ............................................................................................ 51
Figure 8 JyRetic adaptor structure example............................................................................. 54
Figure 9 JyRetic configuration and administration frontend ................................................... 56
Figure 10 Mule architecture ..................................................................................................... 59
Figure 11 Mule architecture detailed ....................................................................................... 60
Figure 12 Mayor Mule components & stages .......................................................................... 60
Figure 13 Schematic example of a Mule configuration ........................................................... 61
Figure 14 Asynchronous event processing .............................................................................. 61
Figure 15 Synchronous event processing................................................................................. 62
Figure 16 Transformer chaining............................................................................................... 63
Figure 17 Mule exception strategies ........................................................................................ 63
Figure 18 Mule IDE ................................................................................................................. 65
Figure 19 OpenAdaptor Structure ............................................................................................ 67
Figure 20 Openadaptor configuration example........................................................................ 68
Figure 21 Functional schema of the openadaptor controller.................................................... 69
Figure 22 Openadaptor error handling example ...................................................................... 71
Figure 23 The Adaptor Framework Editor............................................................................... 72
Figure 24 The HAT message management frontend ............................................................... 73
Figure 25 xBus layer architecture ............................................................................................ 79
Figure 26 xBus message processing......................................................................................... 81
Figure 27 xBus administration frontend .................................................................................. 83
CRP Henri Tudor
Page 100/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Annex D: Licenses
5.1 Apache License, Version 1.1
Copyright (c) 1995-1999 The Apache Group. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are
met:
1.
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3.
All advertising materials mentioning features or use of this software must display the following acknowledgment: "This product
includes software developed by the Apache Group for use in the Apache HTTP server project (http://www.apache.org/)."
4.
The names "Apache Server" and "Apache Group" must not be used to endorse or promote products derived from this software without
prior written permission. For written permission, please contact [email protected].
5.
Products derived from this software may not be called "Apache" nor may "Apache" appear in their names without prior written
permission of the Apache Group.
6.
Redistributions of any form whatsoever must retain the following acknowledgment: "This product includes software developed by the
Apache Group for use in the Apache HTTP server project (http://www.apache.org/)."
THIS SOFTWARE IS PROVIDED BY THE APACHE GROUP ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE GROUP OR ITS CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This software consists of voluntary contributions made by many individuals on behalf of the Apache Group and was originally based on
public domain software written at the National Center for Supercomputing Applications, University of Illinois, Urbana-Champaign. For more
information on the Apache Group and the Apache HTTP server project, please see <http://www.apache.org/>.
CRP Henri Tudor
Page 101/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
5.2 GPL
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License
is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General
Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some
other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs,
too.
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if
you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These
restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have.
You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original authors' reputations.
Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will
individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be
licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and modification follow.
GNU GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0.
This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the
Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a
portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included
without limitation in the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.
1.
You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this
License along with the Program. You may charge a fee for the physical act of transferring a copy, and you may at your option offer
warranty protection in exchange for a fee.
2.
You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
a)
You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
b)
You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or
any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
c)
If the modified program normally reads commands interactively when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice
and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the
program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself
is interactive but does not normally print such an announcement, your work based on the Program is not required to print
an announcement.)
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to t
hose sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a
work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees
extend to the entire whole, and thus to each and every part regardless of who wrote it.
CRP Henri Tudor
Page 102/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or collective works based on the Program.
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program)
on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
3.
You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms
of Sections 1 and 2 above provided that you also do one of the following:
a)
Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms
of Sections 1 and 2 above on a medium customarily used for software interchange; or,
b)
Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost
of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
c)
Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you received the program in object code or executable form with
such an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete
source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used
to control compilation and installation of the executable. However, as a special exception, the source code distributed need not
include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so
on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4.
You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this
License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so
long as such parties remain in full compliance.
5.
You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying the Program or works based on it.
6.
Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to
this License.
7.
If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do
not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you,
then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended
to apply and the section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is
implemented by public license practices. Many people have made generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot impose that choice.
This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
8.
If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original
copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those
countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the
limitation as if written in the body of this License.
9.
The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new
versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it
and "any later version", you have the option of following the terms and conditions either of that version or of any later version
published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any
version ever published by the Free Software Foundation.
10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author
to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we
sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of
our free software and of promoting the sharing and reuse of software generally.
CRP Henri Tudor
Page 103/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE
EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL
NECESSARY SERVICING, REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT
HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED
ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT
NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR
THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH
HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free
software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey
the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
more details.
You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) year name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the
commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever
suits your program.
You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if
necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
<signature of Ty Coon>, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library,
you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU
Library General Public License instead of this License.
CRP Henri Tudor
Page 104/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
5.3 LGPL
GNU LESSER GENERAL PUBLIC LICENSE
Version 2.1, February 1999
Copyright (C) 1991, 1999 Free Software Foundation, Inc.
51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
[This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence
the version number 2.1.]
Preamble
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public
Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users.
This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free
Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this
license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below.
When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that
you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it
if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these
things.
To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights.
These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it.
For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you.
You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete
object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you
must show them these terms so they know their rights.
We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal
permission to copy, distribute and/or modify the library.
To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by
someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation
will not be affected by problems that might be introduced by others.
Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot
effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent
license obtained for a version of the library must be consistent with the full freedom of use specified in this license.
Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser
General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this
license for certain libraries in order to permit linking those libraries into non-free programs.
When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a
combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire
combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library.
We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public
License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are
the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special
circumstances.
For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a
de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the
same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the
Lesser General Public License.
In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free
software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU
operating system, as well as its variant, the GNU/Linux operating system.
Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked
with the Library has the freedom and the wherewithal to run that program using a modified version of the Library.
The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work
based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be
combined with the library in order to run.
CRP Henri Tudor
Page 105/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND
MODIFICATION
0.
This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or
other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License").
Each licensee is addressed as "you".
A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs
(which use some of those functions and data) to form executables.
The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the
Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a
portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation
is included without limitation in the term "modification".)
"Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code
means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control
compilation and installation of the library.
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of
running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work
based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library
does and what the program that uses the Library does.
1.
You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that
you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all
the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library.
You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for
a fee.
2.
You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and
distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
a)
The modified work must itself be a software library.
b)
You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change.
c)
You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License.
d)
If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses
the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure
that, in the event an application does not supply such function or table, the facility still operates, and performs whatever
part of its purpose remains meaningful.
(For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the
application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be
optional: if the application does not supply it, the square root function must still compute square roots.)
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and
can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work
based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend
to the entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or collective works based on the Library.
In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a
volume of a storage or distribution medium does not bring the other work under the scope of this License.
3.
You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library.
To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License,
version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared,
then you can specify that version instead if you wish.) Do not make any other change in these notices.
Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all
subsequent copies and derivative works made from that copy.
This option is useful when you wish to copy part of the code of the Library into a program that is not a library.
4.
You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the
terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code,
which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange.
If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the
source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to
copy the source along with the object code.
5.
A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or
linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore
falls outside the scope of this License.
CRP Henri Tudor
Page 106/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.
When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a
derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be
linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law.
If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline
functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative
work. (Executables containing this object code plus portions of the Library will still fall under Section 6.)
Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any
executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself.
6.
As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit
modification of the work for the customer's own use and reverse engineering for debugging such modifications.
You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered
by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include
the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must
do one of these things:
a)
Accompany the work with the complete corresponding machine-readable source code for the Library including whatever
changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable
linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source
code, so that the user can modify the Library and then relink to produce a modified executable containing the modified
Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be
able to recompile the application to use the modified definitions.)
b)
Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time
a copy of the library already present on the user's computer system, rather than copying library functions into the
executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the
modified version is interface-compatible with the version that the work was made with.
c)
Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in
Subsection 6a, above, for a charge no more than the cost of performing this distribution.
d)
If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the
above specified materials from the same place.
e)
Verify that the user has already received a copy of these materials or that you have already sent this user a copy.
For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for
reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is
normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system
on which the executable runs, unless that component itself accompanies the executable.
It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany
the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you
distribute.
7.
You may place library facilities that are a work based on the Library side-by-side in a single library together with other library
facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based
on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things:
a)
Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library
facilities. This must be distributed under the terms of the Sections above.
b)
Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining
where to find the accompanying uncombined form of the same work.
8.
You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any
attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights
under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses
terminated so long as such parties remain in full compliance.
9.
You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or
distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying the Library or works based on it.
10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the
original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any
further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third
parties with this License.
CRP Henri Tudor
Page 107/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do
not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent
license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you,
then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library.
If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended
to apply, and the section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented
by public license practices. Many people have made generous contributions to the wide range of software distributed through that
system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute
software through any other system and a licensee cannot impose that choice.
This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original
copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those
countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the
limitation as if written in the body of this License.
13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such
new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it
and "any later version", you have the option of following the terms and conditions either of that version or of any later version
published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version
ever published by the Free Software Foundation.
14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these,
write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free
Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free
status of all derivatives of our free software and of promoting the sharing and reuse of software generally.
NO WARRANTY
15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE
EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY
SERVICING, REPAIR OR CORRECTION.
16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT
HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED
ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT
NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR
THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH
HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Libraries
If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that
everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the
ordinary General Public License).
To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found.
<one line to give the library's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as
published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public
License for more details.
You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free
Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
Also add information on how to contact you by electronic and paper mail.
You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if
necessary. Here is a sample; alter the names:
CRP Henri Tudor
Page 108/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
Yoyodyne, Inc., hereby disclaims all copyright interest in the
library `Frob' (a library for tweaking knobs) written by James Random Hacker.
<signature of Ty Coon>, 1 April 1990
Ty Coon, President of Vice
CRP Henri Tudor
Page 109/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
5.4 Openadapter license
Permissive non-copyleft free software variant of the MIT licence.
Copyright (C) 2001 - 2005 The Software Conservancy as Trustee. All rights reserved.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the
following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT
OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Nothing in this notice shall be deemed to grant any rights to trademarks, copyrights, patents, trade secrets or any other intellectual property of
the licensor or any contributor except as expressly stated herein. No patent license is granted separate from the Software, for code that you
delete from the Software, or for combinations of the Software with other software or hardware.
CRP Henri Tudor
Page 110/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
5.5 Mule License
Copyright (c) 2003-2005 SymphonySoft Limited. All rights reserved.
http://www.symphonysoft.com
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are
met:
1.
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with
the distribution.
3.
The end-user documentation included with the redistribution, if any, must include the following acknowlegement:
"This product includes software developed by SymphonySoft Limited (http://www.symphonysoft.com)."
Alternately, this acknowlegement may appear in the software itself, if and wherever such third-party acknowlegements normally
appear.
4.
All advertising materials mentioning features or use of this software must display the following acknowledgement:
"This product includes software developed by SymphonySoft Limited (http://www.symphonysoft.com) and its contributors".
5.
Neither the name of SymphonySoft Limited, Cubis Limited, Mule, Universal Message Objects nor the names of its contributors
may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE
CRP Henri Tudor
Page 111/112
Project Freegate: Market Survey of Open Source EAI Software
Authors. Oechsle, Donak
Date: September, 29th, 2006
5.6 xBus License
The xBus Software License, Version 1.0
(derived from the Apache Software License 1.1)
Copyright (c) 2005 Stefan Fleckenstein
All rights reserved
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are
met:
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
The end-user documentation included with the redistribution, if any, must include the following acknowlegement:
"This product includes software developed by Stefan Fleckenstein and Xenium AG."
Alternately, this acknowlegement may appear in the software itself, if and wherever such third-party acknowlegements normally appear.
The names "xBus" must not be used to endorse or promote products derived from this software without prior written permission. For written
permission, please contact sfleckenstein[at]sourceforge.net.
Products derived from this software may not be called "xBus" nor may "xBus" appear in their names without prior written permission of
Stefan Fleckenstein.
THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR IMPLIED WARRANTIES INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL STEFAN FLECKENSTEIN OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
CRP Henri Tudor
Page 112/112