University Devs Forge New Middleware Approach

Frustrated by the cost and proprietary nature of today's ERP/EAI middleware, developers at the University of Illinois are creating an ambitious open alternative to proprietary brokers and Java connectors. With a well-mixed brew of XML, SOAP, message queuing, ERP APIs, and Java, The OpenEAI Project is now releasing code and template work to developer review. Get a closer look, and download some code.

Tags: OpenEAI, Developers, Integration, Wheat, Message Object, Enterprise, APIs,

Developers at the University of Illinois are creating an Open Source alternative to expensive and proprietary ERP/EAI middleware solutions. The OpenEAI framework, now in its third year of development, is ready for developer review. Modeled after Apache, the project sports templates, business workflow rules and components for Java, XML and ERP APIs.

To get a closer look at the project, Integration Developer News spoke with Stephen Wheat and Tod Jackson, founders of the OpenEAI Software Foundation and enterprise architects for Administrative IT at UoI.

"Our project is trying to provide a project model, artifacts and real-world examples," Wheat started out. "First, OpenEAI is based on first principles, which means we need to do some work before any coding or integration begins."

"We always start by documenting the requirements of the integration project and then secondly by defining the message objects," Wheat explained. To that end, the OpenEAI framework comes with developer templates, which give developers guidance on specifying all the new "objects" that might be needed for an integration project, and listing how a developer makes sure those objects are in place.

Many ERP vendors do not expose Java, C or stored procedure APIs, but they offer a "message gateway" to get customers to purchase and upgrade. The OpenEAI approach looks to define, expose and leverage those APIs, he said.

Roots of OpenEAI -- There's Gotta Be a Better Way
Wheat explained the roots of their OpenEAI project in simple terms. "Back in 2000, we had put out a simple integration project for bid, and every vendor's response to the RFP was way more than our budget. We looked around again and said, 'There's gotta be a better approach, and maybe with XML, and other standards we can come up with something. '"

In 2001, UoI's Enterprise Architecture Group of Administrative IT Services developed a comprehensive enterprise application integration methodology, based on a Java message object API, and Java messaging and application foundation components.

First used to begin some tactical implementation projects for personnel departments, the approach began getting the attention of other UoI departments, as well as vendor/suppliers. Given this broad interest, UoI sought to make these integration concepts and software available to these other organizations and the general public on a sound basis. An Open Source project, patterned on the Apache Software Foundation, was launched. The resultant OpenEAI Software Foundation donated all its work -- templates, design, code, methodologies -- to the OpenEAI Project in October 2002.

UoI has already saved "significant money" deploying OpenEAI APIs and gateways. The other big savings is with the business manager, Jackson said. "UoI planned a $1.5 million budget for the purchase of an integration broker and consulting/support services over 2-3 years," Jackson said. "With OpenEAI, so far we've spent just about $80,000 of that budget." While Jackson admits that staffing costs are harder to determine, because "IT staffing is free in a university setting," he said the costs for in-house staff are nowhere near those for outside professional services.

Open Source Integration Starts with a Sharp Blueprint
A key OpenEAI aid to this initial part of the project is the Layout Manager, which lets a developer take a message and transform it into the "complex logic" Java API that may be used for accessing mainframe data.

"When it comes to navigating directly into mainframe applications, there are enough standards and technologies existing today that there is no reason why a Java developer needs to know all that complexity," Jackson said. "With the OpenEAI Layout Manager, you can even have the business analyst -- not the developer -- work on that to describe what data he needs to work with what other data or application."

The OpenEAI methodology presents a step-by-step blueprint for outlining a clear process for documenting requirements for key integration components, including:
  1. Interfaces among enterprise applications;
  2. Requirements for enterprise data services; and
  3. Requirements for information exchange with trading partners.
To double-check this project definition, OpenEAI also sports a feature-rich analysis template, as well as instructions for analysts, functional experts and developers. The OpenEAI analysis process results in a defined set of "enterprise message objects" that use XML.

Inside OpenEAI -- The Technology of Messaging and Integration Code
OpenEAI defines a new Open Source messaging protocol (OpenEAI Message Protocol) and message format in XML for both request/reply and publish/subscribe messaging models for any enterprise message object, Wheat explained. The OpenEAI analysis also helps specify which XML messages (defined in the OpenEAI Message Protocol) are required for each enterprise message object identified during the analysis process.

In specific, OpenEAI provides a suite of runtime management and monitoring scripts and documentation for managing messaging gateways and applications. Reference implementations of typical message-aware applications/gateways are also included. Support for a variety of infrastructure applications (including message routers, message proxies, point-to-point destination polling applications and testing applications) is also maintained and documented by the OpenEAI Project.

The core coding and documentation elements (or "artifacts") of OpenEAI available to developer/members include:

  • Configs -- Deployments of sample applications and reference implementations following the recommended OpenEAI deployment patterns.

  • Documentation -- Contains sub-modules with documentation from all departments of the project including methodology, software and deployment.

  • Java -- Contains the Java source tree and Java library directory of the project.

  • Message -- Contains a global XML message development tree and a global XML message release tree for message definitions and sample messages.

  • XML -- Contains a development and a release tree for non-message XML definitions and sample documents.

  • Documentation, source code, sample implementations, deployments and other artifacts of the OpenEAI Project are available for download and review in the project's CVS repository, which is open to view to the world, according to Wheat and Jackson. However, only members of the OpenEAI Foundation have direct access to update and modify artifacts in this official, public repository. OpenEAI Downloads here .

    OpenEAI's CVS repository here: .

    Aside from the message service, OpenEAI supplies message object APIs that provide developers patterns and a foundation for building application gateways and message-aware applications. The key tools here are business-object-oriented APIs generated from the XML message object definitions, which are specified during the initial integration analysis. This process leads to the OpenEAI gateways, which are key to the OpenEAI ERP integration's flexibility and low cost.

    "The use of OpenEAI gateways avoids re-engineering of legacy data and applications often required by some middleware or broker vendors," Wheat said. The benefits of the common-protocol/gateway approach is twofold, according to Wheat and Jackson:
    1. It provides a way to help create a variety of "self-service" applications that business analysts and other non-developers can implement and update; and
    2. When there are changes to the underlying enterprise systems, the gateway can help shield developers and end users from that level of detail because they now have a pattern for integration implementation.
    But these gateways are not objects in the traditional way of thinking, Wheat added. "We're looking at a uniformity tool, based on the application of best practices, models and open technologies," he told IDN. "This is not a reusability tool."

    OpenEAI Project software and documentation artifacts are available to the public under the terms of one of the following licenses: the GNU Lesser General Public License (LGPL), the GNU General Public License (GPL) or the GNU Free Documentation License (GFDL).

    OpenEAI's Protocols and Transports
    The project's newly created OpenEAI Message Protocol -- designed to be open -- is based on a basic EAI (enterprise application integration) principle of "authoritative source," and is not dependent on any vendor-specific middleware implementations.

    For a native transport, OpenEAI uses the Java Message Service (JMS). "JMS reads the protocol document. The high-level message protocol document really relies on some of those basic constructs of any messaging provider like MQSeries, because a lot of those solve fundamental problems," Wheat said. To make sure that its reliance on JMS stays "open," OpenEAI is "working with Sonic Software, provider of core JMS technology to the OpenJMS project, as well as ASF," he added.

    Wheat views SOAP as just another wrapping and relay strategy, supported with the OpenEAI Message/Logger Request proxy.

    No JMS at Your Place? OK with Open EAI
    What if your enterprise doesn't use JMS?

    Although Java, JMS and XML are the native technology, message transport and message format for OpenEAI, many non-Java technologies can also be exposed through gateways or made message-aware using OpenEAI concepts and foundational APIs. Wheat and Jackson shared two examples, which should be familiar to many developers:

    "Even in our [university] enterprise, many applications don't readily speak JMS, so we have a bridging strategy. For example, PowerBuilder was a language heavily in the university setting [before many systems moved to] J2EE. To accommodate many of the developers who still use PowerBuilder, and give them a bridge to other systems, we have a PowerBuilder API to let them work just the way they have always worked. Their own version of an 'enterprise message' is sent through HTTPS to a broker, an original message is formed into a 'native ERP message,' and we use OpenEAI APIs to handle the request to the ERP system.

    With OpenEAI, Wheat also said he had ColdFusion developers working to build integration functionality. "Because ColdFusion can use Java objects, we had those developers using Java objects just like any Java developers. We could expose an API that lets them call and perform an action and call the method," Wheat added.

    The key to supporting a variety of developers is the same basic advice that Wheat and Jackson suggest for any multi-platform EAI project: "To get real scalability with any of these techniques, we always try isolate those components likely to be very proprietary or project-specific, and then make the rest as standard and uniform as possible," Wheat said.

    "With OpenEAI, we feel one of the big steps forward is that we have both a methodology for finding those components, and the development tools and communications support to make it happen. With Open EAI, we're showing [developers] how to generate the APIs, the objects and the messaging requirements for an integration project," he told IDN.