What are the basic philosophies driving the Application Integration Framework™?
Based on several years of discussions with customers, partners
and industry analysts, Red Oak Software has identified several
requirements for Application Integration. The AIF has taken the
following basic principles into account to address the core needs
of integration projects. These include:
Ubiquitous access to application data
Non-intrusive (non-invasive) access to data
High performance
Rapid development
Adaptability to changing requirements
Easily maintained and updated
Works with existing applications
Works with existing integration systems
Low overhead for startup
Designed for production systems
Ubiquitous access to application data
Corporate data resides on many different platforms with in
the corporation. Many companies are struggling with how to
integrate the many different applications. With data currently
residing in host-based applications, client-server applications,
PC-based applications, and web-based applications, integration
needs run across all of these platforms. In addition, on
each of these platforms, the application being integrated
can be an off-the-shelf application, a homegrown application,
or a combination that falls somewhere in between. Integration
efforts need to take all of these into account. The AIF has
taken all of these into account.
The current products in the AIF address most critical host
applications and web applications. Red Oak is investigating
adding additional host applications as well as access through
additional application types.
Non-intrusive (non-invasive) access to data
In many cases, there is no easy way to tap directly into
the data or logic of the application. There are many reasons
that applications may require non-intrusive access.
In some cases, the technology does not exist or may not
be easily available to easily access the underlying logic
of the application. In other cases, advanced resources
required to access the underlying logic or data may not
be available or may be too complex or expensive to implement.
In some cases, the more complex solution cannot be realized
in real time.
An application may reside outside of the corporate domain,
either on a partner's site or in the public domain, where
access to the underlying logic and data has not been granted.
This is becoming more common with the increasing partnerships
and resources that are required for competitive advantage.
Whether it is expensive, time-consuming, inconvenient or
impossible to access the native data or business logic
of an application, integration still needs to occur. In
these cases and others the only access allowed is
non-intrusive - either through a host terminal interface
or web browser interface. AIF delivers solutions that take
this into account.
High performance
Many integration projects have consolidated data off-line
to satisfy the need for integration. While this has been
successful in some cases, in a large number of cases, we
have found that the access to data must be real time.
Critical business decisions are being made based on the
accuracy of the information. Information that is not
immediate may be too old to make the necessary decisions.
The current trend of "off-line" access to data can be
compared to traditional "batch" processing. We have found
that "batch" data is not the ideal that many CIOs have for
their integration projects.
The AIF is designed to provide access to information in
real. The AIF places a minimum overhead between the source
application and the integration. In most cases, the integration
occurs as fast as if the traditional user was using the native
application. In some cases, the access is even faster.
Rapid development
Companies embarking on integration projects have an immediate
need to have the integration completed as quickly as possible.
In addition, many of the resources required for the more complex
integration projects are hard to find or hard to schedule for
immediate needs. AIF provides an infrastructure that addresses
this problem in several ways.
AIF is structured such that all integrations can have a
"Fast Start." Someone can perform initial application access
and integration with user-level access and knowledge of
the target application. A project can be created very
quickly. The developer and user of the application can
simply step through the target application and identify
the critical elements for integration. Once the initial
steps have been taken, the AIF development tool can automatically
generate the integration code. In addition, all generated
application code can be modified manually to include advanced
concepts and logic for more complex implementations.
More advanced developers may wish to bypass the code
generation process and develop the integration code themselves.
The AIF design allows this to take place as well.
Adaptability to changing requirements
One of the common themes for integration projects is that
they often have incremental requirement changes. After the
initial integration, additional requirements are identified
where more data either needs to be gathered from the target
application or entered into the target application. AIF has
taken this into account and identified a model where an existing
integration project can be reopened and incremental changes
can be made without modifying the entire application.
Easily maintained and updated
Because of the infancy of the integration market, many
integration efforts have on-going maintenance and update
efforts for their integration projects. External forces,
such as the rapidly changing industry standards, are the
cause of some changes. Internal changes, such as the adoption
of new standards or new platforms, may force some changes.
Mergers and acquisitions may introduce new applications
that need to be integrated with existing applications. For
whatever the reason, change is the one thing that is constant
in integration efforts. The AIF is designed to allow changes
to be made easily.
The AIF has a modular design that allows new applications
to be integrated rapidly. It allows existing application
integrations to be migrated to new integration platforms.
It allows emerging technical standards to be used with existing
integrations. Red Oak Software has committed to blend new
standards such as Web Services into the AIF, such that work
that is completed today can be migrated to emerging standards
in the future.
Works with existing applications
While working with our existing customers, partners and
analysts, Red Oak identified the most common systems and
interfaces that require integration. We have taken that
into account while building the AIF and built integration
tools for the most common host and web applications first.
In some cases these systems are off-the-shelf applications
that have proprietary native interfaces. Many off-the-shelf
applications also require significant additional development
before the application can satisfy the needs of the organization.
A proprietary interface may be provided with the application,
but in many cases that interface only works with a small subset
of the application and may not satisfy the integration requirements.
There are also the complex occurrences where there has been
a homegrown customization of an off-the-shelf application.
In these cases, the developer needs tools other than those
that are provided by the provider of the original application.
Sometimes the target application is an in-house developed
or homegrown application. Even if the underlying subsystem
provides integration capabilities, the integration is often
either very complex or only works with a subset of the
applications developed on that platform. Many of these
applications have no native means for integration and a
custom solution is the only means for integration.
The AIF has taken all of these issues into account. The
AIF addresses the native user interface of the application.
If the application has a standard host or web interfaces,
the AIF can address access to the application and therefore
the information that resides in that application.
Works with existing integration systems
There are an ever-increasing number of ways to integrate
corporate data. Integration systems may be provided by
industry leaders like IBM, WebMethods, Vitria, GE/GXS.
In many cases, a company even provides multiple solutions
such as MQSeries and Websphere from IBM. Whether they call
it an adapter, a connector, or something else, each of these
vendors provides a model for linking external data with their
integration subsystem. In many cases this is a proprietary
model. AIF has taken this into account and has addressed many
of these subsystems directly.
In addition, many of these subsystems have started adding
industry standard models such as J2EE, JMS or Web Services
as alternative ways to link the application integration
with the integration subsystem. AIF is designed to accommodate
these emerging standards.
Low overhead for startup
With some of the more immediate integration efforts, there
is not time available for our integration expert to become
an application expert. It is rare to have an individual
that has a background in both integration and in the target
application(s). The AIF addresses this by making the
information required for integration is readily available.
In many cases, the experience of an advanced user is all
that is required for an integration project. The integration
expert doesn't have to have an understanding of the underlying
logic or structures of the target application. Simply having
access to a target-application expert should be enough for
identifying the information in the application that is required
for integration. In many cases, this provides for a fast
startup and shortens the development cycle considerably.
Designed for production systems
The AIF is based on the experience that Red Oak Software
has developed over several years of integration projects.
The technology delivered based on the AIF has been tested
in many significant integration efforts. The combination
of the products that are provided in the AIF and the experience
of Red Oak Software provide a solution that is solid, stable,
and production-ready.
back to top
What does the Application Integration Framework™ look like?
Red Oak Software's Application Integration Framework has
taken into account the many different functions that are
required to integrate an application. By breaking these
tasks into their logical components, the AIF is designed
to allow full functionality with existing applications.
It also provides a means to insert additional technologies
as required. Below is a diagram of the AIF with a description
of each component.
Integration Layer
This layer provides the necessary interface between the
target application and the integration subsystem. The
integration may require a proprietary interface or an
industry standard interface. Whether the interface is
proprietary, such as a WebMethods adapter, or industry
standard, such as JMS, this is where it would access the
underlying AIF technologies.
Custom Application Logic
This is where the custom integration code resides at
runtime. The code in this section drives all of the other
components below. This identifies what data is needed to
drive the application and what data will be extracted from
the application. It also holds the business logic that
drives the target application.
Logic Generation
This is a tool that allows the developer to simply use
the target application and identify the components that
are required for integration. This is a process that
does not require someone with advanced knowledge of the
inner workings of the application. In this case, the
integrator can drive logical units of work that are required
for integration. From here, usable code can be generated
that contains all of the logic required to drive the application.
This also stores the project information. If incremental
updates need to be made to the integration, the project
can be re-opened, additional components can be identified
and new code can be generated.
Logic Customization
If the generated code requires more complex or additional
logic beyond what the Logic Generation component can provide,
then the code can be opened and edited directly. The AIF
provides a very easy and straightforward set of functions
that can be used to modify and extended the generated logic.
In many cases, as developers become more familiar with the
technology, they may choose to develop the logic from scratch.
The flexibility to generate and edit code or manually create
code is a fundamental concept of the AIF.
Logic Engine
This engine understands the core functions of the logic
that drives an application running on the given system.
This is provided by the AIF and the engine is chosen based
on what type of interface the application provides.
Interface Engine
The interface engine has all of the logic that understands
the interface that is provided by the system on which the
application is running. This contains the information such
as terminal or browser interface information.
Communications Engine
This is the core communications engine that understands
how to communicate with the network substructure that
is provided for the application. This engine knows how
to format a packet of data that travels on the network
to interface with the given application.
Data Generation
In addition to providing links with common integration
subsystems and standards, the AIF provides a mechanism
whereas data can be delivered directly in a given format.
In this example, the generated logic can automatically
deliver the resulting application data in XML format.
In addition, the integrator can specify tags that fit
in with a custom format or with any of the industry standard
formats such as RosettaNet or BizTalk.
back to top