Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/46—Multiprogramming arrangements
  • G06F9/54—Interprogram communication
  • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications

Definitions

• the invention relates generally to components useful for integrating applications.
• the first attempts at application integration were primarily focused on low-level implementation details such as the format ofthe 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.
• a resource adapter can be used to invoke functionality in a first application and expose that functionality.
• An application view component can be used to provide a way for a second application to access the first application, and/or the invoked functionality, through the resource adapter.
• the application view component can allow the second application to access the first application without the second application knowing functional details about the first application.
• the application view component can allow bidirectional communication between the first application and the second application, and can translate messages between the applications.
• FIG. 1 is a diagram of an integration system that can be used in accordance with one embodiment of the present invention.
• Figure 2 is a flowchart showing a method for creating and deploying an application view that can be used in the system of Figure 1.
• Figures 3(a) and 3(b) show computer systems communicating with and without a common protocol.
• Figure 4 shows a client using application views to make request into various systems.
• Figure 5 is a flowchart showing the lifecycle of an application view component that can be used in the system of Figure 1.
• Figure 6 is a diagram showing a system for integrating Siebel and SAP systems in accordance with one embodiment ofthe present invention.
• Application integration components can be used to integrate a variety of applications and systems, such as Enterprise Information Systems (EISs).
• EISs Enterprise Information Systems
• IT Information technology
• IT Information technology
• Application integration can utilize adapters to establish an enterprise-wide, united framework for integrating any current or future application.
• Adapters can simplify integration efforts by allowing each application to be integrated with an application server, instead of requiring that each application being integrated with every other application.
• J2EE Java 2 Platform, Enterprise Edition
• XML extensible Markup Language
• Connector architecture provides a standardized approach for the development of adapters for all types of applications, from legacy mainframe applications, such as CICS from IBM, to packaged applications such as PeopIeSoft, Siebel, and SAP.
• legacy mainframe applications such as CICS from IBM
• packaged applications such as PeopIeSoft, Siebel, and SAP.
• the adoption of such standards enables businesses to develop adapters that work on any J2EE-compliant application server, for example.
• Application integration can build on this standardized approach in an application integration framework by providing a standardsrbased architecture for hosting J2EE Connector architecture-based adapters. Developers can build J2EE Connector architecture-compliant adapters and deploy these adapters, in the integration framework, to connect enterprise applications to an application server.
• An application view can provide a simple, self- describing, consistent interface to services and events in an application.
• Application views can make use of an adapter for an EIS, making it possible to expose existing information systems as business services. Unlike adapters, however, an application view does not require users to have intimate knowledge ofthe EIS or the client interface forthat EIS, such that non-programmers or technical analysts can use application views.
• An application view can provide a business-oriented way for business analysts to access enterprise data without worrying about the programmatic details defined in an adapter. These same users may be otherwise unable to use an adapter directly, due to a lack of familiarity with the EIS.
• An application integration component directed at enterprise application integration can have several primary aspects. If the functionality of an EIS such as a PeopIeSoft system or an SAP system is to be invoked, an implementation ofthe J2EE Connector Architecture can be used. If something occurs inside an EIS system, such as a trigger going off, an event can be generated. This event may, in some embodiments, need to be communicated to an external application. An event architecture in an application integration component can handle this communication.
• An application view can provide significant value to an application integration component.
• An application view can abstract away much ofthe complexity in dealing with an application, such as a backend EIS system.
• Application views can also simplify the way in which adapters are accessed.
• Application views can provide a layer of abstraction, for example, between an adapter and the EIS functions exposed by that adapter. Instead of accessing an EIS by direct programming a user can simply edit an adapter's application views, create new application views, or delete any obsolete application view(s).
• a layer of abstraction formed by application views can help non-programmers maintain the services and events exposed by an adapter.
• Each application view can be specific to a single adapter, and can define a set of business functions on that adapter's EIS. After an adapter is created, a Web-based interface for the adapter can be used to define application views.
• 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. Bidirectional 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.
• 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.
• adapters 106, 108, 110 can be developed that allow a client application 100 to communicate with an Enterprise Information System 104 through the use of an application view 102.
• a developer can begin by coding an adapter that exposes the functionality in the enterprise application that accesses enterprise data.
• the functionality the adapter exposes could, for example, update records in a database using SQL statements, or could request information from an
• SAP system using its BAPI or I DOC interfaces.
• a business analyst working with the developer, can then define an application view of the adapter using an application view interface.
• An application view is an object, which can be implemented in one embodiment as a stateless session JavaBean.
• a Java application can be custom coded to use that object, such as by passing XML in and receiving XML back.
• a business process management component can be included that allows process engineers to define workflows, and allows application views to be invoked as business sen/ices. 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 sen/ice.
• Another protocol that may be used includes UDDI, a platform-independent, open frameworkfordescribing services, discovering businesses, and integrating business sen/ices using the Internet.
• a WSDL protocol can also be used, which is an XML format for describing network services .
• a web sen/ices layer can be provided on top of the application view so that any application view can be invoked as a web service.
• 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.
• Application integration can utilize an integration framework, which can provide a systematic, standards-based architecture for hosting application views.
• a framework can include application views for exposing application functions and design-time graphical user interfaces (GUIs), such as web-based interfaces that can be used for creating application views.
• GUIs design-time graphical user interfaces
• the integration framework utilizes adapters, instead of "hardwiring" enterprise systems together. Once an adapter is deployed for an EIS, other components and applications can use that adapter to access data on the EIS.
• a framework in accordance with one embodiment of the present invention relies on XML as the standard format for messages.
• XML includes XSLT, a standard for transforming XML documents into other XML documents.
• XSLT is designed for use as part of XSL, which is a stylesheet language for XML.
• XSL a stylesheet language for XML.
• an XML document is used to specify the operations to perform on a class of XML documents in order to transform the documents' structure and content.
• An XSLT transformation can make use of any of the operations built into the Java programming language, or can make use of custom operations written either in Java or in native code.
• An integration framework allows a business process to invoke an XSLT engine in order to transform XML messages.
• JMS Java Message Service
• HTTPS HyperText Transfer Protocol Secure
• An integration framework can be based on an existing standard infrastructure, such as an application serverthat supports J2EE, JMS, and the J2EE Connector architecture. Using such a standard infrastructure also provides for high availability and scalability, such as by clustering and resource pooling.
• the framework can provide for universal connectivity by enabling the construction of XML-based application adapters that can connect to any legacy and packaged application.
• An adapter development kit can be used to allow users such as customers, system integrators, and packaged application vendors to quickly develop J2EE connector architecture-compliant and integration framework-based adapters.
• the framework can utilize XML, which means that the same data format can be used for both within- and between-enterphse integration, since many e- commerce systems use XML as the standard message format.
• An integration framework can also utilize a business-process engine to allow non-programmers to graphically construct and maintain business processes.
• An integration framework can implement a common model on top of the J2EE Connector architecture that is focused on business-level concepts. This model, which can consist of XML-encoded events and services, allows the management of a consistent integration environment, regardless of the interface required between adapters and their target applications.
• the business processes can react to events generated by applications, and they can invoke an application's functionality via services that are exposed by an application adapter.
• an application view can provide an abstraction layer between the technical implementation of an adapter and the usage of the capabilities exposed by the adapter, as an application view can be a standardized, self-describing interface to an application.
• a business-level view of an application's capabilities can provide a logical separation between a programmer and a business analyst. For example, this abstraction can enable a business analyst to create records in a database without having to know statements for creating database records, such as SQL statements.
• UpdateRecords can be invoked by an XML message from, for example, a business process.
• the application view in turn, can call the adapter and pass the SQL statements to the adapter.
• the adapter can access the enterprise data and return the result to the UpdateRecords application view, which can return the result in another XML message.
• a user may need to define application views in certain instances and write custom code in others.
• Using an adapter's design-time GUI is not the only way to expose the functionality of an EIS, but can be the most convenient in certain circumstances.
• application views can be defined or custom code can be written to accomplish specific functionality.
• application views can be defined for each adapter to expose the application functions.
• custom code can be written to access the resources of an adapter. For an enterprise, a combination of both methods can be used.
• application views can be defined for a situation where there is more than one EIS system in an enterprise, especially if there is a lack of developers who have detailed, thorough knowledge of all the systems.
• Application views can also be defined, for example, when an integration studio is to be used to construct and manage business processes, or where it will be necessary to update the parameters of an adapter or one of its processes.
• An application view can enable a user to define integration points by browsing fields and data for a specific application.
• a user can define integration endpoints, such as for a customer management system, sales, order management system, or purchase order management system.
• a user can create an application view for each business use, and can deploy and manage these application views using an integration framework component.
• an appropriate adapter should have been developed, such as by using an ADK.
• Certain application views can only be created and configured for existing adapters. It should also be determined which processes need to be supported by the application view being configured. Any required processes can determine the type(s) of services and events to be included in an application view. This can require, for example, gathering information about the application's business requirements from a business analyst to be used with certain business processes. Once the necessary processes are determined, the appropriate services and events can be defined and tested.
• an interface such as an XML- based interface can be created between an application server and a particular EIS application within the enterprise.
• a business analyst can use it, for example, to create business processes that use the application.
• any number of application views can be created, each with any number of services and events.
• FIG. 2 shows an overview of a method for defining an application view in accordance with one embodiment of the present invention.
• a user logs on to an application view console 200.
• the user can select an option to add or create an application view through the console in order to create an application viewforthe appropriate adapter.
• This new application view will enable a set of business processes for this adapter's target EIS application.
• the user can define the application view as necessary for the adapter, EIS, and/or business processes 202.
• the user can enter and configure application connection parameters 204.
• the information can be validated by the console, and the application view can be configured to connect to the specified system.
• a user can add events 208 or services
• the application view can then be deployed 210 on the application server so other entities can interact with the application view, at least according to any security settings.
• the sen/ices can be tested 212, and the events can be tested 214, to make sure they properly interact with the target EIS application.
• the application view can be used in workflows.
• the application view can be undeployed 216 if necessary to reconfigure connection parameters or add services and events.
• One approach to defining and maintaining application views can be shown using the example of an EIS adapter for a hypothetical database EIS called simply "DBMS.”
• DBMS database EIS
• the application view screens may look different than the screens for a different enterprise.
• An application view's adapter can determine the information required for each application view page, and each enterprise can have its own specialized adapters.
• the first step in creating this new application view is to log on to an application view "Console" page.
• the Console can display all the application views in an application integration environment, such as may be organized into folders.
• a user can open a Web browser window using a URL for the appropriate application view Console.
• a user can click add or define an application view.
• a "Define" page can then be displayed.
• an application view may not be moved to another folder once it is defined.
• a "Define" page can be fields where a user can enter a name for an application view, such as a name that describes the set of functions performed by this application.
• Each application view name can be unique to its adapter, and can include both letters and numbers.
• a user can enter any relevant notes. These notes can be viewed by users when they use this application view in workflows, such as workflows using business process management (BPM). From a list of associated adapters, a user can select an adapter to use to create this application view.
• BPM business process management
• a user can navigate to a page that allows the configuring of the appropriate connection parameters.
• a user can define the network-related information necessary for the application view to interact with the target EIS. This information can be entered once per application view.
• a user can add services that support the application's functions. While the application view is open, a user can navigate to an "Administration" page. Here, a user can add a service, giving the service a name that describes the function performed by this service. Each service name can be unique to its application view. A user can enter any relevant notes in a description or similar field. These notes can be viewed by users when they use this application view service in workflows using BPM. When finished, a user can add an event to an application view by following similar steps to adding a service.
• An application view can support events and services for an application through an underlying adapter. These events and services can be established for a particular use, such as for a particular business process.
• an "event” enables messages generated by an application to be managed following a publish/subscribe model. In this model, users can "subscribe” to receive messages that are "published” by an application. Each message can be referred to as a publication event.
• Such a model can be implemented through multicasting, for example.
• a "service” can act as a business function that can be invoked by a user. Service invocations can cause messages to be sent to an application following a request/response model. This model can differ from a publish/subscribe model, in that messages are only sent when requested by a user. This can be implemented, for example, using a point-to-point messaging system. Both events and services can be passed through the system as XML documents.
• a service can constitute business logic within an application that an application view exposes for reuse.
• an application view receives an XML document containing a request to invoke a business service
• the application view can invoke that functionality within its target application and return an XML document that describes the result.
• Each service on an application view can represent a single function, such as a single, logical business function, within a target application.
• a service can take request data, such as in the form of an XML document, and return response data, which can also take the form of an XML document.
• Services can represent bi-directional communication between an application view client and a target application. Services can allow for synchronous or asynchronous communication between applications.
• An application view can inform a client application of all available services that can be utilized. For a customer management example, these might be services such as "GetCustomerDetail” or "CheckOrderStatus.”
• An application view can provide metadata about itself, such as in the form of XML schemas.
• An application view can also include self-describing metadata.
• An application view can use an XML schema as metadata to describe XML information for events, service requests, and responses. This metadata can help a user to understand the data requirements of the event or service of interest.
• An application view can be created on one system and deployed on another.
• An application view can provide a logical separation between the programmer and a business analyst, for example.
• the business analyst can create records in a database without having to know SQL, or can request information from SAP without having a technical understanding of SAP.
• An application view can provide a consistent data representation, regardless of the underlying implementation used by an adapter. For example, each EIS might have an XML interface. For every interaction available to a client there can be a corresponding XML schema that describes the criteria for a valid XML document for that interaction.
• An application view can allow enterprise integration points to be organized by business semantics, such as Customer Management, Order Processing, and Inventory Control.
• At least three features can be exposed to application view clients in certain situations, including outbound messages, inbound requests that return a message, and a way to view the description of any messages that can be sent outbound or processed inbound.
• the application view can hide the technical details from a business analyst.
• the adapter can be responsible for making the transition from the EIS proprietary connection to methods the application view is able to use.
• An application view can take advantage of a common protocol.
• a common protocol can help make application integration possible, as each application only needs to be integrated with the common protocol rather than with every other application.
• applications can communicate using a standard language, such as XML.
• One such common protocol can be based on events and services that are represented by XML documents.
• Adapters can expose an application's functionality and data formats as events and services in an XML format via the application view so that they the events and services be used by all clients of the integration sen/ice.
• Figures 3(a) and 3(b) illustrate application integration with a common protocol versus application integration without a common protocol.
• Figure 3(a) four computer systems 300, 302, 304, 306 are shown communicating without a common protocol.
• a central hub 320 must handle protocol 308 for computer 300, as well as protocols 310, 312, and
• the hub 320 must also handle all byte formats, character encodings, and type casting for each of the protocols 308, 310, 312, 314. ,
• an integration framework provides a common protocol 318 for application integration on top of the J2EE Connector architecture.
• This protocol 318 can be supported via an application view 316, and can consist of events and services encoded as XML documents.
• application views 316 each computer system 300, 302, 304, 306 can communicate with the computer systems using a common protocol, or canonical protocol, without having to understand the other protocols. Further, the central hub does not need to handle multiple protocols 308, 310, 312, 314, but can deal with only the common protocol 318.
• Each of the application views 316 can enforce a consistent data format and consistent behavior in the integration framework.
• Requests to an application view can be made in XML, even though a request made to a target application can use SQL or direct API calls.
• a client 400 can make calls to three separate applications 406, 408, 410 through two separate application view components 402, 404.
• a request to one of the application views 402, 404 does not need to address any login information.
• call A and call B both calls are requesting the same information, as call A to the "East Coast" application view 402 is attempting to get customer information, as is call B to the "West Coast” application view 404.
• the actual data is retrieved from PeopIeSoft 406 and SAP 408, respectively.
• the client 400 initiating the call is not aware of which application is actually processing each request.
• calls B and C both calls are associated with the same application view 404, but each request is handled differently as call B to get customer information gets the information from SAP 408, and call C to get customer history gets the information from a legacy system 410.
• This allows a logical grouping of information to be handled by a single application view 404.
• a client 400 or user can see a subset of the functionality available from the target application, and the functionality can be grouped in a form that is more useful.
• An application view can be the middleman that translates XML messages into the necessary interfaces required by an EIS, and vice- versa. Additionally, an application view can provide an introspection feature so that a client interested in using the application view can determine which capabilities are available, as well as and the type of XML documents each capability will accept and return.
• GUI Graphical User Interface
• An integration framework can provide a way for developers to provide a design-time GUI for each adapter.
• a design-time GUI can provide a way to create application views; to add services and events to application views; and to deploy, test, and edit application views.
• An application view console can be included in a GUI to help a user access, organize, and edit all application views in an enterprise.
• An application view console can be used to create new folders and add new application views to the folders. These new folders can allow a userto organize application views according to a particular navigation scheme, regardless of the adapter being used by the application view.
• An application view can be removed when it becomes obsolete or the application is retired.
• An application view can be removed in some embodiments only if certain conditions are true.
• One such condition- is that the user has undeployed the application view.
• Another condition is that the user is logged onto the application server with the appropriate write privileges.
• To remove a folder a user must first remove all of the folder's application views and subfolders. The user can then navigate to the folder in the Console and remove or delete the folder.
• Application integration configuration data can be stored in the same repository as data for business process management (BPM). Therefore, the same tools can be used to migrate application integration when migrating BPM data.
• BPM business process management
• Migrating application integration data can be straightforward between application server domains and an EIS when instances do not change. However, if the EIS instances change, special procedures may need to be followed in order to ensure a working solution in the target environment.
• an import/export utility can be used to make migrating data simple. For BPM, this can involve exporting a package from BPM in the source domain, and importing that package into BPM in the target domain.
• the Extensible Markup Language is an industry standard for a self-descriptive, extensible, text-based format used to encode data.
• XML provides a general-purpose data format that can be extended for use by any vertical application. Because XML was specifically developed for the Web, it is rapidly being adopted as the language for cross-enterprise data interchange. Because XML is general purpose, it makes sense to use it as the language for communication between two or more groups that have different native languages, for both internal and external enterprise integration. By using XML, an enterprise can have a common format for both internal and external data that can be used to facilitate cross- enterprise integration. The first wave of application integration lacked a common representation for data and metadata. XML provides both.
• An application view can accept XML documents and return XML documents for sen/ices, and can publish events as XML documents. This functionality can be useful in abstracting the complexity of the EIS, even though most EIS systems do not understand XML or use it as a native data format. XML is an easier format to use in integration scenarios.
• An application view and adapter can work together to present an XML interface of an EIS.
• Using application views can make it possible to expose existing enterprise applications as business services that accept XML data as input and that return XML data as output.
• XML as the common format to represent enterprise data makes it possible to treat different systems in similar ways.
• the technical details of the system being integrated can be made transparent, enabling the business analyst to focus on the business service being called to solve a business problem.
• Each application view can use an XML schema as metadata to describe the XML data for events, service requests, and service responses. This metadata can help users understand the data requirements of any application view event or service.
• An application view can provide its clients with the XML schemas that describe the data requirements ofthe services that the application view exposes.
• J2EE Connector architecture provides a standard programming interface to message transport mechanisms.
• J2EE Connector architecture provides a standard for application adapters.
• a J2EE Connector architecture adapter can run within any integration server that supports the J2EE Connector architecture standard.
• the adoption of standards such as the J2EE Connector architecture allows packaged application vendors to construct application adapters that will work within any compliant application server.
• the architecture is a new standard that only addresses low-level integration issues.
• the connector architecture is unidirectional, allowing for synchronous communication from an integration server to an external application.
• the connector architecture does not, however, specify how an external application can asynchronously send data to an integration server. It also does not provide any common or required interface for application adapters, nor specify how data passed between adapters and applications are encoded.
• Basic services such as events, receiving XML, returning XML, and self-describing available services / events, are not addressed in the J2EE Connector architecture. This can be an advantage to using an application view in accordance with one embodiment of the present invention.
• the J2EE connector architecture also fails to address application integration at the business level.
• An application framework in accordance with the present invention adds value to the connector architecture by providing support for business process-level integration and bi-directional data flow between the framework integration server and external applications.
• a business-level view can be implemented on top of the connector architecture that consists of events and services.
• An event can be a message delivered asynchronously via JMS from an application, such as by an application adapter, to the framework server.
• a service can be a function provided by an application that any business process can invoke via the application's adapter.
• BPM can provide a GUI-based environment for designing business process workflows. These workflows can include application view services and events defined using application integration.
• a task node is set up to call an application view service.
• an event node is set up to wait for a response from an asynchronous application view service.
• a workflow is created that is started by an application view event.
• an event node is set up to wait for an application view event. If BPM is not used, an alternate way to use an application view in an enterprise is to write custom Java code to implement a business process.
• BPM should be used to implement a business process in certain situations.
• BPM to implement a business process occurs when implementation would require complicated error management, persistent processes, and sophisticated conditional branching. For example, if a business process receives events, selects only a subset of the events, performs complex branched actions, then generates many complex messages and sends the messages to a variety of application server clients, it can be advantageous to use BPM to implement the business process.
• BPM can also be used when only occasional changes need to be made to the business process. BPM can reduce the number of compile/test/debug cycles. BPM can also be used when, as in most organizations, developers are valuable and scarce.
• Certain prerequisites can be met before a user invokes an application view service or receives an application view event in BPM.
• a user can have created an application view and defined services and events for the application view. Also, the application view and its adapter can be functional and saved. If the user is planning to call application view services and events from a running workflow, the application view should be deployed as well. Both BPM and application integration should be running, and the application integration plug-in should be loaded. The user should have information about any required business logic for the workflows being defined. This information can come from a business analyst, for example. Also, a workflow template definition can be open.
• BPM can be used to design business process workflows that use the application view services and events.
• BPM can provide a GUI-based environment for designing business process workflows. These workflows can include application view services and events defined using application integration.
• Event Router An application programming interface (API) can be used to interact with XML documents, such as to set basic data on an XML document. If a new customer is in an EIS system, there can be information related to that customer such as the customer's name and address.
• An event generator can do a "post" event, which posts the event to an event router.
• the event router can transfer the event from an event generator to an application integration server so the application integration server can notify listeners registered for that event. The event router can know how to communicate with the application integration server.
• An event router can sit on a different server than the main server or application server. This may be a common scenario, as something tightly coupled to an SAP system may be kept close to the SAP system instead of on the main server.
• An event router can publish an event message over to the application integration server with a "publish” call of "event message.” This can then be published to the application view topic. Once the topic receives the event, it can notify the registered event listener of the client. This can all be based, at least in part, on JMS/XML standards.
• FIG. 5 is a diagram showing the life-cycle of an application view in accordance with one embodiment of the present invention.
• an application view needs to be created 500.
• a user can create an application view within a parent namespace and provide a name for the new application view.
• the state of the in- memory object may not yet match the persistent state of the object in the repository.
• a user can save the application view 504 and/or deploy the application view 506, which can automatically save.
• the user can ask to delete an application view 508 and confirm the request.
• a user can edit an existing application view, for example, by picking one from the namespace browser and indicating that the application view is to be edited.
• a transition can occur if the user asks to edit the application view, in which case the application view is undeployed after the user is prompted and confirms.
• An application view can be available for use by runtime clients.
• the application view can have a container with allocated resources for the application view that can service requests for the application view.
• Runtime clients can obtain instances of this application view from the application view container, and invoke its services and listen for its events.
• Other steps in the life cycle of an application view include defining the application view and using the application view.
• communication parameters can be configured before services and/or events are added.
• the application view's services and events can expose specific functions of the application.
• the communication parameters of the application view can govern how the application view will connect to the target EIS.
• Defining an application view can include tasks such as entering a unique name for the application view and configuring parameters that establish the network connection between the application view and the application itself. Other tasks can include configuring parameters that establish the network connection between the application view and the application, as well as configuring parameters specific to the application, parameters used for load balancing by the application view, parameters used for load balancing by the application view, and parameters used to manage the pool of connections available to the application view. Another task can involve defining security privileges for users of the application view. After defining an application view, it can be deployed on an application server. Deployed application views can be used to implement an enterprise's business processes in a business process workflow. After using an application view in a business process workflow, the end result is a deployed electronic representation of that enterprise's business process.
• the workflow can specify how applications interact with each other to accomplish the business processes.
• the application views can perform the transactions themselves.
• an XML-based interface can be created between the application server hosting the application view and a particular EIS application.
• Defining an application view can involve at least a few basic steps, including naming and configuring connection parameters for an application view. Other steps can include adding services and events to an application view, as well as testing services and events.
• An existing application view can be modified to account for definition errors, incomplete definition, change in business purpose, or change in underlying application connectivity.
• the resulting application view can satisfy the business data requirements and can perform the proper interaction with applications.
• it can be necessary to first identify the application view and verify that it exists.
• the technical analyst can enlist the help of a subject matter expert to assist in defining the application view by offering application expertise, and possibly by modifying the application or its metadata to meet the needs of the application view. It is necessary, in some embodiments, that the adapter for the application selected by the technical analyst has been installed, and that the appropriate JSP-based design-time GUI has been installed.
• the server hosting the adapter and the design-time interface should also be up and running.
• the basic flow and alternate flows can assume that the business analyst, technical analyst, and subject matter expert are all interacting during the creation / definition of the application view. This often may not be the case.
• the flow of events can take the form of multiple passes through the flow of events, with each pass representing only the single user interactions.
• a technical analyst can browse a metadata tree of the application and identify the proper metadata to represent the event or sen/ice. The technical analyst can then create an event or service that is specific to the adapter and its design-time interface capabilities. An event or service definition can be created and added to the application view. What the definition contains can be specific to the adapter, but the definition can contain enough information for the event adapter to properly generate events of the requested type at runtime.
• Figure 6 shows the interrelation of some of the features described above. This figure shows an example situation that could arise which would involve adding customers to an SAP instance 616 that were created originally created in a Siebel system or instance 600.
• a new customer 602 is created in Siebel 600.
• the Siebel-specific event adapter 604 is notified and is passed the customer information.
• the event adapter creates an XML-based object containing the customer information and notifies the Siebel application view 608 of the event.
• the Siebel application view 608 then passes the event to the business process 612.
• the business process 612 can determine that the customer information needs to be replicated to an SAP system 616.
• the business process 612 transforms the Siebel XML representation of a customer to an SAP XML representation.
• the business process then invokes a service provided by the SAP application view 610, which can be part ofthe same integration framework 606 as the Siebel application view 608.
• the SAP application view 610 calls the SAP service adapter 614 and passes the XML message, which is now in a format that the SAP adapter 614 can understand.
• the SAP adapter 614 can convert the XML message to a specific BAPI (business application programming interface) and can call the SAP instance 616.
• SAP 616 can process the request, insert the customer 618, and return the customer number assigned by SAP 616.
• An application view object can be created with a name that reflects its business purpose and within a namespace that describes its place within the organizational structure of the business.
• the resulting application view can satisfy the business data requirements and can perform the proper interaction with applications.
• Users of the application view can include business analysts, technical analysts, and subject matter experts.
• a business analyst can decide what the business purpose of the application view will be.
• the technical analyst can decide which application is best suited to the purpose for the application view.
• the technical analyst can enlist the help of the subject matter (application) expert to assist in defining the application view by offering application expertise, and possibly modifying the application or its metadata to meet the needs of the application view.
• the adapter for the application selected by the technical analyst should already be installed and the appropriate JSP-based design- time GUI installed.
• the server hosting the adapter and the design-time interface should also be up and running before creating a new application view.
• a technical analyst opens a web browser and points to the URL forthe adapter design-time interface.
• the technical analyst and business analyst decide which business organization the application view belongs under, and verifies that an appropriate application view namespace exists. This can be done using the namespace browser tree on the home page of the adapter design-time interface. If no appropriate namespace exists, it can be created using the namespace browser.
• the technical analyst and business analyst agree on the name for the application view.
• the name can reflect the business purpose for the application view.
• the technical analyst can create a new application view within the identified namespace and give it the agreed-upon name.
• the business analyst gives a brief description ofthe application view's business purpose and the technical analyst types it into the description field of the new application view.
• the set of events and services for the application view are reviewed and edited, if necessary.
• the technical analyst can then save the new application view. At this point, the application view can be saved for later use, tested, or deployed into the runtime application view engine.
• adapters can be developed as service or event adapters.
• a service adapter can invoke a specific function in the enterprise system to which it is connected.
• An event adapter can propagate information from the enterprise system to the integration environment. For each application view, businesses can add any number of services and events to an application view definition to support specific types of transactions between an application server and the target enterprise system.
• an adapter can use XML to translate an application's data format, business analysts do not need to understand the format. If a business analyst wants to use an adapter, it is only necessary to know how to define and use application views. Best of all, because all adapters can use a similar Web-based interface for defining application views, it can be easy to learn to use current and future adapters.
• XML can make application integration smooth both for developers and business analysts.
• the J2EE specification does not currently provide guidelines for an EIS to initiate communication with the application server or client.
• Application integration can provide this capability through the user of event adapters.
• Another important feature of an application view is the ability to support bi-directional communication.
• the J2EE specification does not currently provide guidelines for an EIS to initiate communication with the application server or client.
• This capability can be provided by an event adapter.
• each event responds to a particular enterprise application state.
• the application view can extract data about the event from the enterprise system and propagate the data in an XML document to the integration environment.
• each service can represent a particular function in an enterprise system.
• an application view receives an XML document that maps to a particular server, it invokes the corresponding function in the enterprise system using the service adapter.
• the enterprise system can in some embodiments send a response to the service.
• the application view can be customized for a specific business purpose.
• the business purpose can be defined by the business analyst. For example, if defining a "customer management" application view on an adapter for a Customer Relationship Management (CRM) system, only the sen/ices and events related to customer management can be added.
• Application views can be created that are as inclusive as necessary. Because application views can be customized for a specific business purpose, application views can work much better than the "one size fits all" approach used by many other enterprise application integration systems.
• the business-level view of an application's capabilities can provide a logical separation between the programmer and the technical analyst. For example, this abstraction can enable a technical analyst to create records in a database without having to know SQL. Deploying Application Views
• An application view can be deployed when there has been at least one event or service added to it.
• An application view may need to be deployed before its services and events can be tested, as well as before the application view is used in an application server environment.
• Application view deployment can place relevant metadata about its services and events into a run-time metadata repository. Deployment makes the application view available to other application server clients. Business processes can then interact with the application view.
• a user can open an application view console and select a "deploy" option from an application view administration page.
• a user can enable asynchronous service invocation.
• An entity that calls an application view service asynchronously can continue its process without waiting for a response from the service.
• a user can enter the URL of the adapter's event router.
• a user can also enter a minimum number of connection pools to be used by this application view, such as for example "1.” Similarly, a user can enter a maximum number of connection pools.
• a user can enter the ideal pool size, such as may be measured from 0 to 1.0. For example, a value of "0.7" could be entered. If the maximum pool size is 10 and the target fraction is 0.7, this means the adapter will perform load balancing to attempt to maintain the connection pool size at 70% ofthe maximum, which in this case means 7 connections. To automatically delete unused connections, a user can select an option that will allow the pool to shrink.
• logging preferences such as logging errors and audit messages; logging warnings, errors, and audit messages; logging informationals, warnings, errors, and audit messages; and logging all messages.
• An application view "Security" page can be included in the Console, which can be used to grant or revoke a user's or group's read and write access to this application view.
• a user can choose to apply the changes.
• the user can also choose to deploy the application view after any changes.
• An application view can be undeployed, for example, when a user wants to edit its connection parameters, add services and events, or disable clients from using the application view.
• a user can choose to display a "summary" page for the application view.
• To undeploy the application view from the application server, a user can select an "undeploy" option.
• a user can configure its connection parameters. After adding and testing sen/ices and events, a user may want to reconfigure the connection parameters or remove services and events.
• a user can open the application view and click on the "summary" option, or simply display an application view "Administration" page. From here, a user can reconfigure the application view's connection parameters or add services and events.
• a node that synchronously calls a service can be configured to wait for a service to return a response document before the workflow can continue.
• a user can select a predefined XML variable, such as from a "response document variable list.
• the response document variable can store the response. If a user does not care about the response data, the user can leave this field empty.
• a user can select an option to create a new XML variable. If it is necessary to examine the XML schema of the response document, the user can view the response definition.
• a predefined string variable can be selected from the application view Console. If no suitable string variable exists, a "variable properties" dialog box can be opened where a new string variable can be created.
• a task node is set up to call an asynchronous application view service, the result can be returned to BPM.
• the workflow can identify this response using the selected request ID variable.
• To set an event node to receive the response the same request ID variable should be used for the event node.
• a user may wish to set up an event mode to wait for a response from an asynchronous application view service. In a workflow, whenever an action calls an application view service asynchronously, the application view service will return a response.
• an event node can be created with the event node being set to wait for an event, such as an event of type "Async Response.”
• a user can select a "response document” option.
• a user can receive an asynchronous sen/ice response by selecting the request ID variable and a response document variable.
• the request ID variable is a string and the response document variable is of type XML.
• a second method uses an "asynchronous variable" option. When using this method, the asynchronous service response can be received by selecting the request ID variable and an asynchronous service response variable.
• ID variable is a string and the asynchronous service response variable can be of a type such as "AsyncServiceResponse.”
• a preferred method may be the response document method, as it can provide a universal means of receiving both asynchronous and synchronous responses.
• an XML document can be received regardless of whether the response is asynchronous or synchronous, and it will not be necessary to query the value of the asynchronous service response variable.
• a response document variable can be used to receive asynchronous service responses whenever possible. Whenever an "event properties" dialog box is set to wait for an event of the asynchronous response type, a user can choose to use an asynchronous variable to receive the response.
• an asynchronous response event node is edited that was previously set up to use an asynchronous service response variable to receive the response
• two options can be displayed in an event properties dialog box: an asynchronous variable option and a response document option.
• a user can select one of the two methods to receive the service response.
• an event properties dialog box can display a dialog box that will allow a user to set a response document to receive the service response.
• An application integration plug-in in accordance with one embodiment of the present invention can include a variable type such as AsyncServiceResponse and functions such as AIHasError(),
• an event node can be created and set to wait for an event of a type such as "Al Async Response.”
• Steps for setting an event node to use an XML variable to receive an asynchronous service response can include, first, opening a workflow template definition. A user can create an event node if one does not already exist, which will wait for an asynchronous response from a designated application view service. The user can select an already- defined string variable, and BPM will listen for an asynchronous response with an ID matching this variable.
• the event node can wait for a response to an action, such as a call to an application view service, that was called asynchronously earlier in the workflow.
• the "call application view service” action can set the request ID variable. To make the action and this event node work together, they can both use the same request ID variable.
• a user can select a predefined XML variable, such as from a response document variable list.
• the response document variable can be used to store the response. If no suitable XML variable exists, the user can create a new variable.
• a preferred method for receiving an asynchronous service response may be to use a response document variable of type XML.
• an existing workflow contains an asynchronous event node that was previously set to use an AsyncServiceResponse variable to wait for a response from an asynchronous application view service, a user can modify the event node.
• an event mode uses an AsyncServiceResponse variable to receive an asynchronous service response
• one approach to modifying the event mode uses the following steps.
• a workflow template definition is opened and an asynchronous variable type selected.
• a user selects an already-defined string variable, and BPM listens for an asynchronous response with an ID matching this variable.
• a client can choose to invoke a service asynchronously if it is a long- running service. For instance, some SAP requests can take about two or three minutes to process. The processing of the request usually happens transparent to the client. If the user is sitting at a web page, it can be undesirable for the page to simply "hang" for two minutes without doing anything. It may be preferable to issue some sort of response, then update the web page once the proper response is received, such as a new message from SAP. This is one reason for using a callback listener for asynchronous responses. In this way, a client does not want to have to wait around for a response, but will instead be notified when the response is received by the callback listener.
• a listen and receive event is another valuable part of certain embodiments in accordance with the present invention, as a listen and receive event is not addressed in the J2EE Connector architecture.
• a trigger can occur in an EIS, and external applications may need to know about the firing of the trigger. In other words, an event occurs that needs to be propagated out to certain applications. All the registered listeners may need to be notified as well.
• a client can create an application view and can add an event listener.
• a handler is created that knows what to do once it receives an event from the application view.
• the application view in one embodiment subscribes to a JMS topic and registers the listener on that topic.
• a JMS topic is a JMS feature to which JMS messages can be posted, similar to an inbox.
• Event generator There can be defined an object, or application integration component, called an "event generator.”
• One job of the event generator is to watch and communicate with an EIS to determine when an event occurs. For a DBMS adapter, this can involve a query on a staging table. A user can make a request, such as "select * from event.” Any record in that event table will be a record of a new event in the DBMS. The event generator periodically look to the EIS for new events.
• an event can result the system triggering a notification that it needs to restock a certain product.
• This event can happen, for example, in an EIS.
• Triggers can be used for DBMS. Once an insert occurs on a certain table, a trigger can fire and place information about the new data into the event table, such as by using an "insert into event" statement. Then, once a new event occurs, the event generator can pull that event.
• a user can grant or revoke a user's access privileges by specifying a user or group name in an appropriate form.
• Each application view can have at least two types of access, including read access and write access. Read access allows the user to execute services and subscribe to events. Write access allows the user to deploy/edit/undeploy the application view.
• Methods can be invoked on an application view that allow the security level be set before services are invoked on an application view. Methods such as “setConnectionSpecO” and “getConnectionSpecQ” can be used to set the credentials for an EIS. Using a "ConnectionSpec” object. To instantiate a ConnectionSpec object, a class such as “ConnectionRequestlnfoMap” can be provided, such as in an ADK. A user can also implement that a class created by that user.
• JCA class ConnectionSpec interface
• JCA class ConnectionRequestlnfo interface
• SDK class Map interface
• SDK class Serializable interface
• a user can use ConnectionSpec in conjunction with the setConnectionSpecO and getConnectionSpec() methods.
• a user can pass a properly initialized ConnectionSpec object.
• the user can pass a ConnectionSpec object with a null value.
• Special care may need to be taken when migrating data between application server domains and between different instances of an EIS, as application views defined against one EIS instance can contain identifiers and data specific to that EIS instance. This can also be true of a connection factory used by the application view. A user may not be able to manually change ElS-instance-specific data in an application view or connection factory. These changes can, however, be made from an application view console by navigating to the desired application view and editing the application view. The user can identify and update all EIS- specific data in the application view, as well as any events, services and associated connection factories.
• Any ElS-instance-specific references can be replaced with references to the new EIS instance in the target environment.
• the user can edit the application view and connection factory definitions.
• Application view definitions may need changes in an "EventRouterURL” or similar parameter, such as may be accessed through an application view "deploy” screen.
• This parameter can be used to refer to the event router in the target environment. Changes may also need to be made to parameters in the service definitions. These can be adapter-specific data that refers to
• ElS-instance-specific data An editing feature can be used to change any EIS instance-specific parameters for the service.
• Event definition parameters may also need to be changed, which contain adapter-specific data that refer to ElS-instance-specific data. Each adapter can place different properties into a service and event.
• an ADK design-time framework can provide the tools needed to build a Web-based GUI that adapter users need to define, deploy, and test their application views.
• each adapter can have ElS-specific functionality, all adapters require a GUI for deploying application views.
• This framework can minimize the effort required to create and deploy these interfaces. This minimization can be accomplished at least in part by using two primary components.
• One of these components is a Web application component that allows a user to build an HTML-based GUI by using, for example, Java Server Pages (JSP).
• JSP Java Server Pages
• This component can be augmented by tools such as JSP templates, a tag library, and the JavaScript library.
• a second component is a deployment helper component or request handler that can provide a simple API for deploying, undeploying, and editing application views on an application server.
• an application view can represent a business-level interface to the specific functionality in an application
• an adapter can represent a system-level interface to all the functionality in the application.
• An application view can be configured for a single business purpose and can contain sen/ices related to that business purpose. These services can require only business-relevant data to be specified in the request document and return only business-relevant data in the response document.
• An application view can combine this business-relevant data with stored metadata necessary for the adapter.
• the adapter can take both the business-relevant data and the stored metadata, and can execute a system-level function on the application.
• An application view can represent both events and services that support a business purpose. This can allow a business user to interact with the application view for all communication with an application. This bidirectional communication can be supported by an event adapter and a sen/ice adapter.
• An application view can abstract this fact from the user and present the user with a unified business interface to the application.
• An event can be an XML document that is published by an application view when an event of interest occurs within an EIS. Clients that want to be notified of events can register their interest with an application view.
• the application view acts as a broker between the target application and the client. When a client has subscribed to events published by an application view, the application view notifies the client whenever an event of interest occurs within the target application.
• An application view represents a business-level interface to specific functionality in an application.
• a service can be a business operation within an application that is exposed by the application view.
• the service can exist as a request/response mechanism.
• the application view can invoke that functionality within its target application and return, or respond with, an XML document that describes the results.
• a user may need to determine and define the input requirements, output expectations, and the content ofthe interaction specification.
• J2EE Connector Architecture CCI connection factory deployment For example, if a user deploys the abc.xyz application view, application integration can deploy a new Connection Factory and bind it to a JNDI location connectionFactorylnstance. For efficiency sake, the new connection factory deployment can use the ⁇ ra-link-ref> setting in the weblogic-ra.xml deployment descriptor.
• the ⁇ ra-link-ref> element can allow for the logical association of multiple deployed connection factories with a single deployed adapter.
• the specification of the optional ⁇ ra-link-ref> element with a value identifying a separately deployed connection factory can result in this newly deployed connection factory sharing the adapter which had been deployed with the referenced connection factory.
• any values defined in the referred connection factory's deployment can be inherited by this newly deployed connection factory unless specified.
• the adapter logical name can be used as the value for the ⁇ ra-link-ref> element.
• Design-time development can have its own features, which can be different from those associated with run-time adapter development.
• a design-time GUI can be comprised of a set of ten Java Server Pages (JSPs), for example.
• JSPs are HTML pages that call Java servlets to invoke a transaction. To a user, a JSP looks like any other web page.
• JSPs that comprise a design-time GUI can include, for example: display.jsp - a display page, also called the Adapter Home Page; this page can contain HTML necessary to create the look-and-feel of the application view login.isp - a Adapter Design-Time Login page confconn.jsp - a Confirm Connection page; this page can provide a form for the user to specify connection parameters for the EIS appywadmin.jsp - an Application View Administration page; this page can provide a summary of an undeployed application view addevent.jsp - an Add Event page; this page can allow a user to add a new event to the application view addservc.jsp - an Add Service page; this page can allow the user to add a new service to the application view edtevent.jsp - an Edit Event page is an optional page that can allow users to edit events edtservc.jsp - an Edit Service page is an optional page that can allow users to edit services
• a design-time framework can provide a set of JSP templates for rapidly assembling a web application to define, deploy, and test a new application view for an adapter.
• a template is an HTML page that is dynamically generated by a Java Sen/let based on parameters provided in the HTTP request. Templates can be used to minimize the number of custom pages and custom HTML needed for a web application. Templates can provide most ofthe HTML forms needed to deploy an application view.
• the only custom forms can include a form to collect the ElS-specific connection parameters, a second form to collect the EIS- specific information needed to add an event, and a third form to collect the ElS-specific information needed to add a service.
• a custom JSP can be supplied for browsing a metadata catalog for an EIS.
• Templates can also leverage the internationalization and localization features of the Java platform.
• the content of every page in the web application is stored in a message bundle. Consequently, the web interface for an adapter can be quickly internationalized.
• the templates can also centralize look-and-feel into a single location.
• a naming convention can be used for the design-time Web application and connector deployment.
• a text file named webcontext.txt can be included in the root of the .ear file.

Landscapes

• Engineering & Computer Science (AREA)
• Software Systems (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Stored Programmes (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)
• Communication Control (AREA)
• Computer And Data Communications (AREA)

Priority Applications (2)

Applications Claiming Priority (20)

Publications (1)

Family

ID=27581209

Family Applications (5)

Family Applications Before (4)

Country Status (5)

Cited By (3)

Families Citing this family (19)

Citations (3)

Family Cites Families (10)

• 2002
  • 2002-10-17 CN CN 02825183 patent/CN1585948A/zh active Pending
  • 2002-10-17 WO PCT/US2002/033090 patent/WO2003034228A1/en not_active Application Discontinuation
  • 2002-10-17 AU AU2002347926A patent/AU2002347926A1/en not_active Abandoned
  • 2002-10-17 AU AU2002347927A patent/AU2002347927A1/en not_active Abandoned
  • 2002-10-17 EP EP02784131A patent/EP1444609A4/de not_active Withdrawn
  • 2002-10-17 AU AU2002347919A patent/AU2002347919A1/en not_active Abandoned
  • 2002-10-17 WO PCT/US2002/033184 patent/WO2003034183A2/en not_active Application Discontinuation
  • 2002-10-17 JP JP2003536944A patent/JP2005506618A/ja active Pending
  • 2002-10-17 WO PCT/US2002/033183 patent/WO2003034182A2/en not_active Application Discontinuation
  • 2002-10-17 WO PCT/US2002/033097 patent/WO2003044661A1/en not_active Application Discontinuation
  • 2002-10-17 WO PCT/US2002/033098 patent/WO2003034285A1/en active Application Filing

Patent Citations (3)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events