A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
The present application is related to the following U.S. patents and patent applications, which patents/applications are assigned to the owner of the present invention, and which patents/applications are incorporated by reference herein in their entirety:
U.S. patent application Ser. No. 10/706,516, entitled “DYNAMIC CODE GENERATION SYSTEM”, filed on Nov. 12, 2003; and
U.S. patent application Ser. No. 10/706,515, entitled “COMPUTER PRODUCT FOR A DYNAMICALLY GENERATED WRAPPER CLASS”, filed on Nov. 12, 2003.
The current invention relates generally to wrapping software objects, and more particularly to dynamically wrapping software objects.
Application servers provide an environment for programmers to implement application programs for users. BEA System of San Jose, Calif. provides one such application server called Web Logic Server (WLS). Third party vendors typically provide resource adapters, JDBC, JMS and JCA drivers, for use on these application servers. A programmer may use those resource adapters to provide the services to the user through the programmer's application program. Vendor resource adapters are varied and generally provide a broad range of features to be accessed by application programs.
Within an application server, it is desirable to provide support for global transactions. Generally, this involves tracking the status and availability of resources, changes to shared resources throughout the servers, and managing other features that affect the server system. Accordingly, an application server should be informed regarding transactions that occur between application programs and resources. To effectuate this, an application server may not provide application programs with direct access to vendor objects. Providing application programs with direct access to vendor objects would prevent the application server from knowing what was transpiring between application programs and resources. Application servers implement a middle-ware between the application programs and the resources to determine what transpires in transactions between them.
Previously, middle-ware was implemented by application servers in the form of statically generated proxies. The statically generated proxy included hard coded methods that handled interfaces for specific vendor resource adapters. The application server was designed with a proxy that assumed the presence of certain vendor features, such as a particular type of resource or a particular type of resource interface. These application servers worked well to provide the application programs access to those specific resources. However, an application program encountered difficulties if it was configured to use a resource adapter from a different vendor or any other resource adapter not statically included at the development time of the application server.
What is needed is a system and method for providing application programs access to extension features of third-party resource adapters in addition to allowing application server to monitoring the activities between application programs and resource adapters. It would be desirable to provide the full access to the vendor object to the application programs as well as intercept calls made to and returned from the vendor object to handle server side tasks, global transaction enlistment, connection pooling, statement caching, tracing, and profiling.
A method for dynamically generating a wrapper object for a vendor object at runtime. In one embodiment of the present invention, the Dynamic Generated Wrapper (DGW) is a proxy generated at runtime and acts as a delegate for the underlying vendor object being proxied. In one embodiment, the wrapper class may be a subclass of a statically predefined superclass that includes the programming logic to handle server side tasks. The wrapper class may include methods in the vendor class that are not present in the superclass. A wrapper object is an instance of a wrapper class. The wrapper object may be used to intercept method invocations from an application program to an vendor object and provide the execution of server side tasks in a pre-invocation handler and post-invocation handler. Additionally, the wrapper object may be used to intercept the result of the method invocation against vendor object. The wrapper object may provide for server side tasks to be performed before providing the wrapped result to the application programs. The server side tasks may include global transaction enlistment, resource pooling, resource caching, tracing and profiling.
A wrapper object for a vendor object is generated dynamically at runtime. In one embodiment of the present invention, the Dynamic Generated Wrapper (DGW) is a proxy generated at runtime and acts as a delegate for the underlying vendor object being proxied. In one embodiment, the wrapper class may be a subclass of a statically predefined superclass that includes the programming logic to handle server side tasks. The wrapper class may include methods in the vendor class that are not present in the superclass. The wrapper object may be used to intercept method invocations from an application program to the vendor object and provide the execution of server side tasks in a pre-invocation handler and post-invocation handler. Additionally, the wrapper object may be used to intercept the result of the method invocation against the vendor object. The wrapper object may provide for server side tasks to be performed before providing the wrapped result to the application program. The server side tasks may include global transaction enlistment, resource pooling, resource caching, tracing and profiling.
In one embodiment, it is desirable for application servers that host enterprise applications to allow application programs access to Java Database Connectivity (JDBC) vendor extensions. Accordingly, the wrapper object of the present invention may be implemented as a JDBC wrapper object that acts as a proxy between application programs and JDBC vendor objects. To implement application program access to vendor extension methods, JDBC wrapper class should implement vendor extension interfaces. If the JDBC wrapper class of the present invention does not implement an vendor extension interface, application programs may not utilize; the vendor extension features.
In an application server, an application program may invoke a method against a vendor object. In one embodiment of the present invention, a dynamically generated wrapper is used to intercept transmission between vendor object and application program, initiate processing related to the transmissions, and provide the wrapped result back to the application program.
A typical vendor class may contain a large number of methods. Within these methods, few of them may require special treatment. The special treatment may differ from the typical processing that can be applied to the rest of methods with respect to server side tasks. The remainder of the methods may be handled with a wrapper class in a standard manner such as that illustrated in
In one embodiment, the superclass 220 has several requirements. In one embodiment, the superclass must be public and not final. Thus, the superclass may be extended by the dynamically generated wrapper class. The superclass must implement a predefined wrapper interface that includes the preInvocation and postInvocation handler. The superclass requires a member variable, to hold the proxied vendor object, and a non-arg constructor, to instantiate the wrapper object. The superclass should also have an init method for initializing the generated wrapper object.
Below is an example of what code implementing a super class may look like.
An example of the interface that a superclass implements is shown below.
Next, the system performs reflection on the vendor class at step 320. Reflection is an operational feature of Java that allows meta information, what interfaces vendor class implemented, to be retrieved from code. The retrieved meta information allows the application server to dynamically generate a wrapper class, or proxy class, that perfectly matches with the vendor class. The wrapper class is then generated in memory at step 330. The wrapper class is generated in byte code and extends from the superclass received at step 310. Code is generated for vendor methods not implemented in the superclass. In one embodiment of the present invention, the generated code may be similar to the following code.
In one embodiment, the code is generated using hot code generation techniques as described in related U.S. patent application Ser. No. 10/712,384, entitled “DYNAMIC CODE GENERATION METHOD”, herein incorporated by reference in its entirety. After generating the wrapper class, an instance of the wrapper class, wrapper object, is created at step 340. The vendor object is then associated with the wrapper object at step 350. The returned wrapper object is then provided to the application program such that the application program may access both the standard features and non-standard vendor extensions. In one embodiment, the standard features are J2EE features. Operation of method 300 then ends at step 355. The wrapper class includes all public interfaces implemented by the vendor class required by the application program. As a result, the application program may cast the wrapper object to the vendor interface to access vendor extension methods.
The application server system may have code for generating the wrapper. An example of code for generating the wrapper is below.
Once the wrapper object is dynamically created from the Vendor object and superclass, the wrapper object may be used to wrap the particular vendor object.
After any pre-processing is performed, a call is made to the wrapped vendor object at step 430. The wrapper object forwards the call to the vendor object on behalf of the application program. The result of the vendor object call is then received by the wrapper object at step 440. The wrapper object may then initiate any post-processing to be performed at step 450. In one embodiment, post-processing may include calling a post-invocation handler. The post-invocation handler may be used to perform post-processing server-side tasks including global transaction management and wrap the returned result with another wrapper. At step 460, the wrapped result is provided to the application program. Operation of method 400 then ends at step 465.
In one embodiment of the present invention, a static method may be used to generate a wrapper for a vendor object. An example of code implementing the static method in WLS is shown below.
Other features, aspects and objects of the invention can be obtained from a review of the figures and the claims. It is to be understood that other embodiments of the invention can be developed and fall within the spirit and scope of the invention and claims.
The foregoing description of preferred embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Obviously, many modifications and variations will be apparent to the practitioner skilled in the art. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention for various embodiments and with various modifications that are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalence.
In addition to an embodiment consisting of specifically designed integrated circuits or other electronics, the present invention may be conveniently implemented using a conventional general purpose or a specialized digital computer or microprocessor programmed according to the teachings of the present disclosure, as will be apparent to those skilled in the computer art.
Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art. The invention may also be implemented by the preparation of application specific integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be readily apparent to those skilled in the art.
The present invention includes a computer program product which is a storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the processes of the present invention. The storage medium can include, but is not limited to, any type of disk including floppy disks, optical discs, DVD, CD-ROMs, microdrive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data.
Stored on any one of the computer readable medium (media), the present invention includes software for controlling both the hardware of the general purpose/specialized computer or microprocessor, and for enabling the computer or microprocessor to interact with a human user or other mechanism utilizing the results of the present invention. Such software may include, but is not limited to, device drivers, operating systems, and user applications.
Included in the programming (software) of the general/specialized computer or microprocessor are software modules for implementing the teachings of the present invention, including, but not limited to, dynamically generating a vendor object wrapper.
The present application claims the benefit of priority under 35 U.S.C. §119(e) to U.S. Provisional Patent Application entitled “METHOD FOR DYNAMICALLY GENERATING A WRAPPER”, Application No. 60/450,614, filed on Feb. 28, 2003, which application is incorporated herein by reference.
Number | Name | Date | Kind |
---|---|---|---|
4989132 | Mellender | Jan 1991 | A |
5815415 | Bentley | Sep 1998 | A |
5999988 | Pelegri-Llopart et al. | Dec 1999 | A |
6011917 | Leymann | Jan 2000 | A |
6011918 | Cohen | Jan 2000 | A |
6085030 | Whitehead | Jul 2000 | A |
6085198 | Skinner et al. | Jul 2000 | A |
6125383 | Glynias | Sep 2000 | A |
6157960 | Kaminsky | Dec 2000 | A |
6321261 | Glass | Nov 2001 | B1 |
6381737 | Click | Apr 2002 | B1 |
6385661 | Guthrie | May 2002 | B1 |
6389452 | Glass | May 2002 | B1 |
6415315 | Glass | Jul 2002 | B1 |
6442586 | Glass | Aug 2002 | B1 |
6463460 | Simonoff | Oct 2002 | B1 |
6510550 | Hightower | Jan 2003 | B1 |
6513157 | Glass | Jan 2003 | B1 |
6519653 | Glass | Feb 2003 | B1 |
6523171 | Dupuy et al. | Feb 2003 | B1 |
6535928 | Glass | Mar 2003 | B1 |
6549955 | Guthrie | Apr 2003 | B2 |
6578191 | Boehme et al. | Jun 2003 | B1 |
6622175 | Piller | Sep 2003 | B1 |
6629128 | Glass | Sep 2003 | B1 |
6678743 | Glass | Jan 2004 | B1 |
6834389 | Glass | Dec 2004 | B1 |
6877163 | Jones et al. | Apr 2005 | B1 |
6931455 | Glass | Aug 2005 | B1 |
6947965 | Glass | Sep 2005 | B2 |
6951021 | Bodwell et al. | Sep 2005 | B1 |
6961772 | Wensel | Nov 2005 | B1 |
6993774 | Glass | Jan 2006 | B1 |
7051324 | Gissel et al. | May 2006 | B2 |
7146399 | Fox et al. | Dec 2006 | B2 |
7181745 | Foti | Feb 2007 | B1 |
20020152210 | Johnson et al. | Oct 2002 | A1 |
20030105883 | Gibbons | Jun 2003 | A1 |
20040015832 | Stapp | Jan 2004 | A1 |
20040028031 | Valin et al. | Feb 2004 | A1 |
20040143835 | Dattke et al. | Jul 2004 | A1 |
Number | Date | Country | |
---|---|---|---|
20040172639 A1 | Sep 2004 | US |
Number | Date | Country | |
---|---|---|---|
60450614 | Feb 2003 | US |