Patent Application
20060200565
The present invention relates generally to improved systems and techniques for support of communication between software applications. More specifically, the invention relates to improved systems and techniques for mediating communication between software applications in a way that is transparent to the particular communication medium, such as a message transport bus, being used, and that is easily adaptable to changes, additions or substitutions to the applications and the communication medium.
Many communication systems, particularly large communication systems that have been in service for a long period of time, employ numerous instances of what are known as legacy applications. A legacy application is an application that predates newer applications that may be more flexible and efficient, but continues to be used because of its continued serviceability and the inconvenience and expense of replacing it. In order to allow for smooth communication between legacy products, many systems employ what are known as middleware products to facilitate communication. If a middleware product is used, legacy applications do not need to communicate directly with one another. Instead, each legacy application communicates with the middleware product, which provides appropriate message and data transfer and protocol handling. If a legacy application is replaced or changed, it is not necessary to change every other legacy application. Instead, changes only need to be made to the middleware product.
Many legacy applications have the potential to be used with different middleware products. For example, a legacy application deployed for a small customer application might use a simple middleware product hosted on a single computer, while the same legacy application deployed in a larger installation might use a more complex middleware supported on multiple computers. In order for a different middleware product to be used with a legacy application, steps must be taken to allow for communication between the application and the new middleware product.
Prior art approaches to migrating legacy applications from one middleware technology to another include the recoding of each legacy application to adapt the application to the new middleware. Another approach is to use a single standard middleware platform and to use software wrappers to map legacy applications to the target middleware platform. Both of these approaches require significant additional coding to accomplish migration from one middleware platform to another, because each legacy application, or the wrapper used for an individual legacy application, must be adapted to the new middleware platform. An alternative approach that avoids the need to adapt each legacy application is the use of a stateful gateway process to intercept messages from one application and relay them to another application. However, this approach reduces performance.
There exists, therefore, a need for systems and techniques that will allow changes, additions or substitutions to middleware products used with legacy applications with a minimum of adaptation and with a minimal impact on performance.
In one exemplary embodiment, a software wrapper is implemented to mediate communication between one or more applications using a message transport bus. The message transport bus may suitably be implemented as a middleware package. The software wrapper includes a virtual bus wrapper presenting an interface adapted to the supported applications, such that the message transport bus is transparent to the applications. The software wrapper further includes a bus specific wrapper to adapt the virtual bus wrapper to the message transport bus being used, as well as a support wrapper to provide needed services to applications or message transport buses lacking these features. Upon initialization, code and data provided by the construction of the software wrapper is processed to create a body of executable code to carry out the functions of the software wrapper. Initialization is suitably performed using instructions in a configuration file and templates providing data used to adapt the software wrapper to the applications and to the message transport bus. Changes to the applications being supported or to the message transport bus can be accommodated by changes to the virtual bus wrapper or to the bus specific wrapper, respectively. In particular, changes to the bus specific wrapper allow migration to a new or changed message transport bus or a system using a different message transport bus without a need to adapt each application to the new bus.
A more complete understanding of the present invention, as well as further features and advantages, will be apparent from the following Detailed Description and the accompanying drawings.
The present invention will be described more fully hereinafter with reference to the accompanying drawings, in which several exemplary embodiments of the invention are shown. This invention may, however, be embodied in various forms and should not be construed as limited to the embodiments set forth herein.
Communication between the various applications and modules is carried out over a message transport bus 120. The message transport bus 120 is a middleware package, designed to manage communication between the different applications without a need for each application to be specifically adapted to communicate with each of the other applications. The message transport bus 120 is typically implemented as a package having components hosted concurrently on each domain and components providing communication between the domains, in order to manage communication within and between the domains. Various software packages known as enterprise application integration (EAI) tools may be chosen to perform the functions of the message transport bus 120. Examples of such tools include UNIX message queues, BEA TUXEDO™ produced by BEA Systems, Inc., and common object request broker architecture (CORBA).
The various wrappers are implemented as intermediaries between the various applications and the message transport bus 120. The wrappers provide services that render the particular transport bus transparent to the applications, and render the applications transparent to the transport bus. The wrappers manage details specific to each application and to the transport bus 120, so that the applications that are communicating with one another are presented with a standardized interface. The communicating applications do not need to be adapted to the specific needs of the other applications, so that changes or substitutions affecting one application do not need to be accommodated by changes to the other application. A plurality of wrappers are shown here because adaptations are made to accommodate each application and module, so that it is convenient to think of the system 100 as implementing a plurality of wrappers, one for each application or module. However, it will be recognized that the actual implementation of the wrappers can be accommodated in any of a number of ways, for example by implementing the wrapper for each application as a single software component, by implementing a single software component to provide the necessary support for each application, with the single software component including any necessary adaptations to a particular application, or by implementing any desired combination of software components, with proper adaptation to applications served by the components.
The virtual bus wrapper 128 adapts the application 108A to a “virtual” bus. The virtual bus wrapper 128 provides an interface 134 to the virtual bus wrapper 128, providing services that allow the application 108A to communicate with the message transport bus without a need to specifically adapt the application 108A to the bus 120. Design of the interface 134 is preferably accomplished so as to export a vendor neutral interface that can be adapted to different application programming interfaces (APIs) used by legacy applications using standardized service innovation methods. The interface 134 presents its own standardized set of APIs to the application 108A. These APIs do not depend on the middleware package being used to implement the message transport bus 120. The following table presents some of the APIs that may be presented by the interface 134:
The bus specific wrapper 130 enables a dynamic binding between the APIs presented by the virtual bus wrapper 128 and APIs presented by the message transport bus 120. The bus specific wrapper 130 is preferably implemented as a shared library loaded dynamically at initialization of the wrapper 109A. The bus specific wrapper 130 is adapted to a specific middleware package, for example CORBA or BEA TUXEDO™. Thus, one alternative design of a bus specific wrapper 130 may be implemented in order to manage communication between the virtual bus wrapper 128 and an implementation of the message transport bus 120 comprising a CORBA middleware package. An alternative design of the bus specific wrapper would be adapted to manage communication using an implementation of the message transport bus 120 comprising a BEA TUXEDO™ middleware package. The wrapper 109A can be relatively easily changed to adapt to different middleware packages simply by substituting different implementations of the bus specific wrapper.
The service support wrapper 132 provides additional facilities such as name resolution and service location at run time to support message transports lacking these features. The service support wrapper 132 also provides uniform adaptation to the different conditions in message transports having features provided by the service support wrapper 132. Each such facility is implemented once per service type. An example of a service type is service discovery. If the application 108A requests a service but the virtual bus 128 does not include information identifying the application providing the service, the service discovery function of the service support wrapper 132 performs queries to identify the application providing the service and furnishes the identification information to the virtual bus wrapper 128. The virtual bus wrapper 128 is then able to point directly to the required application.
Use of a multilayered design including the virtual bus wrapper 128, the bus specific wrapper 130 and the service support wrapper 132 allows for simpler construction and use of the various components. A number of implementations of each wrapper can be created, with each implementation of a wrapper being appropriate to a set of entities communicating with the wrapper. Combinations of wrappers may then be selected in order to manage communication for a combination of entities. For example, a virtual bus wrapper may be created for a set of applications, with the virtual bus wrapper presenting an interface to the applications that is transparent to the particular middleware package being used for message transport. A bus specific wrapper may be created for a particular type of bus or middleware package, such as CORBA, with the bus specific wrapper being transparent to the applications communicating with the bus. Appropriate implementations of the virtual bus wrapper and the bus specific wrapper may be selected and used in combination to provide communication. Changes to the applications or the addition of new applications can be accommodated by selecting an appropriate version of the virtual bus wrapper 128 or modifying the virtual bus wrapper 128, and changes to the message transport bus 120 or use of a new middleware package as the message transport bus 120 can be accommodated by selecting a new version of the bus specific wrapper 130 or modifying the bus specific wrapper 130.
The virtual bus wrapper 128 presents the client interface 134 to the application 108A, and the bus-specific wrapper 130 adapts communication from the virtual bus 128 to the message transport bus 120. The client interface 134 manages communication between the application 108A and the virtual bus wrapper 128, presenting an interface to the application 108A which is independent of the message transport bus 120. The client interface 134 implements a number of application programming interface modules. Of particular interest are a message management module 138A, a request and response control module 138B, a service management module 138C and an advanced communication module 138D. Also implemented are a group and membership management module 138E, a resource management module 138F, a concurrency management module 138G, a security management module 138H and a reliability management module 1381. Each of the modules 138A-138I supports a number of application programming interfaces (APIs) that are invoked by a calling function. A calling function may be, for example, a function executed as part of the application 108A, and may invoke an API presented by the virtual bus wrapper 128 in order to request services from the virtual bus wrapper 128.
The message management module 138A provides application programming interfaces (APIs) that are implemented so as to insure message bus independence. Message bus independence allows for communication by the application 108A regardless of the specific implementation of the message transport bus 120. The message management module 138A provides support for different messaging techniques, for example, point to point and publish/subscribe. Different transport platforms that may be used as the message transport bus 120 may exhibit different capabilities, and the virtual bus wrapper 128 enables the use of any underlying message facility in a given transport platform.
The message management module 138A also allows applications, such as the application 108A, to specify different control policies on messaging such as synchronous requests, asynchronous requests with receipts, and asynchronous one way notification. Message delivery order can also be specified as part of message construction or by setting message attributes such as in band or out of band. In addition, prioritized message handling is supported so as to allow a message with a higher priority to be served before a lower priority message.
The message management module 138A provides support for a desired transport method without a need for specification by the application 110A. The message management module 138A receives a generic transport handle, obtained earlier by the application 108A. The message management module 138A retrieves or obtains information describing the messaging structure being used. The message management module 138A then performs needed mapping, encoding and decoding and translation to support message transfer between the application 108A and the message transport bus 120.
Applications typically take on the roles of either clients, that is, requesting services from other resources, or servers, that is, receiving and responding to requests. The role of an application may change over time, or an application may serve in dual roles, that is, requesting services from some entities and providing services to others. The request and response control module 138B supports changes in function and dual function performance of applications and generates appropriate scaffolding code to support changes in role between client and server.
The wrapper 109A preferably supports request forwarding. Request forwarding allows one application, such as the application 108A, to forward a request to another application, for example the application 111A of
In addition, the group and membership management module 138E also provides facilities for management of request forwarding. An application or a server can advertise its services dynamically when it joins a group using a group_join API, implemented to support group and resource management. Such advertising of services facilitates transparent load sharing of requests and request forwarding. Request forwarding can also be used to implement security measures such as third party authentication. However, if delegation or advertisement occurs between different applications operating in different servers, or when a group includes applications distributed across several different servers, delegation and advertisement becomes complex. Therefore, the virtual bus wrapper 128 includes a service management module 138C, which provides location transparency by decoupling service location from the application requiring a service. The service management module 138C provides support for various service location policies, such as “nearest” or “round robin”. These policies can be explicitly specified, for example, through an argument explicitly specified when invoking a particular API, or through choices made at initialization of the module 124. Service location policies are implemented by the support wrapper 132. When a request involving location policy is received, it is passed to the service management module 138C. The service management module 138C passes the location policy selection to the service wrapper 132, which provides the support needed to direct the request to the proper location according to the location policy. The service management module 138C can also implement optional server application callback initialization functions in order to accommodate applications with special needs.
The virtual bus 120 also includes an advanced communication module 138D, to support additional communication features such as stateful communication, also known as conversations, message transactions, and event notification mechanisms, for example, receipt of a message. APIs include APIs to start and end conversations and to start and end transactions. In addition, the advanced communication module 138D can also support an optional user defined event handler to be called when messages are sent and received in order to manage application specific bookkeeping, such as billing, related to the messages.
Management and coordination of communication between an application communicating with the virtual bus 128, and the message transport bus 120, is achieved by linking the virtual bus wrapped code generated by the interaction of the application and the virtual bus wrapper 128 with a bus specific library. The virtual bus wrapped code is code and other data and communication generated by the operation of the virtual bus 109A in response to communication from the application 108A. The function of the library is performed by the bus specific wrapper 130, which is preferably implemented as a shared library dynamically loaded at run time, that is, at initialization of the software wrapper 109A.
Implementation of a wrapper typically comprises the examination of the various APIs, library information and other data comprising the layers of the wrapper, and the use of this information, as well as other information drawn from libraries and other repositories, to construct a body of executable code carrying out the functions of the wrapper 109A. This construction may be performed by a data processing unit, suitably a unit hosting the application and wrapper, as well as the libraries used in construction of the executable code and configuration and operations, administration and maintenance files used in initialization of the wrapper.
The initialization module 304 has access to a number of code libraries and templates used to construct scaffolding needed to manage communication between the application 108A and the message transport bus 120. The libraries include a configuration file 306, constructed at initialization of the wrapper 109A and used to manage the operation of the wrapper 109A. The configuration file 306 preferably comprises a repository hosting extensible markup language (XML) files for startup settings, build instructions and for storage of log files. The libraries also include an OAM interface file 308, used to store APIs for management of system startup, shutdown and run time monitoring.
The configuration files include a startup file providing instructions for startup functions. The startup file is preferably in the form of an XML file. In addition, the OAM interface includes a build file providing build instructions, used to create a structure to provide linkages allowing for communication between the application 108A and the message transport bus 120. The build file is preferably also in the form of an XML file.
Initialization of the wrapper 109A may suitably comprise three steps, directed by the startup file and the build file. At initialization, the configuration files employed by the application 108A are transformed to standardized XML format used by the virtual bus wrapper 109A. The transformation is accomplished using extensible stylesheet language transformations (XSLT). Procedural wrapper code generation is then performed. Linkages between the procedural wrapper code and the bus-specific wrapper are then constructed, and finally the code resulting from construction of the linkages is combined with support tier code used by the support layer 132. After the various initializations and linkages are performed, the application 108A is able to communicate with the message transport bus 120.
A procedure template 310 is used to automate procedural wrapper code generation. Code is generated for each procedure performed as part of the application 108A. The procedure wrapper template 310 is a set of instructions for automating code generation, and the procedure directed by the template 310 includes three steps. The first step is a precondition step performing any needed initializations and argument mapping. Next, a command step constructs code for executing the procedure. The last step performs any needed cleanup and dispatches the result to the calling or requesting entity, such as another application or a procedure included in another application.
A template such as the template 310 may be used to provide for application and configuration file scaffolding. In addition, result dispatch must be managed with care, because the application responding to a request from a client may be different from the application that initially received the request. This difference may result from conditions such as service forwarding or load balancing.
As an example, consider construction of scaffolding for a single C++ function WM_CREATE. The function is adapted to an EAI TUXEDO™ message transport bus, and assumes that the EAI tool will determine which services it is supporting and will also receive messages from the supported service. After processing the message, the function will act as a client and will forward the message to another server via the tp_forward procedure supported by TUXEDO™.
The virtual bus wrapper 128 generates appropriate C code scaffolding from a TUXEDO™ template 312. The TUXEDO™ template 312 includes code directing the initialization of resources and identification of the service being supported. Then, the bus specific wrapper 130 waits in a message loop until it receives a message destined for the supporting service. Next, the bus specific wrapper 130 decodes the message to the format used by the application 108A and invokes an appropriate function provided by the application 108A. This process of decoding the message and invoking the application continues until the application is shut down via a signal.
In addition, the virtual bus wrapper 128 performs initialization tasks specific to the application 108A, for example message timeouts and signal scaffolding. The bus specific wrapper 130 also performs any needed message encoding and decoding to perform any required format conversions, as well as procedure mappings between the API presented by the message transport bus and the APIs presented by the application 108A. Once initialization is complete, the wrapper 109A is able to mediate communication between the application 108A and the message transport bus 120.
The initialization of a single wrapper 109A for communication with a single application 108A is discussed here for simplicity of illustration and explanation, but it will be recognized that initialization of a plurality of wrappers, or more complex wrappers supporting communication with a number of applications, is accomplished in a similar way.
The code section labeled “Legacy Server Application” corresponds to the application 402, the code section labeled “a) Virtual bus wrapper” corresponds to the virtual bus wrapper 408, the code section labeled “b) Bus specific wrapper for Unix message queue” corresponds to the virtual bus wrapper 410, and the code section labeled “c) Support wrapper” corresponds to the support wrapper 412.
The code section labeled “Legacy Server Application” corresponds to the application 402, the code section labeled “a) Virtual bus wrapper” corresponds to the virtual bus wrapper 408 and the code section labeled “b) Bus specific wrapper for Unix message queue” corresponds to the virtual bus wrapper 456. The application 402 and the virtual bus wrapper 408 are carried over unchanged to the system 450, with the new bus specific wrapper 456 being substituted for the bus specific wrapper 410.
Next, at step 604, upon initialization of the software wrapper, code and data presented by the wrapper is processed to create a body of executable code to carry out the wrapper functions. Initialization is suitably performed using a stored configuration file and templates providing data used for adapting the software wrapper to the applications being supported and to the message transport bus being used.
At step 606, the software wrapper is used to mediate communication between applications. At step 608, carried out in response to addition of or changes to one or more applications, the virtual bus is adapted so as to support the new or changed application, and initialization is performed. At step 610, carried out in response to changes to the message transport bus, substitution of a different message transport bus or migration of the applications to a new system using a different message transport bus, the bus specific wrapper is adapted to support the new or changed message transport bus and initialization is performed.
While the present invention is disclosed in the context of several embodiments, it will be recognized that a wide variety of implementations may be employed by persons of ordinary skill in the art consistent with the above discussion and the claims which follow below.
