Patent Grant
7165249
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 patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
The present invention relates to the deployment of software components across a system.
In existing integration systems, the primary use of an application integration (AI) component, such as an application view, is through a business process management (BPM) workflow. Potential consumers of an AI component, such as Web service developers and portal developers, will also require access to an Enterprise information system (EIS). However, like a business process engineer, these developers are not interested in dealing with the intricate details of a particular EIS. Further, the developers want access to the AI component with minimal installation, configuration, and administration overhead.
Certain components are tightly integrated with the integration system, such that system providers do not worry about providing integration flexibility. Users purchasing an integration system get a pre-configured integration domain. If a user wants to use system functionality with other domains, such as a Web portal domain, it is necessary for the user to do the integration.
Systems and methods in accordance with embodiments of the present invention can overcome deficiencies in existing integration systems by changing the way in which integration components are deployed to system domains. An integration component such as an application integration engine can be bundled as a single, self-contained J2EE Enterprise archive (EAR) file. The bundling of the component into an EAR file enables the component to be deployed to any valid system domain that is running and available. A recycling of the server can then be necessary only if a Java archive file is added to the classpath for non-system domains.
Other features, aspects, and objects of the invention can be obtained from a review of the specification, the figures, and the claims.
Systems and methods in accordance with embodiments of the present invention can allow application integration (AI) functionality to be imbedded deeply into an integration installation. In one such system, AI functionality can be bundled in an enterprise application archive (EAR) file that is available to any valid system domain. This packaging can retain backward compatibility with existing integration systems, while providing the lightweight solution that developers desire.
Such packaging can be used with modular deployment when, for example, a portal needs to access an EIS. Many such products and processes can leverage AI functionality. One purpose for using modular deployment is to make it as easy as possible to configure AI for downstream products. Presently, a user has to clean up what goes onto the classpath. It can be desirable to use Java™ 2 Enterprise Edition (J2EE) standards, as set forth by Sun Microsystems, Inc., of Santa Clara, Calif., such as using an Enterprise application. An end-user can use an EAR file, for example, to use application integration with a non-system domain.
An exemplary integration system that can be used in accordance with embodiments of the present invention is shown in
When an event occurs in the EIS 100, an event generator 102 can detect the event and determine whether anyone should receive this event. To do this, the event generator 102 can check the types of events that have subscriptions, which can be maintained by the event router 104. The event router can create an event object containing pertinent data about the event, and can sends the event object to the event router 104. The event router 104 can send the event object to any application view 108 that is subscribed to the type of event object received from the event generator 102. The application view 108 can receive the event object and notify any listener 112 registered for that type of event. Exemplary listeners can include integration process flow or custom business logic flow. A listener 112 can process the event object and determine whether a service should be invoked in response to the event.
The application view 108 can combine data from the event object with data held by the application view, such as in state variables, and can make a service invocation on a resource adapter 114. The application view can accept the service request and determine which interaction to request on the resource adapter 114. This mapping from service name to adapter interaction can allow the service to be business-centric and not system-function centric. The resource adapter 114 can carry out the request interaction with the EIS 100 and pass the data received from the application view 108. This data can then be viewed, such as through a Web browser 116, through the integration adapter 110.
As shown in the method of
An AI engine can use an integration repository for metadata persistence. The AI engine can rely on a pre-configured repository and associated Java Database Connectivity (JDBC) connection pool and data source. In this case, the AI engine deployer can provide the JDBC data source name and credentials at the time of deployment. The AI engine can assume that the repository has already been installed in the data source.
An application view engine can use Java Message Service (JMS) resources to handle events and asynchronous service invocations. To support these functions, an application view engine can use functionality such as a JMS Connection Factory, JMS Template, JMS JDBC Store, and/or JMS Server. In addition, an AI engine can define a request and response queue for handling asynchronous service invocations. The AI engine deployer is not forced to define the JMS resources before deploying the AI engine. Consequently, at least two modes of operation can be supported for determining which JMS resources to use.
The AI engine deployer can provide the name of pre-existing JMS resources, such as “JMSConnectionFactory” and “JMSServer”. If a deployer provides the name for a JMS server, the developer may also need to configure the JMS JDBC store. The AI engine deployer does not need to provide the name of pre-existing JMS resources. The AI startup process can use JMS managed beans (MBeans) to define the necessary JMS resources.
AI startup and shutdown classes can be replaced by a Java HTTP servlet, such as “LifeCycleServlet”. The servlet can be deployed in an integration Web application and loaded on startup. On startup, the servlet can also trigger the initialization sequence for the AI engine. The initial parameters provided to the servlet can serve as the configuration parameters for the AI engine. The user can change these parameters by editing a Web application descriptor, for example. A list of potential configuration parameters can include:
An application view management console can provide a way to view the configuration parameters for the AI engine, such as by providing a link to a page containing these parameters. Starting and stopping an AI engine can be done from a console via deploying and/or undeploying the integration application that contains the application integration component.
Certain properties can be edited by a user using a configuration page, including properties such as logLevel, hostPassword, and hostUserID. Since BPM may not always be installed with AI, AI can provide a simple command-line import/export tool for application views. The output of this tool can be a JAR file containing any artifacts owned by the application view. The user can be required to manually import/export any artifacts that are not owned, but are used by the application view.
An example of a common AI JAR file that can be added to the server classpath at startup is “ai-core.jar.” This exemplary JAR can contain:
A client JAR, such as “ai-client.jar”, can be used to contain any classes needed by clients of the AI engine, such as application view clients and resource adapter design time Web applications.
A server JAR file, such as “ai-server.jar,” can contain all classes needed by the server-side components, and does not need to be included into any adapter EAR files or clients. For integration domains, ai-server.jar can be added to a server JAR such as iserver.jar so that server components can access the base AI server classes.
An MBean JAR file, such as “ai-mbean.jar,” can be used to contain the application view MBeans and can be included on the system classpath for the integration server. For integration domains, ai-server.jar can be added to iserver.jar so that server components can access the MBean classes.
A server EJB JAR file, such as “ai-server-ejb.jar,” can contain the base server classes and management EJBs. This JAR can be deployed before all other components of the AI engine, and can contain a startup EJB that can initialize AI.
An AI Web archive (WAR) file, such as “ai.war,” can contain an application view management console Web application and the lifecycle servlet for the AI engine. An event processor EJB JAR file, such as “ai-eventprocessor-ejb.jar,” can contain the event processing message driven EJB for handling AI events.
An asynchronous EJB JAR file, such as “ai-asyncprocessor-ejb.jar,” can contain an asynchronous service processing message-driven EJB for handling asynchronous service invocations. A plug-in EJB JAR file, such as “ai-plugin-ejb.jar,” can contain all classes for a plug-in for BPM. A plug-in WAR file, such as “ai-plugin.war,” can contain the online help Web application for the AI Plug-in for BPM.
In order to configure deployment for integration domains that require AI, components such as the following can be added to an integration application element:
For AI domains, there can be an AI EAR file, such as “ai.ear,” which can contain any file needed to deploy the AI enterprise application outside of an AI domain. The EAR file can be structured as:
Deployers may still need to add ai-core.jar to the system classpath and restart their server in some embodiments.
An application component such as the following can be added to the config.xml for the non-AI domain, or uploaded from the server console once the ai-core.jar file is on the classpath:
A Plug-In for BPM may not be able to be deployed from the ai.ear file for AI domains.
An AI engine can use JMS resources such as a JMS server, a JMS connection factory, JMS queues, and JMS topics. If the JMS connection factory supplied by the user is not bound to a JNDI location, the factory can be cloned and bound to a location, such as com.ai.JMSConnectionFactory, so that internal AI components can be guaranteed to have access to a JMS connection factory. Queues that can be used include event queues, asynchronous request queues, and asynchronous response queues. Topics that can be used can include event topics, for example.
An AI engine can automatically define any necessary JMS resources that are not explicitly defined, such as for a standalone server and a cluster. This can free a user from having to define the resources, such as through a user interface (UI). Automatic definition can be done in a clustered or non-clustered environment. This can save the user from having to do an error-prone process of defining multiple JMS resources. This process can be relatively self-contained and can take care of defining necessary resources and dependencies. Using a system console to define multiple queues can be quite a tedious task, especially if the queues need to be distributed in a cluster.
A system administrator can simply specify configuration parameters such as the JMS server name (e.g., ai.jms.serverName ) and the JMS connection factory JNDI name (e.g., ai.jms.connectionFactoryJNDIName). In addition, if a user wishes to disable the auto-generation of JMS resources, the user can set a JMS auto-generation parameter, such as ai.jms.autogen, to ‘false.’ This can prevent the AI engine from attempting to auto-generate any JMS resources.
It may be desirable that adapters developed and tested on existing systems are able to run un-altered on systems in accordance with the present invention. If an adapter provider needs to rebuild an adapter against a new adapter development kit (ADK) that incorporates an embodiment in accordance with the present invention, the adapter provider may need to change the build procedure to account for new AI binary files such as those described above. Specifically, adapter developers may need to reference new JAR files such as the following:
Adapter developers may also need to change how they declare the environment property. In one embodiment, this declaration can be implemented as, for example:
<property environment=‘env’/>
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.
This application claims priority from U.S. provisional patent application “MODULAR DEPLOYMENT OF COMPONENTS”, Application No. 60/377,354, filed May 2, 2002, incorporated herein by reference. The following applications are cross-referenced and incorporated herein by reference: U.S. Provisional Application No. 60/377,322 entitled “Application View Transactions,” by Timothy Potter et al., filed May 2, 2002. U.S. Provisional Application No. 60/377,303 entitled “Adapter Deployment Without Recycle,” by Timothy Potter et al., filed May 2, 2002. U.S. Provisional Application No. 60/377,353 entitled “Shared Common Connection Factory,” by Timothy Potter et al., filed May 2, 2002.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5321841 | East et al. | Jun 1994 | A |
| 5748975 | Van De Vanter | May 1998 | A |
| 5801958 | Dangelo et al. | Sep 1998 | A |
| 5835769 | Jervis et al. | Nov 1998 | A |
| 5836014 | Faiman, Jr. | Nov 1998 | A |
| 5862327 | Kwang et al. | Jan 1999 | A |
| 5933838 | Lomet | Aug 1999 | A |
| 5950010 | Hesse et al. | Sep 1999 | A |
| 5961593 | Gabber et al. | Oct 1999 | A |
| 6023722 | Colyer | Feb 2000 | A |
| 6028997 | Leymann et al. | Feb 2000 | A |
| 6044217 | Brealey et al. | Mar 2000 | A |
| 6067548 | Cheng | May 2000 | A |
| 6067623 | Blakley, III et al. | May 2000 | A |
| 6085030 | Whitehead et al. | Jul 2000 | A |
| 6119149 | Notani | Sep 2000 | A |
| 6141686 | Jackowski et al. | Oct 2000 | A |
| 6222533 | Notani et al. | Apr 2001 | B1 |
| 6226675 | Meltzer et al. | May 2001 | B1 |
| 6230287 | Pinard et al. | May 2001 | B1 |
| 6230309 | Turner et al. | May 2001 | B1 |
| 6237135 | Timbol | May 2001 | B1 |
| 6256676 | Taylor et al. | Jul 2001 | B1 |
| 6282561 | Jones et al. | Aug 2001 | B1 |
| 6282711 | Halpern et al. | Aug 2001 | B1 |
| 6324681 | Sebesta et al. | Nov 2001 | B1 |
| 6336122 | Lee et al. | Jan 2002 | B1 |
| 6338064 | Ault et al. | Jan 2002 | B1 |
| 6349408 | Smith | Feb 2002 | B1 |
| 6353923 | Bogle et al. | Mar 2002 | B1 |
| 6393605 | Loomans | May 2002 | B1 |
| 6463503 | Jones et al. | Oct 2002 | B1 |
| 6549949 | Bowman-Amuah | Apr 2003 | B1 |
| 6594693 | Borwankar | Jul 2003 | B1 |
| 6604198 | Beckman et al. | Aug 2003 | B1 |
| 6732237 | Jacobs et al. | May 2004 | B1 |
| 6795967 | Evans et al. | Sep 2004 | B1 |
| 6802000 | Greene et al. | Oct 2004 | B1 |
| 6804686 | Stone et al. | Oct 2004 | B1 |
| 20020016759 | Macready et al. | Feb 2002 | A1 |
| 20020073080 | Lipkin | Jun 2002 | A1 |
| 20020165936 | Alston et al. | Nov 2002 | A1 |
| 20030018665 | Dovin et al. | Jan 2003 | A1 |
| 20030041198 | Exton et al. | Feb 2003 | A1 |
| 20030046266 | Mullins et al. | Mar 2003 | A1 |
| 20030051236 | Pace et al. | Mar 2003 | A1 |
| 20030110117 | Saidenbereg et al. | Jun 2003 | A1 |
| 20030115377 | Curtis et al. | Jun 2003 | A1 |
| 20030233631 | Curry et al. | Dec 2003 | A1 |
| 20030236923 | Jeyaraman et al. | Dec 2003 | A1 |
| 20040015564 | Williams | Jan 2004 | A1 |
| 20040068568 | Griffin et al. | Apr 2004 | A1 |
| 20040133660 | Junghuber et al. | Jul 2004 | A1 |
| 20040205692 | Robinson | Oct 2004 | A1 |
| 20040225995 | Marvin et al. | Nov 2004 | A1 |
| Number | Date | Country |
|---|---|---|
| WO 0190884 | Nov 2001 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 20040015859 A1 | Jan 2004 | US |
| Number | Date | Country | |
|---|---|---|---|
| 60377354 | May 2002 | US |
