Abstract:
A method and system to construct Java representations of metadata in an enterprise application. The system extracts metadata from application source code and deployment descriptors to construct a single output available to the application.

Description:
FIELD OF INVENTION 
       [0001]    The invention relates generally to enterprise applications, and, more specifically, to processing metadata in enterprise applications. 
       BACKGROUND 
       [0002]    Application servers are platforms that host and provide services to applications. Application servers manage the life cycles of applications and take care that the logic implemented in applications is accessible to clients in a centralized fashion. Application servers based on the Java™ Platform, Enterprise Edition 5 (hereinafter “Java EE”) host and provide services to Java enterprise applications (also referred to as “Java EE applications”). Such applications are written in the Java language and conform to a set of specifications so that they can run on a Java application server. Application server vendors develop application servers in accordance with the rules and requirements set forth in the Java EE 5 specification. A Java EE application has application code and configuration information packed into an Enterprise Application Archive (hereinafter “EAR”). The EAR contains one or more modules of a specific type, for example, web modules, web services modules, Enterprise JavaBeans (hereinafter “EJB”) modules, and deployment descriptors. Each of these modules is an archive of the respective type. In each of these archives, there is application source code written in the Java language and application configuration information written in eXtensible Markup Language (hereinafter “XML”) format, placed in deployment descriptor files. 
         [0003]    Java EE 5 provides a number of new features as compared to previous versions of the platform. For example, Java EE 5 provides a new way to specify application configuration information, in addition to deployment descriptor files. Java EE 5 supports configuration information supplied with annotations. Annotations are metadata written directly into source code and read by the application server at deploy time and at runtime. Each enterprise technology specification supports a set of annotations that can be used to configure and influence the behavior of the respective application type. For example, the EJB 3.0 specification supports annotations that denote source code as a bean of a specific type, such as session bean or a message-driven bean, and so on. All the metadata that can be supplied with annotations can also be supplied with deployment descriptors. 
         [0004]    When an EJB application is deployed on an application server, the server has to process application source code and both sources of metadata so that a fully functional application is available on the server for clients to use. The EJB specification prescribes what an EJB container on a Java EE application server should support and what rules it should observe when processing application source code and application metadata. However, the specification does not prescribe how such requirements should be implemented by application server vendors. It is up to the application server vendor to decide how to implement all the requirements set forth in the specification so that the application server complies with the specification. 
       SUMMARY 
       [0005]    A system and method to process metadata in an enterprise application is described. The system extracts metadata from a number of sources and combines input into a unified model of all metadata supplied with the application. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0006]    The invention is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. It should be noted that references to “an” or “one” embodiment in this disclosure are not necessarily to the same embodiment, and such references mean at least one. 
           [0007]      FIG. 2  is a block diagram of an enterprise application. 
           [0008]      FIG. 2  is a block diagram of an Enterprise Java Beans application. 
           [0009]      FIG. 3  is a flowchart of a process performed by an embodiment of the invention. 
           [0010]      FIG. 4  is a block diagram of a system implemented according to an embodiment of the invention. 
           [0011]      FIG. 5  is a block diagram of a system implemented according to another embodiment of the invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0012]    Descriptions of certain details and implementations follow, including a description of the figures, which may depict some or all of the embodiments described below, as well as discussing other potential embodiments or implementations of the inventive concepts described herein. 
         [0013]    Java EE application servers run Java EE applications. Each enterprise application has different modules that pack source code and metadata for specific components, as shown on  FIG. 1 . For example, the enterprise application  100  has deployment descriptors  105  that specify metadata pertaining to the whole enterprise application; it also has an EJB module  110 , a web module  120 , and an application client module  130 . The EJB module  110  represents an EJB application. EJB applications run on an EJB container. Referring to  FIG. 2 , each EJB application  200  has bean classes  210 , interfaces  220 , and a deployment descriptor  230 . With version 3.0 of the EJB specification, metadata can be placed both in the deployment descriptor and in bean classes  210  and interfaces  220 . From an application developer point of view, all configuration information that can be supplied with annotations can also be supplied in a deployment descriptor. As such, an EJB container must provide a mechanism to obtain and interpret the metadata from both sources. Because annotations and deployment descriptors provide the same functionality, some entries may be duplicated in both sources. Consequently, the EJB container must also provide a mechanism to evaluate metadata and decide which source takes preference so that no conflicts exist in the application logic. The EJB specification specifies only that the EJB container should be able to treat the logical semantic of metadata correctly to correctly set up the runtime environment for the EJB application. It is up to the application server vendor to define the way in which the EJB container should obtain the metadata and represent it to the running application. 
         [0014]    In an embodiment of the invention, the EJB container provides a mechanism to read and combine metadata as described in  FIG. 3 . Referring to  FIG. 3 , when an EJB application is deployed, the EJB container first parses program code  305  in the application in order to identify metadata in the program code  310 . As described herein, program code is understood to mean both source code as written by an application developer and bytecode as compiled source code. Then the metadata is extracted  315  and a Java model of the metadata is built  320 . Thus, all annotations are extracted from the program code are represented in Java in the model. Then, the deployment descriptor is parsed  325  and the metadata in it is identified  330 . The metadata is extracted  335  and a second Java model is built  340  from the metadata in the deployment descriptor. 
         [0015]    Annotations and the deployment descriptor are written in their own formats. In order for the EJB container to evaluate them consistently and efficiently, it represents them in Java and creates a Java model of the metadata from each source accordingly. To create each model, the EJB container accesses a core metadata model. The core metadata model has Java representations of all metadata supported by the EJB specification. To build the first Java model and the second Java model, the EJB container accesses the core metadata model and maps each extracted metadata to an instance of a class from the core metadata model. Thus, once it iterates over the complete collection of extracted metadata it has mapped each piece of data to an instance of a Java class representing it. With the two models ready, the system proceeds to merge them so that a unified model of the metadata in the application logic is constructed. To merge the models, the system uses a set of rules in order to compare the models and evaluate each duplicate entry. The set of rules specifies how entries from each source should be treated and when entries from one source should take precedence over the other. For example, generally metadata from the deployment descriptor takes precedence over the metadata obtained from annotations. 
         [0016]    To combine metadata in a unified Java model, an EJB container according to the embodiment of the invention implements a system of elements as outlined in  FIG. 4 . Each source of metadata has a dedicated builder to build the Java model from that source. Referring to  FIG. 4 , the program code  410  is read by the builder  430 . The builder  430  extracts metadata from the program code and maps it to metadata classes from the core metadata model  490 . Thus the builder  430  constructs the first Java model  450 . Similarly, the builder  440  reads the deployment descriptor  420  and maps it to metadata classes from the core metadata model  490 . Thus the builder  440  constructs the second Java model  460 . Then the first Java model  450  and the second Java model  460  are supplied to the merger  470 . The merger  470  compares the models and combines them into a unified model  480 . 
         [0017]    Once the unified model is constructed, each element in the model is assigned a unique key. Thus the unified model is navigable as each element can be traced via its key. Element keys can also be used for logging purposes. For example, if an event needs to be logged it can be traced to the element that produced it and logged as produced by that element. When application behavior is analyzed, events can be traced back not only to the application but to pieces of logic in the application that invoked the events in question, such as specific classes or methods. 
         [0018]    In another embodiment of the invention, the business logic to analyze metadata is packaged in an external library and thus integrated in different environments as a standalone module. For example, an external library can be integrated in a development environment and used to analyze source code at development time. Such an implementation is very valuable because usually, in order to test applications, application developers must package their applications and deploy them on an application server. With the possibility to test applications as they are written, the application developers can save time and resources. Referring to  FIG. 5 , a system is implemented to obtain and process metadata. The input module  510  obtains the source to be analyzed, the parsing module  520  parses the source code and identifies the metadata therein. The system has a number of different builders, such as builder 1   540  and builder 2   550  that can read metadata from dedicated sources. In the event that metadata is supplied by new sources the system is extended to accommodate new builders to deal with alternative sources of input. The system also logs results from the operation via a logging module  530  to a permanent store  580  for later retrieval. 
         [0019]    With the advent of Java EE 5, all types of enterprise applications support annotations and thus are faced with the problem of combining metadata from different sources. As such, the embodiments of the invention are not limited to EJB applications only, as described above. Embodiments of the invention can easily be applied to any type of enterprise application such as a web application, a web services application, and so on. 
         [0020]    Elements of embodiments may also be provided as a machine-readable medium for storing the machine-executable instructions. The machine-readable medium may include, but is not limited to, flash memory, optical disks, CD-ROMs, DVD ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cares, propagation media or other type of machine-readable media suitable for storing electronic instructions. For example, embodiments of the invention may be downloaded as a computer program which may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection). 
         [0021]    It should be appreciated that reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Therefore, it is emphasized and should be appreciated that two or more references to “an embodiment” or “one embodiment” or “an alternative embodiment” in various portions of this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures or characteristics may be combined as suitable in one or more embodiments of the invention. 
         [0022]    In the foregoing specification, the invention has been described with reference to the specific embodiments thereof. It will, however, be evident that various modifications and changes can be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.