【正文】 . Section 2 provides necessary background for understanding the specifics of the J2EE ponent technology which are relevant to this study. Section 3 gives a general description of the infrastructure architecture, while section 4 goes deeper in describing particularly important and interesting internal mechanisms of the infrastructure. Section 5 describes the implementation of the framework, and related work is discussed in section 6. 2 J2EE Background Introduction Component frameworks. A ponent framework is a middleware system that supports applications consisting of ponents conforming to certain standards. Application ponents are ―plugged‖ into the ponent framework, which establishes their environmental conditions and regulates the interactions between them. This is usually done through containers, ponent holders, which also provide monly required support for naming, security, transactions, and persistence. Component frameworks provide an integrated environment for ponent execution, as a result significantly reduce the effort .it takes to design, implement, deploy, and maintain applications. Current day industry ponent framework standards are represented by Object Management Group’s CORBA Component Model [18], Sun Microsystems’ Java 2 Platform Enterprise Edition (J2EE) [25] and Microsoft’s .NET [17], with J2EE being currently the most popular and widely used ponent framework in the enterprise arena. J2EE. Java 2 Platform Enterprise Edition (J2EE) [25] is a prehensive standard for developing multitier enterprise Java applications. The J2EE specification among other things defines the following: ? Component programming model, ? Component contracts with the hosting server, ? Services that the platform provides to these ponents, ? Various human roles, ? Compatibility test suites and pliance testing procedures. Among the list of services that a pliant application server must provide are messaging, transactions, naming and others that can be used by the application ponents. Application developed using J2EE adhere to the classical 3Tier architectures – Presentation Tier, Business Tier, and Enterprise Information System (EIS) Tier (see Fig. 1). J2EE ponents belonging to each tier are developed adhering to the Specific J2EE standards. 1. Presentation or Web tier. This tier is actually subdivided into client and server sides. The client side hosts a web browser, applets and Java applications that municate with the server side of presentation tier or the business tier. The server side hosts Java Servlet ponents [30], Java Server Pages (JSPs) [29] and static web content. These ponents are responsible for presenting business data to the end users. The data itself is typically acquired from the business tier and sometimes directly from the Enterprise Information System tier. The server side of the presentation tier is typically accessed through HTTP(S) protocol. 2. Business or EJB tier. This tier consists of Enterprise Java Beans (EJBs) [24] that model the business logic of the enterprise application. These ponents provide persistence mechanisms and transactional support. The ponents in the EJB tier are invoked through remote invocations (RMI), inJVM invocations or asynchronous message delivery, depending on the type of EJB ponent. The EJB specification defines several types of ponents. They differ in invocation style (synchronous vs. asynchronous, local vs. remote) and statefulness: pletely stateless (., MessageDriven Bean), stateful nonpersistent (., Stateful Session Bean), stateful persistent (., Entity Bean). Synchronously invocable EJB ponents expose themselves through a special factory proxy object (an EJB Home object, which is specific to a given EJB), which is typically bound in JNDI by the deployer of the EJB. The EJB Home object allows creation or location of an EJB Object, which is a proxy to a particular instance of an EJB 1. 3. Enterprise Information System (EIS) or Data tier. This tier refers to the enterprise information systems, like relational databases, ERP systems, messaging systems and the like. Business and presentation tier ponent municate with this tier with the help of resource adapters as defined by the Java Connector Architecture [26].The J2EE programming model has been conceived as a distributed programming model where application ponents would run in J2EE servers and municate with each other. After the initial introduction and first server implementations, the technology, most notably, the EJB technology has seen some a significant shift away from purely distributed puting model towards local interactions 2. There were very legitimate performancerelated reasons behind this shift, however the Distributed features are still available. The J2EE specification has seen several revisions, the latest stable being version , while version is going through last review phases 3. We shall focus our attention on the former, while actually learning from the latter. Compliant mercial J2EE implementations are widely available from BEA Systems [4], IBM [9], Oracle [21] and other vendors. Several open source implementations, including JBoss [11] and JOnAS [19] claim patibility as well. A Recent addition to the list is a new Apache project Geronimo [1]. J2EE Component Programming Model Before we describe basic J2EE ponents, let’s first address the issue of defining what a ponent is a software ponent is a unit of position with contractually specified interfaces and explicit context dependencies only. A software ponent