U.S. patent application number 11/467604 was filed with the patent office on 2007-03-22 for data-driven application integration adapters.
Invention is credited to Michael Gilfix, Jerry Walter Malcolm, Foluso Olaiya Okunseinde, Tyron Jerrod Stading, Paul Stuart Williamson, Scott Lee Winters.
Application Number | 20070067779 11/467604 |
Document ID | / |
Family ID | 32824167 |
Filed Date | 2007-03-22 |
United States Patent
Application |
20070067779 |
Kind Code |
A1 |
Gilfix; Michael ; et
al. |
March 22, 2007 |
Data-Driven Application Integration Adapters
Abstract
Software application integration, including constructing an
application integration adapter where the constructing is carried
out in dependence upon a profile. The profile includes data
describing the adapter. Embodiments include communicating
integration messages among applications through the adapter.
Profiles include identifications of at least two communications
transports, including configuration parameters for the data
communications transports. In typical embodiments, constructing an
application integration adapter includes creating the transports
identified in the adapter profile, and configuring the transports
in accordance with the configuration parameters.
Inventors: |
Gilfix; Michael; (Austin,
TX) ; Malcolm; Jerry Walter; (Austin, TX) ;
Okunseinde; Foluso Olaiya; (Austin, TX) ; Stading;
Tyron Jerrod; (Austin, TX) ; Williamson; Paul
Stuart; (Round Rock, TX) ; Winters; Scott Lee;
(Austin, TX) |
Correspondence
Address: |
INTERNATIONAL CORP (BLF)
c/o BIGGERS & OHANIAN, LLP
P.O. BOX 1469
AUSTIN
TX
78767-1469
US
|
Family ID: |
32824167 |
Appl. No.: |
11/467604 |
Filed: |
August 28, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10361202 |
Feb 6, 2003 |
|
|
|
11467604 |
Aug 28, 2006 |
|
|
|
Current U.S.
Class: |
719/313 |
Current CPC
Class: |
G06F 9/541 20130101 |
Class at
Publication: |
719/313 |
International
Class: |
G06F 9/46 20060101
G06F009/46; G06F 9/44 20060101 G06F009/44; G06F 13/00 20060101
G06F013/00; G06F 3/00 20060101 G06F003/00 |
Claims
1. A method of application integration, the method comprising:
constructing an application integration adapter, wherein the
constructing is carried out in dependence upon a profile comprising
data describing the adapter; and communicating integration messages
among applications through the adapter.
2. The method of claim 1 further comprising: providing an adapter
profile comprising identifications of at least two communications
transports, including configuration parameters for the data
communications transports; wherein constructing an application
integration adapter further comprises: creating the transports
identified in the adapter profile; and configuring the transports
in accordance with the configuration parameters.
3. The method of claim 2 wherein each transport comprises a
parameterized factory method for creating a receiver and
configuring the transports further comprises: creating a receiver
for each transport, carried out by a call to the parameterized
factory method for creating a receiver with at least some of the
configuration parameters; registering a transport event listener
with each receiver.
4. The method of claim 3 wherein the application integration
adapter comprises a transport event listener.
5. The method of claim 2 wherein each transport comprises a factory
method for creating a sender, and configuring the transports
further comprises creating a sender for each transport.
6. The method of claim 2 wherein: providing an adapter profile
further comprises providing an adapter profile comprising
identifications of one or more data transfer managers, including
configuration parameters for the data transfer managers, and
constructing an application integration adapter further comprises:
creating the transfer managers identified in the profile; and
configuring the transfer managers in dependence upon the
configuration parameters.
7. The method of claim 1 wherein communicating integration messages
among applications through the adapter further comprises: receiving
from a source application an integration message having a source
message format and a source data structure; translating the
integration message from the source message format to a destination
message format useful to a destination application; and sending the
integration message to a destination application.
8. The method of claim 1 wherein communicating integration messages
among applications through the adapter further comprises: receiving
from a source application an integration message having a source
message format and a source data structure; translating the
integration message from the source message format to an interim
message format useful for internal processing within the adapter;
transforming the integration message from the source data structure
to a destination data structure; and sending the integration
message to a destination application.
9. The method of claim 8 further comprising translating the
integration message from the interim message format to a
destination message format useful to the destination
application.
10. The method of claim 9 wherein the transforming is carried out
through a transfer manager.
11. A system for application integration, the system comprising a
computer processor and a computer memory operatively coupled to the
computer processor, the computer memory having disposed within it
computer program instructions capable of: constructing an
application integration adapter, wherein the constructing is
carried out in dependence upon a profile comprising data describing
the adapter; and communicating integration messages among
applications through the adapter.
12. The system of claim 11 further comprising computer program
instructions capable of: providing an adapter profile comprising
identifications of at least two communications transports,
including configuration parameters for the data communications
transports; wherein constructing an application integration adapter
further comprises: creating the transports identified in the
adapter profile; and configuring the transports in accordance with
the configuration parameters.
13. The system of claim 12 wherein: providing an adapter profile
further comprises providing an adapter profile comprising
identifications of one or more data transfer managers, including
configuration parameters for the data transfer managers, and
constructing an application integration adapter further comprises:
creating the transfer managers identified in the profile; and
configuring the transfer managers in dependence upon the
configuration parameters.
14. The system of claim 12 wherein each transport comprises a
parameterized factory method for creating a receiver and
configuring the transports further comprises: creating a receiver
for each transport, carried out by a call to the parameterized
factory method for creating a receiver with at least some of the
configuration parameters; and registering a transport event
listener with each receiver.
15. The system of claim 11 wherein communicating integration
messages among applications through the adapter further comprises:
receiving from a source application an integration message having a
source message format and a source data structure; translating the
integration message from the source message format to a destination
message format useful to a destination application; and sending the
integration message to a destination application.
16. A computer program product for application integration, the
computer program product disposed upon a recording medium, the
computer program product comprising computer program instructions
capable of: constructing an application integration adapter,
wherein the constructing is carried out in dependence upon a
profile comprising data describing the adapter; and communicating
integration messages among applications through the adapter.
17. The computer program product of claim 16 further comprising
computer program instructions capable of: providing an adapter
profile comprising identifications of at least two communications
transports, including configuration parameters for the data
communications transports; wherein constructing an application
integration adapter further comprises: creating the transports
identified in the adapter profile; and configuring the transports
in accordance with the configuration parameters.
18. The computer program product of claim 17 wherein: providing an
adapter profile further comprises providing an adapter profile
comprising identifications of one or more data transfer managers,
including configuration parameters for the data transfer managers,
and constructing an application integration adapter further
comprises: creating the transfer managers identified in the
profile; and configuring the transfer managers in dependence upon
the configuration parameters.
19. The computer program product of claim 17 wherein each transport
comprises a parameterized factory method for creating a receiver
and configuring the transports further comprises: creating a
receiver for each transport, carried out by a call to the
parameterized factory method for creating a receiver with at least
some of the configuration parameters; and registering a transport
event listener with each receiver.
20. The computer program product of claim 16 wherein communicating
integration messages among applications through the adapter further
comprises: receiving from a source application an integration
message having a source message format and a source data structure;
translating the integration message from the source message format
to a destination message format useful to a destination
application; and sending the integration message to a destination
application.
Description
CLAIM OF BENEFIT OF EARLIER FILING DATE OF RELATED APPLICATION
PURSUANT TO 37 CFR .sctn. 1.78(a)(2)(i)
[0001] This application is a continuation of a prior-filed
copending nonprovisional patent application, U.S. patent
application Ser. No. 10/361,202 filed on Feb. 6, 2003. Applicants
claim for this application the benefit of the earlier filing date
of application Ser. No. 10/361,202.
BACKGROUND OF THE INVENTION
[0002] 1. Field of the Invention
[0003] The field of the invention is data processing, or, more
specifically, methods, systems, and products for software
application integration.
[0004] 2. Description Of Related Art
[0005] Software applications integration is crucial in improving
productivity and reducing costs. By streamlining and integrating
business processes, companies can greatly reduce operational
overhead. By connecting business support systems and operational
support systems, applications are able to work in harmony without
costly intervention. By moving away from point-to-point messaging,
companies gain the benefits of a centralized messaging
infrastructure: greater control over business processes and
increased operational efficiency.
[0006] In the past, software applications integration has been
achieved only with high cost. Components of business support
systems and operational support systems are often developed and
manufactured by separate manufacturers or developers, utilize
disparate data structures to encode the same data and utilize
disparate modes of data communications. An inventory control
application from one developer may post inventory changes, for
example, across TCP/IP to a general ledger developed by an entirely
different company. The same inventory control application may post
in HTML through HTTP to a purchasing system from a third vendor
using a third set of data structures. The purchasing system may
post to the general ledger, using a third combination of data
structures. And so on. The combinations are endless. And in the
past, each such integration was accomplished by hiring systems
analysts, software development project managers, software system
architects, senior programmers, junior programmers, and so on, to
build application integration adapters to convert the data
structures and administer the data communications among all these
disparate software application systems.
[0007] Such application integration adapters have typically been
implemented in a so-called `point-to-point` fashion. That is, an
adapter is developed to couple this particular inventory
application through this particular data communications coupling
using this particular data communications protocol to this
particular general ledger. Adding a new application to the mix
required all the same new develop costs as for the first two
applications to be integrated. For all these reasons, it would be
advantageous to have improved means and methods for application
integration.
SUMMARY OF THE INVENTION
[0008] Exemplary embodiments of the invention include methods of
application integration. Such embodiments include constructing an
application integration adapter where the constructing is carried
out in dependence upon a profile comprising data describing the
adapter. Typical embodiments include communicating integration
messages among applications through the adapter.
[0009] Exemplary embodiments of the invention include providing an
adapter profile including identifications of at least two
communications transports, including configuration parameters for
the data communications transports. In such embodiments,
constructing an application integration adapter includes creating
the transports identified in the adapter profile, and configuring
the transports in accordance with the configuration parameters. In
typical embodiments, providing an adapter profile includes
providing an adapter profile comprising a route map of data routes
among the transports within the adapter. In exemplary embodiments,
communicating integration messages among applications is carried
out in dependence upon the route map.
[0010] In exemplary embodiments of the invention, each transport
includes a parameterized factory method for creating a receiver. In
such embodiments, configuring the transports includes creating a
receiver for each transport, carried out by a call to the
parameterized factory method for creating a receiver with at least
some of the configuration parameters, and registering a transport
event listener with each receiver. In typical embodiments, the
application integration adapter comprises a transport event
listener.
[0011] In exemplary embodiments, each transport includes a factory
method for creating a sender. In such embodiments, configuring the
transports includes creating a sender for each transport. In
typical embodiments, providing an adapter profile includes
providing an adapter profile including identifications of one or
more data transfer managers, including configuration parameters for
the data transfer managers. In such embodiments, constructing an
application integration adapter includes creating the transfer
managers identified in the profile, and configuring the transfer
managers in dependence upon the configuration parameters.
[0012] In exemplary embodiments of the invention, communicating
integration messages among applications through the adapter
includes receiving from a source application an integration message
having a source message format and a source data structure,
translating the integration message from the source message format
to a destination message format useful to a destination
application, and sending the integration message to a destination
application. In such embodiments, communicating integration
messages among applications through the adapter includes receiving
from a source application an integration message having a source
message format and a source data structure, and translating the
integration message from the source message format to an interim
message format useful for internal processing within the adapter
including particularly data transformation and security processing
but also including other modes of processing as will occur to those
of skill in the art. Typical embodiments also include transforming
the integration message from the source data structure to a
destination data structure, and sending the integration message to
a destination application. Such embodiments include translating the
integration message from the interim message format to a
destination message format useful to the destination
application.
[0013] The foregoing and other objects, features and advantages of
the invention will be apparent from the following more particular
descriptions of exemplary embodiments of the invention as
illustrated in the accompanying drawings wherein like reference
numbers generally represent like parts of exemplary embodiments of
the invention.
BRIEF DESCRIPTION OF THE DRAWINGS
[0014] FIG. 1 is a block diagram illustrating architectural aspects
of application integration adapters according to various
embodiments of the present invention.
[0015] FIG. 1a shows a more detailed architectural example of an
adapter providing integration for three applications.
[0016] FIG. 1b shows a further architectural example of an adapter
providing integration for applications.
[0017] FIG. 2 sets forth a data flow diagram illustrating a method
of application integration utilizing application integration
adapters.
[0018] FIG. 3 sets forth a data flow diagram illustrating a method
of creating receivers and senders for transports for application
integration adapters according to the present invention.
[0019] FIG. 4 sets forth a data flow diagram illustrating an
exemplary method of creating transfer managers.
[0020] FIG. 5 illustrates relations among exemplary classes from
which adapters are constructed according to embodiments of the
present invention.
[0021] FIGS. 5a-5h illustrate examples of class structures useful
in various exemplary embodiments of the present invention.
[0022] FIG. 6 sets forth a calling sequence diagram illustrating a
method of constructing application integration adapters.
[0023] FIG. 7 sets forth a data flow diagram depicting an exemplary
method of communicating integration messages among applications
through an adapter.
[0024] FIG. 8 sets forth a data flow diagram depicting a further
exemplary method of communicating integration messages among
applications through an adapter.
[0025] FIG. 9 sets forth a calling sequence diagram illustrating a
method of communicating integration messages among applications
through an adapter.
DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS
Introduction
[0026] The present invention is described to a large extent in this
specification in terms of methods for software application
integration. Persons skilled in the art, however, will recognize
that any computer system that includes suitable programming means
for operating in accordance with the disclosed methods also falls
well within the scope of the present invention.
[0027] Suitable programming means include any means for directing a
computer system to execute the steps of the method of the
invention, including for example, systems comprised of processing
units and arithmetic-logic circuits coupled to computer memory,
which systems have the capability of storing in computer memory,
which computer memory includes electronic circuits configured to
store data and program instructions, programmed steps of the method
of the invention for execution by a processing unit. The invention
also may be embodied in a computer program product, such as a
diskette or other recording medium, for use with any suitable data
processing system.
[0028] Embodiments of a computer program product may be implemented
by use of any recording medium for machine-readable information,
including magnetic media, optical media, or other suitable media.
Persons skilled in the art will immediately recognize that any
computer system having suitable programming means will be capable
of executing the steps of the method of the invention as embodied
in a program product. Persons skilled in the art will recognize
immediately that, although most of the exemplary embodiments
described in this specification are oriented to software installed
and executing on computer hardware, nevertheless, alternative
embodiments implemented as firmware or as hardware are well within
the scope of the present invention.
Definitions
[0029] In this specification, the terms "field," "data element,"
and "attribute," unless the context indicates otherwise, generally
are used as synonyms, referring to individual elements of digital
data. Aggregates of data elements are referred to as "records" or
"data structures." Aggregates of records are referred to as
"tables" or "files." Aggregates of files or tables are referred to
as "databases." Complex data structures that include member
methods, functions, or software routines as well as data elements
are referred to as "classes." Instances of classes are referred to
as "objects" or "class objects."
[0030] "802. 11" refers to a family of specifications developed by
the IEEE for wireless LAN technology. 802.11 specifies an
over-the-air interface between a wireless client and a base station
or between two wireless clients.
[0031] "API" is an abbreviation for "application programming
interface." An API is a set of routines, protocols, and tools for
building software applications.
[0032] "Bluetooth" refers to an industrial specification for a
short-range radio technology for RF couplings among client devices
and between client devices and resources on a LAN or other network.
An administrative body called the Bluetooth Special Interest Group
tests and qualifies devices as Bluetooth compliant. The Bluetooth
specification consists of a `Foundation Core,` which provides
design specifications, and a `Foundation Profile,` which provides
interoperability guidelines.
[0033] "CORBA" means the Common Object Request Broker Architecture,
a standard for remote procedure invocation first published by the
Object Management Group ("OMG") in 1991. CORBA can be considered a
kind of object-oriented way of making "RPCs" or remote procedure
calls, although CORBA supports many features that do not exist in
RPC as such. By use of CORBA technology, remote method invocations
effected in object-oriented programming languages such as Java and
C++ look like invocations of local member methods in local
objects.
[0034] CORBA data communications are administered by middleware
applications known as Object Request Brokers or `ORBs.` ORBs
communicate with "GIOP," the General Inter-ORB Protocol, the CORBA
protocol that defines structures and formats for passing messages
among heterogeneous computers and their various architectures. GIOP
is not based on any particular network protocol, such as IPX or
TCP/IP. GIOP defined to function over its most widely used
communication transport platform, TCP/IP, is called "IIOP," the
Internet Inter-ORB Protocol. Because of the general usefulness of
tcp/ip, this disclosure, in describing example embodiments, tends
to use the terms GIOP and IIOP more or less interchangeably,
although the use of the term IIOP is not intended to limit
application of embodiments of the present invention to the single
transport protocol suite TCP/IP.
[0035] "CGI" means "Common Gateway Interface," a standard
technology for data communications of resources between web servers
and web clients. More specifically, CGI provides a standard
interface between servers and server-side `gateway` programs which
administer actual reads and writes of data to and from file systems
and databases. The CGI interface typically sends data to gateway
programs through environment variables or as data to be read by the
gateway programs through their standard inputs. Gateway programs
typically return data through standard output.
[0036] "Coupled for data communications" means any form of data
communications, wireless, 802.11b, Bluetooth, infrared, radio,
internet protocols, HTTP protocols, email protocols, networked,
direct connections, dedicated phone lines, dial-ups, serial
connections with EIA232 (RS-232), IEEE 1394 (often called
`Firewire` connections, a trademark of Apple Computer, Inc.),
Universal Serial Buses ("USB"), hard-wired parallel port
connections, and other forms of data communications as will occur
to those of skill in the art. Couplings for data communications
include sharing of files, including transferring files from
application to application, from an adapter to an application, or
from an application to an adapter, including flat files, binary
files, text files, database files, HTML files, XML documents, and
so on.
[0037] "DCOM" means `Distributed Component Object Model,` an
extension of Microsoft's Component Object Model ("COM") to support
objects distributed across networks. DCOM is part of certain
Microsoft operating systems, including Windows NT, and is available
for other operating systems. DCOM serves the same purpose as IBM's
DSOM protocol, which is a popular implementation of CORBA. Unlike
CORBA, which runs on many operating systems, DCOM is currently
implemented only for Windows.
[0038] "Format" or "data format" refers to the overall form of data
encoding for data processing and data communications. Examples of
data formats include data encoded in the form of HTML documents,
XML documents, Java data structures, C++ data structures, C data
structures, and so on. In addition to format, computer data has
structure, including data element names, data element types, and
data element values. In this disclosure, changing or converting the
format of data is referred to as "data translation," "translation,"
or "translating." In this disclosure, changing or converting the
structure of data is referred to as "data transformation,"
"transformation," or "transforming."
[0039] "HTML" stands for `HyperText Markup Language,` a standard
markup language for displaying web pages on browsers.
[0040] "HTTP" stands for `HyperText Transport Protocol,` the
standard data communications protocol of the World Wide Web.
[0041] "JMS" means `Java Message Service,` a Java API specifically
designed for application integration messaging. JMS provides a kind
of Java enterprise bean that supports asynchronous administration
of message traffic. JMS sends and receives can participate in
transactions controlled through the Java Transaction API ("JTA").
The JTA operates in coordination with the Java Transaction Service
("JTS"). JTA allows applications and application servers to access
transactions. JTS specifies the implementation of a Transaction
Manager that supports JTA and implements the Java mapping of the
OMG Object Transaction Service ("OTS") at the level below the API.
JTS propagates transactions using IIOP.
[0042] "IMAP" means `Internet Message Access Protocol.` IMAP is a
protocol for retrieving email messages from Internet email servers.
In "offline" operation, an email client fetches messages from an
email server to the client machine where the email client program
is running, and then deletes the email messages from the
server.
[0043] In "online" operation, messages can be left on the email
server and manipulated remotely by email client programs. POP
supports offline email operations. IMAP, the newer protocol,
supports both offline and online email operations.
[0044] "LAN" means `local area network.`
[0045] "Network" is used in this specification to mean any
networked coupling for data communications among computers or
computer systems. Examples of networks useful with the invention
include intranets, extranets, internets, local area networks, wide
area networks, and other network arrangements as will occur to
those of skill in the art.
[0046] "POP" means `Post Office Protocol.` POP is a protocol used
by an email client to retrieve email from a mail server. There are
two versions of POP. POP2 requires SMTP to receive email messages
from clients or other servers. The newer version, POP3, can be used
with or without SMTP.
[0047] "RMI" refers to `Remote Method Invocation,` a protocol set
developed by Sun Microsystems to enables Java objects to
communicate remotely with other Java objects. RMI is a relatively
simple protocol, but unlike more complex protocols such as CORBA
and DCOM, it works only with Java objects. CORBA and DCOM support
networked communications and remote procedure calls among objects
created in any language.
[0048] "Server" in this specification refers to a computer or
device comprising automated computing machinery on a network that
manages resources and requests for access to resources. A "security
server" can be any server that manages access to resources by use
of security objects according to the present invention. A "web
server," or "HTTP server," in particular is a server that
communicates with browsers by means of HTTP in order to manage and
make available to networked computers documents in markup languages
like HTML, digital objects, and other resources.
[0049] A "Servlet," like an applet, is a program designed to be run
from another program rather than directly from an operating system.
"Servlets" in particular are designed to be run on servers from a
conventional Java interface for servlets. Servlets are modules that
extend request/response oriented servers, such as Java-enabled web
servers. Java servlets are an alternative to CGI programs. The
biggest difference between the two is that a Java servlet is
persistent. Once a servlet is started, it stays in memory and can
fulfill multiple requests. In contrast, a CGI program disappears
after it has executed once, fulfilling only a single a request for
each load and run. The persistence of Java servlets makes them
generally faster than CGI because no time is spent on loading
servlets for invocations after a first one.
[0050] "SMTP" means `Simple Message Transfer Protocol.` SMTP is a
protocol for sending email messages between server. Internet email
traffic largely travels over SMTP from server to server. After
email arrives at a target server, email messages are then retrieved
from the server with an email client using either POP or IMAP or.
SMTP also is used to send messages from mail clients to mail
servers.
[0051] "SOAP" is the Simple Object Access Protocol, a protocol for
applications communications over the Internet, independent of
platform. SOAP includes a convention for representing remote
procedure calls and responses. SOAP can potentially be used with a
variety of transport protocols, although as a practical matter to
date, it is used mostly with HTTP. SOAP generally uses XML to
define message formats and then adds HTTP headers for data
communications.
[0052] "TCP/IP" refers to two data communications protocols
implementing the network layer and the transport layer of the
standard ISO protocol stack for data communications protocols.
Strictly speaking, "TCP," the "Transmission Control Protocol," is a
separate layer residing above "IP," the "Internet Protocol." The
two are often spoken of together, however, as the `TCP/IP protocol
suite.`
[0053] A "URI" or "Universal Resource Identifier" is an identifier
of a named object in any namespace accessible through a network.
URIs are functional for any access scheme, including for example,
the File Transfer Protocol or "FTP," Gopher, and the web. A URI as
used in typical embodiments of the present invention usually
includes an internet protocol address, or a domain name that
resolves to an internet protocol address, identifying a location
where a resource, particularly a web page, a CGI script, or a
servlet, is located on a network, usually an internet, a net work
using the Internet Protocol in its ISO network layer. URIs directed
to particular resources, such as particular HTML files, CGI
scripts, or servlets, typically include a path name or file name
locating and identifying a particular resource in a file system
coupled through a server to a network. To the extent that a
particular resource, such as a CGI file or a servlet, is
executable, for example to store or retrieve data, a URI often
includes query parameters, or data to be stored, in the form of
data encoded into the URI. Such parameters or data to be stored are
referred to as `URI encoded data.`
[0054] "URLs" or "Universal Resource Locators" comprise a kind of
subset of URIs, wherein each URL resolves to a network address.
That is, URIs and URLs are distinguished in that URIs identify
named objects in namespaces, where the names may or may not resolve
to addresses, while URLs do resolve to addresses. Although
standards today are written on the basis of URIs, it is still
common to such see web-related identifiers, of the kind used to
associate web data locations with network addresses for data
communications, referred to as "URLs." This specification refers to
such identifiers generally as URIs.
[0055] "WAN" means `wide area network.` An example of a WAN is the
Internet.
[0056] "World Wide Web," or more simply "the web," refers to a
system of internet protocol ("IP") servers that support specially
formatted documents, documents formatted in markup languages such
as HTML, XML (eXtensible Markup Language), WML (Wireless Markup
Language), or HDML (Handheld Device Markup Language). The term
"Web"0 is used in this specification also to refer to any server or
connected group or interconnected groups of servers that implement
a hyperlinking protocol, such as HTTP or WAP (the `Wireless Access
Protocol`), in support of URIs and documents in markup languages,
regardless of whether such servers or groups of servers are coupled
to the World Wide Web as such.
[0057] "XML" refers to the `eXtensible Markup Language,` a known
standard for structuring data. XML is designed to provide flexible
and adaptable information formatting and identification. XML is
called extensible because it has no fixed format like HTML, the
Hypertext Markup Language, which is a set of predefined markups.
Instead, XML is actually a `metalanguage`--a language for
describing other languages--which allows users to design customized
markup languages for many different types of documents. XML is not,
however, a programming language as such; it is a markup standard
for structuring data. In this disclosure, however, because XML has
the effect of encoding or structuring computer data, preparation of
XML documents and XSL specifications, although they may not be
carried out by computer programmers as such, nevertheless are
considered computer programming or software development.
[0058] Like HTML, XML makes use of elements, tags, and attributes.
Elements are content segements identified by tags. Elements have
possibly empty values, the value of an instance of an element being
the string between the beginning and ending tags for the instance
of the element. `Tags` are words bracketed by `<` and `>,`
and attributes are defined characteristics of elements having for
example the form: AttributeName="value". While HTML specifies what
each tag and attribute means, and often how the text between them
will look in a browser, XML uses the tags only to delimit pieces of
data, and leaves the interpretation of the data completely to the
application that reads it. In other words, although in the
predefined syntax of HTML, "<p>" means `paragraph,`
"<p>" in an XML file means whatever the reading application
says it means. Depending on the context, it may be a price, a
parameter, a person, or in many cases it represents an entity
having nothing to do with Ps.
[0059] "XSL" refers to the `Extensible Style Language,` a
specification for separating style from content when creating HTML
or XML pages. XSL specifications work much like templates, allowing
users and designers to apply single style documents to multiple
pages. XSL is the second style specification to be offered by the
World Wide Web Consortium. The first, called Cascading Style
Sheets, is similar to XSL but does not include two major XSL's
innovations--allowing developers to dictate the way Web pages are
printed, and, an innovation particularly useful in many embodiments
of the present invention, specifications allowing users or
developers to transfer XML documents across different applications.
That is, XSL has the capability of specifying transformations of
data structures expressed in XML.
[0060] "XSLT" refers to the Short for `Extensible Style Language
Transformation,` the language used in XSL style sheets to transform
XML documents into other XML documents. An XSL processor reads the
XML document and follows the instructions in the XSL style sheet;
then it outputs a new XML document or XML-document fragment. This
is particularly useful in various embodiments of the present
invention, where the same data formats need to be converted into
different structures represented in XML.
Application Integration
[0061] Exemplary embodiments of the present invention provide
application integration adapters capable of data transformation,
data translation, and data communications in a variety of computer
architectures. FIG. 1, 1a, and 1b illustrate several architectural
arrangements supported by, or useful with, application integration
adapters ("adapters") according to various embodiments of the
present invention. These figures also present certain architectural
aspects of the adapters themselves according to various embodiments
of the present invention.
[0062] FIG. 1 sets forth exemplary data communications
architectures among adapters. According to one exemplary
architecture of FIG. 1, an adapter (102) integrates functions of an
application (106), inside a security firewall (128), with an
application (116) on the other side of the same firewall (128). The
adapter is coupled (118) for data communications across a WAN (126)
to the application (116) outside the firewall (128). The adapter is
coupled (106) for data communications to the application (116)
inside the firewall (128), in fact installed on the same
application server (104) with the adapter (102).
[0063] Couplings for data communications include any method,
device, or protocol for data communications, optical, electrical,
mechanical, or other. Couplings for data communications certainly
include all data communications protocols and remote procedure
protocols such as HTTP, CORBA, DCOM, IIOP, GIOP, RMI, SOAP, and so
on.
[0064] Couplings for data communications include messaging to
wireless pager clients identified by telephone numbers over the
Simple Network Paging Protocol or `SNPP,` version 3 of which is an
enhanced, two-way protocol as defined in RFC 1861. RFC 1861 is an
Internet protocol suite specification document promulgated by the
Network Working Group in the Internet Engineering Task Force.
[0065] Couplings for data communications include messaging to
wireless pager clients WCTP, the `Wireless Communication Transfer
Protocol.` WCTP is another two-way messaging protocol. WCTP is
designed with the particular intention of using HTTP as its
transport mechanism. WCTP is an open, non-proprietary industry
standard promulgated by members of the PCIA, the Personal
Communications Industry Association.
[0066] Couplings for data communication include messaging
transmitted over HTTP through any of a number of proprietary
instant messaging protocols, all of which have application
programming interfaces ("APIs") available just for this purpose,
that is, for use in messaging applications such as PVRs. Examples
of such instant messaging protocols having APIs include those
available from American On-Line ("AOL"), Microsoft Network ("MSN"),
Yahoo, Imici, Inc., and ICQ, Inc.
[0067] Couplings for data communications include transmitting
messages as email through SMTP, POP, IMAP or other email protocols,
between adapters and applications on any kind of device, personal
computers, laptops, handhelds, cell phones, servers, and so on.
[0068] Couplings for data communications include the Small Message
Service ("SMS") as supported by any telecommunications or telephone
service. SMS provides a mechanism for transmitting short messages
to and from wireless devices. SMS supports the transmission of
short text messages from an adapter to an application a manner
similar to alpha-numeric paging. SMS makes use of a Small Message
Service Center or `SMSC,` which acts as a store-and-forward system
for short messages. In contrast to other existing text-message
transmission services such as alphanumeric paging, SMS is a
reliable system, providing mechanisms to guarantee delivery of text
messages to destinations. Additionally, SMS supports several input
mechanisms that allow interconnection with different message
sources and destinations. An adapter, or it sender or receiver,
can, for example, function as a so-called `External Short Message
Entity,` or `ESME,` and transmit SMS messages as HTTP forms or
email messages. An adapter can function as a mobile originator, or
`MO,` that is, an SMS-enabled client device or, in effect, a
cellular telephone. A distinguishing characteristic of SMS is that
an SMS-enabled client is able to receive or submit a short message
at any time, regardless whether a voice or data call is in
progress.
[0069] Couplings for data communications include methods of data
coupling other than data communications protocols as such,
including, for example, shared memory segments, which could very
well be the method utilized in an architecture in which an adapter
(102) is installed on the same server (104) with an application
(106) integrated by the adapter. A communications module within the
application (106) and a communications module with the adapter
(102), such as the receivers and senders discussed in more detail
below in this disclosure, can be implemented as synchronized Java
methods or C or C++ threads communicating messages through shared
memory segments with mutual exclusion administered by use of
semaphores.
[0070] As described above, couplings for data communications
include wired network protocols as well as wireless network
protocols and messaging systems. In addition, however, couplings
for data communications include non-networked couplings as well,
including wired serial couplings according to RS-232 (EIA232), IEEE
1394 (often called `Firewire` connections, a trademark of Apple
Computer, Inc.), hard-wired parallel port connections, and other
direct, wired couplings as will occur to those of skill in the
art.
[0071] According to a further exemplary architecture of FIG. 1, an
adapter (136) on a client workstation (132) integrates functions of
an application (134), installed on the same workstation, with an
application (116) on a server coupled (136) for data communications
through a LAN (130) to the workstation. The coupling for data
communications (108) between the adapter (136) and the application
(134), because the adapter (136) and the application (134) are on
the same computer, can be implemented as local calls to software
programs or modules on the work station, even through shared memory
segments, or through other methods as will occur to those of skill
in the art for programs or threads of execution on the same
computer to communicate with one another. Although this particular
architectural example is shown with a LAN (130) coupling between
the server (114) and the workstation (132), readers by now will
understand that the workstation can be a notebook computer and the
coupling for data communications (136) can be an RS232 or USB
connection direct through a wire between the server (114) and the
workstation (132).
[0072] According to a further exemplary architecture of FIG. 1, an
adapter (102) integrates functions of three applications (106, 112,
116). The adapter (102) is coupled (116) for data communications
through a WAN (126) to one application (116). The adapter (102) is
coupled (108) for data communications to another application (106)
installed on the same server (104) with the adapter. And the
adapter (102) is coupled (126) for data communications through a
LAN (124) to a third application (112) on a second server (110)
behind the same firewall (128) with the adapter (102). In such an
architecture, if the application (116) were an inventory control
program in a refinery, the application (106) was a general ledger
on a server in a corporate headquarters, and the application (112)
were a purchasing system in another building on the same corporate
campus as the headquarters, then the purchasing system can transmit
posting messages for inventory changes via HTTP to the adapter
(102) which can forward them via a shared memory segment to the
general ledger and via SOAP, IIOP, or RMI to the purchasing system.
The purchasing system and the general ledger can respond with
acknowledgment messages to the inventory control program. The
purchasing system can transmit posting messages for new purchases
to the general ledger only, without copying the inventory control
system. And the general ledger can send acknowledgements to the
purchasing system only, without copying the inventory control
program. All three applications can utilize completely different
data structures in their messages, developed with no coordination
by three different software development companies.
[0073] FIG. 1a shows a more detailed architectural example of an
adapter (102) providing integration for three applications (106,
112, 116). The example of FIG. 1a includes three software modules
(140, 142, 144) called `transports,` used in many adapters
according to embodiments of the present invention to carry out data
communications and message format translation. The exemplary
adapter of FIG. 1a includes a map (105), a data structure mapping
message routes among the transports. That is, many adapters
according to embodiments of the present invention route messages
among transports, and therefore among applications, in dependence
upon route maps. Continuing with the example of the inventory
control program, the general ledger, and the purchasing system, the
adapter (102) of FIG. 1a, by use of the route map (105) can know
that: [0074] posting messages from the purchasing system are routed
only to the general ledger and not to the inventory control
program; [0075] purchase posting acknowledgment messages from the
general ledger are routed only to the purchasing system, not to the
inventory control program; [0076] posting messages from the
inventory control program are routed to both the general ledger and
to the purchasing system; [0077] inventory posting acknowledgment
messages from the general ledger are routed only to the inventory
control program; and [0078] inventory posting acknowledgement
messages from the purchasing system are routed only to the
inventory control program.
[0079] A simple adapter, having only two transports and integrating
only two applications, may advantageously operate without a route
map, routing all messages from either application to the other
application, regardless of message type. The example of FIG. 1a
illustrates the usefulness of a route map in an adapter, however,
with, in this example, the route map keyed by message type, source,
and destination. The example of FIG. 1a illustrates only three
applications integrated with only three adapters, and this
disclosure discussed only a few messages types. The usefulness of
route maps is clear then in light of the fact that in adapters
according to embodiments of the present invention there is no
limitation regarding the number of transports in an adapter or the
number of applications that can usefully be integrated.
[0080] FIG. 1b shows a further architectural example of an adapter
(102) providing integration for applications (112, 116). In the
example of FIG. 1b, the transports (142, 144) include additional
software modules, called `receivers` (312) and `senders` (316),
that are used in many adapters according to embodiments of the
present invention to carry out data communications between adapters
and software applications. In embodiments of the kind exemplified
in FIG. 1b, the receivers and senders each administers its own
coupling for data communications (118, 119, 126, 127). In addition,
there is no limitation of the present invention regarding the types
of couplings. That is, in a particular exemplary adapter according
to an embodiment of the present invention, a receiver (312) in a
transport (142) can implement its coupling for data communications
with an application in the form of message traffic according to
SOAP, while the sender (316) in the same transport (142) sends its
message traffic in the form of plain HTTP `post` messages.
[0081] FIG. 2 sets forth a data flow diagram illustrating a method
of application integration utilizing application integration
adapters. In particular, the method of FIG. 2 includes constructing
(204) an application integration adapter, where the constructing is
carried out in dependence upon a profile (202) comprising data
describing the adapter. The method of FIG. 2 also includes
providing (210) an adapter profile comprising identifications (214)
of at least two communications transports, including configuration
parameters (218) for the data communications transports. In many
embodiments of adapters according to the present invention,
providing (210) a profile is carried out by a user's or developer's
typing into a text file designated for use as a profile, through a
word processor or text editor, a representation of a data structure
describing components of an adapter. The representation can be any
encoding of data structure, including, for example, XML. In fact,
this disclosure discusses profile mainly in terms of XML, but this
is for convenience of explanation, not for limitation of the
invention. Profiles can be encoded with any representation of data
structure, C, C++, Java, SGML (the Standard Generalized Markup
Language), and others as will occur to those of skill in the
art.
[0082] The method of FIG. 2 also includes communicating (206)
integration messages (208) among applications (105, 112) through
the adapter (102). In many embodiments of the method of FIG. 2,
providing (210) an adapter profile further comprises providing an
adapter profile comprising a route map (216) of data routes among
the transports (212) within the adapter, and communicating (206)
integration messages among applications is carried out in
dependence upon the route map (216). In the method according to
FIG. 2, constructing (214) an integration adapter also includes
creating (220) the transports (212) identified in the adapter
profile (202) and configuring (222) the transports (212) in
accordance with the configuration parameters (218).
[0083] A profile is a data structure that represents an adapter
structure and has data elements that identify and describe the
adapter's components. An adapter according to embodiments of the
present invention uses the profile to effectively construct itself
according to the descriptions of its components set forth in the
profile. Because profiles are data structures, profiles can be
implemented in any way that any data structure can be implemented,
in any programming language, in any kind of encoding, in any kind
of file format or database record structure. This disclosure
represents profiles in XML, not as a limitation, but because XML is
conveniently comprehensible to human readers where many
implementations of profiles, for example in binary machine-readable
formats would not be so convenient for use in explanation. Also in
this disclosure, examples tend to be presented in object oriented
terms, in terms of Java and C++ in particular. But once again,
there is within the present invention no limitation to any
particular programming paradigm or to any particular programming
language or languages. With these cautionary notes in view, here is
an XML example of a profile: TABLE-US-00001 <adapter>
<transportmodules> <transport
class="InventoryControl.java" id="inventoryControl">
<receiver> <configParm>parmValue</configParm>
</receiver> <sender>
<configParm>parmValue</configParm> </sender>
</transport> <transport class="GeneralLedger.java"
id="generalLedger"> <receiver>
<configParm>parmValue</configParm> </receiver>
<sender> <configParm>parmValue</configParm>
</sender> </transport> </transportmodules>
<transfermodules> <transferManager class="xfrMgr1.java"
order="1"> <configParm>parmValue</configParm>
</transferManager> <transferManager class="xfrMgr2.java"
order="2"> <configParm>parmValue</configParm>
</transferManager> <transferManager class="xfrMgr2.java"
order="3"> <configParm>parmValue</configParm>
</transferManager> </transfermodules>
</adapter>
[0084] This exemplary XML profile identifies two transports, one
named `inventoryControl` and one named `generalLedger.` Each
transport has a receiver and a sender. Each receiver and sender has
a configuration parameter. Many implementations of profiles will
identify and define more than two transports, and many
implementations of senders and receivers will have more than one
configuration parameter. The numbers in this example are picked for
clarity and brevity of explanation, not for limitation.
[0085] In the case of senders and receivers for dial-up telephone
communications protocols, for example, configuration parameters can
include telephone numbers, modems speeds, login identification
codes, passwords, and so on. In the case of senders and receivers
for the HTTP communication protocol, configuration parameters
include one or more URIs. In the case of senders and receivers
implementing data communications with JMS, for example,
configuration parameters can include identifications of JMS queues,
queue connections, queue senders, queue connection factory objects
or factory methods, naming directory contexts, and so on. In the
case of senders and receivers implementing data communications over
plain TCP/IP, configuration parameters include internet protocol
addresses and port numbers. For senders and receivers implementing
data communications through flat files in file systems,
configuration parameters include path names and filenames.
[0086] The example XML profile identifies and provides
configuration parameters for three transfer managers. A transfer
manager is essentially self-contained program code that is allowed
to manipulate message received or sent by an adapter. Transfer
managers allow for arbitrary processing on messages to support
advanced routing, translation, security, logging, or any other
function of message processing as will occur to those of skill in
the art. The transfer managers and the order in which they are run
are defined in the adapter profile. Adapters according to this
invention typically support an arbitrary number of transfer
managers. There are no processing limitations applied to transfer
managers. Any transfer manager is free to manipulate message
content of any message passed to it in any way, including
manipulation of the message body and any header parameters.
[0087] More particularly, this example XML profile identifies and
provides configuration parameters for three transfer managers but
contains no express route map. An adapter built in dependence upon
this example profile routes all messages received in the
inventoryControl transport to all transfer managers and then to the
sender in the generalLedger transport. In such an adapter, all
messages received in the generalLedger transport are routed to all
transfer managers and then to the sender in the inventoryControl
transport. The `class` attribute in the <transferManager>
tags identifies a Java class from which each transfer manager can
be instantiated. The `order` attribute in the
<transferManager> tags identifies the order in which message
events are to be passed to the transfer managers, so that the
transfer managers can be designed and programmed to depend on one
another or not to interfere with one another, as needed.
[0088] Not all transfer managers will process all messages, despite
the fact that in this particular model, all messages are passed to
all transfer managers. That is, a transfer manager programmed to
transform the data structure of an accounting entry in a posting
message will perform no processing whatsoever on an ACK, an
acknowledgment message. In this model, it is part of the
programming of the transfer managers themselves to infer from the
parameters in message events which messages are to be processed by
a particular transfer manager. Given a message event object similar
to that illustrated for example at reference (602) in FIG. 5h, a
transfer manager is programmed to infer from a destinationID code
(604), possibly combined with a sourceID code (606) or a
messageType code (607), that, for example, a posting message
traveling from an inventory control program to a general ledger is
a message to be processed or ignored by the particular transfer
manager. If the routing structure is simple and only one type of
message travels to a particular destination, the destinationID
(604) alone may be sufficient. If routing alternatives in a
particular adapter are complex and many message types travel to the
same destination, a transfer manager may need more information to
determine whether a particular message is its to process.
[0089] Route maps in profiles are aids in addressing such
complexity. Consider, for example, the following exemplary XML
profile: TABLE-US-00002 <adapter> <transportmodules>
<transport class="InventoryControl.java"
id="inventoryControl"> <receiver>
<configParm>parmValue</configParm> </receiver>
<sender> <configParm>parmValue</configParm>
</sender> </transport> <transport
class="GeneralLedger.java" id="generalLedger"> <receiver>
<configParm>parmValue</configParm> </receiver>
<sender> <configParm>parmValue</configParm>
</sender> </transport> <transport
class="Purchasing.java" id="purchasingSystem"> <receiver>
<configParm>parmValue</configParm> </receiver>
<sender> <configParm>parmValue</configParm>
</sender> </transport> </transportmodules>
<transfermodules> <transferManager class="xfrMgr1.java"
mapID="route 1" order="1">
<configParm>parmValue</configParm>
</transferManager> <transferManager class="xfrMgr2.java"
mapID="route3" order="2">
<configParm>parmValue</configParm>
</transferManager> <transferManager class="xfrMgr3.java"
mapID="route3" order="3">
<configParm>parmValue</configParm>
</transferManager> <transferManager class="xfrMgr4.java"
mapID="route2, route4, route5" order="4">
<configParm>parmValue</configParm>
</transferManager> </transfermodules> <routemaps>
<map id="route1"> <msgType>post</msgType>
<from>purchasingSystem</from>
<to>generalLedger</to> </map> <map
id="route2"> <msgType>ACK</msgType>
<from>generalLedger</from>
<to>purchasingSystem</to> </map> <map
id="route3"> <msgType>post</msgType>
<from>inventoryControl</from>
<to>generalLedger</to>
<to>purchasingSystem</to> </map> <map
id="route4"> <msgType>ACK</msgType>
<from>generalLedger</from>
<to>inventoryControl</to> </map> <map
id="route5"> <msgType>ACK</msgType>
<from>purchasingSystem</from>
<to>inventoryControl</to> </map>
</routemaps> </adapter>
[0090] This exemplary XML profile identifies and describes three
transports named respectively "inventoryControl", "generalLedger",
and "purchasingSystem". The exemplary XML profile describes four
transfer managers identified by unique order numbers 1, 2, 3, and
4. The transfer manager elements now have a new attribute, `mapID,`
in the <transferManager> tag to tie the transfer managers to
route maps. `mapID` takes as its value a route map identification
code.
[0091] This exemplary XML profile also describes five route maps
identified by unique identification codes "route1", "route2",
"route3", "route4", and "route5". Route map "route 1" describes a
message route for messages of type `post` from a purchasing system
to a general ledger. Route map "route2" defines a message route for
acknowledgement messages from the general ledger to the purchasing
system. Route map "route3" defines a message route for posting
messages from the inventory control program to both the general
ledger and to the purchasing system. Route map "route4" defines a
message route for inventory posting acknowledgment messages from
the general ledger to the inventory control program. Route map
"route5" defines a message route for inventory posting
acknowledgement messages from the purchasing system to the
inventory control program.
[0092] An exemplary adapter built in dependence upon a profile like
this XML example routes posting messages from the purchasing system
to the general ledger through only on of the transfer managers, the
one identified by the attribute `order=1.` In this example, it is
the adapter that must examine the message event parameters such as
destinationID, sourceID, messageType, and so on, to determine which
route to use and therefore which transfer manager will process
which messages. That is, in this example, only one message type is
routed to the transfer manager having <transferManager>
attribute `order=1,` thereby eliminating any need for the transfer
manager to analyze whether it is to process the messages it
receives: It simply processes all messages it receives.
[0093] Similarly in this example, all acknowledgment messages or
`ACKs` are routed to the transfer manager with
<transferManager> attribute `order=4.` In some exemplary
embodiments of such a transfer manager, the transfer manager will
process all ACK messages in a similar fashion. To the extent that
ACK message processing differs according to destination or source,
then it is to the transfer manager to make that determination by
reference to the destinationID (604 on FIG. 5h) or the sourceID
(606) in each message event passed to it. Still in this example,
the determination whether to process a message is removed from the
transfer manager and placed in the programming of the adapter
itself in dependence upon a route map from its profile.
[0094] The processing of posting messages from the inventory
control program to both the general ledger and to the purchasing
system is also instructive in this example XML profile. Route map
"route3" defines a message route from the inventory control program
to both the general ledger and to the purchasing system. Two
transfer managers are described in the profile as being on
"route3," the transfer manager having <transferManager>
attribute `order=2` and the transfer manager having
<transferManager> attribute `order=3.` In this example, both
the general ledger and the purchasing system are from different
software developers and use completely different data structures
for account postings. Assume that the transfer manager having
<transferManager> attribute `order=2` transforms the data
structure of an incoming message from the inventory control
structure to the general ledger structure and that the transfer
manager having <transferManager> attribute `order=3`
transforms the data structure of an incoming message from the
inventory control structure to the purchasing system structure. The
adapter in this example makes a copy of the incoming posting
message event from the inventory control transport, sends the
original to the transfer manager having <transferManager>
attribute `order=2` and the copy to the transfer manager having
<transferManager> attribute `order=3.` On return of the call
to the transfer manager having <transferManager> attribute
`order=2,` the adapter forwards the original message event, now
structured for use in the general ledger, to the sender in the
transport for the general ledger. On return of the call to the
transfer manager having <transferManager> attribute
`order=3,` the adapter forwards the copy of the message event, now
structured for use in the purchasing system, to the sender in the
transport for the purchasing system. In all cases in this example,
the transfer manager receiving a message simply processes the
message without deciding whether to do so. The processing burden of
deciding which transfer manager is to process which message is
effectively shifted to the adapter object itself in dependence upon
destination, source, and type information in the message event
itself (references 604, 606, 607, for example, on FIG. 5h).
[0095] In some embodiments, a transfer manager is called on more
than one route through an adapter. Rather than effect multiple
routings by use of multiple entries of transfer managers in a
transfer modules element (speaking in terms of our XML example), in
alternative exemplary embodiments it is advantageous to list the
transfer mangers directly in the route map descriptions, as
illustrated by the following example: TABLE-US-00003
<adapter> <transportmodules> <transport
class="InventoryControl.java" id="inventoryControl">
<receiver> <configParm>parmValue</configParm>
</receiver> <sender>
<configParm>parmValue</configParm> </sender>
</transport> <transport class="GeneralLedger.java"
id="generalLedger"> <receiver>
<configParm>parmValue</configParm> </receiver>
<sender> <configParm>parmValue</configParm>
</sender> </transport> <transport
class="Purchasing.java" id="purchasingSystem"> <receiver>
<configParm>parmValue</configParm> </receiver>
<sender> <configParm>parmValue</configParm>
</sender> </transport> </transportmodules>
<transfermodules> <transferManager class="xfrMgr1.java"
id="xfrMgrName1" order="1">
<configParm>parmValue</configParm>
</transferManager> <transferManager class="xfrMgr2.java"
id="xfrMgrName2" order="2">
<configParm>parmValue</configParm>
</transferManager> <transferManager class="xfrMgr3.java"
id="xfrMgrName3" order="3">
<configParm>parmValue</configParm>
</transferManager> <transferManager class="xfrMgr4.java"
id="xfrMgrName4" order="4">
<configParm>parmValue</configParm>
</transferManager> </transfermodules> <routemaps>
<map id="route1"> <msgType>post</msgType>
<from>purchasingSystem</from>
<to>generalLedger</to> <transferManager>
xfrMgrName1</transferManager> </map> <map
id="route2"> <msgType>ACK</msgType>
<from>generalLedger</from>
<to>purchasingSystem</to> <transferManager>
xfrMgrName4</transferManager> </map> <map
id="route3"> <msgType>post</msgType>
<from>inventoryControl</from>
<to>generalLedger</to>
<to>purchasingSystem</to> <transferManager>
xfrMgrName2</transferManager> <transferManager>
xfrMgrName3</transferManager> </map> <map
id="route4"> <msgType>ACK</msgType>
<from>generalLedger</from>
<to>inventoryControl</to> <transferManager>
xfrMgrName4</transferManager> </map> <map
id="route5"> <msgType>ACK</msgType>
<from>purchasingSystem</from>
<to>inventoryControl</to> <transferManager>
xfrMgrName4</transferManager> </map> </routemaps>
</adapter>
[0096] This example profile implements the exact same routes among
senders and receivers as the earlier example profile. That is,
route map "route1" describes a message route for messages of type
`post` from a purchasing system to a general ledger, including
routing through the first listed transfer manager, here identified
with its identification name "xfrMgr1." Route map "route2" defines
a message route for acknowledgement messages from the general
ledger to the purchasing system, including routing through the
second listed transfer manager, here identified with its
identification name "xfrMgr2." And so on for the remaining three
route maps. Unlike the first example, however, in this example the
route identifiers in the transfer managers, mapID="route1",
mapID="route2", and so on, are removed, and the transfer managers
are associated with map routes by placing the names of the transfer
managers directly in the map definitions as <transferManager>
xfrMgrName1</transferManager>,
<transferManager>xfrMgrName2 </transferManager>, and so
on. The fourth transfer manager, the one named "xfrMgr4," is called
on three routes through the adapter, the three identified as
"route2," "route4," and "route5."
[0097] Creating (220) the transports (212) identified in the
adapter profile (202) and configuring (222) the transports (212) in
accordance with the configuration parameters (218) are carried out
in many adapters according to embodiments of the present invention
as illustrated by the exemplary class structures set forth in FIGS.
5 and 5a-5h. FIG. 5 illustrates relations among exemplary classes
from which adapters are constructed according to embodiments of the
present invention.
[0098] Often in this disclosure, software modules are described as
`comprising` other software modules, as when an adapter is
described of as `comprising` or `including` a transport, a sender,
a receiver, or a transfer manager. It is useful to note that in the
object oriented paradigm used most often in this disclosure to
describe various exemplary embodiments of the invention, that one
module comprises or includes another usually means that the first
module possesses a reference or a pointer to the second module, as
in a transport `has a` receiver, meaning that the transport holds
in its member data elements a reference to the receiver object. In
C++ it might be more common to administer references as pointers to
objects, but for brevity and clarity in this disclosure, such
relationships are usually described in terms of references. The
arrows in FIG. 5 generally indicate the object-oriented `has-a`
relationship, that is, which class will typically possess
references to other classes.
[0099] An adapter (102) according to the example of FIG. 5 has a
reference to a profile (202), although as a practical matter, the
profile (202) often will not be a class object at all, but will be
a file in a file system instead. Administration of data in a file
system is much slower than in computer memory, of course, so that
most adapters (102) according to embodiments of the present
invention therefore parse the profile (102) into an internal class
object more convenient for reference within a running software
system, here illustrated as a parsed profile class (502). The
adapter (102) instantiates the transports (212) and the transfer
managers (406) identified in the profile (202). In this example,
the transport (212) instantiates the receiver (312) and the sender
(316) and returns references to them to the adapter so that the
adapter also possesses references to the receiver class (312) and
the sender class (316). The adapter uses its reference to the
receiver to register an event listener (536) with the receiver
(312). The event listener (536) is shown in FIG. 5 as a separate
class, but as a practical matter many adapters will register the
adapter itself as an event listener. When a receiver (312) receives
a message, the receiver encapsulates the message in a message event
(504) and passes a reference to the message event back through the
event listener to the adapter (102), or directly to the adapter if
the adapter is the event listener. The adapter passes the message
event object, or actually the reference to the message event
object, to the transfer managers (406) and then to the sender (504)
to process the message and then send it on to its destination.
Hence the transfer manager class (406), the receiver (312), the
sender (316), and the adapter (102) all gain references to the
message event class (504).
[0100] Again with reference to FIG. 2 and in terms of the class
diagrams of FIG. 5 and 5a-5h, constructing (204) an application
integration adapter, where the constructing is carried out in
dependence upon a profile (202) comprising data describing the
adapter, is in many example initiated by a command line interface
entry having a form similar to the following example: [0101] Java
com.adapters.Adapter <ProfileName>
[0102] This example command instructs a Java Virtual Machine to
load and instantiate an adapter name Adapter and run its member
method named `main( )` (reference 520 on FIG. 5a). In this
disclosure, descriptions of actions or processing steps carried out
by adapter objects are, unless context requires otherwise,
generally descriptions of the operation of a maino member method in
an adapter object of the kind illustrated at reference (102) on
FIG. 5a. In this example, main( ), or the adapter rather,
optionally, but typically, proceeds by opening a profile in a file
named "ProfileName" and parsing it into internal memory in a data
structure similar to the one illustrated at reference (502) on FIG.
5b. The parsed profile class of FIG. 5b provides parsed storage for
a list of transfer managers (542), a list of transports including
their configuration parameters (544), and a list of route maps
(555). In addition to the structured memory provided by the lists,
the parsed profile class of FIG. 5b also provides member methods
for adding to the lists (546, 544, 555) and member methods for
retrieving the lists (550, 552, 553) when they are needed by other
cooperating objects.
[0103] The list of transfer managers (542), the list of transports
including their configuration parameters (544), and the list of
route maps (555) are all described in FIG. 5b as having the
datatype `List`. This description of datatype is not limiting. A
variety of datatype can be used for such data structures, and for
all data structures discussed in this disclosure, as will occur to
those of skill in the art, including, for example, vectors,
arraylists, sets, containers, and so on.
[0104] In the method according to FIG. 2, constructing (214) an
integration adapter also includes creating (220) the transports
(212) identified in the adapter profile (202) and configuring (222)
the transports (212) in accordance with the configuration
parameters (218). In this example, Adapter.main( ) creates
transports by instantiating each transport listed in the transport
list (544) in the parsed profile (502). Configuring (222) the
transports (212) in accordance with the configuration parameters
(218) typically comprises creating the receivers and senders for
each transport and configuring the receivers and senders with the
configuration parameters.
[0105] FIG. 3 sets forth a data flow diagram illustrating a method
of creating receivers and senders for transports for application
integration adapters according to the present invention. In many
adapters implemented according to the method of FIG. 3, each
transport comprises a parameterized factory method (556 on FIG. 5c)
for creating a receiver. In such embodiments, configuring (222) the
transports includes creating (306) a receiver for each transport,
carried out by a call to the parameterized factory method (556 on
FIG. 5c) for creating a receiver with at least some of the
configuration parameters. In the method according to FIG. 3, each
transport typically includes a factory method for creating a sender
(558 on FIG. 5c), and configuring (222) the transports (212) also
includes creating (318) a sender (316) for each transport
(212).
[0106] Here is an explanatory pseudocode example of a factory
method: TABLE-US-00004 // // Transport Class // // Illustrating a
parameterized factory method for creating receiver objects // class
TransportClass { public static Receiver createReceiver(ConfigParm1,
ConfigParm2, and so on ... ) { if(ConfigParm1==HTTP &&
ConfigParm2==INVENTORYCONTROL) receiverID = "receiver1"; else
if(ConfigParm1==IIOP && ConfigParm2==INVENTORYCONTROL)
receiverID = "receiver2"; else if(ConfigParm1==HTTP &&
ConfigParm2==GENERALLEDGER) receiverID = "receiver3"; else
if(ConfigParm1==JMS && ConfigParm2==GENERALLEDGER)
receiverID = "receiver4"; else if(ConfigParm1==HTTP &&
ConfigParm2==PURCHASINGSYSTEM) receiverID = "receiver5"; else
if(ConfigParm1==IIOP && ConfigParm2==PURCHASINGSYSTEM)
receiverID = "receiver6"; Receiver aReceiver = null; // empty
reference for new receiver object switch(receiverID) { case
"receiver1": aReceiver = new receiver1.class; break; case
"receiver2": aReceiver = new receiver2.class; break; ... ... ...
case "receiverN-1": aReceiver = new receiver5.class; break; case
"receiverN": aReceiver = new receiver6.class; break; } // end
switch( ) return aReceiver; } // end createReceiver( ) public
static Sender createSender(ConfigParm1, ConfigParm2, and so on ...
) { // Exemplary Transport classes also support factory methods for
senders // similar to the one for receivers set forth just above,
createReceiver( ). } } // end class TransportClass
[0107] In this pseudocode example, createReceiver( ) is a
parameterized factory method. CreateReceiver( ) is called by, for
example, Adapter.main( ) with a set of configuration parameter as
parameters for the call. CreateReceiver( ) can be overloaded and
called with any combination of configuration parameters supported
by any receiver class supported in the factory method
createReceiver( ). CreateReceiver( ) can support any number of
concrete receiver classes. CreateReceiver( ) functions by selecting
a receiver identification through a series of IF statements based
upon the configuration parameters. CreateReceiver( ) then operates
a switch( ) statement in dependence upon the receiver
identification to select a concrete receiver class and instantiate
from it a new receiver object.
[0108] In this example, the class named "Receiver" is an abstract
class from which all the other receiver classes inherit, thereby
enabling createReceiver( ) to returns a reference of type
`Receiver` that can in fact be a reference to any receiver class
object. Calls to receiver objects from cooperating objects in an
adapter can therefore be polymorphic. In this way, neither the
transport, the adapter itself, nor any cooperating object or
software module comprised within the adapter knows or cares which
applications are being integrated nor which communications
protocols are used to integrate them. All cooperation among objects
within the adapter is rendered completely neutral, transparent, and
modular with respect to application identities and communications
protocols.
[0109] The method illustrated in FIG. 3 includes registering (310)
a transport event listener with each receiver. In some adapters
that create receivers according to the method of FIG. 3, the
integration adapter (102) itself comprises a transport event
listener (314). That is, in some embodiments, registering (310) a
transport event listener with each receiver, is carried out by
registering the adapter itself as an event listener. In such
embodiments, the adapter itself will contain a member method for
the receiver to call to hand off an incoming message, such as, for
example, the transportEvent( ) method shown at reference (532) in
the exemplary adapter class (102) on FIG. 5a. In embodiments in
which the event listener (314) is a separate object from the
adapter itself, a constructor first creates (308) a transport event
listener (314) by instantiating a separate object of an event
listener class such as the one illustrated at reference (536) on
FIG. 5a.
[0110] FIG. 4 sets forth a data flow diagram illustrating an
exemplary method of creating transfer managers. In the method of
FIG. 4, providing (210) an adapter profile (202) includes providing
an adapter profile comprising identifications (402) of one or more
data transfer managers (406), including configuration parameters
(404) for the data transfer managers. The method of FIG. 4 includes
constructing (204) an application integration adapter (102) which
in turn includes creating (408) the transfer managers (406)
identified (402) in the profile (202) and configuring (410) the
transfer managers (406) in dependence upon the configuration
parameters (404).
[0111] In terms of the exemplary data structures of FIG. 5a, the
adapter (102) comprises a factory method named
createTransferManagers( ) (530) for creating a transfer manager. In
this example, the transfer manager list (542) in the parsed profile
class (502) contains definitions for all the transfer managers
defined in the profile, as well as configuration parameters for
each transfer manager. Constructing such an exemplary adapter
includes calling the factory method for transfer managers once for
each transfer manager in the transfer manager list (542) with the
configuration parameters for the transfer manager and receiving in
return a reference to a new transfer manager. The references to the
new transfer managers along with their attributes such as route map
identifiers and calling order numbers are then stored in the
transfer manager list (514) in the adapter (102) for the adapter's
use in routing messages.
[0112] FIG. 6 sets forth a calling sequence diagram illustrating a
method of constructing application integration adapters. More
particularly, FIG. 6 describes an exemplary calling sequence among
member methods in cooperating objects for constructing an adapter
according to exemplary embodiments of the present invention. The
sequence of FIG. 6 begins when an adapter is instantiated with a
command line entry similar to this one: [0113] Java
com.adapters.Adapter <ProfileName>
[0114] A member method in the adapter, either its constructor or
its main( ) method, parses the profile identified as
<ProfileName> by calling (622) the add methods (FIG. 5b: 546,
548, 549) in a parsed profile (502 on FIG. 5b). The add methods
insert descriptions of the transfer managers (542), the transports
(544), and any route maps (555) into the member data elements of
the parsed profile.
[0115] The adapter (102) constructs (624) each transport described
in the parsed transport list (544 on FIG. 5b). The adapter calls
createReceiver( ) (626) in each transport constructed, and each
createReceiver( ) call results in construction (628) of a receiver
for a transport. Each createReceiver( ) call (626) returns to the
adapter a reference to the receiver created. The adapter stores a
reference to each receiver in a receiver list (516 on FIG. 5a) in
the adapter, particularly for use in configuring receivers and
registering event listeners. The adapter calls createSender( )
(630) in each transport constructed, and each createSender( ) call
results in construction (632) of a sender for a transport. Each
createSender( ) call (630) returns to the adapter a reference to
the sender created. The adapter stores a reference to each sender
in a sender list (518 on FIG. 5a) in the adapter for use in
configuring senders and in routing messages.
[0116] The adapter calls (634) a configure( ) method (566 on FIG.
5d) in each receiver (312), passing the receiver configuration
parameters as call parameters, so that each receiver can
self-configure. The adapter registers, in each receiver in its
receiver list, either itself or another object as an event listener
with a call (636) to a method such as addEventListener( ) (570 on
FIG. 5d). The adapter calls (638) a configure( ) method (584 on
FIG. 5e) in each sender (316), passing sender configuration
parameters as call parameters, so that each sender can
self-configure.
[0117] The adapter constructs (640) each transfer manager (120)
identified in the profile or in the transfer manager list (542 on
FIG. 5b) in a parsed profile (502 on FIG. 5b). For use in routing
messages, the adapter retains references to each transfer manager
in a transfer manager list (514 on FIG. 5a) in the adapter
(102).
[0118] The adapter calls (641) a run( ) method (574 on FIG. 5d) in
each receiver to advise each receiver to begin data communications
operations in accordance with whatever protocol the receiver uses.
More than one receiver must run at the same time in typical
embodiments of the present invention, so that calls (641) to run( )
methods (574) advantageously are non-blocking calls that trigger a
new, parallel process or thread of execution and return control
promptly to the caller. More particularly, in terms of Java for
example, receiver classes in such exemplary embodiments
advantageously are defined to inherit from the `thread` class with
its start( ) interface method. Then in such embodiments, a call to
a run( ) method is implemented as a call to
SomeReceiverClass.start( ), which in turn executes the run( )
method in a separate thread of execution and returns promptly to
the caller. Here is an example: TABLE-US-00005 class HTTPReceiver
extends Thread { private Port ListenPort = 80; public void run( ) {
// control code to operate // a receiver over the HTTP protocol //
for data communication from // a particular software application }
}
[0119] This example declares HTTPReceiver as a subclass of Thread
and overrides the run( ) method from the Thread class, well known
in current Java. The following exemplary Java code then can create
a separate thread of execution and start it running: [0120]
HTTPReceiver aReceiver=new HTTPReceiver( ); [0121] aReceiver.start(
);
[0122] This exemplifies one particular way to implement a
receiver's run( ) method as a separate thread of execution,
presented for explanation, not for limitation. There are many ways
to start separate threads of execution for receivers as will occur
to those of skill in the art, and all of them are well within the
scope of the present invention. It is in this way generally,
however, that an adapter instantiates and activates any number of
receivers which then operate asynchronously with the adapter by,
for example, use of event listeners as described in more detail
below in this disclosure.
[0123] Implementing receivers' run( ) methods asynchronously as
parallel separate threads of execution, however, is not a general
limitation for all embodiments of the invention. Some adapters
according to embodiments of the present invention in fact do not
implement receiver's run( ) methods asynchronously as parallel
separate threads of execution. Some adapters according to
embodiments of the present invention poll receiver's run( ) methods
sequentially with blocking calls. In such embodiments, an adapter's
main( ) method, for example, polls each receiver in turn through a
blocking call to the receiver's run( ) method. Execution of the
calling method pauses until the call to the run( ) method returns.
Typically in such embodiments, the receiver's run( ) method checks
for incoming messages, translates the encoding format of any
incoming messages as needed, encapsulates the incoming message in a
message event object, and returns to the calling adapter a
reference to any message event object so created. Then the adapter
calls the next receiver on its receiver list. In such embodiments,
event listeners optionally and advantageously may not be used--or
may be used less often than in asynchronous embodiments.
[0124] At this point in processing, the receivers in our example
adapter, having configured themselves with their configuration
parameters and begun data communications operations in their
protocols, are operating in accordance with their protocols, ready
to receive messages, place the messages in message events, and hand
them off to an event listener for processing through the adapter.
That is, at this point, the adapter is constructed and running.
[0125] FIG. 7 sets forth a data flow diagram depicting an exemplary
method of communicating (206 on FIG. 2) integration messages (208)
among applications (106, 116) through an adapter (102). The method
of FIG. 7 includes receiving (702) from a source application (106)
an integration message (208) having a source message format (712)
and a source data structure (714). In terms of the exemplary class
structures of FIG. 5a-5h, it is assumed for purposes of explanation
that a runo method in each receiver of an adapter is carrying data
communications in accordance with a data communications protocol
identified in the configuration parameters for each receiver.
[0126] The method of FIG. 7 includes translating (708) the
integration message (208) from the source message format (712) to a
destination message format (720) useful to a destination
application (116). In terms of the exemplary class structure of
FIG. 5d, translating (708) is carried out by a call from a run( )
method (574) to a translation method (575) in a receiver class
(560). The operation of the translation method (575) is to convert
the format of the message, not the data structure of the message.
That is, the translation method converts the overall form of the
message leaving unchanged the internal data structure, the data
element names, types, and values. Converting the internal data
structure, if needed, is the job of a transformation method in a
transfer manager, not the job of the receiver or its translation
method. Examples of format translation include translating from
stringified Java to XML, from binary C++ data format to XML, and so
on. As particular example of format translation is a receiver
programmed to translate the following C structure: TABLE-US-00006
struct address { char *name = "John Smith"; char *address = "100
Main Street" char *city = "Smallville"; char *state = "Iowa"; char
*zip = "10101"; }
[0127] to this XML structure: TABLE-US-00007 <address>
<name>John Smith</name> <address>100 Main
Street</address> <city>Smallville</city>
<state>Iowa</state> <zip>10101</zip>
</address>.
[0128] Such a receiver proceeds by reading each C data elements and
creating a corresponding XML element having the same name, type,
and value. The C structure can be transmitted in compiled form,
that is, encoded binary, or in uncompiled text appearing just as
shown above. The transformation to XML preserves all structure in
the data, the names, types, and values of the data elements,
changing only the format from C to XML.
[0129] As practical matter, in support of asynchronous operations
inside the adapter, adapters implementing the method of FIG. 7
typically also include encapsulating (704) the integration message
in a message event (716) and passing (706) the message event (716),
or a reference to the message event, to at least one event
listener. An exemplary structure for a message event is illustrated
at reference (602) on FIG. 5h. The message event class (602)
contains only one member method, a constructor (616) whose only
functions are to record the message parameters in the message even
object and return to the calling receiver a reference to the
message event. The message event parameters include its destination
(604), its source (606), its message type (607), a message
identification code (608), a security tag (610), a status code
(612), and, usefully, the body of the message itself (614), shown
here as of datatype `stringified,` but alternatively of any useful
datatype as will occur to those of skill in the art.
[0130] Passing (706) the message event (716) to an event listener
is carried out in our exemplary class structures by from a receiver
to a transportEvent( ) method (532 on FIG. 5a) in an event listener
(536). A transportEvent( ) method (532) is shown in the adapter
class (102) on FIG. 5a also as a reminder that the adapter
optionally registers itself as an event listener. It is typically
then the event listener, either itself or through other cooperating
objects, that causes the message event to be circulated among any
transfer mangers and ultimately to a sendo method in a sender
object. In typical embodiments, the sending (710) includes
unencapsulating the integration message from the message event and
reencapsulating it in whatever message structure is required by the
data communication protocol used by the send( ) method (592 on FIG.
5e) of the destination transport (144).
[0131] The method of FIG. 7 also includes sending (710) the
integration message to a destination application (116), implemented
in our exemplary class structures by call to a send( ) method (592
on FIG. 5e) in a sender object (576). More particularly, the method
of FIG. 7 includes no data structure transformation and no
translation to a destination format. This means that the method of
FIG. 7 is useful, for example, in cases where a source application
and a destination application are capable of working with the same
data structures, but the source application exports the data
structures in binary form, stringified Java, C++ structures, or any
form other than XML, and the destination application requires to
import them in XML.
[0132] FIG. 8 sets forth a data flow diagram depicting a further
exemplary method of communicating (206 on FIG. 2) integration
messages (208) among applications (106, 116) through an adapter
(102). The method of FIG. 8 includes receiving (702) from a source
application (106) an integration message (208) having a source
message format (712) and a source data structure (714). The method
of FIG. 8 also includes translating (802) the integration message
(208) from the source message format (712) to an interim message
format (804) useful for internal processing within the adapter
including particularly data transformation and security processing
but also including other modes of processing as will occur to those
of skill in the art.
[0133] The method of FIG. 8 further includes transforming (806) the
integration message (208) from the source data structure (714) to a
destination data structure (808). In data transformation, as
distinct from data translation, the data structure itself is
altered, as when the following structure from a source application:
TABLE-US-00008 <address>
<lastName>Smith</lastName>
<firstName>John</firstName> <addressLine1>100
Main Street</addressLine1> <addressLine2>Suite
5</addressLine2> <city>Smallville</city>
<state>Iowa</state>
<mailCode>10101</mailCode> </address>
[0134] is translated to the following structure required by a
destination application: TABLE-US-00009 <address>
<name>John Smith</name> <address>100 Main Street,
Suite 5</address> <city>Smallville</city>
<state>Iowa</state> <zip>10101</zip>
</address>
[0135] The data format is the same for both structures, the interim
format for translation, in this example, XML. The data structure
itself, however, is altered in its data element names and
values.
[0136] In many exemplary embodiments of the method of FIG. 8, the
transforming (806) is carried out through a transfer manager.
Continuing with XML as an explanatory example of interim data
format for data translation: transforming (806) the integration
message (208) from the source data structure (714) to a destination
data structure (808) is carried out in terms of our exemplary class
structures by passing to transfer manager (619 on FIG. 5g) through
a call to a member method such as process( ) (609 on FIG. 5g) a
messageevent object such as that illustrated at reference (602) on
FIG. 5h carrying the message structure (614) as well as processing
parameters needed by the transfer manager to carry out the
translation.
[0137] In this example, the process(messageEvent) method (609) uses
the source identification (606) and the destination identification
(604) from the message event (602) to infer the filename of an XSLT
style sheet from an arraylist (615) stored for that purpose in the
transfer manager (619). The process( ) method (609) proceeds by
calling an XSL processor (not shown), passing the name of the style
sheet and the input XML as call parameters. The XSL processor reads
the input XML and follows the instructions in the XSL style sheet;
then it outputs the translated XML as its return to the process( )
method. Many XSL processors are readily available off-the-shelf
from a variety of manufacturers including, for example, the well
known `Xalan` XSLT processor available from the Apache Software
Foundation.
[0138] The method of FIG. 8 includes sending (710) the integration
message to a destination application (116). FIG. 8 illustrates two
exemplary execution paths for sending an integration message. FIG.
8 discloses the alternative of sending (710) the message directly
without additional translation (806, 208, 710). This alternative is
useful particularly when the interim message format (804) used for
transforming the data structure of the message is the same as the
format expected by a destination application. That is, for example,
sending without additional translating is useful when, for example,
the interim format (804) is XML and the destination application is
capable of receiving and using an integration message in XML.
[0139] FIG. 8 also discloses the alternative of translating (810)
the integration message (208) from the interim message format (804)
to a destination message format (812) useful to the destination
application (116). That is, as an alternative embodiment, the
method of FIG. 8 includes translating (810) the integration message
(208) from the interim message format (804) to a destination
message format (812) useful to the destination application (116)
before sending (710) the message to the destination application.
This alternative is useful in the many embodiments where the
message format expected by a destination application is different
from the interim format (804) used for data structure
transformation (806) inside an adapter. Examples of such
embodiments include those in which the interim format is XML and
the destination format is HTML, stringified Java, binary C++
structures, or any other message format other than XML.
[0140] FIG. 9 sets forth a calling sequence diagram illustrating a
method of communicating (206 on FIG. 2) integration messages among
applications through an adapter. More particularly, FIG. 9
describes an exemplary calling sequence among member methods in
cooperating objects for communicating integration messages among
applications through an exemplary adapter according to embodiments
of the present invention. The sequence of FIG. 6 begins when an
adapter instantiated, constructed, and running as described in
detail above in this disclosure. A receiver (312) of the adapter
receives a message and calls (902) its own translation( ) method
(575 on FIG. 5d). The translation( ) method translates the format
of the body of the message into an interim format.
[0141] The receiver (312) constructs (904) a message event object
(536, class structure at 602 on FIG. 5b) to use as a container for
the message as the message is passed around among objects with in
the adapter for further processing and transmission to its
destination. The constructor of the message event object accepts as
call parameters descriptive parameters of the message as well as
the body of the message itself, returning to the receiver a
reference to the message event object.
[0142] The receiver (312) passes the message event object through a
call (906) to a transportEvent( ) method (532 on FIG. 5a), or
rather passes a reference to the message event object, to an event
listener object listed in an event listener list (564 on FIG. 5d)
in the receiver.
[0143] The transportEvent( ) method in the event listener calls
(906) each transfer manager listed in a transfer manager list (514
on FIG. 5a) in the adapter, through a process( ) method (618 on
FIG. 5f, 609 on FIG. 5g) in each transfer manager, passing as a
call parameter a reference to the message event object.
Alternatively, the transportEvent( ) method infers a route map
identification from a route map list and then calls the process( )
method in each transfer manager identified by the inferred route
map identification. Either way, each transfer manager called in
turn performs upon the body of the message in the message event
object whatever processing each transfer manager is designed to
perform, including for example data structure transformation,
security checks, source authentication, encryption, decryption,
validation of digital signatures, and other functions as will occur
to those of skill in the art. FIG. 5g is presented as an example of
a concrete transfer manager class optimized for data translation
with XSLT. FIG. 5f is presented as an example of an abstract
transfer manager class providing only an interface from which many
concrete transfer manager classes can inherit. Using concrete
transfer managers to implement classes for various processing
purposes each of which inherits from an abstract transfer manger
class supports an adapter's use of a factory method such as
createTransferManager( ) (532 on FIG. 5a). Use of a factory class
and transportEvent( ) (532 on FIG. 5a) processing against a
transfer manager list (514) means that the adapter object itself
need never know nor care what any particular transfer manager does
to the body of any message, thereby supporting cooperation among
objects within the adapter that is rendered neutral, transparent,
and modular with respect to processing of message content.
[0144] The transportEvent( ) method in the sequence of FIG. 9
identifies from a list of senders (518 on FIG. 5a) in the adapter
the sender in the transport for the destination of the message and
calls (908) a send( ) method (592) in the destination sender (class
structure illustrated at reference 575 on FIG. 5a). The send( )
method calls (910) as needed a translate( ) method (593 on FIG. 5e)
in the sender to get the message body into the form needed by its
destination application. Then the send( ) transmits the message to
the destination application using whatever data communications
protocol the sender is configured to use.
[0145] It will be understood from the foregoing description that
various modifications and changes may be made, and in fact will be
made, in the exemplary embodiments of the present invention without
departing from its true spirit. The descriptions in this
specification are for purposes of illustration only and are not to
be construed in a limiting sense. The scope of the present
invention is limited only by the language of the following
claims.
* * * * *