Method and apparatus for verifying Enterprise Java Beans

[0002] 1. Technical Field

[0003] The present invention generally relates to distributed data processing systems and in particular to server programming in distributed data processing systems. Still more particularly, the present invention relates to verification tools for pre-developed program applications deployed to the distributed data processing systems.

[0004] 2. Description of the Related Art

[0005] Java™ (a trademark of Sun Microsystems, Inc. of San Jose, Calif.) is a type of object-oriented software programming language that enables programmers to create program applications and small programs called applets. A virtual machine is generated-by Java™ (Java) that provides a control interface allowing a Java™ program to overlay and operate on virtually any operating system.

[0006] Java was developed with distributed computing, low to no administration and platform independence in mind. The Java platform for enterprise-capable Java computing utilizes Enterprise JavaBean™ (EJBean) (trademark of Sun Microsystems) technology that provides for the development and deployment of reusable server components. EJBean (referred to hereinafter as Enterprise Java Bean, EJB or EJBean) server components are serveriside object oriented objects that run in an application server, with interfaces, that are typically deployed on one computer and may be invoked by a client from another computer and manipulate a database management system on the server. EJBeans are stored in a Java Archive (JAR) file which contains a Manifest file located at META-INF/MANIFEST.MF within the archive.

[0007] Referring to FIG. 3, a block diagram of a prior art JAR file, is illustrated. EJBeans are typically distributed and installed in a development environment by packaging them in a JAR file. These files are essentially ZIP files that are created using a JAR utility. The illustrated JAR file has subdirectory 300 of meta-information that is always named META-INF. Subdirectory 300 contains a single Manifest file 302 that is always named MANIFEST.MF. The MANFEST.MF file contains arbitrary information about the files in the archive, such as their encoding or language. The JAR file is capable of containing signature files named “name.SF” 304. There is one of these files for each entry that has signed files in the archive. In addition, the JAR file may contain zero or more digital signature files named “name.suf” 306, where the suffix (e.g., RSA) is determined by the digital signature format. There is a least one of these files for each signature instruction file. In addition to the MANIFEST.MF subdirectory, the archive contains whatever files (EJBean) 308 a user wishes to package in the archive.

[0008] EJBeans operate within-logical “containers” and are designed to support high scalability using a multi-tier distributed application architecture. (architecture that has multiple application components) and the multi-tier orientation provides many advantages over traditional client/server architectures. Containers provide security, remote access, concurrency, transactions, etc., and may span multiple servers. EJBean components:contain no system level programming, include only business related logic and are fully portable across any EJBean compliant server and any Operating System (OS). Some advantages to EJBean components include reusability, performance, scalability, wire protocol neutral architecture and manageability among others.

[0009] Locating logic, EJBeans, for manipulating data on one or more servers allows an application to operate in multi-processing and multi-threaded systems. Server components can be replicated and distributed across multiple systems enabling multi-tier systems with a scalability of essentially no limit. With a multi-tier environment, reliability is high and manageability is easier because most of the application logic is on the server.

[0010] A server component is a reusable software application that performs specific functions and is accessible to any other application through the server component's interface. A server component can be developed for one application and reused in another application that may require the function. Basically, server components are basic building blocks that have specific, published functions that can be combined with other components and applications into a configuration that performs a task designed by a developer.

[0011] Traditionally, a Java Virtual Machine (JVM) allows a Java application to run on any operating system, but server side components require proprietary programming interfaces based on vendor software and hardware. EJBean serve side components are portable and virtually vehdor-independent on all Java EJBean compliant application servers. With server component portability, increased scalability, reliability and re-usability, EJBean components can be moved from one execution environment to another without requiring any recoding Determining whether a new component is valid is a problem that accompanies portability and reusability of EJBean components. EJBean components are required to implement a specific set of interfaces with the container that encloses the beans so the container can manage and control the bean. If the component has a purported function and is moved from one execution environment to another, the component should be validated before being deployed throughout the system served by an EJBean compliant server.

[0012] Therefore, it would be desirable for the EJBean server program to validate, before deploying, any EJBean server component. It would also be desirable to validate a newly developed EJBean server component. It would further be desirable have the capability to verify any EJBean component at any time, even during operation.

[0013] It is therefore one object of the present invention to provide a tool that will enable a developer to verify an EJBean server component prior to use in a data processing system.

[0014] It is another object of the present invention to provide a tool that will validate an EJBean server component utilizing a Java Archive file.

[0015] It is yet another object of the present invention to provide a tool that will validate an EJBean component prior to deployment.

[0016] The foregoing objects are achieved as is now described. The introspection capability of Java is utilized by the described verification tool to verify validity of a target bean's Java Archive (JAR) file. The deployment descriptor class is verified first according to Enterprise Java Bean specification rules. The remaining classes: remote interface, home interface and bean class are all loaded into a Java Virtual Machine (JVM) and verified by the described verification tool through Java introspection.

[0017] The above as well as additional objectives, features, and advantages of the present invention will become apparent in the following detailed written description.

[0018] The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself however, as well as a preferred mode of use, further objects and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:

[0019] FIG. 1A depicts a distributed computing system in accordance with a preferred embodiment of the present invention;

[0020] FIG. 1B is a high-level block diagram of operation of an Enterprise Java bean in accordance with the present invention;

[0021] FIG. 2A depicts a high-level flow diagram for verifying Enterprise Java Beans, whether imported or developed locally, in accordance with the present invention;

[0022] FIG. 2B is a high-level flow diagram for verifying a remote interface of an Enterprise Java Bean in accordance with the present invention;

[0023] FIG. 2C depicts a high-level flow diagram for verifying validity of a home interface of an Enterprise Java Bean in accordance with the present invention; and

[0024] FIG. 2D illustrates a high-level flow diagram for verifying validity of the home interface of an Enterprise Java Bean in accordance with the present invention is continued from FIG. 2C;

[0025] FIG. 2E illustrates a high-level flow diagram for verifying validity of the home interface of an Enterprise Java Bean in accordance with the present invention is continued from FIG. 2D;

[0026] FIG. 2F depictstat high-level flow diagram for verifying validity of an Enterprise Java Bean through introspection, in accordance with the present invention; and

[0027] FIG. 3 illustrates a block diagram of a prior art JAR file.

[0028] With reference now to the figures, and in particular with reference to FIG. 1, a distributed computing system in accordance with a preferred embodiment of the present invention, is depicted. System 100 includes server 102, Enterprise Java Bean 104 (EJBean), Internet 106 and separate installations 108 through 112. On server 102, multiple EJBean 104 components may exist at any one time, providing various business related functions. Server 102 must be Enterprise Java Bean compliant and must supply a standard set of services to support EJBean 104 components. Additionally, server 102 must provide a container for the EJBean 104 component which implements control and management for classes of the EJBean 104. Since EJBean 104 components do not require a specific container system, virtually any application server can be adapted to support EJBean 104 components, by adding support for the service defined in the EJB specification.

[0029] In the present invention, Internet 106 provides the connection between systems 108-112 and systems 108-112 represent Local Area Networks (LAN), standalone computers, Wide Area Networks (WAN), any data processing system that may connect with server 102 through Internet 106. Multiple systems may connect at the same time with EJBean 104, via home and remote interfaces, utilizing Internet 106 browser clients. Each Enterprise Java Bean is stored in a logical container (see FIG. 1B) and any number of EJBean 104 classes can be present in a single container. A container may not necessarily be present in a single server location and the EJB container could be replicated and distributed across many systems. EJBean 104 may be transient or persistent. A transient bean is termed a “session” bean and a persistent bean is termed an “entity” bean. Session beans are temporary and usually exist only for a single client/server session.

[0030] Referring to FIG. 1B, a high-level block diagram of operation of an Enterprise Java bean in accordance with the present invention, is illustrated. Client 120 is a Java compliant program originating on a data processing system that is typically remote from the server. Container 114 is the interface between client 120 and EJBean 104. When EJBean 104 is to be deployed (accessed by client 120), container 114 automatically produces home interface 116 and remote interface 118. Remote interface 118 provides access, by client 120, to business methods within EJBean 104. Home interface 116 identifies EJBean 104 class and is utilized to create, find and remove EJBean l04 instances. Essentially, container 114 acts as a filter and provides rules concerning transactions, state, security, etc., on all operations. Additionally, container 114 provides an interface with data sources 122, external to the container, that EJBean 104 utilizes during transactions.

[0031] Introspection is the process of discovering properties, methods and events of a component object, all the necessary information about a bean, at runtime. Introspection of an EJBean is accomplished through a set of Java's runtime classes. Java Development Kit (JDK) includes three parts: the interpreter or JVM; a runtime class library—“classes.zip”, which includes all the Java runtime classes that can be used by a Java program; and a set of programming tools including the Java compiler. Introspection utilized in the present invention is part of the Java runtime class library and consists of several classes: “Class”, “Method”, “Field”, “Array” and “Modifier. To introspect an object a call is made to retrieve information on each class. For instance, a “getClass” call is made to get the object's “Class” details. A “getMethods” call is made on the “Class” object to retrieve a “Method” object array of all the methods defined in that class. All the fields (properties) and constructors defined on that class are retrieved in a similar fashion. The process then loops through each “Method” or “Field” to get more detailed information such as method parameters and field types. The introspection classes provide the detailed information of a class and the information is utilized to verify the EJBean.

[0032] Referring now to FIG. 2A, a high-level flow diagram for verifying Enterprise Java Beans, whether imported or developed locally, in accordance with the present invention is depicted. The process begins with step 200, which depicts activation of a verifier tool. The process then proceeds to step 202, which illustrates the verifier tool invoking introspection methods. The process then proceeds to step 204, which depicts a Java Development Kit introspecting a deployment descriptor of the subject EJBean. Next, the process proceeds to step 206, which is a determination of whether the class inheritance of the deployment descriptor is a subclass of either an EntityDescriptor or a SessionDescriptor (types of bean descriptors).

[0033] If the class inheritance is neither an EntityDescriptor or a SessionDescriptor the process proceeds to step 207, which depicts throwing (signaling or indicating) an error. Each error thrown is specifically determined by the verifier tool and displayedon the tool operator's terminal, thus providing efficient error discovery and thus, efficient error correction. The process then proceeds to step 209, which illustrates the verifier tool aborting the verification process. Returning to step 206, if the class inheritance is a subclass of either an EntityDescriptor or a SessionDescriptor, the process proceeds instead, to step 208, which illustrates a determination of whether data type linked to the EJBean is primitive, remote or value type.

[0034] If Container managed (CM) field's data type is neither primitive, remote nor value type, the process proceeds to step 207, which illustrates the verifier tool throwing an error. The process then proceeds to step 209, which depicts the verifier tool aborting, or stopping, the verification process. If the data type is primitive, remote or value type, the process then passes from step 208 to step 210, which illustrates determining whether each CM field has a matching EJBean field. Mapping between CM field and EJBean field is not 1:1 mapping. For each CM field there must be a EJBean field to match it, though not all EJBean fields require a matching CM field. If any CM field does not have a matching EJBean field the process proceeds to step 207, which depicts an error being thrown respective to the field mismatch. The process then proceeds to step 209, which illustrates the verifier tool stopping the verification process. Returning to step 210, if the EJBean fields and container managed fields all match, the process then proceeds to step 212, which depicts a determination of whether the entity bean key class is serializable.

[0035] If the key class is not serializable, the process moves to step 213, which illustrates an error being thrown. The process then passes to step 209, which depicts the verifier tool aborting verification. Returning to step 212, if the entity bean key class is serializable, the process then passes to step 214, which illustrates a determination of whether each key field has a matching container field. If there is a key field and container managed field mismatch, the process proceeds to step 213, which illustrates an error being thrown. Each key field requires a matching CM field, but some CM fields may not have a matching key field. The process then proceeds to step 209, which illustrates the verifier tool aborting the verification process. Returning to step 214, if each key field has a matching CM field, the process then proceeds to step 216, which illustrates a determination of whether, at most, one control descriptor has no bean method. If this is not true, the process proceeds to step 213, which illustrates an error being thrown. The process then passes to step 209 to discontinue the verification process.

[0036] Returning to step 216, if at most, only one control descriptor has no bean method, the process continues to step 217, which illustrates a determination of whether there are two control descriptors defined for the same bean method. If there are two control descriptors defined for the same bean method, the process proceeds to step 213, which depicts throwing an error. The process then passes to step 209, which illustrates the verification tool aborting the verification process. If more than one control descriptor are found for the same method, the process proceeds instead from step 217 to step 218, which depicts determining whether the descriptor method matches the method in the EJBean. If the methods don't match, an error is thrown and the process moves to step 209, where the verification tool aborts the verification process. If the descriptor method does match the method in the EJBean, the process then passes to step 230 in FIG. 2B via connector A, which illustrates beginning introspection of the EJBean remote interface.

[0037] Referring to FIG. 2B, a high-level flow diagram for verifying the remote interface of an EJBean in accordance with the present invention is illustrated. The process begins with connector A, which is a continuation of a successful verification of the deployment descriptor. The process proceeds to step 230, which depicts introspection of the remote interface. The process then passes to step 232, which illustrates a determination of whether the class inheritance is a subclass to EJBObject. If the class inheritance is not a subclass the process passes to step 233, which depicts an error being thrown. Process then passes to step 234, which illustrates the verification tool aborting the verification process.

[0038] Returning to step 232, if class inheritance is a subclass of EJBObject, the process instead proceeds to step 236, which depicts a determination of whether the method returned type is void, primitive, remote or value type. If the return type is not void, primitive, remote or value type, the process proceeds to step 233, which depicts an error being thrown. The process then passes to step 234, which depicts the verification tool aborting the verification process. Returning to step 236, if the Return type is void, primitive, remote or value type, the process instead proceeds to step 238, which illustrates a determination of whether each argument data type is primitive, remote or value type. If any argument data type is not primitive, remote or value type, the process proceeds to step 233, which depicts an error being thrown. The process then proceeds to step 234 which illustrates the verification tool aborting the verification process. Returning to step 238, if each data type is primitive, remote or value type, the process then passes to step 240, which depicts a determination of whether each remote interface method throws a java.rmi.RemoteExceltion. If any remote interface method does not throw the java.rmi.RemoteException, the process passes to step 233, which illustrates throwing an error. The process then proceeds to step 234, which depicts the verification tool aborting the verification process. If, in step 240, the determination is made that each method does throw a java.rmi.RemoteException, the process instead proceeds to step 242, which illustrates a determination of whether there is a matching EJBean method for each method in the remote interface. Each method in the remote interface must have a matching bean method, but the bean method is not required to match up with the remote interface method. If each method in the remote interface does not match each EJBean method, the process passes to step 233, which depicts an error been thrown. The process then continues to step 234, which illustrates discontinuing the verification process. If the determination is made that each method in the remote interface has a matching EJBean method, the process instead passes to step 250 in FIG. 2C via connector B to begin a verification process for the home interface.

[0039] Referring now to FIG. 2C, a high-level flow diagram for verifying validity of a home interface for an Enterprise Java Bean in accordance with the present invention is depicted. Beginning with connector B, following a successful verification of the remote interface, the process moves to step 250, which depicts the verifier tool beginning introspection of the home interface. The process passes to step 252, which illustrates a determination of whether EJBean's home interface class inheritance is a subclass of EJBHome. If the class inheritance is not a subclass of EJBHome, the process proceeds to step 253, which depicts an error regarding class inheritance being thrown. The process then passes to step 254, which illustrates the verification tool aborting the verifications process. If it is determined that the class inheritance is a subclass of EJBHome, the processpasses instead to step 260 in FIG. 2D, via connector C.

[0040] Referring now to FIG. 2D, a high-level flow diagram for verifying validity of the home interface of an Enterprise Java Bean in accordance with the present invention is continued from FIG. 2C. The process moves from connector C to step 260, which depicts a determination of whether the EJBean has only finder or create methods. If not, the process proceeds to step 262, which illustrates an error being thrown. The process then passes to step 264, which illustrates aborting the verification process. Arguments of each finder methodare used by entity bean implementation to locate requested entity objects. Arguments of the create methods are typically used to initialize the state of a created entity object and the return type of a create method is the entity bean's remote interface. The throws clause of every finder and create method includes java.rmi.RemoteException, javax.ejb.FinderException or javax.ejb.CreateException.

[0041] Returning to step 260, if there are only finder or create methods, the process then passes to step 266, which depicts a determination of whether the EJBean is a session bean. If the EJBean is a session bean, the process proceeds to step 268.

[0042] Returning to step 266, if the determination is made that the EJBean is not a session bean, the process instead proceeds to step 267, which illustrates a determination of whether a findByPrimaryKey method is present. If the findByPrimaryKey (allows a client to locate an entity object using a primary key; return type is Entity bean's remote interface) method is present, the process passes to step 270 which depicts confirming the data type. The process then continues, via connector D to steps 274 and 278 in FIG. 2E. If there is no findByPrimaryKey method, the process passes from step 267 to step 262, which depicts an error being displayed/thrown. Next the process continues to step 264, which illustrates the verification tool discontinuing the verification process.

[0043] Returning to step 268, if the determination is made that there is no finder method present, the process passes instead to step 269, which illustrates a determination of whether the EJBean is a stateless session bean. If the EJBean is determined not to be stateless, the process proceeds to step 270, which depicts confirming the data type. If the EJBean is determined to be stateless, the process instead proceeds to step 272, which depicts a determination of whether there is “one create method without parameter” present. If not, the process moves to step 262, which illustrates an error being thrown. The process then passes to step 264, which depicts discontinuing the verification process. If the one create method without parameter is present, the process instead proceeds to step 270, which illustrates confirming the data type. The verification process then proceeds to step 274 in FIG. 2E via connector D.

[0044] Referring to now FIG. 2E, a high-level flow diagram for verifying validity of the home interface of an Enterprise Java Bean in accordance with the present invention is continued from FIG. 2D. Continuing from FIG. 2D via connector D, the process proceeds to step 274, which depicts a determination of whether the create method returns EJBObject (class instance that implements the EJBean's remote interface). If not, the process passes to step 276, which illustrates an error being thrown/displayed. The process continues to step 277, which illustrates the verification tool aborting the verification process. If, in step 274, Create method returns EJBObject, the process proceeds instead to step 282, which depicts a determination of whether the parameter's data type is remote, value type or primitive. If the parameter's data type is not remote, value type or primitive, the process passes to step 276, which illustrates an error being returned and the process continues to step 277, which depicts discontinuation of the verification process.

[0045] Returning to connector D, concurrently with step 274, the process passes to step 278, which depicts a determination of whether the Finder method returns either EJBobject or Enumeration. If not, the process passes to step 279, which illustrates an error being thrown by the process. The process then passes to step 280, which depicts discontinuing the verification process. If the Finder method does return EJBObject or Enumeration in step 278, the process instead proceeds to step 282, where a determination is made whether the parameter's data type is remote, value type or primitive. If not, the process passes to step 276, which illustrates an error being thrown by the process. The IS process then continues to step 277, signifying that the verification process is discontinued.

[0046] Returning to step 282, if both the Finder method and the Create method have a correct return type and the parameter's data type is remote, value type or primitive, the process proceeds to step 284 and 286 simultaneously. Step 284, illustrates whether a create method of the EJBean's remote interface throws CreateException and Remote exception. A create method must throw CreateException and remote exception. Create methodmay also throw user defined exceptions, but not any other system exceptions. If not, the process passes to step 276, which depicts an error being thrown. The process then continues to step 277, which illustrates discontinuation of the verification process.

[0047] If the home's create method throws CreateException and RemoteException, the process proceeds instead to step 288, which depicts a determination of whether the finder and create method is throwing any system exception other than remote, finder or create. No other system exception may be thrown unless the exception is a remote exception, create exception or finder exception. If the determination is made that a system exception other than a remote, create or finder exception is thrown, the process passes to step 287, which illustrates an error being thrown. The process continues to step 280, which depicts the verification process being discontinued.

[0048] If the determination is made that the only system exception thrown is either a remote, create or finder exception, the process proceeds instead, to step 290, which illustrates a determination of whether the EJBean method is mapped. If not, the process passes to step 287, which illustrates an error being thrown. Next, the process passes to step 280, which depicts discontinuing the verification process. At the same time that the determination is being made on whether the CreateFinder method throws CreateException and RemoteException, the process concurrently passes to step 286, which illustrates determination of whether the finder method throws FinderException and RemoteException If not, the process moves to step 287, which depicts throwing an error. The process then proceeds to step 280, which illustrates discontinuation of the verification process.

[0049] Returning to step 286, if the determination is made that the home's finder method throws FinderException and RemoteException, the process proceeds instead to step 288, which depicts a determination of whether the finder and create method is throwing any other system exception. If not, the process passes to step 287, which depicts throwing an error and continues to step 280, which illustrates discontinuing the verification process. If the determination is made that a system exception other than a remote, create or finder exceptionis thrown, the process passes instead to step 290, which depicts a determination of whether the EJBean method is mapped. If the EJBean is not mapped, the process passes to step 287, which illustrates throwing an error. The process continues to step 280, which depicts discontinuation of the verification process. If instead, the determination is made that the EJBean method is mapped, the process instead, proceeds to step 300, in FIG. 2F, via connector E.

[0050] Referring now to FIG. 2F, a high-level flow diagram for verifying validity of an Enterprise Java Bean through introspection in accordance with the present invention, is depicted. Beginning with connector E, the process continues to step 300, which depicts beginning introspection of the Enterprise Java bean utilizing the JAR files of the bean. The process passes to step 302, which illustrates a determination of whether the bean is an entity bean or a session bean. If the bean is an entity bean, the process proceeds to step 303, which depicts a determination of whether the entity bean implements javax.ejb.EntityBean. If not the process proceeds to step 314, which illustrates an error being thrown and the process continues to step 316, which depicts the verification tool aborting the verification process. If the Entity bean implements javax.ejb.EntityBean, the process proceeds instead to step 308, which illustrates a determination that the EJBean class is public and not abstract. The process then passes to step 310, which depicts confirmation of the validity of the Enterprise Java Bean.

[0051] Returning to step 302, if the determination is made that the EJBean is a session bean, the process passes to step 304, which depicts a determination of whether the session bean is stateless or not. If the session bean is stateless, the process passes to step 306, which illustrates a determination of whether the bean implements javax.ejb.SessionSynchronization (provides session bean instances with transaction synchronization interface). If javax.ejb.SessionSynchronization is implemented, the process proceeds to step 308, which depicts a determination that the EJBean class is public and not abstract. The process continues to step 310, which illustrates verifidation of the Enterprise Java Bean as valid. If javax.ejb.SessionSynchronization is not implemented the process proceeds instead, to step 314, which depicts the verification process throwing an error. The process then continues to step 316, which illustrates discontinuing the verification process.

[0052] Returning to step 304, if the Enterprise Java Bean is determined not to be stateless, the process proceeds instead to step 312, which depicts a determination of whether the session bean implements javax.ejb.SessionBean. If not, the:. process passes to step 314, which illustrates an error being thrown. The process then passes to step 316, which depicts the discontinuation of the verification process. If in step 312, the session bean does implement javax.ejb.SessionBean, the process proceeds instead to step. 308, which depicts the Enterprise Java Bean class being designated as public and not abstract. The process continues to step 310, which, illustrates confirmation of the validity of the Enterprise Java Bean.

[0053] It is important to note that while the present invention has been described in the context of a fully functional data processing system and/or network; those skilled in the art will appreciate that the mechanism of the present invention is capable of being distributed in the form of a computer usable medium of instructions in a variety of forms, and that the present invention applies equally regardless of the particular type of signal bearing medium used to actually carry out the distribution. Examples of computer usable mediums include: nonvolatile, hard-coded type mediums such as read only memories (ROMs) or erasable, electrically programmable read only memories (EEPROMs), recordable type mediums such as floppy disks, hard disk drives and CD-ROMs, and.transmission type mediums such as digital and analog communication links.

[0054] An exemplary set of instructions for determining validity of an Enterprise Java Bean in accordance with the preferred embodiment is shown below. It should be understood by those skilled in the art that changes in structure and order of the compilation may be made without altering the scope and spirit of the embodiment.

[0055] While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention.