U.S. patent application number 10/271423 was filed with the patent office on 2003-05-15 for system and method using asynchronous messaging for application integration.
Invention is credited to Upton, Mitch.
Application Number | 20030093471 10/271423 |
Document ID | / |
Family ID | 26995469 |
Filed Date | 2003-05-15 |
United States Patent
Application |
20030093471 |
Kind Code |
A1 |
Upton, Mitch |
May 15, 2003 |
System and method using asynchronous messaging for application
integration
Abstract
The J2EE Connector architecture (JCA) does not provide for the
use of asynchronous messaging. Embodiments of the present invention
utilize a call-back listener passed with a request or service
invocation to listen for responses from a JCA-compliant server or
enterprise system. A client application passing the request can go
about other processing instead of waiting for a response. A unique
identifier can be used with an application view component that
provides the interface to the enterprise system or server. This
identifier can be used to track and filter messages for a
particular client application. This description is not intended to
be a complete description of, or limit the scope of, the invention.
Other features, aspects, and objects of the invention can be
obtained from a review of the specification, the figures, and the
claims.
Inventors: |
Upton, Mitch; (Highlands
Ranch, CO) |
Correspondence
Address: |
FLIESLER DUBB MEYER & LOVEJOY, LLP
FOUR EMBARCADERO CENTER
SUITE 400
SAN FRANCISCO
CA
94111
US
|
Family ID: |
26995469 |
Appl. No.: |
10/271423 |
Filed: |
October 15, 2002 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60347919 |
Oct 18, 2001 |
|
|
|
60347901 |
Oct 18, 2001 |
|
|
|
Current U.S.
Class: |
709/203 ;
709/246; 719/314; 719/318 |
Current CPC
Class: |
Y10S 707/99945 20130101;
G06F 9/542 20130101; G06Q 10/103 20130101; G06F 9/541 20130101;
G06F 2209/544 20130101; Y10S 707/99943 20130101 |
Class at
Publication: |
709/203 ;
709/318; 709/314; 709/246 |
International
Class: |
G06F 015/16; G06F
009/46 |
Claims
What is claimed is:
1. A system for asynchronous messaging between integrated
applications, comprising: an application view component adapted to
provide an interface to an enterprise system for a client
application; a request queue adapted to store request messages from
the application view for retrieval by an enterprise system; a
response queue adapted to store response messages from the
enterprise system; and a call-back listener adapted to notify the
client application when a response message is stored in the
response queue.
2. A system according to claim 1, further comprising: a resource
adapter adapted to invoke functionality in the enterprise system
and expose that functionality to the application view
component.
3. A system according to claim 1, further comprising: an
application integration server adapted to contain the application
view component.
4. A system according to claim 3, further comprising: an event
routeradapted send an event message from the enterprise system to
the response queue.
5. A system according to claim 4, wherein: the call-back listener
is further adapted to notify the client application when an event
message is being stored in the response queue.
6. A system according to claim 4, further comprising: an event
generator adapted to generate an event in an enterprise system to
be sent by the event router.
7. A system according to claim 4, wherein: the call-back listener
is adapted to listen for related event messages.
8. A system according to claim 4, wherein: the call-back listener
is adapted to listen for related event messages, related event
messages associated with a topic.
9. A system according to claim 1, further comprising: a request
handler adapted to direct requests from a client application to an
appropriate request queue.
10. A system according to claim 1, wherein: the application view
component has a unique identifier that can be used for filtering
requests and responses.
11. A system according to claim 1, wherein: at least one of the
request queue and response queue is a JMS queue.
12. A method for asynchronous messaging between integrated
applications, comprising: creating a request to invoke a service in
an enterprise system; passing a call-back listener with the
request; posting the request onto a request message queue for
retrieval by the enterprise system; putting a response from the
enterprise system onto a response queue; and monitoring the
response queue with the call-back listener and notifying the
application creating the request when a response is present in the
response queue.
13. A method according to claim 12, further comprising: using an
application view component as an interface to the enterprise
system.
14. A method according to claim 13, further comprising: using a
resource adapter to invoke functionality in the enterprise system
and expose that functionality to the application view
component.
15. A method according to claim 12, further comprising: sending an
event message from the enterprise system to the response queue
using an event router.
16. A method according to claim 15, further comprising: notifying
the client application when an event message is being stored in the
response queue.
17. A system according to claim 15, further comprising: specifying
the call-back listener to listen for related event messages.
18. A system according to claim 12, further comprising: using a
request handler to direct requests from a client application to an
appropriate request queue.
19. A system according to claim 13, further comprising: assigning
the application view component a unique identifier that can be used
for filtering requests and responses.
20. A method for asynchronous messaging between integrated
applications, comprising: posting a request onto a request message
queue for retrieval by an enterprise system; putting a response
from the enterprise system onto a response queue; and monitoring
the response queue with a call-back listener and notifying the
application posting the request when a response is present in the
response queue.
21. A computer-readable medium, comprising: means for posting a
request onto a request message queue for retrieval by an enterprise
system; means for putting a response from the enterprise system
onto a response queue; and means for monitoring the response queue
with a call-back listener and notifying the application posting the
request when a response is present in the response queue.
22. A computer program product for execution by a server computer
for integrating applications, comprising: computer code for posting
a request onto a request message queue for retrieval by an
enterprise system; computer code for putting a response from the
enterprise system onto a response queue; and computer code for
monitoring the response queue with a call-back listener and
notifying the application posting the request when a response is
present in the response queue.
23. A system for asynchronous messaging, comprising: means for
posting a request onto a request message queue for retrieval by an
enterprise system; means for putting a response from the enterprise
system onto a response queue; and means for monitoring the response
queue with a call-back listener and notifying the application
posting the request when a response is present in the response
queue.
24. A computer system comprising: a processor; object code executed
by said processor, said object code configured to: post a request
onto a request message queue for retrieval by an enterprise system;
put a response from the enterprise system onto a response queue;
and monitor the response queue with a call-back listener and
notifying the application posting the request when a response is
present in the response queue.
25. A computer data signal embodied in a transmission medium,
comprising: a code segment including instructions to post a request
onto a request message queue for retrieval by an enterprise system;
a code segment including instructions to put a response from the
enterprise system onto a response queue; and a code segment
including instructions to monitor the response queue with a
call-back listener and notifying the application posting the
request when a response is present in the response queue.
Description
CLAIM OF PRIORITY
[0001] This application claims priority to U.S. Provisional Patent
Application No. 60/347,919, filed Oct. 18, 2001, entitled
"APPLICATION VIEW," as well as Application No. 60/347,901, filed
Oct. 18, 2001, entitled "EVENT ADAPTER," each of which is hereby
incorporated herein by reference.
COPYRIGHT NOTICE
[0002] A portion of the disclosure of this patent document contains
material which is subject to copyright protection. The copyright
owner has no objection to the facsimile reproduction by anyone of
the patent document of the facsimile reproduction by anyone of the
patent Trademark Office patentfile or records, but otherwise
reserves all copyright rights whatsoever.
CROSS-REFERENCED CASES
[0003] The following applications are cross-referenced and
incorporated herein by reference:
[0004] U.S. patent application Ser. No. ______ entitled
"APPLICATION VIEW COMPONENT FOR SYSTEM INTEGRATION," by Mitch
Upton, filed Oct. 15, 2002.
[0005] U.S. patent application Ser. No. ______ entitled "SYSTEM AND
METHOD FOR PROVIDING A JAVA INTERFACE TO AN APPLICATION VIEW
COMPONENT," by Mitch Upton, filed Oct. 15, 2002.
[0006] U.S. patent application Ser. No. ______ entitled "SYSTEM AND
METHOD FOR INVOKING BUSINESS FUNCTIONALITY FOR A WORKFLOW," by
Mitch Upton, filed Oct. 15, 2002.
[0007] U.S. patent application Ser. No. ______ entitled "SYSTEM AND
METHOD FOR USING WEB SERVICES WITH AN ENTERPRISE SYSTEM," by Mitch
Upton, filed Oct. 15, 2002.
[0008] U.S. patent application Ser. No. ______ entitled "SYSTEM AND
METHOD FOR IMPLEMENTING AN EVENT ADAPTER," by Mitch Upton, filed
Oct. 15, 2002.
[0009] U.S. patent application Ser. No. ______ entitled "SYSTEM AND
METHOD USING A CONNECTOR ARCHITECTURE FOR APPLICATION INTEGRATION,"
by Mitch Upton, filed Oct. 15, 2002.
[0010] U.S. patent application Ser. No. ______ entitled "SYSTEM AND
METHOD FOR IMPLEMENTING A SCHEMA OBJECT MODEL IN APPLICATION
INTEGRATION," by Mitch Upton, filed Oct. 15, 2002.
[0011] U.S. patent application Ser. No. ______ entitled "SYSTEM AND
METHOD UTILIZING AN INTERFACE COMPONENT TO QUERY A DOCUMENT," by
Mitch Upton, filed Oct. 15, 2002.
[0012] U.S. patent application Ser. No. ______ entitled "SYSTEMS
AND METHODS FOR INTEGRATION ADAPTER SECURITY," by Mitch Upton,
filed Oct. 15, 2002.
[0013] U.S. patent application Ser. No. ______ entitled "SYSTEM AND
METHOD FOR IMPLEMENTING A SERVICE ADAPTER," by Mitch Upton, filed
Oct. 15, 2002.
TECHNICAL FIELD
[0014] The invention relates generally to the messaging between
integrated applications.
BACKGROUND
[0015] E-commerce has become a major driving factor in the new
economy. To be successful in the long-term, e-commerce will require
many companies to engage in cross-enterprise collaborations. To
achieve cross-enterprise integration, a company must first
integrate its internal applications. Using existing technology and
tools, application integration can be an expensive proposition. No
integration solution exists that is easy to use, affordable, and
based on industry standards. Neither does a solution exist that is
based on an industry standard infrastructure, has universal
connectivity, is capable of massive scalability, and has accessible
business process tools.
[0016] Application integration to this point has been very
inward-focused. Many existing integration systems have not focused
on integrating applications between enterprises. Even when
integration solutions were used for cross-enterprise integration,
the solutions were still narrowly focused and aimed at vertical
markets. This inward focus did little to help companies field
external business-to-consumer and business-to-business
applications, such as applications that can utilize the Internet to
generate revenue and reduce costs. The requirement for
Internet-enabled applications led to the rise of the application
server market. To date, application servers have primarily been
used to host external applications targeted at customers and
partners. Application servers are themselves packaged applications
that, instead of solving a specific problem, are general-purpose
platforms that host vertical solutions.
[0017] The first attempts at application integration were primarily
focused on low-level implementation details such as the format of
the data, the byte ordering between machines, and character
encoding. The focus on low-level data formats was necessary
because, for the first generation of application integration
solutions, there were no widely adopted standards for data encoding
that could be deployed across multiple vertical applications.
[0018] The traditional approach involved connecting individual
systems to, in effect, hardwire the systems together. This approach
can be complex, as connecting different systems can require an
intimate, low-level knowledge of the proprietary technologies of
multiple systems.
[0019] Present integration systems, which have moved away from
"hardwiring" systems together, still suffer from a lack of
standards. Each integration vendor typically provides a proprietary
solution for application integration, message transformation,
message formats, message transport, and routing. Not one of these
systems to date has achieved significant market share to enable its
technologies to become the de-facto standard. This lack of
standards has given packaged application vendors little incentive
to integrate these systems with their. Further, each of these
integration systems or servers has its own proprietary API, such
that packaged application vendors cannot leverage development
beyond a single integration server. This fragmentation of the
integration market has provided little financial incentive for
third parties.
BRIEF SUMMARY
[0020] As the J2EE Connector architecture does not provide for
asynchronous messaging, systems and methods in accordance with the
present invention can utilize various components to add such
functionality to system integration. An application view component
can provide an interface to a resource such as an enterprise system
for a client application. A request queue can be used to store
request messages from the application view component for retrieval
by an enterprise system. The request can be tracked, for instance,
by a unique identifier associated with the application view
component. A response queue can be used store response messages
from the enterprise system. A call-back listener, which can be
passed with the request, can notify the client application when a
response message is stored in the response queue.
[0021] Other features, aspects, and objects of the invention can be
obtained from a review of the specification, the figures, and the
claims.
BRIEF DESCRIPTION OF THE DRAWINGS
[0022] FIG. 1 is a diagram of an integration system that can be
used in accordance with one embodiment of the present
invention.
[0023] FIGS. 2 and 3 are diagrams showing one method useful for the
synchronous invoking of services that can be used with the system
of FIG. 1.
[0024] FIGS. 4 and 5 are diagrams showing one method useful for the
asynchronous invoking of services that can be used with the system
of FIG. 1.
[0025] FIGS. 6(a) and 6(b) show computer systems communicating with
and without a common protocol in accordance with one embodiment of
the present invention.
[0026] FIG. 7 is a diagram showing a flow of calls that can be used
with the system of FIG. 1.
[0027] FIG. 8 is a flowchart showing a method for developing a
service adapter that can be used with the system of FIG. 1.
[0028] FIG. 9 is a diagram of an asynchronous messaging system in
accordance with one embodiment of the present invention.
DETAILED DESCRIPTION
[0029] Application integration components can be used to integrate
a variety of applications and systems, such as Enterprise
Information Systems (EISs). Information technology (IT)
organizations typically utilize several highly-specialized
applications. Without a common integration platform to facilitate
application-level integration, these applications cannot be
integrated without extensive, highly-specialized development
efforts.
[0030] Application integration can utilize adapters to establish an
enterprise-wide, united framework for integrating any current or
future application. Adapters can simplify integration efforts by
allowing each application to be integrated with an application
server, instead of requiring that each application being integrated
with every other application.
[0031] The development and widespread acceptance of standards such
as the Java 2 Platform, Enterprise Edition (J2EE) from Sun
Microsystems, Inc. of Santa Clara, Calif., as well as the
extensible Markup Language (XML), has laid the groundwork for a
standardized approach to the development of these adapters. Perhaps
the most significant of these standards for application integration
is the J2EE Connector architecture. The J2EE Connector architecture
provides a standardized approach for the development of adapters
for all types of applications, from legacy mainframe applications,
such as CICS from IBM, to packaged applications such as PeopleSoft,
Siebel, and SAP. The adoption of such standards enables businesses
to develop adapters that work on any J2EE-compliant application
server, for example.
[0032] Application integration can build on this standardized
approach in an application integration framework by providing a
standards-based architecture for hosting J2EE Connector
architecture-based adapters. Developers can build J2EE Connector
architecture-compliant adapters and deploy these adapters, in the
integration framework, to connect enterprise applications to an
application server.
[0033] These adapters can be used to define business-focused
interfaces to an EIS, the interfaces referred to herein as
"application views" of the respective adapters. An application view
can provide a simple, self-describing, consistent interface to
services and events in an application. Application views can make
use of an adapter for an EIS, making it possible to expose existing
information systems as business services. Unlike adapters, however,
an application view does not require users to have intimate
knowledge of the EIS or the client interface for that EIS, such
that non-programmers or technical analysts can use application
views. An application view can provide a business-oriented way for
business analysts to access enterprise data without worrying about
the programmatic details defined in an adapter. These same users
may be otherwise unable to use an adapter directly, due to a lack
of familiarity with the EIS.
[0034] An application integration component directed at enterprise
application integration can have several primary aspects. If the
functionality of an EIS such as a PeopleSoft system or an SAP
system is to be invoked, an implementation of the J2EE Connector
Architecture can be used. If something occurs inside an EIS system,
such as a trigger going off, an event can be generated. This event
may, in some embodiments, need to be communicated to an external
application. An event architecture in an application integration
component can handle this communication.
[0035] Application Views
[0036] An application view can provide significant value to an
application integration component. An application view can abstract
away much of the complexity in dealing with an application, such as
a backend EIS system. Application views can also simplify the way
in which adapters are accessed. Application views can provide a
layer of abstraction, for example, between an adapter and the EIS
functions exposed by that adapter. Instead of accessing an EIS by
direct programming a user can simply: edit an adapter's application
views, create new application views, or delete any obsolete
application view(s). A layer of abstraction formed by application
views can help non-programmers maintain the services and events
exposed by an adapter. Each application view can be specific to a
single adapter, and can define a set of business functions on that
adapter's EIS. After an adapter is created, a Web-based interface
for the adapter can be used to define application views.
[0037] If an application view is used as a primary user interface
for an adapter, a number of features can be included that are not
commonly found in existing enterprise application integration
technologies. Application views can, for example, use XML as a
common language among applications. Service and event definitions
can be used to expose application capabilities. XML schemas can be
used to define the data for services and events. Bi-directional
communication can also be supported in adapters.
[0038] An application view can be an integral part of an
integration framework. An application view can provide a view of
the application capabilities exposed by an adapter that a user can
customize to meet specific needs. A user can tailor an application
view, for example, for a specific business purpose. As a result,
the application view can provide an effective alternative to the
"one size fits all" approach that many applications provide for the
design of a client interface. An application view can be defined
for only the business or other capabilities that are applicable for
a specific purpose. The capabilities can be customized such as by
naming, describing, and defining the data requirements.
[0039] In one example of a system using a resource adapter and
application view component, shown in FIG. 1, adapters 106, 108, 110
can be developed that allow a client application 100 to communicate
with an Enterprise Information System 104 through the use of an
application view 102. A developer can begin by coding an adapter
that exposes the functionality in the enterprise application that
accesses enterprise data. The functionality the adapter exposes
could, for example, update records in a database using SQL
statements, or could request information from an SAP system using
its BAPI or IDOC interfaces. A business analyst, working with the
developer, can then define an application view of the adapter using
an application view interface.
[0040] An application view is an object, which can be implemented
in one embodiment as a stateless session JavaBean. There can be a
Java interface to the application view for the client application.
A Java application can be custom coded to use that object, such as
by passing XML in and receiving XML back. In addition, a business
process manager component can be included that allows process
engineers to define workflows, and allows application views to be
invoked as business services. A workflow is a graphical
representation of a business process, which can be defined and
modified using, for example, a business process management (BPM)
component such as a BPM plug-in, as well as a business process
engine. In a workflow, a callout can be made to an EIS to get
information such as a customer's credit record. The fact that the
application view is a Java object or enterprise JavaBean can be
hidden from the process and designer.
[0041] In application integration, new application views can be
hot-deployed against an existing EIS through a web-based interface.
An application view is hot-deployed when it is deployed with the
system running, without restarting the destination server. A new
customer management tool for SAP, for example, can also be defined
through a web browser.
[0042] Integration Framework
[0043] Application integration can utilize an integration
framework, which can provide a systematic, standards-based
architecture for hosting application views. Features of such a
framework can include application views for exposing application
functions and design-time graphical user interfaces (GUIs), such as
web-based interfaces that can be used for creating application
views. The integration framework utilizes adapters, instead of
"hardwiring" enterprise systems together. Once an adapter is
deployed for an EIS, other components and applications can use that
adapter to access data on the EIS.
[0044] A framework in accordance with one embodiment of the present
invention relies on XML as the standard format for messages. XML
includes XSLT, a standard for transforming XML documents into other
XML documents. XSLT is designed for use as part of XSL, which is a
stylesheet language for XML. In XSLT, an XML document is used to
specify the operations to perform on a class of XML documents in
order to transform the documents' structure and content. An XSLT
transformation can make use of any of the operations built into the
Java programming language, or can make use of custom operations
written either in Java or in native code. An integration framework
allows a business process to invoke an XSLT engine in order to
transform XML messages.
[0045] An integration framework can also rely on standards for
transporting messages such as Java Message Service (JMS) and HTTPS.
JMS is a standard API for interfacing with message transport
systems. Using JMS, a framework can utilize any message transport
mechanism that provides a JMS interface. The J2EE Connector
architecture standard does not specify a message transport
mechanism, but an application integration framework can specify
such a transport mechanism.
[0046] An integration framework can be based on an existing
standard infrastructure, such as an application server that
supports J2EE, JMS, and the J2EE Connector architecture. Using such
a standard infrastructure also provides for high availability and
scalability, such as by clustering and resource pooling. The
framework can provide for universal connectivity by enabling the
construction of XML-based application adapters that can connect to
any legacy and packaged application. An adapter development kit can
be used to allow users such as customers, system integrators, and
packaged application vendors to quickly develop J2EE connector
architecture-compliant and integration framework-based adapters.
The framework can utilize XML, which means that the same data
format can be used for both within- and between-enterprise
integration, since many e-commerce systems use XML as the standard
message format.
[0047] An integration framework can also utilize a business-process
engine to allow non-programmers to graphically construct and
maintain business processes. An integration framework can implement
a common model on top of the J2EE Connector architecture that is
focused on business-level concepts. This model, which can consist
of XML-encoded events and services, allows the management of a
consistent integration environment, regardless of the interface
required between adapters and their target applications. The
business processes can react to events generated by applications,
and they can invoke an application's functionality via services
that are exposed by an application adapter.
[0048] Services
[0049] A "service" can act as a business function that can be
invoked by a user. Service invocations can cause messages to be
sent to an application following a request/response model. This
model can differ from a publish/subscribe model, in that messages
are only sent when requested by a user. This can be implemented,
for example, using a point-to-point messaging system. Both events
and services can be passed through the system as XML documents.
[0050] A service can constitute business logic within an
application that an application view exposes for reuse. When an
application view receives an XML document containing a request to
invoke a business service, the application view can invoke that
functionality within its target application and return an XML
document that describes the result. Each service on an application
view can represent a single function, such as a single, logical
business function, within a target application. A service can take
request data, such as in the form of an XML document, and return
response data, which can also take the form of an XML document.
Services can represent bi-directional communication between an
application view client and a target application. Services can
allow for synchronous or asynchronous communication between
applications.
[0051] FIGS. 2 and 3 refer to one method for the synchronous
invoking of services that can be used, for example, with a system
as shown in FIG. 1. Across the top of the figures are various
objects that can be used in an interaction, including a client 200,
an application view 202, an application view bean 204, a JNDI
service 206, a connection factory 208, a connection 210, an
interaction 212, an interaction specification 214, and an
enterprise information system 214. In invoking a service, a user or
client 200 might, for example, call functionality to get details
relating to a customer from an EIS system 216. FIG. 2 shows the
first part, and FIG. 3 the second part, of one sequence of steps
that can occur in an application view engine to enable a client to
invoke a service in an EIS.
[0052] In the first step, a Java object or application view 202 is
issued from the client 200 for a web service. Three basic clients
in this example can include workflow, BPM, and custom-coded Java
applications. A new instance will be created on the server by
creating an enterprise java bean, triggered by calling an
ejbCreate( ) or create( ) routine.
[0053] The client 200 requests and receives the Request Document or
IDoc definition for a service, such as GetCustomerDetail, in the
example referred to as Service 1, or "Svc1." This definition can be
used to create a default document. Creating a default document does
a lot of the work otherwise required of a user by filling in a
skeleton XML document to be sent to the backend EIS. It also saves
the client a lot of work in creating a document, as the definition
knows exactly how the document should look.
[0054] Once the skeleton document is created, the client can call a
routine to set various parameters on the request into the XML
document, such as setting a customer number, name, or address.
After the client has set all the necessary parameters on a
document, or IDoc, the client 200 can use the application view 202
to invoke the service, such as by calling "InvokeService." The user
can pass the request document with the invoke.
[0055] The invoke request can trigger an application view bean 204
to begin interacting with a J2EE connector, or Connection Factory
208, such as by calling "Getinteraction." Such a routine can get a
connection, such as to SAP. The connector architecture can provide
for connection pulling, transaction management, and security
services for adapters. The connector architecture can get the
interaction on the connection, then execute the interaction and
pass the request document. The interaction object can be provided
by a resource adapter. SAP, for example, builds a particular
interaction into an adapter.
[0056] The interaction can figure out what specific EIS
functionality is being invoked, and can invoke that functionality
on the EIS ("function") object 216. This approach is very
adapter-specific. Some of the value added to the J2EE Connector
architecture is that this functionality is hidden behind standard
APIs. Finally, the interaction object 212 can create a response XML
document that is passed back to the client 200.
[0057] In such a synchronous invoke, a client makes a request and
waits until a response is received before the client proceeds with
processing. Asynchronous invokes can also be supported. One
asynchronous approach is shown in FIGS. 4 and 5. Across the top of
the figures are various objects that can be used in an interaction,
including a client 300, an application view 302, an application
view bean 304, an asynchronous service response listener 306, a
request queue 308, an asynchronous message request handler 310, an
asynchronous response message listener 312, a response queue 314,
an asynchronous service response 316, and an application view 318.
In asynchronous mode, a client 300 can make a request for which the
client does not need a response right away, but is able to come
back later to get the response. This approach can be more
complicated than a synchronous approach, as it is necessary to use
an underlying queuing mechanism to track requests to, and responses
from, an EIS.
[0058] A basic diagram showing some of these components is shown in
FIG. 9. Once a client 700 sets up an application view 704 as part
of an integration framework 702, that application view can have a
unique identifier. The unique identifier can be used for filtering
back on the server or EIS 710. A user can create a document and
invoke a service, such as by calling "invokeServiceAsync". A
call-back listener 714 can be passed, which handles the response
when it comes back from the server 710. The application view 704
can post the request onto a JMS request queue 706, such as by using
a "post (AsyncRequest) via JMSQueueSender" call.
[0059] A return response document (e.g., IDocument or IDoc) can be
placed onto a response message queue 712, such as a JMS response
queue, by calling a method such as "onMessage(asyncRespMessage)."
This can be a virtual call. When the user or client 700 invoked the
service, a call-back listener 714 was registered. Once a message
arrives on a JMS response queue 712, the call-back listener 714 can
look at the response and determine an appropriate listener, if
applicable, to notify the client 700 that the response has
returned. A request such as "OnAsyncServiceResponse" can be
serviced on the call-back listener. The client 700 can then have a
response document in its call-back listener, and can do with the
document whatever is necessary.
[0060] Common Protocol
[0061] An application view can take advantage of a common protocol.
A common protocol can help make application integration possible,
as each application only needs to be integrated with the common
protocol rather than with every other application. With a common
protocol, all applications can communicate using a standard
language, such as XML. One such common protocol can be based on
events and services that are represented by XML documents. Adapters
can expose an application's functionality and data formats as
events and services in an XML format via the application view so
that they the events and services be used by all clients of the
integration service.
[0062] Without a common protocol, there might be a number of
different languages that would need to be translated between each
other. FIGS. 6(a) and 6(b) illustrate application integration with
a common protocol versus application integration without a common
protocol. In FIG. 6(a), four computer systems 400, 402, 404, 406
are shown communicating without a common protocol. In this
situation, a central hub 420 must handle protocol 408 for computer
400, as well as protocols 410, 412, and 414 for computers 402, 404,
and 406, respectively. The hub 420 must also handle all byte
formats, character encodings, and type casting for each of the
protocols 408, 410, 412, 414.
[0063] In FIG. 6(b), an integration framework provides a common
protocol 418 for application integration on top of the J2EE
Connector architecture. This protocol 418 can be supported via an
application view 416, and can consist of events and services
encoded as XML documents. Through the use of application views 416,
each computer system 400, 402, 404, 406 can communicate with the
computer systems using a common protocol, or canonical protocol,
without having to understand the other protocols. Further, the
central hub does not need to handle multiple protocols 408, 410,
412, 414, but can deal with only the common protocol 418. Each of
the application views 416 can enforce a consistent data format and
consistent behavior in the integration framework.
[0064] Requests to an application view can be made in XML, even
though a request made to a target application can use SQL or direct
API calls. For example, as shown in FIG. 7, a client 500 can make
calls to three separate applications 506, 508, 510 through two
separate application view components 502, 504. A request to one of
the application views 502, 504 does not need to address any login
information. In call A and call B, both calls are requesting the
same information, as call A to the "East Coast" application view
502 is attempting to get customer information, as is call B to the
"West Coast" application view 504. The actual data, however, is
retrieved from PeopleSoft 506 and SAP 508, respectively. The client
500 initiating the call is not aware of which application is
actually processing each request. In calls B and C, both calls are
associated with the same application view 504, but each request is
handled differently as call B to get customer information gets the
information from SAP 508, and call C to get customer history gets
the information from a legacy system 510. This allows a logical
grouping of information to be handled by a single application view
504. A client 500 or user can see a subset of the functionality
available from the target application, and the functionality can be
grouped in a form that is more useful.
[0065] An application view can be the middleman that translates XML
messages into the necessary interfaces required by an EIS, and
vice-versa. Additionally, an application view can provide an
introspection feature so that a client interested in using the
application view can determine which capabilities are available, as
well as and the type of XML documents each capability will accept
and return.
[0066] In an application view, there can be consistent interaction.
Outgoing messages can be generated by events and incoming messages
can be processed by services. An application view can be
dynamically implemented and configured by metadata. There may be no
code generation needed. This approach allows for a fluid adaptation
to business events and changes. There may be no need for compilers
and no need to worry about compatibility, such as with new versions
of Java.
[0067] J2EE Connector Architecture
[0068] The lack of widely adopted standards within the application
integration market is being addressed by the introduction of
standards such as the J2EE Connector architecture and the Java
Messaging Service (JMS). JMS provides a standard programming
interface to message transport mechanisms. The J2EE Connector
architecture provides a standard for application adapters. A J2EE
Connector architecture adapter can run within any integration
server that supports the J2EE Connector architecture standard.
[0069] The adoption of standards such as the J2EE Connector
architecture allows packaged application vendors to construct
application adapters that will work within any compliant
application server. However, the architecture is a new standard
that only addresses low-level integration issues. For example, the
connector architecture is unidirectional, allowing for synchronous
communication from an integration server to an external
application. The connector architecture does not, however, specify
how an external application can asynchronously send data to an
integration server. It also does not provide any common or required
interface for application adapters, nor specify how data passed
between adapters and applications are encoded.
[0070] Basic services, such as events, receiving XML, returning
XML, and self-describing available services / events, are not
addressed in the J2EE Connector architecture. This is one advantage
to using an application view in accordance with one embodiment of
the present invention.
[0071] The J2EE connector architecture also fails to address
application integration at the business level. An application
framework in accordance with the present invention adds value to
the connector architecture by providing support for business
process-level integration and bi-directional data flow between the
framework integration server and external applications. A
business-level view can be implemented on top of the connector
architecture that consists of events and services. An event can be
a message delivered asynchronously via JMS from an application,
such as by an application adapter, to the framework server. A
service can be a function provided by an application that any
business process can invoke via the application's adapter.
[0072] Event Router
[0073] An application programming interface (API) can be used to
interact with XML documents, such as to set basic data on an XML
document. If a new customer is in an EIS system, there can be
information related to that customer such as the customer's name
and address. An event generator can do a "post" event, which posts
the event to an event router. The event router can transfer the
event from an event generator to an application integration server
so the application integration server can notify listeners
registered for that event. The event router can know how to
communicate with the application integration server.
[0074] An event router and server can sit on a different server
than the main server or application server. This may be a common
scenario, as something tightly coupled to an SAP system may be kept
close to the SAP system instead of on the main server.
[0075] An event router can publish an event message over to the
application integration server with a "publish" call of "event
message." This can then be published to the application view topic.
Once the topic receives the event, it can notify the registered
event listener of the client. This can all be based, at least in
part, on JMS/XML standards.
[0076] Adapters
[0077] As discussed above, adapters can be developed as service or
event adapters. A service adapter can invoke a specific function in
a resource or enterprise system to which it is connected. An event
adapter can propagate information from the resource or enterprise
system to the integration environment. For each application view,
businesses can add any number of services and events to an
application view definition in order to support specific types of
transactions between an application server and the target
enterprise system. Because an adapter can use XML to translate an
application's data format, business analysts do not need to
understand the format. If a business analyst wants to use an
adapter, it is only necessary to know how to define and use
application views. Best of all, because all adapters can use a
similar Web-based interface for defining application views, it can
be easy to learn to use current and future adapters. XML can make
application integration smooth both for developers and business
analysts.
[0078] The J2EE specification does not currently provide guidelines
for an EIS to initiate communication with the application server or
client. Application integration can provide this capability through
the user of event adapters. Another important feature of an
application view is the ability to support bi-directional
communication. The J2EE specification does not currently provide
guidelines for an EIS to initiate communication with the
application server or client. This capability can be provided by an
event adapter. When added to an application view, each event
responds to a particular enterprise application state. When a
particular event is triggered, the application view can extract
data about the event from the enterprise system and propagate the
data in an XML document to the integration environment.
[0079] Similarly, when added to an application view, each service
can represent a particular function in an enterprise system. When
an application view receives an XML document that maps to a
particular server, it invokes the corresponding function in the
enterprise system using the service adapter. The enterprise system
can in some embodiments send a response to the service.
[0080] Asynchronous Approach
[0081] For asynchronous services, such as may require storage of
the request ID, a predefined string variable can be selected, such
as from an application view console. If no suitable string variable
exists, a "variable properties" dialog box can be opened where a
new string variable can be created. When a task node is set up to
call an asynchronous application view service, the result can be
returned to BPM. The workflow can identify this response using the
selected request ID variable. To set an event node to receive the
response, the same request ID variable can be used for the event
node.
[0082] A user may wish to set up an event mode to wait for a
response from an asynchronous application view service. In a
workflow, whenever an action calls an application view service
asynchronously, the application view service will return a
response. Normally, if the user wants to know about the response,
the user may want to set up a corresponding asynchronous event node
to wait for the response. To configure an asynchronous event node
to wait for a response from an asynchronous application view
service, an event node can be created with the event node being set
to wait for an event, such as an event of type "Async
Response."
[0083] There are at least two primary methods that can be used to
set up the event node to receive the asynchronous service response
in this embodiment. In a first method, a user can select a
"response document" option. When using this method, a user can
receive an asynchronous service response by selecting the request
ID variable and a response document variable. The request ID
variable is a string and the response document variable is of type
XML. A second method uses an "asynchronous variable" option. When
using this method, the asynchronous service response can be
received by selecting the request ID variable and an asynchronous
service response variable. The request ID variable is a string and
the asynchronous service response variable can be of a type such as
"AsyncServiceResponse." A preferred method may be the response
document method, as it can provide a universal means of receiving
both asynchronous and synchronous responses. When using the
response document method, an XML document can be received
regardless of whether the response is asynchronous or synchronous,
and it will not be necessary to query the value of the asynchronous
service response variable.
[0084] A response document variable can be used to receive
asynchronous service responses whenever possible. Whenever an
"event properties" dialog box is set to wait for an event of the
asynchronous response type, a user can choose to use an
asynchronous variable to receive the response. If an asynchronous
response event node is edited that was previously set up to use an
asynchronous service response variable to receive the response,
then two options can be displayed in an event properties dialog
box: an asynchronous variable option and a response document
option. In this case, a user can select one of the two methods to
receive the service response.
[0085] If an existing asynchronous response event node is edited
that does not use an asynchronous service response variable or a
new asynchronous event node is created, an event properties dialog
box can display a dialog box that will allow a user to set a
response document to receive the service response.
[0086] Although this scenario does not handle errors returned in
the application view service response, a user may want to handle
errors in specific user workflows. To handle asynchronous service
response errors in these workflows that may use, for example, an
AsyncServiceResponse variable, a user can use features included in
an application integration plug-in. An application integration
plug-in in accordance with one embodiment of the present invention
can include a variable type such as AsyncServiceResponse and
functions such as AlHasError( ), AlGetErrorMsg( ), and
AlGetResponseDocument( ).
[0087] To set up an asynchronous event node to wait for a response
from an asynchronous application view service, an event node can be
created and set to wait for an event of a type such as "Al Async
Response." Steps for setting an event node to use an XML variable
to receive an asynchronous service response can include, first,
opening a workflow template definition. A user can create an event
node if one does not already exist, which will wait for an
asynchronous response from a designated application view service.
The user can select an already-defined string variable, and BPM
will listen for an asynchronous response with an ID matching this
variable.
[0088] The event node can wait for a response to an action, such as
a call to an application view service, that was called
asynchronously earlier in the workflow. The "call application view
service" action can set the request ID variable. To make the action
and this event node work together, they can both use the same
request ID variable.
[0089] For asynchronous services that require storage of the
response, a user can select a predefined XML variable, such as from
a response document variable list. When BPM receives the response
from the application view service, the response document variable
can be used to store the response. If no suitable XML variable
exists, the user can create a new variable. A preferred method for
receiving an asynchronous service response may be to use a response
document variable of type XML. However, if an existing workflow
contains an asynchronous event node that was previously set to use
an AsyncServiceResponse variable to wait for a response from an
asynchronous application view service, a user can modify the event
node.
[0090] If an event mode uses an AsyncServiceResponse variable to
receive an asynchronous service response, one approach to modifying
the event mode uses the following steps. A workflow template
definition is opened and an asynchronous variable type selected. A
user selects an already-defined string variable, and BPM listens
for an asynchronous response with an ID matching this variable.
[0091] Callback Listener
[0092] A client can choose to invoke a service asynchronously if it
is a long-running service. For instance, some SAP requests can take
about two or three minutes to process. The processing of the
request usually happens transparent to the client. If the user is
sitting at a web page, it can be undesirable for the page to simply
"hang" for two minutes without doing anything. It may be preferable
to issue some sort of response, then update the web page once the
proper response is received, such as a new message from SAP. This
is one reason for using a callback listener for asynchronous
responses. In this way, a client does not want to have to wait
around for a response, but will instead be notified when the
response is received by the callback listener.
[0093] A listen and receive event is another valuable part of
certain embodiments in accordance with the present invention, as a
listen and receive event is not addressed in the J2EE Connector
architecture. A trigger can occur in an EIS, and external
applications may need to know about the firing of the trigger. In
other words, an event occurs that needs to be propagated out to
certain applications. All the registered listeners may need to be
notified as well.
[0094] As before, a client can create an application view and can
add an event listener. A handler can be created that knows what to
do once it receives an event from the application view. The
application view in one embodiment subscribes to a JMS topic and
registers the listener on that topic. A JMS topic is a JMS feature
to which JMS messages can be posted, similar to an inbox.
[0095] There can be defined an object, or application integration
component, called an "event generator." One job of the event
generator is to watch and communicate with an EIS to determine when
an event occurs. For a DBMS adapter, this can involve a query on a
staging table. A user can make a request, such as "select*from
event." Any record in that event table will be a record of a new
event in the DBMS. The event generator periodically look to the EIS
for new events.
[0096] For example, when an order processing system is running low
on an item in inventory, an event can result the system triggering
a notification that it needs to restock a certain product. This
event can happen, for example, in an EIS. Triggers can be used for
DBMS. Once an insert occurs on a certain table, a trigger can fire
and place information about the new data into the event table, such
as by using an "insert into event . . . " statement. Then, once a
new event occurs, the event generator can pull that event.
[0097] Adapter Development Kit (ADK)
[0098] An adapter development kit (ADK) can be used to facilitate
the construction of adapters that will run, for example, in any
J2EE-compliant environment. These adapters can have additional,
value-added functionality when hosted within an integration
framework component. An ADK can provide tools to allow adapter
developers to create bi-directional adapters that support the
business-level concepts of events and services. An adapter
developed using the ADK can provide access to an application's
metadata, which can be used to define events and services via the
application view. The ADK can provide run-time support for events
and services. The ADK can also provide support for constructing
thin, JSP-based user interfaces for use in defining application
views based on the adapter.
[0099] An ADK run-time framework can provide a complete, extensible
event generator to support the development of event adapters. To
support the development of service adapters, the runtime framework
can provide a complete, but minimally functional J2EE-compliant
adapter. Adapter developers can save time coding and debugging by
starting with and extending this base framework.
[0100] An ADK can be thought of as a tool set for implementing an
event and service protocol of application integration. An ADK can
be a collection of frameworks that support the development,
testing, packaging, and distribution of resource adapters for
application integration. Specifically, an ADK can be comprised of
the four primary frameworks, including a design-time framework, a
run-time framework, a logging framework, and a packaging
framework.
[0101] An ADK can address three requirements for adapter
development, including a requirement for structure. Regarding
structure, a prominent theme in any integrated development and
debugging environment, such as IDDE, is development project
organization. A well structured development environment is
desirable so that a user can immediately begin coding the adapter.
A user will usually prefer not to spend time designing and
organizing a build process. An ADK can provide an organized
development environment, build process, intuitive class names and
class hierarchy, and test methodology. Since an ADK encompasses so
many advanced technologies, an incremental development process can
be the key to success. An ADK test process can allow a developer to
make a simple change and test it immediately.
[0102] Another requirement for some embodiments includes a minimal
exposure to users of the details of peripheral implementation.
Peripheral implementation details are sections of code that are
needed to support a robust software program, but are not directly
related to the kernel of the program. Moreover, peripheral
implementation details are sections of code that are needed to
support the framework the software program runs in. For example,
the J2EE Connector Architecture specification requires that the
JAVAX.RESOURCE.CCI.INTERACTIONSPEC implementation class provide
getter and setter methods that follow the JavaBeans design pattern.
To support the JavaBeans design pattern, a user may need to support
PROPERTYCHANGELISTENERS and VETOABLECHANGELISTENERS in an
implementation class. A user will not want to have to study the
JavaBeans specification to learn how to do this, but would prefer
to focus on implementing the enterprise information system
(EIS)-specific details of the adapter. The ADK provides base a base
implementation for a majority of the peripheral implementation
details of an adapter.
[0103] It can also be desirable to have a clear road map to
success. A key concept in adapter development is the exit criteria.
The exit criteria answers the question: "How do I know I am done
with an implementation?" In other words, a clear road map details
that which needs to be implemented ion order to complete an
adapter. An ADK can provide a clear methodology for developing an
adapter. The ADK methodology organizes a user's thoughts around a
few key concepts: events, services, design time, and run time.
[0104] An ADK can provide run-time support for events and services.
An ADK can also include an API to integrate an adapter's user
interface into the WebLogic Integration Application View Management
Console. Another added value that can be provided by an ADK is that
adapters can become an integral part of a single graphical console
application that allows business users to construct integration
solutions.
[0105] Resource adapters, which shall be referred to herein as
"adapters," are software components that connect one application to
another when those applications are not originally designed to
communicate with each other. For example, an order entry system
built by one company requires an adapter to communicate with a
customer information system built by another.
[0106] By using an ADK, a user can create at least two types of
adapters: service adapters, which consume messages, and event
adapters, which generate messages. A user can also use the ADK to
create J2EE-compliant adapters that are not specific to an
application or application integration environment, but still
comply with the J2EE Connector Architecture specification.
[0107] These adapters may not contain application integration
specifics, such that they can be plugged into any application
server that supports the J2EE Connector Architecture specification.
These adapters can be developed by making minor modifications to
the procedures given for developing a service adapter.
[0108] An ADK packaging framework can provide a tool set for
packaging an adapter for delivery to a customer. Ideally, all
adapters are installed, configured, and uninstalled the same on a
single application server. Moreover, all service adapters can be
J2EE compliant. The packaging framework can make creating a J2EE
adapter archive (.rar) file, Web application archive (.war) file,
the enterprise archive (.ear) file, and application integration
design environment archive easy.
[0109] Adapter activity typically falls within one of two
conceptual entities: run time and design time. Run time refers to
functionality that occurs when adapters execute their processes.
Design time refers to the adapter user's implementation of an
application view. In essence, design time is the act of creating,
deploying, and testing an application view.
[0110] Run time and design time can be characterized in an ADK by
run-time and design-time frameworks. A run-time framework can be
comprised of the tools used when developing adapters, while the
design-time framework can refer to the tools used to design
Web-based user interfaces.
[0111] A run-time framework is a set of tools that can be used to
develop event and service adapters. To support event adapter
development, the run-time framework can provide a basic, extensible
event generator. For service adapter development, the run-time
framework can provide a complete J2EE-compliant adapter.
[0112] Classes supplied by the run-time framework can provide
several following benefits. One benefit of such a class is that it
can allow a user to focus on EIS specifics rather than J2EE
specifics. The classes can also minimize the effort needed to use
the ADK logging framework, can simplify the complexity of J2EE
Connector Architecture, and can minimize redundant code across
adapters.
[0113] In addition, a run-time framework can provide abstract base
classes to help implement an event generator to leverage the event
support provided by an ADK environment. A key component of a
run-time framework is a run-time engine, which can host the adapter
component responsible for handling service invocations, and can
manages physical connections to the EIS, login authentication, and
transaction management, all in compliance with the J2EE Connector
Architecture standard.
[0114] A design-time interface for each adapter in accordance with
one embodiment of the present invention is a J2EE Web application
that is bundled as a .war file. A Web application is a bundle of
.jsp, .html, image files, and so on. The Web application descriptor
is web.xml. The descriptor instructs the J2EE Web container how to
deploy and initialize the Web application. Every Web application
has a context. The context is specified during deployment and
identifies resources associated with the Web application under the
Web container's doc root.
[0115] An ADK can be used to create event adapters and service
adapters. Within the ADK architecture, services and events can be
defined as self-describing objects that use an XML schema to define
their input and output.
[0116] Each adapter created can have an adapter logical name, a
unique identifier that represents an individual adapter and serves
as the organizing principle for all adapters. As such, the adapter
logical name can be used to identify an individual adapter and can
be used to name a message bundle, a logging configuration, and log
categories. An adapter logical name can be, for example, a
combination of the vendor name, the type of EIS connected to the
adapter, and the version number of the EIS. By convention, this
information can be expressed as VENDOR_EIS-TYPE_EIS version.
[0117] An adapter logical name can be used with adapters in a
number of ways. One way is to use it as a convention, although this
is not required. Another way is to use it during adapter deployment
as part of the .war, .rar, .jar, and .ear filenames. It can also be
used as an organizing principle, or as a return value to an
abstract method such as getAdapterLogicalName( ).
[0118] The Name attribute of a <ConnectorComponent> element
can be an adapter logical name. This can be a key that is used by
application integration to associate application views to a
deployed resource adapter, as shown for the sample adapter:
[0119] <ConnectorComponent Name="BEA_WLS_SAMPLE_ADK"
Targets="myserver" URI="BEA_WLS_SAMPLE_ADK.rar"/>
[0120] The adapter logical name can be used as the name of the .rar
file as a convention, but is not required in the URI attribute.
[0121] Lastly, the adapter logical name can be used as a return
value to the abstract method getAdapterLogicalName( ) on a
com.adapter.web.Abstrac- tDesignTimeRequestHandler. This return
value can be used during the deployment of application views as the
value for the RootLogContext for a connection factory.
[0122] When an application view is deployed, it can have an
associated J2EE Connector Architecture CCI connection factory
deployment. For example, if a user deploys the abc.xyz application
view, application integration can deploy a new ConnectionFactory
and bind it to a JNDI location connectionFactorylnstance. For
efficiency sake, the new connection factory deployment can use the
<ra-link-ref> setting in the weblogic-ra.xml deployment
descriptor.
[0123] The <ra-link-ref> element can allow for the logical
association of multiple deployed connection factories with a single
deployed adapter. The specification of the optional
<ra-link-ref> element with a value identifying a separately
deployed connection factory can result in this newly deployed
connection factory sharing the adapter which had been deployed with
the referenced connection factory. In addition, any values defined
in the referred connection factory's deployment can be inherited by
this newly deployed connection factory unless specified. The
adapter logical name can be used as the value for the
<ra-link-ref> element.
[0124] An ADK can use Enterprise Archive files, or .ear files, for
deploying adapters. A single .ear file can contain the .war and
.rar files, as well as any Event Router Web application files
necessary to deploy an adapter.
[0125] ADK classes, interfaces, methods, and constructors can be
defined in Javadocs included in a development kit. An ADK can
employ a build process based upon Ant, a 100% pure Java-based build
tool. For the ADK, Ant can facilitate creating a Java archive
(.jar) file for the adapter, creating .war file for an adapter's
Web application, creating a .rar file for a J2EE-compliant adapter,
and encapsulating the above listed components into a .ear file for
deployment.
[0126] Traditionally, build tools are inherently shell-based. They
evaluate a set of dependencies and then execute commands, not
unlike those that would be issued on a shell. While it is simple to
extend these tools by using or writing any program for a
user-specific operating system, the user is also limited to that
OS, or at least that OS type, such as for example.
[0127] Ant can be preferable to shell-based make tools for several
reasons. First, instead of a model where it is extended with
shell-based commands, it is extended using Java classes. Second,
instead of writing shell commands, the configuration files can be
XML-based, calling out a target tree where various tasks get
executed. Each task can be run by an object that implements a
particular task interface. While this can remove some of the
expressive power inherent in being able to construct a shell
command, it can give an application the ability to be
cross-platform. Also, if a user wants to execute a shell command,
Ant has an execute rule that can allow different commands to be
executed based on the OS upon which it is executing.
[0128] Logging toolkit
[0129] A logging toolkit is a framework that can wrap the necessary
classes to provide added functionality for J2EE-compliant adapters.
It can be provided in a .jar file. This .jar file can depend, for
example, on DOM, XERCES, and Log4j.
[0130] A logging configuration file is an .xml file that can be
identified by the adapter logical name, such as for example
DBMS_ADK.xml. It can contain base information for logging concepts
and can be modified for a specific adapter.
[0131] In one embodiment, logging has four main components: message
categories, message priority, message appenders, and message
layout. These components can work together to enable a user to log
messages according to message type and priority, and to control at
run time how these messages are formatted and where they are
reported.
[0132] Categories can be hierarchically defined. That is, any
category can inherit properties from parent categories. The
hierarchy can be defined for one embodiment as follows. A category
is an ancestor of another category if its name followed by a dot is
a prefix of the descendant category name. A category is a parent of
a child category if there are no ancestors between itself and the
descendant category. The root category can reside at the top of the
category hierarchy. It may always exist and cannot be retrieved by
name.
[0133] Every message can have a priority that indicates its
importance. Message priority can be determined by the method on an
interface used to log the message. In other words, calling a debug
method on a logging instance can generate a debug message. One
embodiment of the logging toolkit can support five possible
priorities for a given message, including AUDIT, ERROR, WARN, INFO,
and DEBUG. AUDIT can indicate an extremely important log message
that relates to the business processing performed by an adapter.
Messages with this priority can always be written to the log
output. ERROR can indicate an error in the adapter. Error messages
can be internationalized/localized for the user. WARN can indicate
a situation that is not an error, but could cause problems in the
adapter. This can include a warning message that is
internationalized/localized for the user. INFO can indicate an
informational message that is internationalized/localized for the
user. DEBUG can indicate a debug message, which can be used to
determine how the internals of a component are working and are
typically not internationalized.
[0134] A priority can be assigned to a category. If a given
category is not assigned a priority, it can inherit one from its
closest ancestor with an assigned priority. In other words, the
inherited priority for a given category can be equal to the first
non-null priority in the category hierarchy, starting at the given
category and proceeding upwards in the hierarchy towards the root
category.
[0135] A log message can be output to the log destination if its
priority is higher than or equal to the priority of its category.
Otherwise, the message may not be written to the log destinations.
A category without an assigned priority can inherit one from the
hierarchy. To ensure that all categories can eventually inherit a
priority, the root category can always have an assigned priority. A
log statement of priority p in a category with inherited priority q
can be enabled if p is greater than, or equal to, q. This rule
assumes that priorities are ordered as follows:
DEBUG<INFO<WARN<ERROR<AUDIT.
[0136] A logging framework can allow an adapter to log to multiple
destinations by using an interface called an appender. Log4j can be
used, which provides appenders for the console, files, remote
socket servers, NT Event Loggers, and Remote Unix Syslog daemons.
In addition, an appender can be used that allows a user to specify
that a log message would be output to a log for the user's
application server.
[0137] A category can refer to multiple appenders. Each enabled
logging request for a given category can be forwarded to all the
appenders in that category, as well as the appenders higher in the
hierarchy. In other words, appenders can be inherited additively
from the category hierarchy. For example, if a console appender is
added to the root category, then all enabled logging requests will
at least print on the console. If in addition a file appender is
added to category "C," then enabled logging requests for C and C's
children will print to a file and on the console. It is possible to
override this default behavior so that appender accumulation is no
longer additive by setting the additivity flag to false.
[0138] By using Log4j, a user can also customize the format of a
log message. This can be accomplished by associating a layout with
an appender. The layout is responsible for formatting a log message
while an appender directs the formatted message to its destination.
The log toolkit typically uses the PatternLayout to format its log
messages. The PatternLayout, part of a standard Log4j distribution,
allows a user to specify the output format according to conversion
patterns.
[0139] Setting up a logging framework for an adapter in accordance
with one embodiment of the present invention is a four-step
process. In the first step, a user should identify all of the basic
components used in the adapter. For example, if an adapter has an
EventGenerator, a user might want to have an EventGenerator
component; if it supports a design-time GUI, a user may need a
design-time component.
[0140] In addition to understanding the basic concepts of a logging
framework, a user may also need to understand three main classes
provided in a log toolkit, referred to herein as ILogger,
LogContext, and LogManager. ILogger is a main interface to a
logging framework. It can provide numerous convenience methods for
logging messages. LogContext is a class that can encapsulate
information needed to identify an ILogger instance in the logging
framework. A LogContext can encapsulate a log category name and a
locale, such as en_US. This class can be a primary key for uniquely
identifying an ILogger instance in the log manager. A LogManager
class can provide a method to allow a user to configure the logging
framework and provide access to ILogger instances.
[0141] An ADK can hide most of the log configuration and setup from
a user. An AbstractManagedConnectionFactory class can configure a
log toolkit for service adapters and an AbstractEventGenerator can
configure a log toolkit for event adapters. In addition, all of the
Client Connector Interface (CCI) and Service Provider Interface
(SPI) base classes that can be provided in an ADK can provide
access to an ILogger and its associated LogContext. For other
layers in an adapter to access the correct ILogger object, there
are at least two approaches that can be taken. Herein, "Other
layers" refers to layers in an adapter that support the
CCI/SPIlayer, such as a socket layer for establishing communication
to the EIS.
[0142] In a first approach, the CCI/SPI layers can pass the
LogContext object into the lower layers. This works but can also
add overhead. In a second approach, a CCI layer can establish a
LogContext for the current running thread at the earliest possible
place in the code. An ADK's ConnectionFactoryImpl class can set the
LogContext for the current running thread in the getconnection( )
methods. The getConnection( ) methods can be the first point of
contact a client program has with an adapter. Consequently, lower
layers in an adapter can safely access the LogContext for the
current running thread.
[0143] Additionally, a convenience method can be provided on the
LogManager, such as may be given by:
[0144] public static ILogger getLogger( ) throws
IllegalStateException
[0145] This method can provide an ILogger for the current running
thread. There is one caveat to using this approach: lower layers in
some embodiments should not store the LogContext or ILogger as
members. Rather, they should dynamically retrieve them from the
LogManager. An IllegalStateException can be thrown if this method
is called before a LogContext is set for the current running
thread.
[0146] Internationalization and localization can be central
concepts to an ADK logging framework. All logging convenience
methods on an ILogger interface, except the debug methods, allow
for internationalization, such as 118N. The implementation can
follow Java Internationalization standards, such as by using
ResourceBundle objects to store locale-specific messages or
templates.
[0147] Most real-world systems have to deal with multiple clients
simultaneously. In a typical multi-threaded implementation of such
a system, different threads can handle different clients. Logging
can be especially well suited to trace and debug complex
distributed applications. One approach to differentiate the logging
output of one client from another is to instantiate a new separate
category for each client. This promotes the proliferation of
categories and increases the management overhead of logging.
[0148] A lighter technique is to uniquely stamp each log request
initiated from the same client interaction. To uniquely stamp each
request, a user can push contextual information into a Nested
Diagnostic Context (NDC). A logging toolkit can provide a separate
interface for accessing NDC methods. The interface can be retrieved
from the ILogger such as by using a method getNDCInterface( ).
[0149] NDC printing can be turned on in the XML configuration file,
such as with the symbol % x. Every time a log request is made, the
appropriate logging framework component can include the entire NDC
stack for the current thread in the log output. The user may not
need to intervene in this process. In fact, the user can be
responsible only for placing the correct information in the NDC by
using the push and pop methods at a few well-defined points in the
code.
[0150] Service Adapters
[0151] Service adapters can receive an XML request document from a
client and invoke the associated function in the underlying EIS.
They can be consumers of messages and may or may not provide a
response. Service adapters can perform at least four primary
functions. Service adapters can receive service requests from an
external client. Service adapters can transform an XML request
document into an EIS specific format. The request document can
conform to a request XML schema for the service. The request XML
schema can be based on metadata in the EIS.
[0152] They invoke the underlying function in the EIS and wait for
its response. They transform the response from the EIS specific
data format to an XML document that conforms to the response XML
schema for the service. The response XML schema is based on
metadata in the EIS.
[0153] As discussed above, FIGS. 2-5 show processes executed when a
service adapter is used in a run-time environment. FIGS. 2 and 3
show an asynchronous service adapter while FIGS. 4 and 5 show a
synchronous adapter. FIG. 8 outlines one approach to developing a
service adapter in accordance with one embodiment of the present
invention. First, a user can determine various needs for the
adapter 600. A user can determine the EIS and the appropriate
service required for this adapter. This can be based upon the
user's knowledge of the EIS, and the user must identify the
interface to the back-end functionality. A user can also determine
an "expensive" connection object required to invoke a function
within the EIS. The expensive connection object is a resource used
to communicate with the EIS that can require the allocation of
system resources, such as a socket connection or DBMS connection. A
valuable asset of the J2EE Connector architecture is that the
application server can provide pooling of these objects. Therefore,
a user can determine this object for the adapter, as it may need to
be pooled by the application server. The user can also determine
the environment for the adapter 602, such as by setting up a file
structure and assigning an adapter logical name. The user can then
implement the SPI 604 and CCI 606 for the adapter. The user can
then test 608 and deploy 610 the adapter.
[0154] ManagedConnectionFactory
[0155] In the ADK sample adapter, the class
sample.spi.ManagedConnectionFa- ctoryImpl is provided. This class
extends AbstractManagedConnectionFactory- . Use this class as an
example of how to extend the ADK's base class.
[0156] The ManagedConnection object is responsible for
encapsulating all expensive resources needed to establish
connectivity to the EIS. A ManagedConnection instance represents a
physical connection to the underlying EIS. ManagedConnection
objects are pooled by the application server in a managed
environment.
[0157] An ADK can provide an abstract implementation of
ManagedConnection. The base class can provide logic for managing
connection event listeners and multiple application-level
connection handles per ManagedConnection instance. When
implementing a ManagedConnection interface, the user may need to
determine the transaction demarcation support provided by the
underlying EIS.
[0158] An ADK can also provide AbstractManagedConnection, an
abstract implementation for the
javax.resource.spi.ManagedConnection interface that can provide
access to an ADK logging framework. The implementation can also
manage a collection of connection event listeners, and can provide
convenience methods for notifying all connection event listeners of
connection-related events. It can also simplify clean-up and
destruction of a ManagedConnection instance.
[0159] A ManagedConnectionMetaData interface can provide
information about an underlying EIS instance associated with a
ManagedConnection instance. An application server can use this
information to get run-time information about a connected EIS
instance. An ADK can also provide
AbstractManagedConnectionMetaData, an abstract implementation of
the ManagedConnectionMetaData and ConnectionMetaData interfaces
that can simplify exception handling, provide access to an
AbstractManagedConnecti- on instance, allow a user to focus on
implementing EIS-specific logic, and can prevent a user from having
a separate metadata class for the CCI and SPI implementations.
[0160] A ConnectionEventListener interface can provide an event
callback mechanism that enables an application server to receive
notifications from a ManagedConnection instance.
[0161] An ADK can provide at least two concrete implementations of
ConnectionEventListener. One implementation is a
ConnectionEventLogger, which logs connection-related events to the
adapter's log by using the ADK logging framework. Another
implementation is aNonManagedConnectionEve- ntListener which can
destroy ManagedConnection instances when the adapter is running in
a non-managed environment. This implementation can log
connection-related events using the ADK logging framework, and can
destroy ManagedConnection instances when a connection related error
occurs.
[0162] An ADK can provide a concrete implementation of
NonManagedConnectionManager. This implementation can provide a
basic connection manager for adapters running in a non-managed
environment. In a managed environment, this interface can be
provided by the application server. NonManagedConnectionManager is
a concrete implementation of the ConnectionManager interface. It
can serve as the ConnectionManager in the non-managed scenario for
an adapter. It may not provide any connection pooling or any other
quality of service.
[0163] A ConnectionRequestInfo interface can enable an adapter to
pass its own request specific data structure across the connection
request flow. An adapter extends the empty interface to support its
own data structures for a connection request.
[0164] An ADK can provide a concrete implementation of an interface
called ConnectionRequestInfoMap. This is a concrete implementation
of the ConnectionRequestInfo interface and can provides a
java.util.Map interface to such connection request information as
username and password. An ADK can also provide an abstract
implementation of this interface called AbstractLocalTransaction.
This implementation can allow a user to focus on implementing the
EIS-specific aspects of a LocalTransaction. This implementation can
simplify exception handling, allow adapter providers to focus on
implementing EIS-specific transaction logic, and prevent a user
from having a separate metadata class for the CCI and SPI
implementations.
[0165] A user may also need to implement the CCI. This client
interface can allow a J2EE-compliant application to connect to, and
access, back-end systems. The client interface can manage the flow
of data between the client application and the back-end system, and
may not have any visibility into what either the container or the
application server are doing with the adapter. The client interface
can specify the format of the request and response records for a
given interaction with the EIS.
[0166] First, the user must determine whether the adapter must
support the J2EE-compliant Common Client Interface (CCI). Although
not a requirement in the current J2EE specification, it may be a
requirement in a later version. Consequently, the ADK can focus on
helping a user implement a CCI interface for the adapter.
[0167] To implement the CCI for an adapter, a user can extend at
least two interfaces, including Connection, which represents an
application-level handle that can be used by a client to access the
underlying physical connection, and Interaction, which can enable a
component to execute EIS functions. In some embodiments, a user
should implement these interfaces in the order specified. In
addition to these interfaces, a user can implement any other
interfaces needed by the adapter. These interfaces can include
ConnectionFactory, ConnectionMetaData, ConnectionSpec,
InteractionSpec, LocalTransaction, Record, and
ResourceAdapterMetaData.
[0168] A Connection can represent an application-level handle that
can be used by a client to access the underlying physical
connection. The actual physical connection associated with a
Connection instance can be represented by a ManagedConnection
instance. A client can get a Connection instance by using a
getConnection( ) method on a ConnectionFactory instance. A
Connection can be associated with zero or more Interaction
instances.
[0169] An ADK can provide an abstract implementation of an
interface called AbstractConnection that provides functionality
including access to an ADK logging framework, access to an
AbstractManagedConnection instance, and state management and
assertion checking. A user may need to extend this class by
providing an implementation for:
[0170] Public Interaction createInteraction( ) throws
ResourceException. This method can create an interaction associated
with this connection. An interaction enables an application to
execute EIS functions. This method can return an Interaction
instance and throw a ResourceException if the "create" operation
fails. An Interaction instance can enable a component to execute
EIS functions. An Interaction instance can support several ways of
interacting with an EIS instance. One way is through an executes
method that takes an input Record, output Record, and
InteractionSpec. This method can execute the EIS function
represented by the InteractionSpec and can update the output
Record.
[0171] An execute( ) method that takes an input Record and an
InteractionSpec. This method implementation executes the EIS
function represented by the InteractionSpec and produces the output
Record as a return value.
[0172] An Interaction instance is created from a connection and is
required to maintain its association with the Connection instance.
The close( ) method releases all resources maintained by the
adapter for the interaction. The close of an Interaction instance
should not close the associated Connection instance.
[0173] The foregoing description of preferred embodiments of the
present invention has been provided for the purposes of
illustration and description. It is not intended to be exhaustive
or to limit the invention to the precise forms disclosed. Many
modifications and variations will be apparent to one of ordinary
skill in the art. The embodiments were chosen and described in
order to best explain the principles of the invention and its
practical application, thereby enabling others skilled in the art
to understand the invention for various embodiments and with
various modifications that are suited to the particular use
contemplated. It is intended that the scope of the invention be
defined by the following claims and their equivalence.
* * * * *