US20080270974A1

US20080270974A1 - Enterprise JavaBeans Metadata Model

Info

Publication number: US20080270974A1
Application number: US11/966,849
Authority: US
Inventors: Krasimir Topchiyski; Alexandrina Ivanova; Hristo Sabev; Vladimir Pavlov
Original assignee: Individual
Current assignee: SAP SE
Priority date: 2007-04-30
Filing date: 2007-12-28
Publication date: 2008-10-30
Also published as: US20080270986A1; US8261272B2; US20080271044A1; US8082508B2; US9065843B2; US20080270992A1; US20080270617A1; US20080270600A1; US8510717B2; US7962612B2; US20080270924A1

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

The invention relates generally to enterprise applications, and, more specifically, to processing metadata in enterprise applications.

BACKGROUND

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.
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.
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

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

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.

FIG. 2 is a block diagram of an enterprise application.

FIG. 2 is a block diagram of an Enterprise Java Beans application.

FIG. 3 is a flowchart of a process performed by an embodiment of the invention.

FIG. 4 is a block diagram of a system implemented according to an embodiment of the invention.

FIG. 5 is a block diagram of a system implemented according to another embodiment of the invention.

DETAILED DESCRIPTION

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.
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.
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.
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.
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.
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.
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 builder1 540 and builder2 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.
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.
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).
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.
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.

Claims

1. A method of generating a unified metadata model for a java enterprise application comprising:

extracting metadata from program code;

building a first java model of the metadata extracted from the program code;

extracting metadata from a deployment descriptor;

building a second java model of the metadata extracted from the deployment descriptor; and

merging the first and second models.

2. The method of claim 1, wherein program code comprises java source code and bytecode.

3. The method of claim 1, wherein extracting metadata from program code comprises:

parsing the program code; and

identifying metadata in the program code.

4. The method of claim 1, wherein building the first java model from the metadata extracted from the program code comprises:

accessing a model comprising java classes representing metadata in java code;

identifying an instance of a class from the model that represents the extracted metadata; and

mapping the extracted metadata to the identified instance of the class.

5. The method of claim 1, wherein extracting metadata from a deployment descriptor comprises:

parsing the deployment descriptor; and

identifying metadata in the deployment descriptor.

6. The method of claim 1, wherein building the second java model from the metadata extracted from the deployment descriptor comprises:

accessing a model comprising java classes representing metadata in java code;

mapping the extracted metadata to the identified instance of the class.

7. The method of claim 1, wherein merging comprises:

parsing the first metadata model;

parsing the second metadata model;

combining the first and second models in a unified model using a set of rules;

constructing a logical graph of the unified model; and

assigning each element in the unified model a unique identifier representing the absolute path to the model element in the graph.

8. The method of claim 7, wherein combining the first model and the second model into a unified model comprises applying the set of rules so that no conflicts exist in the application logic.

9. An apparatus comprising:

a core metadata model to maintain java representations of metadata objects;

a first builder to construct a java model of metadata in program code using the core metadata model responsive to receiving the program code;

a second builder to construct a java model of metadata in a deployment descriptor using the core metadata model responsive to receiving the deployment descriptor; and

a merger to receive the models from the first and second builder and unite the first model and the second model.

10. The apparatus of claim 9, wherein each of the builders maps metadata objects to instances of classes from the core metadata model.

11. The apparatus of claim 9, wherein the merger merges the models against a set of rules.

12. A system to run Enterprise Java Beans (EJB) applications, the system comprising:

an input module to receive an EJB application;

a parsing module to parse the metadata in the EJB application; and

a set of builder modules to build Java models of the metadata in the EJB application;

a permanent store to store processed EJB applications; and

a network infrastructure to connect the permanent store to the container.

13. The system of claim 12, further comprising a logging module to log events produced by the EJB application.

14. The system of claim 12, wherein the set of builder modules comprises:

a first builder module to build a first Java model of metadata from Java source code; and

a second builder module to build a second Java model of metadata from a deployment descriptor.

15. A machine readable medium having instructions therein that when executed by the machine, cause the machine to:

extract metadata from program code;

build a first java model of the metadata extracted from the program code;

extract metadata from a deployment descriptor;

build a second java model of the metadata extracted from the deployment descriptor; and

merge the first and second models.

16. The machine readable medium of claim 15, wherein program code comprises java source code and bytecode.

17. The machine readable medium of claim 15, wherein instructions causing the machine to extract metadata from program code, cause the machine to:

parse the program code; and

identify metadata in the program code.

18. The machine readable medium of claim 15, wherein instructions causing the machine to build the java model from the metadata extracted from the program code, cause the machine to:

access a model comprising java classes representing metadata in java code;

identify an instance of a class from the model that represents the extracted metadata; and

map the extracted metadata to the identified instance of the class.

19. The machine readable medium of claim 15, wherein instructions causing the machine to extract metadata from a deployment descriptor, cause the machine to:

parse the deployment descriptor; and

identify metadata in the deployment descriptor.

20. The machine readable medium of claim 15, wherein instructions causing the machine to build the java model from the metadata extracted from the deployment descriptor, cause the machine to:

access a model comprising java classes representing metadata in java code;

map the extracted metadata to the identified instance of the class.

21. The machine readable medium of claim 15, wherein instructions causing the machine to merge, cause the machine to:

parse the first metadata model;

parse the second metadata model;

compare the first metadata model to the second metadata model using a set of rules;

combine the first and second models in a unified model;

construct a logical graph of the unified model; and

assign each element in the unified model a unique identifier representing the absolute path to the model element in the graph.

22. The machine readable medium of claim 21, wherein instructions causing the machine to combine the first model and the second model into a unified model, cause the machine to apply the set of rules so that no conflicts exist in the application logic.