U.S. patent application number 11/966849 was filed with the patent office on 2008-10-30 for enterprise javabeans metadata model.
Invention is credited to Alexandrina Ivanova, Vladimir Pavlov, Hristo Sabev, Krasimir Topchiyski.
Application Number | 20080270974 11/966849 |
Document ID | / |
Family ID | 39888336 |
Filed Date | 2008-10-30 |
United States Patent
Application |
20080270974 |
Kind Code |
A1 |
Topchiyski; Krasimir ; et
al. |
October 30, 2008 |
Enterprise JavaBeans Metadata Model
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.
Inventors: |
Topchiyski; Krasimir;
(Sofia, BG) ; Ivanova; Alexandrina; (Sofia,
BG) ; Sabev; Hristo; (Sofia, BG) ; Pavlov;
Vladimir; (Sofia, BG) |
Correspondence
Address: |
BLAKELY SOKOLOFF TAYLOR & ZAFMAN LLP
1279 OAKMEAD PARKWAY
SUNNYVALE
CA
94085-4040
US
|
Family ID: |
39888336 |
Appl. No.: |
11/966849 |
Filed: |
December 28, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60926989 |
Apr 30, 2007 |
|
|
|
Current U.S.
Class: |
717/104 |
Current CPC
Class: |
H04L 67/2842 20130101;
H04L 67/28 20130101; H04L 67/14 20130101; G06F 8/60 20130101; H04L
67/143 20130101; G06F 8/61 20130101; G06F 21/6281 20130101 |
Class at
Publication: |
717/104 |
International
Class: |
G06F 9/44 20060101
G06F009/44 |
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; 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.
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; 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.
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.
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.TM. 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
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.
[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.
* * * * *