The present invention relates to ways of allowing users to interact with an Enterprise application.
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.
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' 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.
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.
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. To remove this complexity, businesses began developing and using adapters.
Adapters are software components that applications can use to programmatically access enterprise data. For example, an adapter can use a Java class to represent enterprise data, and can provide methods that applications can invoke to access the data. When an application invokes an access method, the adapter can execute the method to retrieve the enterprise data.
These integration systems, however, suffer from a lack of standards. Each integration vendor typically provides a proprietary solution for application adapters, 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 create adapters to their applications. Further, each of these integration servers has its own proprietary API for constructing adapters, so packaged application vendors cannot leverage the development of an adapter beyond a single integration server. This fragmentation of the integration market has provided little financial incentive for third parties to build adapters.
Application views were developed as a solution to this problem. An application view provides a layer of abstraction between an adapter and Enterprise Information System (EIS) functions exposed by that adapter. Instead of accessing an EIS by directly programming the EIS, a user can simply edit the application views for the adapter, create new application views, or delete obsolete application views. This layer of abstraction, formed by application views, makes it easy for non-programmers to maintain the services and events exposed by the adapter. Each application view is adapter-specific, and defines a set of business functions on the adapter's EIS. Such application views provide a view of the application capabilities exposed by an adapter. Presently, there is no analogous functionality for users of tools such Cajun, a Java 2 Enterprise Edition (J2EE)-based Web services development framework available from BEA Systems Inc. of San Jose, Calif., that can allow tool developers to easily interact with information systems.
An application view tool control can allow users of a software tool to interact with Enterprise applications using simple Java APIs. Such an approach can allow a user who is not an expert in the use of a given Enterprise system to utilize system capabilities in a manner a Java programmer can understand. An application view tool control, hereafter referred to as an application view control, can provide a way for a tool developer to invoke application view services both synchronously and asynchronously, and to subscribe to application view events. In both the service and event cases, the tool developer can use simple Java objects. The developer need not understand XML, or the particular protocol or client API for the Enterprise application, such as an Enterprise Information System (EIS). Systems and methods in accordance with embodiments of the present invention can allow tool developers, or non-EIS experts, to access Enterprise application functionality.
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 assist in system integration, such as between a client application and an Enterprise Information System. Such systems can take advantage of application views, and can provide an external software tool with access to application view services and events. Systems in accordance with one embodiment will be described using a Cajun environment, although many such environments can take advantage of aspects of the present invention. Generation tools, such as control wizards, can be used to guide a user through the process of developing an application view control. These tools can automate much of the generation process, generating the necessary objects and files for selections made by the user. For example, meaningful and/or useful classes can be generated to describe request, response, and event payload data structures for services, such as Web services. Schema definitions can be handled automatically, such that any application view defined in terms of an adapter can be imported into, and used within, the external environment. In certain environments, a conversational Java Web services (JWS) instance can be configured to listen for application view events and respond to those events via a callback method.
An exemplary integration system that can take advantage of embodiments in accordance with 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.
The event object message is stored in the event queue 222 until it is retrieved for processing by the AI event processor 220, which can process events in a first-in-first-out (FIFO) manner. It may not be enough to send a message to a distributed queue and expect the message to be received by a receiver of that distributed queue. There can be a receiver, or “QueueReceiver”, receiving or listening on each physical queue to which an event could be forwarded. Thus, an AI event processor can be deployed on all nodes in a cluster. Multiple event processor deployment can further prevent single points of failure.
The event processor 220 can forward the event to all registered event destinations 210, which in the Figure include a BPM event queue 212, an event topic 114, and a Cajun event processor 216. Event destinations can be added by posting a message to a notification topic 208 for application integration. For example, when an AI plug-in 200 for BPM is deployed, it can send an “addDestination” message to the notification topic to register the BPM event queue 212 as an event destination. The BPM event queue can be a distributed queue. A message published on the notification topic can have cluster-wide visibility. Each node in the cluster can have a singleton event destination manager 218 that is a durable subscriber to this topic. Thus, the message can be published to every event destination manager in the cluster.
The event processor can use a singleton event destination manager 218 to listen for add/remove event destination messages on the notification topic 208 to configure the list of event destinations 210. The event object message can be delivered to all registered event destinations in a single transaction, such as in a single Java Transaction API (JTA) user transaction. If a post to any event destination 210 fails, the event message can be rolled back to the distributed queue 222. The roll back can use the same alias, but can forward the event to a different physical queue in the cluster. If the event processor 220 receives a message such as one that has “getJMSRedelivered( )” true, the post can be tried again. If the retry fails, the message can be sent to an error queue, which can be a distributed queue for failed event and asynchronous service response messages.
If an AI plug-in 200 for BPM is deployed, the plug-in can add the BPM event queue 212 as an event destination during startup so that AI events are passed to a BPM workflow 202 for processing. If there are any registered application view event listeners 206, the event can be sent to an event topic 214 which will use event context 204 to establish a connection with the remote event listener 206 for the application view.
Application Views
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 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.
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.
An application view can be an integral part of an integration framework when used as an interface object. 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.
In one example, shown in
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 management component can be included that allows process engineers to define workflows, and allows application views to be invoked as business services. 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.
A Web services interface can also be used with an application view. A protocol such as SOAP can be used to invoke a Web service. Another protocol that may be used includes UDDI, a platform-independent, open framework for describing services, discovering businesses, and integrating business services using the Internet. A WSDL protocol can also be used which is an XML format for describing network services. A Web services layer can be provided on top of the application view so that any application view can be invoked as a Web service.
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. A user can also decide whether or not an application view should be deployed persistently. Persistent deployment means the application view can be redeployed whenever the application server is restarted.
Control Wizard
One such software tool for providing access to application view services and events is a control wizard, or application view control wizard. A control wizard can be, for example, a Cajun design-view wizard. One purpose for such a wizard is to guide a user through the process of creating a new instance of an application view control.
For example, as shown in the method of
Each run of the control wizard can identify a single application view definition, such as in an integration XML repository, and can generate a single JWI file representing that application view definition. A JWI file is a ‘standard’ Java file, except that the file contains annotations used to define a control. This process can be referred to as ‘importing’ an application view, such as for use in the Cajun environment.
A control wizard can be invoked in one embodiment when a user clicks on an ‘Application View Control’ button on a user interface (UI) toolbar. At the end of the wizard, a new icon can exist on an area of the design view that corresponds to the imported application view and the resultant application view control instance.
The control wizard can display a navigation tree that allows a user to navigate namespaces and application view definitions, similar to the way that an application integration (AI) plug-in does for BPM. Once a user has designated an application view definition as the import source for the control instance, the wizard can allow the user to select any number of services defined for the application view to be generated with asynchronous invocation support.
Since a model such as a Cajun model can be strongly-typed and early-bound, the choice of synchronous/asynchronous invocation can be made at design-time instead of being deferred to runtime. Any service the user chooses to make asynchronous can have both a call-in method and a callback method defined.
A control wizard can also provide a way for a user to ‘update’ a control instance with any new metadata contained in the application view that was originally imported to create the control instance. The user should be allowed to designate an existing control instance (such as through a pick-list or by name) or a new control instance as the target of the import/JWI generation. This can allow a user to iteratively import an application view to a control instance in the development phase of a Web service. If the user chooses to import to an existing control instance name, then the original contents of the JWI file for that control instance can be overwritten. A backup copy of the JWI can always be kept to prevent the loss of any customizations that may have been made to the JWI contents.
A control wizard can generate a JWI file that contains Java class definitions corresponding to schemas for all services (request/response) and events on the application view that was imported. The generated Java types can be used by the JWS developer when invoking methods and responding to callbacks within the JWS.
At dialog in the control wizard user interface can allow a user to specify the name of the control instance variable in the JWS, and the package name to use when generating the JWI file for the control. It can also allow a user to navigate the namespace/application view hierarchy in the AI repository and select an application view to be imported. Each time the selection changes, the application view and description fields can be updated with the information from the current selection. The description can help the user understand the purpose of the application view that is selected, and thus help the user make the correct decision about whether to import the application view.
A main dialog can also allow a user to specify a ‘Run as’ identity for a control. Services invoked via a generated JWI file can use the specified user name as their effective identity. The password can be passed to the JWI generator in clear text, but can be encrypted by the JWI generator before placing it into the generated JWI text.
A user can choose services to be imported as asynchronous methods in one embodiment by clicking an ‘Async Services . . . ’ button. This can pop up in an ‘Async Services’ dialog. Clicking ‘OK’ on this dialog can cause the generation of a JWI file for the ApplicationViewControl instance, as well as the creation of the JWS variable for the control.
For the main dialog, a navigation tree can be backed by a Namespace Navigation Facility. Such a facility can allow a user to list application views and namespaces within a namespace. The root of the tree can be populated by listing application views and namespaces in the root namespace, which can be specified by passing the namespaceName as the empty string.
The description can be obtained from the application view selected in the tree. Retrieving the application view's descriptor or metadata about an ApplicationView, such as by using a ‘Get ApplicationView’ command, can return the XML for the application view descriptor. The user can pass an ‘objectQName’ parameter as the qualified name of the application view. The user can generate this qualified name by composing the node names of all the nodes in the currently selected TreePath. For example, if the currently selected application view were named ‘baz’, and it lived inside a namespace called ‘bar’ (represented by a tree node with label ‘bar’), and bar lived inside a namespace called ‘foo’ (represented by a tree node with label ‘foo’), then the selected node would be represented by a TreePath object containing the sequence ‘foo’, ‘bar’, and ‘baz’. The qualified name ‘foo.bar.baz’ can be created by contatenating together each segment with a period or ‘dot’.
To get the description, a user can parse the XML descriptor for the application view. If this proves to be too cumbersome, Java archive (JAR) files such as xmltoolkit.jar and wlai-common.jar can be included to allow the user to use the an ApplicationViewDescriptor object that parses the XML for the user.
A dialog can be ‘popped up’ from the main wizard dialog when a user clicks ‘Async Services . . . ’ Such a dialog can allow the user to choose which services on the selected application view should be imported to be asynchronous. The user can choose any services that are to be imported as asynchronous. By default, all services can be imported as synchronous. Synchronous services can be represented by a control method having both input parameters and a non-void return type. Asynchronous services can be represented by a control method having input parameters and a void return type, as well as a callback method having input parameters matching the type that would have been returned if the service was imported as synchronous.
A services list can be populated by getting all the ‘service’ elements from the descriptor XML, and getting the ‘name’ attribute value from each. If an IApplicationViewDescriptor object is generated from the XML, such as may require xmltoolkit.jar and wlai-common.jar to be on the classpath, then the user can just call the ‘listServiceNames( )’ method on the IApplicationViewDescriptor object.
JWI Generation
An application view control can have a JWI generation facility. A servlet can be written to implement an HTTP interface to the JWI generation facility. Such a servlet can accept the information taken from the user during their interaction with the control wizard, and can return the generated JWI text. The servlet can interface with the JWI generation facility in the ApplicationViewControl.
A JWI Generation Servlet can be called, for example, ApplicationViewJWIGeneratorServlet, and can accept parameters such as the following in an HTTP request (both ‘get’ and ‘post’ can be supported):
The following signature can be called by an application view JWI generator servlet when a generation request is received. This can be when a user clicks the ‘OK’ button on the control wizard dialog, for example.
The following describes each parameter and where the data for each parameter can be retrieved:
A servlet interface can be provided to the namespace navigation features of a namespace manager, and the application view retrieval facilities of an application view manager. A ‘Ping’ command can allow a caller to verify the presence of a running AI engine within the target server and can be indicated by passing a ‘PING’ parameter in an HTTP query string. Ping can be used to verify that this servlet is alive in the server.
A ‘List ApplicationViews’ command can be indicated by passing a ‘NM_LIST_APPVIEWS’ parameter in the HTTP query string, such as:
This can list objects of application view type in the given namespace. Names may not include the name of the parent namespace. To form a qualified name, the name of the namespace passed in the namespaceName argument can be pre-pended. The command can return a comma-separated list of object names.
A ‘List Namespaces’ command can be indicated by passing a ‘NM_LIST_NAMESPACES’ parameter in the HTTP query string, such as:
This can list objects of Namespace type in the given namespace. Names do not include the name of the parent namespace. To form a qualified name, the name of the namespace passed in the namespaceName argument can be pre-pended.
A ‘Get ApplicationView’ command can be indicated by passing a ‘NM_GET_APPVIEW’ parameter in the HTTP query string, such as:
Schema Type to Java Type Mapping
When importing an application view using a control wizard, the wizard can automatically generate Java types corresponding to the request/response types for services and the payload types for events. These types can be generated based on the schema information associated with the service and events on the application views.
The generated Java type can contain fields for all element definitions at the root level of the schema, such as contained in the named root element definition within the schema. These fields can be derived from simple XML types or from complex XML types. In the case of complex XML types, a new Java type can be generated, and the generated field definition can have the generated Java type for that field. Thus, the generation of Java types from a schema can result in any number of Java class definitions, and thus a nested Java datatype.
All generated types can be inner classes of a container class representing the service request/response or event payload. The container class can be named according to the appropriate naming conventions. This can provide a guaranteed unique namespace for all generated Java types.
For example, given the following schema:
and assuming that the schema is associated with the response for the ‘GetSomeRows’ service. Java types such as the following could be generated:
The outer class can be named for the service and the act that it is the response from the service. The outer class can contain a single field, as the schema contains a single child element, but the field's type is not ‘Rows’, but rather ‘Row[ ]’. The type generation facility can detect parent elements that contain a single child with maxOccurs>1, and can treat the parent element as an array of the child's type.
The Row class can contain fields for all elements in the ‘Row’ element definition, and can be defined as an inner class of a GetSomeRowsResponse class. This can ensure that the Row class can be named according to the name in the schema without fear of name collisions, which might otherwise be the case if another service used a schema that contained a ‘Row’ element definition that differs from this one.
Generated Java types can implement java.io.Serializable. This can allow any generated Java type to be serialized to an ObjectOutputStream, and deserialized from an ObjectInputStream. Given the above Java type definitions, in order to retrieve the IntField value from the first Row object in a response object of the above type, a user could write the following code.
Types
A single top-level type can be generated to represent the schema for a service request. The generated Java type can be named according to the following pattern:
<service name>Request
Another possible naming convention would use the root element name or the schema name. However, both these approaches have their problems. In general, the schema name might contain information about the application view and service for which it was defined. This information may not be not terribly useful or readable in the context of the JWI definition. The root element name may not be guaranteed to be unique among all root element names for all service request/responses and event payload types in the application view. Thus using the root element name could lead to name collisions in the generated JWI file. Because the service name is guaranteed to be unique within an application view, this name can be used to qualify the name of the generated Java type.
A single type can be generated to represent the schema for a service response. The generated Java type can be named according to the following pattern:
<service name>Response
A single type can be generated to represent the schema for an event. The generated Java type can be named according to the following pattern:
<event name>Event
Invoke Service Synchronously
Given an application view control instance, such as may be represented by a JWI file with the same name as the application view control instance type name, a JWS developer can invoke an application view service using a single simple Java method taking and/or returning simple Java objects. These objects can represent the data structures required by the service and described by the schemas for request/response on the service. The JWI file can contain sufficient information in any generated types to support the generation of useful JavaDoc pages. Such JavaDoc information can be gleaned from the service names and descriptions, and any documentation elements in the request/response schemas.
When the method representing a synchronous service is invoked, the caller can block until the method returns and the response data is available. Any exceptions thrown from the underlying invocation of the service can be thrown as-is back from the method representing the service. No wrapping of exceptions may be performed by the application view control.
The control wizard can generate a method declaration for each service, not designated as async, on the application view. The generated method can have the following signature:
Here, <return type> represents a generated Java type corresponding to the <response schema+root element name> for the service, and <input arguments> represents the generated Java type(s) for the <request schema+root element name> for the service. The @jws:av-request and @jws:av-response JavaDoc annotations can be used to control how Java types are mapped to XML for input to the service, and how XML output from the service is mapped to Java types, respectively.
The input argument list can represent the fields of the generated request Javatype. This effectively ‘unwraps’ the request type, making it easier for the user to invoke the JWI method representing a service because variables only need to be created for the request fields, and not the request itself. This can be particularly useful in cases where the generated request type contains a small number of fields. Without unwrapping, the user could have to create a wrapper object, and then set its few fields before passing the wrapper object into the JWI service method. With unwrapping, the user can simply pass these field values directly into the JWI service method.
Invoke Service Asynchronously
To invoke a service asynchronously, a user can designate the service to be invoked asynchronously, such as at design-time while importing the application view. This can cause the control wizard to generate code for both a call-in and a callback method in the JWI. The call-in method can have the following signature:
The @jws:service async=“true ” JavaDoc annotation can be required to indicate that this method represents an async service invocation. Without this, there may be no way to distinguish an async service method from a service method that returned a single String value. The @jws:av-request JavaDoc annotation can be used to control how Java types are mapped to XML for input to the service.
When a call-in method is invoked, the request can be enqueued, and the call can return without actually servicing the request. Instead, an identifier representing the enqueued request can be returned that allows the correlation of request to response when the response is actually returned, such as by the callback method. This request identifier is a String object. At a later time, such as may be subject to server load, the number of threads processing async requests, and the amount of time required for the EIS to process the request, the response can be made available to the JWS instance via its implementation of the callback method. The callback method can have the following signature and can be defined in the JWI's Callback interface:
The requestID parameter to the callback can give the identifier for the request caused this response. The <output argument> parameters can represent the response data from the async service invocation, and can be dependent on the response schema for the service. The @jws.av-async-response JavaDoc annotation can be used to control hor XML output from the service is mapped to Java types.
In order for a JWS instance to receive this callback, it can implement a method with the following signature:
Here, <control instance name> is the name of the variable that holds the reference to the control instance in the JWS file. For example, an application view can be imported based on the database adapter that handles customers (e.g. CustomerMgmt). This can result in the generation of a CustomerMgmt.jwi file. Assuming services to create/update/delete customers named CreateCustomer, UpdateCustomer, DeleteCustomer, respectively, and assuming that the JellyBeans design-time user designated the UpdateCustomer service as async as the user imported the ApplicationView, the JWI file could look like this:
The JWS instance can be in conversational mode before invoking a method representing an async service on an application view control instance. This can be required in certain systems where something is around after the initial request call returns in order to receive the response at a later date. In non-conversational JWS instances, no state may be maintained between method invocations, and thus no state may be available to assist in the processing of the async response. In conversation mode, the response can be routed back to the proper JWS/control instance such that the appropriate state can be used to process the response (i.e. the state, or a descendent of the state, that was present when the async request was made).
The async request can be entered by calling an ApplicationView.invokeServiceAsync( ) method with a ServiceHandle instance, and a specific response queue (CAJUN_ASYNC_RESPONSE_QUEUE). An ApplicationViewBean implementation can attach the ServiceHandle instance representing the JWS instance to the async request, and the async request processor can replicate the ServiceHandle into the async response. The async response can be retrieved by a message driven bean (MDB) listening on the CAJUN_ASYNC_RESPONSE_QUEUE queue. This MDB can retrieve the ServiceHandle from the response message, and route the response by calling ServiceHandle.invoke( ).
The ability of async responses to survive a server crash/restart can be directly predicated on the ASYNC_REQUEST and WLAI_ASYNC_RESPONSE queues being managed by a JMS server running in persistent mode. The MDB can always be up and listening to the response queue, so as long as the responses arrive/remain on the queue, the response can be routed to the JWS instance that made the request.
A CAJUN_SYNC_RESPONSE_QUEUE can be a distributed queue with multiple physical destinations. When a response is enqueued to the response queue, it can be sent to a single physical destination. The MDB deployment listens on a single physical destination, even though it can establish its connection by specifying a distributed destination. Thus, a single MDB deployment can receive the response and receive it exactly once.
Multiple async requests could be pending for a given JWS conversation instance at any given time. This means that multiple responses may be ready to dispatch to the JWS conversation instance at any given time. An entity EJB locking mechanism can be relied upon to ensure that only one response is dispatched to the entity EJB at a time.
Listen for Event in Existing Conversation
A JWS instance can be in conversation mode in order to listen for and receive events. This means that a JWS method marked as @jws:conversation phase=“start” can have been invoked prior to attempting to receive events. To receive events, a JWS instance can indicate its desire to receive events, such as by invoking an enableEventDelivery( ) method on the application view control instance from which it wishes to receive events. After such a call, callback methods corresponding to events of given types can be invoked. To stop receiving events, a JWS instance can invoke the disableEventDelivery( ) method on the ApplicationView control instance.
Events can be delivered via a callback method. The signature of the callback method (within the application view control JWI file) can be of the form:
The @jws:av-event JavaDoc annotation can be used to control how the event payload XML is mapped to the Java types represented in the callback signature.
The callback method can be implemented in the JWS and can conform to the standard Cajun control callback naming scheme (<control instance name>_<callback name>). So in this case:
The application view control can manage the subscription for events upon receiving a call to the enableEventDelivery( ) method, and can unsubscribe for events upon receiving a call to the disableEventDelivery( ) method. In general, JWS developers can call enableEventDelivery( ) from a conversation start JWS operation, or from an operation that is guaranteed to be called within a conversation, and can call disableEventDelivery( ) before the conversation ends.
A JWS developer can use the event listening features in many ways. One typical example would be of a JWS that acts as a ‘daemon’ service that handles synchronizing data records from one system to another. The JWS can be ‘triggered’ to start listening for events via a JWS operation, and can stop listening for events via another JWS operation.
Between ‘start listening’ and ‘stop listening’ operation calls, a JWS can process any incoming events according to business logic coded in the event callback methods or utility methods on the JWS. Such processing can make use of any state accumulated into the JWS conversation instance. Given this, it can be possible for a JWS implementation to ‘parameterize’ its processing of events by parameters passed into the ‘start listening’ operation.
As an example of this type of JWS usage, a use case can be described in which a user wishes to synchronize a customer database in a customer relationship management (CRM) system with multiple legacy customer databases. The legacy customer databases can contain customers meeting different criteria. For the sake of example it can be assumed that LegacyEast only contains customers that live in the eastern part of the United States. LegacyWest only contains customers that live in the western part of the United States. The CRM database contains customers from both the eastern and western parts of the United States.
An example JWS can be intended to synchronize changes in the CRM database into the appropriate legacy database (LegacyEast or LegacyWest). There can be an application view defined for each database and named <db name>AppView. Each application view can have a CreateCustomer, DeleteCustomer, and UpdateCustomer service. Each of these application views can be imported via the application view control wizard, and can have a JWI file representing each one. The JWI class names can match the names of the ApplicationViews (i.e. <db name>AppView).
Given these descriptions, a JWS could be written that looks like the following:
A user of this JWS could then call ‘startListening( )’ and pass a longitude somewhere in the middle of the United States. From this point, until no more synchronization is desired, the JWS, or its single conversational instance, could continue to synchronize customers between the CRM database and LegacyEast/LegacyWest databases.
If a JWS developer wants to allow for better parallelism, the developer can define ‘startListening( )’ to take a range of longitudes. The JWS conversation instance could then only handle the creation of customers only when the customer's longitude fell within the given range. In this way, the JWS user could call startListening with multiple discrete longitude ranges, and get parallel synchronization of customers from multiple JWS conversation instances.
Application views may not explicitly provide for event filtering based on payload content. Each independent JWS conversation instance mentioned above could receive a copy of the event, and they could discard it if it did not meet the filter criteria. The event delivery mechanism for the application view control (ApplicationViewControl) can be directly invocable from an MDB onMessage( ) callback. This can allow an AI event processing MDB to directly dispatch the event to Cajun without the need for an intervening send/publish to another destination.
The event delivery mechanism can store event>watch=information that will control the routing of events off the AI event queue into JWS conversation instances. This event watch info can include a mapping from event type to Cajun ServiceHandle, that can identify the JWS/conversation/control instance identity, and can be persistently stored to a database.
Upon initialization, the event delivery mechanism can read stored event watch information and prepare to route events based on those event watches. As new event watches are added, they too can be persisted to the event watch store, such as to a single table in the database.
This implementation can allow event subscription information and associations with JWS instances to survive server crashes/restarts. A system entity EJB locking mechanism can be relied upon to handle concurrency issues with dispatching multiple events from different nodes in a cluster to the same conversation instance.
JavaDoc Tag Reference
In addition, a user object value can be included in the AsyncServiceRequest object created to represent this request, and can be transferred to the AsyncServiceResponse object that will result from this request. The user object can be retrieved from the AsyncServiceResponse object thus:
public Serializable getUserObject( )
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 relevant arts. 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 claims and their equivalence.
This application is a continuation of U.S. patent application Ser. No, 10/409,753 entitled “System and Method for Enterprise Application Interactions,” (now U.S. Pat. No. 7,350,184) filed Apr. 9, 2003, which claims the benefit of US Provisional Patent Application No. 60/377,306, filed May 2, 2002. 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 following applications are cross-referenced and incorporated herein by reference: U.S. patent application Ser. No. 7,493,628 entitled “Shared Common Connection Factory,” by Timothy Potter et al., issued Feb. 17, 2009. U.S. patent application Ser. No. 7,484,224 entitled “Adapter Deployment Without Recycle,” by Timothy Potter et al., issued Jan. 27, 2009. U.S. Pat. No. 7,165,249 entitled “System and Methods for Modular Component Deployment,” by Timothy Potter et al., issued Jan. 16, 2007. U.S. Pat. No. 7,080,092 entitled “Application View Component for System Integration,” by Mitch Upton et al., issued Jul. 18, 2006. U.S. patent application Ser. No. 7,676,538 entitled “Systems and Methods for Application View Transactions,” by Tim Potter et al., issued Mar. 9, 2010.
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 | Nov 1998 | A |
5862327 | Kwang et al. | Jan 1999 | A |
5867822 | Sankar | Feb 1999 | A |
5933838 | Lomet | Aug 1999 | A |
5950010 | Hesse et al. | Sep 1999 | A |
5961593 | Gabber et al. | Oct 1999 | A |
5966535 | Benedikt et al. | Oct 1999 | A |
6012083 | Savitzky et al. | Jan 2000 | A |
6023722 | Colyer | Feb 2000 | A |
6028997 | Leymann et al. | Feb 2000 | A |
6029000 | Woolsey et al. | Feb 2000 | A |
6044217 | Brealy et al. | Mar 2000 | A |
6067548 | Cheng | May 2000 | A |
6067623 | Blakely et al. | May 2000 | A |
6070184 | Blount et al. | May 2000 | A |
6085030 | Whitehead et al. | Jul 2000 | A |
6092102 | Wagner | Jul 2000 | A |
6119149 | Notani | Sep 2000 | A |
6141686 | Jackowski et al. | Oct 2000 | A |
6141701 | Whitney | Oct 2000 | A |
6148336 | Thomas et al. | Nov 2000 | A |
6185734 | Saboff et al. | Feb 2001 | B1 |
6212546 | Starkovich et al. | Apr 2001 | B1 |
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 |
6243737 | Flanagan et al. | Jun 2001 | B1 |
6282711 | Halpern et al. | Aug 2001 | B1 |
6292932 | Baisley et al. | Sep 2001 | B1 |
6292933 | Bahrs et al. | Sep 2001 | B1 |
6324681 | Sebesta et al. | Nov 2001 | B1 |
6330569 | Baisley et al. | Dec 2001 | B1 |
6336122 | Lee et al. | Jan 2002 | B1 |
6338064 | Ault et al. | Jan 2002 | B1 |
6343265 | Glebov et al. | Jan 2002 | B1 |
6349408 | Smith | Feb 2002 | B1 |
6353923 | Bogle et al. | Mar 2002 | B1 |
6367068 | Vaidyanathan et al. | Apr 2002 | B1 |
6377939 | Young | Apr 2002 | B1 |
6393605 | Loomans | May 2002 | B1 |
6408311 | Baisley et al. | Jun 2002 | B1 |
6411698 | Bauer et al. | Jun 2002 | B1 |
6445711 | Scheel et al. | Sep 2002 | B1 |
6463503 | Jones et al. | Oct 2002 | B1 |
6549949 | Bowman-Amuah | Apr 2003 | B1 |
6560636 | Cohen et al. | May 2003 | B2 |
6560769 | Moore et al. | May 2003 | B1 |
6567738 | Gopp et al. | May 2003 | B2 |
6594693 | Borwankar | Jul 2003 | B1 |
6594700 | Graham et al. | Jul 2003 | B1 |
6604198 | Beckman et al. | Aug 2003 | B1 |
6643652 | Helgeson et al. | Nov 2003 | B2 |
6662357 | Bowman-Amuah | Dec 2003 | B1 |
6678518 | Eerola | Jan 2004 | B2 |
6687702 | Vaitheeswaran et al. | Feb 2004 | B2 |
6687848 | Najmi | Feb 2004 | B1 |
6721740 | Skinner et al. | Apr 2004 | B1 |
6721779 | Maffeis | Apr 2004 | B1 |
6732237 | Jacobs et al. | May 2004 | B1 |
6748420 | Quatrano et al. | Jun 2004 | B1 |
6757689 | Battas et al. | Jun 2004 | B2 |
6795967 | Evans et al. | Sep 2004 | B1 |
6802000 | Greene et al. | Oct 2004 | B1 |
6804686 | Stone et al. | Oct 2004 | B1 |
6832238 | Sharma et al. | Dec 2004 | B1 |
6836883 | Abrams et al. | Dec 2004 | B1 |
6847981 | Song et al. | Jan 2005 | B2 |
6850979 | Saulpaugh et al. | Feb 2005 | B1 |
6859180 | Rivera | Feb 2005 | B1 |
6889244 | Gaither et al. | May 2005 | B1 |
6915519 | Williamson et al. | Jul 2005 | B2 |
6918084 | Slaughter et al. | Jul 2005 | B1 |
6922827 | Vasilik et al. | Jul 2005 | B2 |
6959307 | Apte | Oct 2005 | B2 |
6963914 | Breitbart et al. | Nov 2005 | B1 |
6976086 | Sadeghi et al. | Dec 2005 | B2 |
6996800 | Lucassen et al. | Feb 2006 | B2 |
7027997 | Robinson et al. | Apr 2006 | B1 |
7043722 | Bau, III | May 2006 | B2 |
7051072 | Stewart et al. | May 2006 | B2 |
7054858 | Sutherland | May 2006 | B2 |
7072934 | Helgeson et al. | Jul 2006 | B2 |
7073167 | Iwashita | Jul 2006 | B2 |
7076772 | Zatloukal | Jul 2006 | B2 |
7089584 | Sharma | Aug 2006 | B1 |
7107578 | Alpern | Sep 2006 | B1 |
7117504 | Smith et al. | Oct 2006 | B2 |
7127704 | Van De Vanter et al. | Oct 2006 | B2 |
7155705 | Hershberg et al. | Dec 2006 | B1 |
7165041 | Guheen et al. | Jan 2007 | B1 |
7181731 | Pace et al. | Feb 2007 | B2 |
7260599 | Bauch et al. | Aug 2007 | B2 |
7260818 | Iterum et al. | Aug 2007 | B1 |
7350184 | Upton | Mar 2008 | B2 |
7584473 | Forin et al. | Sep 2009 | B2 |
20020004848 | Sudarshan et al. | Jan 2002 | A1 |
20020010781 | Tuatini | Jan 2002 | A1 |
20020010803 | Oberstein et al. | Jan 2002 | A1 |
20020016759 | Macready et al. | Feb 2002 | A1 |
20020049788 | Lipkin et al. | Apr 2002 | A1 |
20020073080 | Lipkin | Jun 2002 | A1 |
20020073236 | Helgeson et al. | Jun 2002 | A1 |
20020078365 | Burnett et al. | Jun 2002 | A1 |
20020083075 | Brummel et al. | Jun 2002 | A1 |
20020116454 | Dyla et al. | Aug 2002 | A1 |
20020120685 | Srivastava et al. | Aug 2002 | A1 |
20020152106 | Stoxen et al. | Oct 2002 | A1 |
20020165936 | Alston et al. | Nov 2002 | A1 |
20020169644 | Greene | Nov 2002 | A1 |
20020174178 | Stawikowski | Nov 2002 | A1 |
20020174241 | Beged-Dov et al. | Nov 2002 | A1 |
20020184610 | Chong et al. | Dec 2002 | A1 |
20020188486 | Gil et al. | Dec 2002 | A1 |
20020194267 | Flesner et al. | Dec 2002 | A1 |
20020194495 | Gladstone et al. | Dec 2002 | A1 |
20030004746 | Kheirolomoom et al. | Jan 2003 | A1 |
20030005181 | Bau et al. | Jan 2003 | A1 |
20030014439 | Boughannam | Jan 2003 | A1 |
20030018665 | Dovin et al. | Jan 2003 | A1 |
20030018963 | Ashworth et al. | Jan 2003 | A1 |
20030023957 | Bau, III et al. | Jan 2003 | A1 |
20030028364 | Chan et al. | Feb 2003 | A1 |
20030041198 | Exton et al. | Feb 2003 | A1 |
20030043191 | Tinsley et al. | Mar 2003 | A1 |
20030046266 | Mullins et al. | Mar 2003 | A1 |
20030055868 | Fletcher et al. | Mar 2003 | A1 |
20030055878 | Fletcher et al. | Mar 2003 | A1 |
20030074217 | Beisiegel et al. | Apr 2003 | A1 |
20030084203 | Yoshida et al. | May 2003 | A1 |
20030110117 | Saidenberg et al. | Jun 2003 | A1 |
20030110446 | Nemer | Jun 2003 | A1 |
20030126136 | Omoigui | Jul 2003 | A1 |
20030149791 | Kane et al. | Aug 2003 | A1 |
20030167358 | Marvin et al. | Sep 2003 | A1 |
20030196168 | Hu | Oct 2003 | A1 |
20030233631 | Curry et al. | Dec 2003 | A1 |
20040019645 | Goodman et al. | Jan 2004 | A1 |
20040068568 | Griffin et al. | Apr 2004 | A1 |
20040103406 | Patel | May 2004 | A1 |
20040133660 | Junghuber et al. | Jul 2004 | A1 |
20040148336 | Hubbard et al. | Jul 2004 | A1 |
20040204976 | Oyama et al. | Oct 2004 | A1 |
20040216086 | Bau | Oct 2004 | A1 |
20040225995 | Marvin et al. | Nov 2004 | A1 |
20040260715 | Mongeon et al. | Dec 2004 | A1 |
20060206856 | Breeden et al. | Sep 2006 | A1 |
Number | Date | Country |
---|---|---|
0190884 | Nov 2001 | WO |
Number | Date | Country | |
---|---|---|---|
20070234371 A1 | Oct 2007 | US |
Number | Date | Country | |
---|---|---|---|
60377306 | May 2002 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 10409753 | Apr 2003 | US |
Child | 11758594 | US |