Abstract: Highly-available processing of an asynchronous request can be accomplished in a single transaction. A distributed request queue receives a service request from a client application or application view client. A service processor is deployed on each node of a cluster containing the distributed request queue. A service processor pulls the service request from the request queue and invokes the service for the request, such as to an enterprise information system. If that service processor fails, another service processor in the cluster can service the request. The service processor receives a service response from the invoked service and forwards the service response to a distributed response queue. The distributed response queue holds the service response until the response is retrieved for the client application.

Abstract: Highly-available processing of an asynchronous request can be accomplished in a single transaction. A distributed request queue receives a service request from a client application or application view client. A service processor is deployed on each node of a cluster containing the distributed request queue. A service processor pulls the service request from the request queue and invokes the service for the request, such as to an enterprise information system. If that service processor fails, another service processor in the cluster can service the request. The service processor receives a service response from the invoked service and forwards the service response to a distributed response queue. The distributed response queue holds the service response until the response is retrieved for the client application.

Abstract: High availability event forwarding can be obtained utilizing distributed queues in a server cluster. Each server can receive an event from a data system, such as a database or SAP™ system. Event queues exist oil servers in the cluster can store an event until, for example, the event is delivered to a user or retrieved for processing. An event processor examines the load of each event queue and selects tie event queue with the lightest load The event processor generates an alias for the selected queue, such that a user, integration system, or client application does not need to know the identity of the physical queue storing the event, but only needs to refer to the ‘distributed queue’ or alias. After a physical queue is selected and an alias assigned, the event is forwarded to the selected queue. This description is not intended to be a complete description of, or limit the scope of, the invention.

Abstract: 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 then may be necessary only if a Java archive file is added to the classpath for non-system domains. 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.

Abstract: High availability event forwarding can be obtained utilizing distributed queues in a server cluster. Each server can receive an event from a data system, such as a database or SAP™ system. Event queues exist on servers in the cluster can store an event until, for example, the event is delivered to a user or retrieved for processing. An event processor examines the load of each event queue and selects the event queue with the lightest load. The event processor generates an alias for the selected queue, such that a user, integration system, or client application does not need to know the identity of the physical queue storing the event, but only needs to refer to the ‘distributed queue’ or alias. After a physical queue is selected and an alias assigned, the event is forwarded to the selected queue. This description is not intended to be a complete description of, or limit the scope of, the invention.

Abstract: Communication can be passed between components, such as an enterprise system and a client application, by utilizing schemas. A schema can ensure that a communication, such as a request or response, is in the proper format for one of the components. For instance, metadata can be received from an enterprise system in response to a request from a client application. That metadata can be transformed into an XML document that conforms to an XML schema. At least portions of the XML document can be validated against the XML schema. Those portions can be queried using a document interface component, such as an XML document API, that provides a path interface to elements in an XML document. The XML document can be passed on to the client application after validation. This description is not intended to be a complete and accurate description of the invention or to limit the scope of the invention.

Abstract: An application view, or application view component, can represent a self-describing interface to functionality in a resource such as an application or enterprise system. An application view can abstract away much of the complexity in dealing with the application, such that non-programmers can maintain the services and events exposed by an adapter for that application. Application views can also simplify the way in which adapters are accessed, and can allow the functionality exposed by the adapter to be invoked as a business service. An application view can be specific to a single adapter, and can define a set of functions on the corresponding 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.

Abstract: Events are delivered to multiple topic subscribers using a single distributed event topic. An event generator can receive data for the event from an EIS and can generate an event object. An event queue stores the event object until the event is retrieved by an event processor, which publishes the event to each destination. One of these destinations, the distributed event topic, receives the published event from the event processor and handles the delivery of the event to any user subscribing to the event topic. Each subscriber can utilize a remote application view to invoke system functions in the EIS and receive messages from the information system on behalf of the subscriber. A user event queue can be used for each topic subscriber to store an event until the subscriber is capable of receiving the event.

Abstract: Systems that use application view components to allow a user to exploit functionality in an EIS can utilize a shareable connection factory. Instead of having a connection factory for each application view, a single connection factory can be used that is simply referenced by each application view. Users can then choose to associate an application view with any available connection factory on the system, or can choose to create a new connection factory that can be available to any other application view or resource adapter.

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.

Abstract: 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 then may be necessary only if a Java archive file is added to the classpath for non-system domains.

Abstract: Highly-available processing of an asynchronous request can be accomplished in a single transaction. A distributed request queue receives a service request from a client application or application view client. A service processor is deployed on each node of a cluster containing the distributed request queue. A service processor pulls the service request from the request queue and invokes the service for the request, such as to an enterprise information system. If that service processor fails, another service processor in the cluster can service the request. The service processor receives a service response from the invoked service and forwards the service response to a distributed response queue. The distributed response queue holds the service response until the response is retrieved for the client application.

Abstract: An adapter can be deployed into a system in a single step without recycle. An adapter can contain components, such as an integration adapter, event router, and resource adapter, which all conform to a given specification such that these components use some of the same classes. A class loader allows these components to share common classes, instead of having separate classes. A single Enterprise archive file contains files necessary to deploy the adapter, such as Web archive files, resource adapter archive files, event router Web application files, and shared Java archive files. The inclusion of these files in an Enterprise archive file allows all components for the adapter to be deployed in a single step without the need to recycle.

Abstract: An application view control can allow users of a software tool to interact with Enterprise applications using simple Java APIs. This can allow a user who is not an expert in the use of a given Enterprise system to utilize its capabilities in a manner a Java programmer can understand. A developer can invoke application view services both synchronously and asynchronously, and can subscribe to application view events. The developer can use simple Java objects in both the service and event cases. The developer need not understand XML, or the particular protocol or client API for the Enterprise application, such as an Enterprise Information System (EIS).

Abstract: High availability is obtained for the deployment and undeployment of application views by placing a redundant JMX server on each server in a cluster of servers for an application integration system. Each redundant JMX server can manage deployment work for the cluster, and is capable of sending a JMX notification to every other server in the cluster relating to the deployment work, such as a deploy, undeploy, or processing notification. While an administration server can manage the other servers in the cluster, the redundant JMX servers are capable of managing deployment work for the cluster in the event of a failure of the administration server.

Abstract: High availability event forwarding can be obtained utilizing distributed queues in a server cluster. Each server can receive an event from a data system, such as a database or SAP system. Event queues exist on servers in the cluster can store an event until, for example, the event is delivered to a user or retrieved for processing. An event processor examines the load of each event queue and selects the event queue with the lightest load. The event processor generates an alias for the selected queue, such that a user, integration system, or client application does not need to know the identity of the physical queue storing the event, but only needs to refer to the ‘distributed queue’ or alias. After a physical queue is selected and an alias assigned, the event is forwarded to the selected queue.

Abstract: Communication can be passed between components, such as an enterprise system and a client application, by utilizing schemas. A schema can ensure that a communication, such as a request or response, is in the proper format for one of the components. For instance, metadata can be received from an enterprise system in response to a request from a client application. That metadata can be transformed into an XML document that conforms to an XML schema, such as by an XML schema mechanism. At least portions of the XML document can be validated against the XML schema, such as by using a schema object model. The XML document can be passed on to the client application after validation.

Abstract: Communication can be passed between components, such as an enterprise system and a client application, by utilizing schemas. A schema can ensure that a communication, such as a request or response, is in the proper format for one of the components. For instance, metadata can be received from an enterprise system in response to a request from a client application. That metadata can be transformed into an XML document that conforms to an XML schema. At least portions of the XML document can be validated against the XML schema. Those portions can be queried using a document interface component, such as an XML document API, that provides a path interface to elements in an XML document. The XML document can be passed on to the client application after validation.

Abstract: A Java-based interface can be used to allow a Java client or application to access an application view component. An application view component can provide an interface to an application or enterprise system, using a resource adapter to expose functionality in the enterprise system. A Java-based interface for the resource adapter can allow the Java client to access the application view component. The interface can be a design-time graphical user interface, which can include a set of Java server pages and can be Web-based. The interface can allow a Java client to access the application view component in order to accomplish a task such as creating, defining, deploying, and testing the application view component. Each of these tasks can have their own page in the interface, such as a Java server page.

Abstract: An application view control can be added to a Web service to allow the Web service to make requests into a resource such as an enterprise system through an integration system. The integration system can include a resource adapter that can invoke functionality in the enterprise system, as well as an application view component that acts as an interface through which the functionality can be exposed to the application view control. The application view component can allow the Web service to accomplish tasks such as subscribing to application view events. A callback object can be used to notify a client of the Web service that an event has occurred in the underlying resource.