Patent Application
20060053087
The present invention relates generally to enterprise applications. More particularly, this invention relates to deploying enterprise components using deployment descriptors.
Java 2 Enterprise Edition (“J2EE”) is a specification for building and deploying distributed enterprise applications. Unlike traditional client-server systems, J2EE is based on a multi-tiered architecture in which server side program code is divided into several layers including a “presentation” layer and a “business logic” layer.
As illustrated in
The information systems of a modern day enterprise (such as a corporation or government institution) are often responsible for managing and performing automated tasks upon large amounts of data. Persistent data is that data that “exists” for extended periods of time (i.e., it “persists”). Persistent data is typically stored in a database so that it can be accessed as needed over the course of its existence. Here, complex “database software” (e.g., such as DB2, Oracle, and SQL Server) is often used to read the data and perhaps perform various intelligent functions with it. Frequently, persistent data can change over the course of its existence (e.g., by executing a series of reads and writes to the data over the course of its existence). Moreover, multiple items of different persistent data may change as part of a single large scale “distributed transaction.”
Session beans typically execute a single task for a single client during a “session.” Two versions of session beans exist: “stateless” session beans and “stateful” session beans. As its name suggests, a stateless session bean interacts with a client without storing the current state of its interaction with the client. By contrast, a stateful session bean stores its state across multiple client interactions.
Entity beans are persistent objects which represent data (e.g., customers, products, orders, . . . etc) stored within a database 223. Typically, each entity bean 252 is mapped to a table 260 in the relational database and, as indicated in
Each EJB consists of “remote home” and/or “local home” interface and “remote component” and/or “local component” interface, and one class, the “bean” class. The home interface lists the methods available for creating, removing and finding EJBs within the EJB container. The home object is the implementation of the home interface and is generated by the EJB container at deploy time. The home object is used by clients to identify particular components and establish a connection to the components' interfaces. The component interfaces provide the underlying business methods offered by the EJB.
A “deployment descriptor” is an XML file (named “ejb-jar.xml”) that describes how enterprise beans are deployed within the J2EE application server 100. For each CMP entity bean, the deployment descriptor defines “persistent fields” which represent and store a single unit of data, and “relationship” fields which represent and store references to other entity beans. Relationship fields are analogous to foreign keys used in relational database tables. Relationships between entity beans may be defined as “one-to-one” where each entity bean is associated with a single instance of another entity bean, “one-to-many” where each entity bean is associated with many instances of another entity bean, or “many-to-many” where entity bean instances may be related to multiple instances of each other.
An exemplary object model of three entity beans is illustrated in
The container-managed persistence (“CMP”) fields of the product bean 303 include product Name, Product ID, and Price (identifying the name, product identification code and price, respectively, of each product). The CMP fields for the order bean 301 include Order ID, Order Date, Credit Approved (indicating whether the user's credit card company approved the order) and Order Status; and the CMP fields for the customer bean 302 include social security number (SSN), Age, First Name and Last Name of the customer.
The deployment descriptor illustrated in
A <relationships> section 405 of the deployment descriptor (see
Thus, the standard deployment descriptor, ejb-jar.xml, defines the various CMP fields for each entity bean and the relationships between entity beans. However, non-standard fields or parameters have not been provided in the standard deployment descriptor.
System and method for deploying enterprise components using a deployment descriptor are described herein. In one embodiment, a deployment module of an enterprise container parses a deployment descriptor (DD) for deploying one or more enterprise components. For each of the enterprise components being deployed, the deployment module retrieves from the DD mapping information for mapping one or more persistent fields to one or more columns of a database table, where for each persistent field, the mapping information includes names of the persistent field and the columns of the database table where the persistent field is being mapped to. Thereafter, the deployment module populates each of the persistent fields of each enterprise component in the database table based on the mapping information during a deployment of the enterprise component.
In another embodiment, the deployment module parses a deployment descriptor (DD) for deploying one or more enterprise components. For each of the enterprise components being deployed, deployment module retrieves from the DD an initial cache size specifying a size of a cache memory initially allocated to the enterprise component when the enterprise component is being deployed and allocates a cache memory for the enterprise component having a size according to the initial cache size retrieved from the DD during a deployment of the enterprise component.
Other features of the present invention will be apparent from the accompanying drawings and from the detailed description which follows.
The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements.
System and method for deploying enterprise components using a deployment descriptor are described herein. In the following description, numerous details are set forth to provide a more thorough explanation of the present invention. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the present invention.
Some portions of the detailed descriptions which follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.
It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
The present invention also relates to apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), erasable programmable ROMs (EPROMs), electrically erasable programmable ROMs (EEPROMs), magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein.
A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium includes read only memory (“ROM”); random access memory (“RAM”); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.); etc.
Exemplary Enterprise Container
Referring to
In one embodiment, each of the EJBs 503-505 may include one or more deployment descriptors 506-511 having deployment information for deploying the respective EJB. In one embodiment, each of the EJBs may include a standard deployment descriptor and an extended deployment descriptor. For example, EJB 503 may include a standard deployment descriptor 506 and an extended deployment descriptor 507. In one embodiment, both of the standard and extended deployment descriptors may be implemented as extensible markup language (XML) files.
The standard deployment descriptor may be a deployment descriptor in the enterprise computing industry, such as, for example, ejb-jar.xml as shown in
When an EJB is deployed, the deployment module 502 may parse the deployment descriptors associated with the respective EJB, including the standard and extended deployment descriptors. The deployment module 502 retrieves the necessary deployment information from the deployment descriptors and uses the retrieved information to configure the respective EJB during the deployment of the EJB. As a result, an application developer can specify detailed configuration information for an enterprise component (e.g., EJB) via one or more deployment descriptors without having to change (e.g., recompiling) the source code, which provides great flexibilities.
Exemplary Persistent Deployment Descriptors
Referring to
In one embodiment of the invention, each persistent field of each persistent data object is mapped to a single column or a set of columns. Prior to mapping, each persistent field (also referred to as a “cmp-field”) is classified as Type1, Type 2 or Type 3. Type 1 is a “settable” cmp-field (i.e., a cmp-field mapped to one column as described below); Type2 is a “non settable” cmp-field stored in one column (also mapped to one column); and Type3 is a “non settable” cmp-field stored in a set of columns. Type 3 includes type “dependent value class” and the “dependent value class” which should have an empty constructor and public modifier for all its persistent subfields.
A “settable” type is a java type that can be mapped to a proper JDBC type (i.e., proper set/get<Type> methods are provided for it in the JDBC API). A “settable” cmp-field is a field with “settable” type. Each “non settable” cmp-field may be mapped to one column in the database. Its value is serialized/desterilized before/after the database operations described herein. In one embodiment, a “non-settable” cmp-field may be mapped to a set of columns if the following requirements are fulfilled: (1) the cmp-field's class has an empty constructor; and (2) its “persistent subfield” is a field in the dependent value class that intends to be stored in a separate column in the database. The “persistent subfield” should be subset of public fields of the dependent value class and should have “settable” java type. As described below, the names of the “persistent fields” in the persistence descriptor are specified using the tag <dv-column>/<subfield-name>. The term “dependent value persistent field” is equivalent to Type2 (“non settable” cmp-field) or Type3 (“non settable” cmp-field stored in a set of columns).
In one embodiment, if the persistent data field is a dependent-value field and if it contains an empty constructor, the database mapping of its fields that are declared public may be declared in the dv-column tag 606, where the persistent data field may be mapped to multiple columns, which may be identified by subfield-name 608 and column-name 609. However, according to one embodiment, both dependent value and non-dependent value persistent data field mappings may be described in the column tag 605. In this case, the dependent value persistent data field may be serialized and stored in a java.sql.Types.BLOB column.
If a persistent field is a dependent-value persistent field then, in one embodiment of the invention, it is mapped to a single column of type java.sql.Types.BLOB or to a set of columns. As is known in the art, BLOB is a type that stores a “Binary Large Object” as a column value in a row of a database table. By default, drivers implement BLOB using an SQL locator (BLOB), which means that a BLOB object contains a logical pointer to the SQL BLOB data rather than the data itself. Methods provided with the interfaces ResultSet, CallableStatement, and PreparedStatement (e.g., getBlob and setBlob) provide access to SQL BLOB values. The BLOB interface defined in the Java specification provides methods for retrieving the length of an SQL BLOB value, for materializing a BLOB value on a client, and for determining the position of a specific pattern of bytes within a BLOB value. In addition, the BLOB interface includes methods for updating a BLOB value.
If the dependent-value class has an empty constructor and all its fields are public, then the dependent-value persistent field is mapped to a set of columns. These columns are not stored in a separate database table; they are stored in the same database table as the other persistent fields of the bean. If at least one private field exists, or the constructor is not empty, then the dependent value class is mapped to a single column of type java.sql.Types.BLOB. The dependent-value object is serialized and is stored in the database as a byte[ ]. In this case the default mapping may not be permitted to be changed.
In one embodiment, column names for cmp-fields are selected according to the following rules. For persistent fields of Type1 (“settable” cmp-fields) or Type2 (“non settable” cmp-fields stored in one column), the name of the column is generated concatenating the name of the cmp-field, followed by UNDERSCORE, followed by index 0. For cmp-fields of Type3 (“non settable” cmp-fields stored in a set of columns), the name of the column is generated concatenating the name of the persistent subfield, followed by UNDERSCORE, followed by an index. An example of a descriptor, which is written in XML as an example, according to the DTD shown in
In one embodiment, key-type tag 612 associated with the field map section 602 may be used to specify the type of the column or the set of columns, in which the values of the persistent data field are stored. The value of the key-type tag 612 may be one of a “NoKey”, a “PrimaryKey”, and a “UniqueKey”, which is used to identify a column of the database table. The default value of the key-type tag 612 may be a “NoKey”.
Optionally, according to one embodiment, when a read-only tag 610 exists, the respective entity bean is not allowed to update the data in the database table. In this situation, the respective entity bean can only be allowed to read data from the database table. Alternatively, according to an alternative embodiment, when a select-for-update tag 611 exists, the respective entity bean identified by the entity-bean section 601 will use the database locking mechanism. The read-only tag 610 and the select-for-update tag 611 may mutually exclusively exist.
In one embodiment, the locking mechanism of the database table may be further controlled by a locking tag 613. The locking tag 613 may be used to control concurrent access from different transactions to the entity beans. According to one embodiment, there may be a variety of different types of locking. For example, the locking may be a table locking that automatically locks the entity beans in the Enqueue server, such that it ensures all applications that run in the cluster and use common data have the common locks. A local locking may be used when there is only one server running, because it does not synchronize the locks on multiple servers that work in a cluster. That is, the local locking synchronizes the concurrent access on one server only, and it does not use the Enqueue server to keep the locks. In this situation, an application may use a function call, such as, an EJBLocking API to make an explicit locking in the Enqueue server. Other locking types, such as, for example, an administrative locking, may also exist.
According to one embodiment, the DTD 600 further includes one or more relationship tags 614 that may be used as relation descriptors. In one embodiment, relations are realized using references between primary key column(s) and foreign key column(s), or “logical foreign key” column(s), which may be identified via a key-type tag 618. A key-type specified in key-type tag 618 may be one of a “NoKey”, a “PrimaryKey”, and a “ForeignKey”. This tag is used to describe a foreign (logical) key column and its reference to the corresponding primary key cmp-field. In such cases, the <fk-column> elements may be mandatory. If the key-type is PrimaryKey, the <fk-column> element should exist only if the relationship has multiplicity many-to-many. The <fk-column> element describes the referenced columns in the help table.
A column is called “a logical foreign key” if it is a column that contains the values of the referenced table's primary key column, but is not declared as a foreign key. As used herein, a “foreign key” column 619 may refer to both standard foreign keys and logical foreign keys. In one embodiment, one or more different foreign key columns are defined for each relationship. For example, if there are N relationships between two entity beans, then there are N mappings between primary keys and foreign key columns.
Relations may be one-to-one, one-to-many, or many-to-many (defining the “cardinality” of the relation). In addition, relations may be unidirectional or bidirectional. A unidirectional relationship can be navigated in only one direction. For example, a “contact” entity bean (representing a contact within an address book) may include a relationship field that refers to an address bean but the address bean may not require a relationship field that refers to the contact bean. By contrast, a bidirectional relationship may be navigated in both directions. For example, an order bean may refer to a series of line items and each of the series of line items may refer back to the order (i.e., so that the order may be identified given a particular line item of that order).
For one-to-one relationships, foreign key columns are provided in at least one of the two tables that participate in the relationship. For unidirectional one-to-one relations, a foreign key column is created in the table mapped to the entity bean which contains relationship field. For bidirectional one-to-one relations, foreign key columns are created in the tables mapped to each entity bean containing the relationship fields (e.g., identified in the first element of the <table-relatidnship-role>/<table-relationship-role> pair 615 and 616 identified under the <relationships> tag 614 in the deployment descriptor).
In one embodiment of the invention, for one-to-many relations, foreign key columns are generated in the table of the bean whose multiplicity in this relationship is “many.” In addition, in one embodiment, for many-to-many relationships, a mapping is provided which contains columns that are foreign key columns referencing the primary key columns of the two tables to which the beans participating in this relationship are mapped. The columns should have the same JDBC type as the primary key columns of the referenced tables. In one embodiment, this mapping is accomplished via a helper table 617.
In one embodiment, the following naming conventions are employed. The name of the foreign key columns is the name of the referenced primary key column, followed by UNDERSCORE, followed by a unique identifier of the relationship that is mapped with this foreign key column. For example, if a relationship with multiplicity 1:M exists between CustomerBean and OrderBean, the primary key column of the CustomerBean is “ssn—0” and the unique relationship ID is 0, as shown in
In one embodiment, many-to-many relationships between entity beans are represented within the persistence description using a “help table” 617 in which the primary keys of one enterprise bean are associated with the primary keys of a second bean. In one embodiment, the help-table name is selected to be the ejb-name of the CMP bean in the relationship, followed by UNDERSCORE, followed by the ejb-name of the other CMP bean in the relationship, followed by UNDERSCORE, followed by relationship ID. In addition, the name of the foreign key columns in the help-table are the name of the referenced primary key column, followed by UNDERSCORE, followed by the bean ID, followed by UNDERSCORE, followed by a unique identifier of the relationship.
The following is an example of an “ProductBean_OrderBean—1” helper table for two beans, “ProductBean” and “OrderBean”, that have related primary keys (i.e., Product with productId=1 is related to Order with orderId=2; Product with productId=4 is related to Order with orderId=8; Product with productId=1 is related to Order with orderId=1; Product with productId=11 is related to Order with orderId=10):
The foreign key column in the help-table that refers the OrderBean is “orderId—0—0—1” because the name of the primary key column of OrderBean is “orderId—0”, the OrderBean ID is 0, and the relationship ID is 1. The foreign key column in the help-table that refers the ProductBean is “productId—0—2—1” because the name of the primary key column of ProductBean is “productId—0”, the ProductBean ID is 2, and the relationship ID is 1. An example of the help table is shown in
Each entity bean section 701, 702, 703 includes a mapping of the entity bean it represents to a database table, and a mapping of the persistent fields of the entity bean to the columns of the database table. For example, entity bean section 701 includes an association between the entity bean name (“OrderBean”) 710 and a table name (“OrderBean0”) 711. In one embodiment, the name of the database table is automatically generated based on the name of the entity bean which represents it (e.g., using the same name or a derivation of the entity bean name). It should be noted, however, that automatic generation of table names is not required for complying with the underlying principles of the invention. For example, an O/R mapping generation logic may map existing database tables to entity beans, rather than generating a new name for each table.
In addition, in one embodiment, the O/R persistence description includes a plurality of field mapping sections 712-715 that map each persistent field of the entity bean to a column in the associated database table. For example, in
Table-relation section 706 provides the relationship mapping between the order bean 301 and the product bean 303. For example, “table-relationship-role” section 722 maps a foreign key column orderId—0—0—1 in the help-table ProductBean_OrderBean—1 table to the primary key column of the OrderBean0 table; and “table-relationship-role” section 723 maps a foreign key column productId—0—2—1 in the help-table ProductBean_OrderBean—1 to the primary key column of the ProductBean2 table.
Referring back to
If the beans are developed according to the enterprise JavaBeans™ v.2.0 specification, this element describes the bean's SQL finder methods, which differ from the default finder statements that are generated by the EJB QL parser. This element also specifies whether data storing for the finder and select methods is switched on or off, which of the bean's fields will be retrieved from the database, and whether the EJB QL is 2.1 compatible.
In one embodiment, a criteria tag 621 may be used to define the select statement that is going to be executed in the finder method. Use format “?I” to specify the number of the parameter, which should be used instead of the statement. Parameters are numbered from 1 to N. An example of such usage is shown as follows:
The system will not detect whether the criteria is not correct, or whether it returns the wrong result type during the application's deployment. However, the system will throw an exception at runtime when you try to execute the incorrect criteria.
In addition, one or more parameters of the finder method may be further specified in the tags 622. A switch-off-storing tag 623 may be used to specify whether operations of data storing should be performed prior to the finder method being executed. Further, a load-selected-objects tag 624 may be used to specify whether certain objects should be automatically loaded when the finder method is executed. If this element exists, the bean is locked and when the finder/select method is executed, all fields of the bean are loaded from the database. Otherwise, if the element is omitted, only the primary key fields are retrieved from the database. The locking ensures that, until the end of the transaction, the loaded data will remain consistent with the last state of the data in the database and avoids the reloading of the same data when the transaction uses it later again.
By default, each query is QL 2.0 compatible. If an application developer needs to use new functionality of an updated specification, such as, for example, ORDER BY, aggregate functions, and so on, tag 625 may be used to indicate that the QL is 2.1 compatible. If this element exists, the query is considered QL 2.1 compatible. This element is taken into account only if the specified method is an EJB 2.0 finder or select method.
Furthermore, according to one embodiment, a switch-off-verification tag 626 may be used to indicate whether a verification operation can be disabled during a deployment of an enterprise component. If this tag is specified, the verification of whether the O/R mapping is correct will be disabled.
Referring to
For each of the persistent fields of each EJB, at block 803, mapping information is retrieved from the deployment descriptor. In one embodiment, the mapping information includes identifications of the respective persistent field and the column of the database table being mapped to. At block 804, for each of the relationships fields of each EJB, relationship information is retrieved from the deployment descriptor. The relationship information representing relationships between the respective EJB and another EJB. Thereafter, at block 805, each of the persistent fields of each EJB is populated in the database table according to the mapping information and the relationship information. Other operations may also be performed.
At block 902, for each of the EJBs being deployed, an indication is retrieved from the deployment descriptor, where the indication indicates whether a current transaction should be saved before executing a finder method of the respective EJB. If such an indication exists, according to one embodiment, the data associated with the current transaction will be saved prior to executing the finder method.
At block 903, for each of the EJBs being deployed, an indication is retrieved from the deployment descriptor, where the indication indicates whether some or all of the fields of the EJB should be loaded during executing a finder method. In one embodiment, dependent upon the setting of this indication, some or all of the fields of the EJB may be locked and loaded during an execution of the finder method. Alternatively, only the primary key fields may be loaded.
At block 904, for each of the EJBs being deployed, an indication is retrieved from the deployment descriptor, where the indication indicates whether the finder method currently submitted is compatible with a new and updated specification. If the indication indicates that the respective finer method is compatible with the new and updated specification, the finder method may be executed according to the new and updated specification.
At block 905, for each of the EJBs being deployed, an indication is retrieved from the deployment descriptor, where the indication indicates whether an alternative SQL statement other than the default SQL should be used during an execution of a finder method. Thereafter, at block 906, a finder method is executed according to at least the settings set forth in operations 902-905. Other operations may also be performed.
Exemplary Enterprise Engine Deployment Descriptors
Referring to
Referring back to
Further, according to one embodiment, the exemplary DTD 1000 includes security-role-map tag 1014 to provide mapping information for mapping a security role of an application to a user or a server role. Under the security-role-map tag 1014, a role-name tag 1015 may be used to specify a name of the security role being mapped. A user-name tag 1016 may be used to specify a user of a user group that is identified via a group-name tag to be mapped to the security role. Alternatively, the security role may be mapped to an existing server role identified by a server-role-name tag 1017. In one embodiment, a server role is a predefined security role in the root policy configuration of an enterprise engine to which the current security role will be mapped. An example of the security mapping tag in an XML format is shown as tag 1114 in
Further, according to one embodiment, the exemplary DTD 1000 includes a transaction descriptor section having an isolation level tag 1018 for defining transaction isolation levels for entire enterprise component or for some of its methods. Transactions not only ensure the full completion (or rollback) of the statements that they enclose but also isolate the data modified by the statements. The isolation level describes the degree to which the data being updated is visible to other transactions.
For example, suppose that a transaction in one program updates a customer's phone number, but before the transaction commits another program reads the same phone number. Will the second program read the updated and uncommitted phone number or will it read the old one? The answer depends on the isolation level of the transaction. If the transaction allows other programs to read uncommitted data, performance may improve because the other programs don't have to wait until the transaction ends. But there is a trade-off, where if the transaction rolls back, another program might read the wrong data.
Referring to
Further, according to one embodiment, the exemplary DTD 1000 further includes one or more session property sections 1022 for specifying information regarding one or more enterprise session components (e.g., session beans). A session-timeout tag 1023 may be used to specify a period (in seconds) since the session was last used, after which the enterprise container may destroy it. That is, the enterprise container performs the same operation as if the bean's remove( ) method was invoked. The default session timeout is 36000 seconds. It is recommended that the value of the session-timeout is longer than the expected duration of the methods; otherwise, this will lead to system errors. A passivation tag 1024 may be used to specify whether an EJB container passivates the bean instances. If this element is omitted in the deployment descriptor, according to one embodiment, the EJB container will not passivate the bean instances. In one embodiment, this property can be specified for stateful session beans only.
According to one embodiment, the passive timeout tag may be used to specify the period (in seconds) since the bean's passivation, after which the EJB Container clears the session bean's instance from the swap and destroys the session. In addition, a LRU (least recently used) limit tag may be used to specify the maximum number of active sessions in the EJB container. Once this number is reached, the EJB container passivates the session that was used least recently (LRU algorithm) and swaps its instance to the hard disk. An example of the above descriptor in an XML format is shown as tag 1122 in
Further, a keeps-open-resources tag 1025 may be used to specify that the enterprise bean holds open resources. This means that the enterprise bean's ejbPassivate( ) method must be executed before serializing the enterprise bean. In one embodiment, this element is used only when the application is set to use failover.
According to one embodiment, the exemplary DTD 1000 further includes a message driven component (e.g., message driven bean in a Java environment) section 1027 to specify information about the message-driven component in an enterprise application. Under the tag 1027, a destination-name tag 1028 may be used to specify a name of the topic or the queue to which the enterprise component wants to be subscribed. In addition, a connection factory name tag 1029 may be used to specify a name of the connection factory that will be used by the enterprise container to obtain connections in order to register the enterprise component as a message listener. An example of the above descriptor in an XML format is shown as tag 1127 in
It will be appreciated that other properties may also be implemented. For example, additional properties of the enterprise component may also be specified, such as, for example, a property having the following property members:
Stateful-failover—enables stateful failover for stateful session beans. The possible values for this property are true and false. This property enables stateful failover for stateful session components (e.g., session beans). If some server nodes in the cluster fail, all the active sessions on those server nodes may be replicated or transferred to another server node and the client or clients will not lose the respective information.
These properties may be set for stateless session beans, message-driven beans, and entity beans in a Java environment, whose containers use pools with instances. Other configurations may exist.
Referring to
Exemplary Data Processing System
Note that while
As shown in
The bus 1402 interconnects these various components together and also interconnects these components 1403, 1407, 1405, and 1406 to a display controller and display device 1408, as well as to input/output (I/O) devices 1410, which may be mice, keyboards, modems, network interfaces, printers, and other devices which are well-known in the art. Typically, the input/output devices 1410 are coupled to the system through input/output controllers 1409.
The volatile RAM 1405 is typically implemented as dynamic RAM (DRAM) which requires power continuously in order to refresh or maintain the data in the memory. The non-volatile memory 1406 is typically a magnetic hard drive, a magnetic optical drive, an optical drive, or a DVD RAM or other type of memory system which maintains data even after power is removed from the system. Typically the non-volatile memory will also be a random access memory, although this is not required. While
According to one embodiment, the exemplary system 1400 further includes a deployment module, which when executed from the memory, deploys one or more enterprise components based on the information retrieved from one or more deployment descriptors.
Exemplary Persistent DTD Descriptions
Following descriptions describe detailed information regarding the exemplary persistent DTD 600 of
Exemplary Enterprise Engine DTD Descriptions
Following descriptions describe detailed information regarding the exemplary enterprise engine DTD 1000 of
Thus, system and method for deploying enterprise components using a deployment descriptor have been described herein. Note that although a Java computing environment has been used throughout this application, embodiments of the present application are not limited to the Java computing environment. It will be appreciated that other computing environments, such as, for example, the NET framework environment from Microsoft may also be applied. The examples of deployment descriptors described above are for illustration purposes only. It will be appreciated that other formats or scripting languages may also be utilized.
In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope of the invention as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.
