Systems and methods for application view transactions

Abstract

Local transactions are supported by an application view instance that can switch from a stateless session bean to a stateful session bean in order to open a connection for a local transaction. The state that the stateful session bean holds is then the connection. The stateful session bean can hold the connection open across multiple requests in the local transaction for the duration of the transaction. A local transaction interface allows a user to manage the transaction in the application view, and to switch the application view between a stateless session bean and a stateful session bean. A local transaction interface can contain a local transaction management contract, which enables an application server to provide an infrastructure and run-time environment for management of the transaction.

Description

COPYRIGHT NOTICE

[0007] 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.

FIELD OF THE INVENTION

[0008] The present invention relates to supporting transactions in application integration.

BACKGROUND

[0009] In existing application integration (AI) systems, users are unable to capitalize on the full extent of resource adapter functionality. One main area of functionality that is not exploited involves local transaction support. In order to manage a local transaction, a user must acquire a local transaction from a connection object. There is presently no way to do this through an application view component or application view layer. While a Java connector, or at least a Common-Client Interface (CCI)-based Java connector, can support a local transaction, this functionality has not been implemented with regard to an application view layer.

BRIEF SUMMARY

[0010] Systems and methods in accordance with embodiments of the present invention can overcome deficiencies in existing integration systems by providing a way to support a local transaction through an application view instance. An application view can switch from a stateless session bean to a stateful session bean in order to open a connection for a local transaction. A state being held by a stateful session bean can be the connection. A stateful session bean can hold a connection open across multiple requests in a local transaction, and can maintain the connection open for the duration of the local transaction.

[0011] A local transaction interface can allow a user to manage a local transaction in an application view, and can allow the user to switch the application view between a stateless session bean and a stateful session bean. A Common Client Interface (CCI) class can be used to expose a local transaction interface to a resource adapter client. A transaction manager can be used to obtain a resource for any open connection. The local transaction interface can contain a local transaction management contract, which can enable an application server to provide an infrastructure and run-time environment for management of the transaction.

[0012] 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

[0013] FIG. 1 is a diagram of a system in accordance with one embodiment of the present invention.

[0014] FIG. 2 is a flowchart showing a method that can be used with the system of FIG. 1.

DETAILED DESCRIPTION

[0015] Systems and methods in accordance with embodiments of the present invention can enable an application view to support local transactions against a resource adapter. An application view can provide a layer of abstraction between an adapter and Enterprise Information System (EIS) functions exposed by that adapter. Instead of accessing an EIS by direct programming, a user can simply edit the adapter's application views, create new application views, or delete obsolete application views. This layer of abstraction, formed by application views, helps non-programmers easily maintain services and events exposed by the adapter. Each application view can be adapter-specific, and can define a set of business functions on the adapter's EIS. Such application views can provide a view of the application capabilities exposed by an adapter.

[0016] As shown in the exemplary method of FIG. 2, if a client of an application view decides to open a local transaction against an Enterprise Information System (EIS), the application view can switch from a stateless session Enterprise JavaBean (EJB) to a stateful session EJB 200. Since the state that the application view holds is the connection itself, the application view can hold the same local transaction open across multiple service requests 202. A local transaction interface can allow a user to manage a local transaction in an application view 204, and can allow the user to switch the application view between a stateless session bean and a stateful session bean. A Common Client Interface (CCI) class can be used to expose a local transaction interface to a resource adapter client 206.

[0017] An example of one such system is shown in FIG. 1. As shown in the Figure, an integration adapter 110 can allow a user to browse documents or interfaces in an EIS system 100, such as an SAP system, through a Web browser 116. A resource adapter 114 can be used to send requests to, and receive requests from, the EIS 100. The resource adapter 114 can also be used to implement a connector specification 118. An event router 104, which can also be a Web application, can be used to route messages from the EIS 100 to an application view 108 for the application integration component 106.

[0018] 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 send the event to the event router 104. The event router 104 can send the event object to an instance of an application view 108 that is subscribed to the type of event object received from the event generator 102. The application view 108 receives the event object and can notify any listener 112 registered for that type of event. Listeners can include integration process flow or custom business logic flow, for example. A listener 112 can process the event object and determine whether a service should be invoked in response to the event.

[0019] If a local transaction needs to be opened against the EIS 100, the application view 108 can switch from a stateless session EJB to a stateful session EJB, such that the application view 108 instance can hold the connection with the EIS 100 as state. A transaction interface 128 can manage the transaction for the application view 108. 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.

[0020] An integration adapter 110, a resource adapter 114, and an event router 104 are three components that can conform to the J2EE standard. Since these components can be part of the same adapter, they can have many components shared between them. A class loader 122 can be used, such as from an application server 120, which can allow for the use of shared classes at the root of an Enterprise archive (EAR) file 124. An EAR file can be deployed from a server console 126.

[0021] Multiple actions against an EIS for a local transaction can be grouped into a logical unit of work. A customer can be unaware of any such grouping. If a customer needs to do local transaction work, the work can be interfaced with a stateful session EJB instead of a stateless session EJB.

[0022] A local transaction interface can be exposed to resource adapter clients through a Common Client Interface (CCI) connection class. Presently, the application view interface does not utilize the CCI local transaction interface. By adding the ability to manage a local transaction in the application view, there is no need to use two interfaces to process local transactions.

[0023] In order to retain some control over the use of a local transaction interface, the local transaction interface may not be directly exposed. Instead, the functionality of the local transaction can be provided on the application view interface. The application view can provide methods to support the use of local transactions, including methods such as begin( ), commit( ), and rollback( ). In order to provide a client with local transaction functionality, state can be provided in the application view bean. An application view bean can retain a connection for the duration of a single transaction. In order to provide state, the application view bean can be deployed as both a stateful and stateless bean. The client can manage which bean is used, based on calls to the transaction services.

[0024] A local transaction management contract can occur whenever an adapter implements a local transaction interface, such as a javax.resource.spi.LocalTransaction interface, to provide support for local transactions performed on the underlying resource manager. These contracts can enable an application server to provide the infrastructure and run-time environment for transaction management. Application components can rely on this transaction infrastructure to support their component-level transaction model.

[0025] The methods that are added to the application view interface to support local transactions do not need to be exposed to the user in an application integration (AI) Plug-in. There can be several approaches to supporting application view local transactions within an AI Plug-in.

[0026] In one such approach, a connector supports only local transactions with user-defined transaction demarcation. A connector supporting only local transactions can be similar to a TX_REQUIRES_NEW for EJB transactions.

[0027] One simple approach, from a user perspective, to supporting application view local transactions is to create a new plug-in action that performs a transaction method for a particular application view instance. In order to use the local transaction plug-in action, additional plug-in actions can be created. Specifically, additional actions can be created that can generate a new application view instance and invoke a service within the local transaction of an application view instance.

[0028] Since the demarcation of a local transaction can be represented as separate actions within business process management (BPM), the transaction that is active in BPM may need to be suspended when an application view local transaction ‘begin’ action is encountered. The BPM transaction can be resumed once a local transaction ‘commit’ or ‘rollback’ action is executed. While functionality can be added to the plug-in to reduce the amount of work for a user by catching exceptions between the begin and commit actions, and rolling back the transaction, the begin/suspend and commit/rollback/resume are separate actions in BPM and the potential for problems in user workflows that use application view local transactions increases dramatically. This could result in support problems, mainly due to migration.

[0029] In a second scenario, a connector supports only local transactions with transaction demarcation being more transparent and atomic. Such a scenario can be similar to a TX_REQUIRES_NEW for EJB transactions. This scenario can require the development of a base class to perform certain functions. These functions can include suspending a BPM transaction, caching an application view instance for use by user code, and invoking the user's implementation of an abstract method. Other functions can include catching any exceptions from the user's implementation and performing a rollback on the application view instance, then resuming the BPM transaction. On a normal return from the user's implementation, a commit can also be performed on the application view local transaction and the BPM transaction resumed.

[0030] In another scenario, a connector supports only local transactions with no user-defined transaction demarcation. Once again, this scenario is similar to a TX_REQUIRES_NEW for EJB transactions because the connector can only support local transactions. In this scenario, the BPM designer does not explicitly demarcate the start and end of a local transaction. The system can allow the connector to participate in the global transaction by providing an XA wrapper around the local transaction object. The XA wrapper can no-opt all methods on the XAResource interface that cannot be delegated to the local transaction instance. The system can allow only one non-XA resource in the transaction chain. A user can then only have one application view local transaction within a workflow.

[0031] In another scenario, a connector can support XA transactions. In this case, there may be no support for calling application view services within a local transaction. Each service invocation can automatically be enlisted into the global XA transaction because the resource adapter supports XA.

[0032] An XA resource-based contract can occur between a transaction manager and a resource manager in a distributed transaction processing (DTP) environment. An “XAResource” interface can be a Java mapping of an industry standard XA interface. Such an interface can be used with a javax.transaction.xa package, which can provide an API to define the contract between the transaction manager and the resource manager. This contract can allow the transaction manager to enlist and delist resource objects, which can be supplied by the resource manager driver, in Java Transaction API (JTA) transactions. A driver vendor for a specific resource manager can provide the implementation of this API. A JDBC driver or JMS provider can implement this interface to support an association between a global transaction and a database or message service connection. An XAResource interface can be supported by any transactional resource intended for use by application programs. This can be accomplished in an environment where transactions are controlled by an external transaction manager. An example of such an environment includes a database management system where an application accesses data through multiple database connections. Each database connection is enlisted with the transaction manager as a transactional resource. The transaction manager obtains an XAResource for each connection participating in a global transaction. The transaction manager uses a start( ) method to associate the global transaction with the resource. The transaction manager uses an end( ) method to disassociate the transaction from the resource. The resource manager can associate the global transaction to all work performed on its data between the start( ) and end( ) method invocation.

[0033] At transaction commit time, the transaction manager can inform the resource managers to prepare, commit, or rollback a transaction according to the two-phase commit protocol.

[0034] 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.

Claims

1. A system for supporting a local transaction with an application view, comprising: an application view capable of switching from a stateless session bean to a stateful session bean in order to open a connection for a local transaction, the stateful session bean capable of holding the connection open across multiple requests in the local transaction; and a local transaction interface allowing a user to manage the local transaction in the application view.

2. A system according to claim 1, further comprising: a Common Client Interface class through which the local transaction interface can be exposed to a resource adapter client.

3. A system according to claim 1, wherein: the application view maintains the connection open for the duration of the local transaction.

4. A system according to claim 1, wherein: the local transaction interface further allows a user to switch the application view between a stateless session bean and a stateful session bean.

5. A system according to claim 1, wherein: the application view is capable of opening a database connection for a local transaction.

6. A system according to claim 1, further comprising: a transaction manager adapted to obtain a resource for any connection open for a local transaction.

7. A system according to claim 1, wherein: the local transaction interface further contains a local transaction management contract.

8. A system according to claim 1, wherein: the local transaction interface further contains a local transaction management contract adapted to enable an application server to provide an infrastructure and run-time environment for management of the transaction.

9. A system according to claim 1, further comprising: a plug-in capable of performing a transaction method for the application view.

10. A system according to claim 1, further comprising: a plug-in capable of creating a new instance of the application view.

11. A system according to claim 1, further comprising: a plug-in capable of invoking a service within the local transaction.

12. A system according to claim 1, wherein: the application view is capable of opening a connection for a local transaction against an Enterprise Information System.

13. A system according to claim 1, wherein: the application view is capable of opening a connection for a local transaction against a resource adapter.

14. A method for supporting a local transaction with an application view, comprising: opening a connection for a local transaction by switching an application view from a stateless session bean to a stateful session bean, the stateful session bean capable of holding the connection open across multiple requests in the local transaction; and allowing a user to manage the local transaction in the application view through a local transaction interface.

15. A method according to claim 14, further comprising: holding the connection open for the duration of the local transaction.

16. A method according to claim 14, further comprising: exposing a local transaction interface to a resource adapter client.

17. A system for supporting a local transaction with an application view, comprising: means for opening a connection for a local transaction by switching an application view from a stateless session bean to a stateful session bean, the stateful session bean capable of holding the connection open across multiple requests in the local transaction; and means for allowing a user to manage the local transaction in the application view through a local transaction interface.

18. A computer-readable medium, comprising: means for opening a connection for a local transaction by switching an application view from a stateless session bean to a stateful session bean, the stateful session bean capable of holding the connection open across multiple requests in the local transaction; and means for allowing a user to manage the local transaction in the application view through a local transaction interface.

19. A computer program product for execution by a server computer for supporting a local transaction with an application view, comprising: computer code for opening a connection for a local transaction by switching an application view from a stateless session bean to a stateful session bean, the stateful session bean capable of holding the connection open across multiple requests in the local transaction; and computer code for allowing a user to manage the local transaction in the application view through a local transaction interface.

20. A computer system comprising: a processor; object code executed by said processor, said object code configured to: open a connection for a local transaction by switching an application view from a stateless session bean to a stateful session bean, the stateful session bean capable of holding the connection open across multiple requests in the local transaction; and allow a user to manage the local transaction in the application view through a local transaction interface.

21. A computer data signal embodied in a transmission medium, comprising: a code segment including instructions to open a connection for a local transaction by switching an application view from a stateless session bean to a stateful session bean, the stateful session bean capable of holding the connection open across multiple requests in the local transaction; and a code segment including instructions to allow a user to manage the local transaction in the application view through a local transaction interface.