Component based computer architectures utilize modular pieces of software, referred to as components, which are assembled together to construct more complex software applications. Through reuse of existing components, software developers often can construct applications in a faster and more effortless fashion than would otherwise occur were the functionality of the existing components required to be written from scratch.
For example, the Java 2 Platform, Enterprise Edition (J2EE) is an open and standard based platform for developing, deploying and managing n-tier, Web-enabled, server-centric, and component-based enterprise applications. Within this environment the principal software components are referred to as Enterprise JavaBeans (EJB), of which there are three primary types: entity beans, session beans, and message-driven beans.
EJB's are typically hosted in runtime environments referred to as containers, e.g., as provided in an application server, and are linked together to construct enterprise class applications.
Deployment of an EJB in a runtime environment traditionally requires a number of steps. First, the EJB is written by a software developer using any of a number of different software programming techniques, and compiled into an intermediate form of program code referred to as bytecode. This bytecode is packaged into an enterprise archive file, also referred to as an EAR file.
In addition, an EAR file typically includes a deployment descriptor, which is generated either manually by a developer or automatically by a programming tool. The deployment descriptor provides additional information for an EJB that assists with the installation and execution of the EJB in the intended runtime environment. Typically, a deployment descriptor takes the form of an XML document, which is parsed during installation of an EJB.
In some instances, a deployment descriptor as created by a developer will lack some information that is needed for installation. For example, an EJB may be designed to interact with some other component during execution, but certain information about the other component may not be known at development time. An EJB such as a message driven EJB (MDB), for instance, often needs to be provided with the name of a message queue before the MDB is capable of receiving messages from that queue during execution. As a result, one step that may be required during installation of an EJB is to manually edit a deployment descriptor to insert any omitted information. Installation of the EJB can then be performed in the same manner as if all of the necessary information was provided in the original deployment descriptor.
One drawback associated with conventional EJB's, however, is that the EJB's are essentially static in nature. Specifically, once an EJB has been installed in a runtime environment, many of the operational characteristics of that EJB cannot be modified without having to reinstall the entire application that uses the EJB. Much of the inflexibility of EJB's in this regard stems from the essentially static nature of the deployment descriptors used to instantiate such components, and the runtime environment within which the EJB's exist. As noted above, installation of an EJB involves parsing of a deployment descriptor during the installation process. Moreover, the EJB is immediately instantiated and activated once installation is complete. As a result, the EJB effectively becomes immutable once installation is complete.
It has been found, however, that some runtime environments may not be as static as the EJB's installed therein. For example, new messaging systems or other back-end services may be installed in a runtime environment, necessitating that EJB's be reconfigured to work with these new services. As another example, existing services may be modified, e.g., where an existing messaging system adds or removes event types that must be recognized by any EJB that listens to the messaging system.
Traditionally, any changes to the runtime environment that require changes in an EJB require that the entire application that uses the EJB to be modified and redeployed. This requirement, however, is excessively burdensome in many instances, and as a result, presents a significant limitation with respect to more complex enterprise applications.
USPTO Backgrounds
USPTO Backgrounds