Open Integration Tools Upgrade Due in March

Developers at the University of Illinois are working on a major upgrade to their Java-based OpenEAI project, an Open Source alternative to expensive and proprietary ERP/EAI middleware solutions. The OpenEAI framework 4.0 is due for release in March, and sports a wide array of integration-enabling templates, business workflow rules and components for Java, XML and ERP APIs. Get an overview, and the free download.

Tags: OpenEAI, Developers, Integration, Enterprise, Java, Wheat, XML,


Developers at the University of Illinois are working on a major upgrade to their Java-based OpenEAI project, an Open Source alternative to expensive and proprietary ERP/EAI middleware solutions.

The OpenEAI framework 4.0 is due for release in March, is modeled after Apache, and sports a wide array of integration-enabling technologies for architects and developers, including templates, business workflow rules and components for Java, XML and ERP APIs.

The 4.0 upgrades on tap look to fill in support for XML Schema and key JDKs, but also bring added testing, visibility and management to the OpenEAI suite.

The technical list of enhancements includes:
  • Test and verify compatibility with JDK 1.5
  • Add support for multiple query objects on a given parent object
  • Add support for XML Schema
  • Database connection pool enhancements to leverage the JDBC Datasource
  • Notification for the ScheduledApps function
  • Dynamic refreshing of certain configurable objects (such as PropertyConfigs) so an application doesn't have to be restarted to know about changes to those objects
  • Add support for the use of the Java Management Extensions (JMX) to manage gateways and scheduled apps
  • Update all dependent required libraries to latest releases
  • Possible re-structuring of the class hierarchy for transport layer objects (such as producers and consumers) so we can leverage other transport mechanisms more easily
  • Possible re-structuring of the command pattern currently being used to separate the command execution from the transport layer in gateways
    Possibly implement foundation that would allow guaranteed order of processing for sync messages

  • [Beta versions OpenEAI 4.0 (which include documentation, source code, sample implementations, deployments and other artifacts of the OpenEAI Project are available from the OpenEAI CVS repository, but…only members of the OpenEAI Foundation have direct access to update and modify artifacts in this official, public repository. ]

    Inside OpenEAI -- A Creator Interview
    On a technical level, 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.

    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 -- Looking for 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 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.

    OpenEAI's Messaging and Integration Approach
    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.
  • -- Contains a development and a release tree for non-message XML definitions and sample documents.

    Message Objects and APIs:
    Two Crucial Components

    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.



    back