RoadMapAssembler: A New Pattern-Based J2EE Development Tool

Transcription

1 RoadMapAssembler: A New Pattern-Based J2EE Development Tool Jun Chen and Steve MacDonald School of Computer Science, University of Waterloo, Waterloo, Ontario, CANADA j2chen@uwaterloo.ca, j2chen stevem@uwaterloo.ca, stevem Abstract The quality of a J2EE web application depends on both the correctness of the code as well as the efficiency and flexibility of its architecture. Unfortunately, the design and development process is complex and includes tedious coding details, making it error-prone. Part of the problem lies in the incomplete abstractions provided by the J2EE specification. The artifacts of the distributed system environment are still present in applications and cannot be ignored, notably interfaces for distributed objects, name space information, and deployment information. In this paper, we present the detailed design of our design-pattern-based J2EE development system, RoadMapAssembler. This system shows that a J2EE architectural framework can be generated by assembling a set of design patterns in an incremental fashion, exploiting our knowledge of pattern implementations and inter-pattern relationships. This same knowledge also allows us to generate code for the distributed system artifacts that pollute J2EE applications. We demonstrate these features through the development of an example J2EE application. Keywords: Java 2 Enterprise Edition (Version 2.1), Development tool, Design patterns, Frameworks, Name space, Deployment information. 1 Introduction Java 2 Enterprise Edition (J2EE) is Sun Microsystem s solution for multi-tiered enterprise web ap- Copyright c 2005 Jun Chen and Steve MacDonald. Permission to copy is hereby granted provided the original copyright notice is reproduced in copies made. plications. It simplifies web application development by providing a set of standardized components and services to developers. Using Java Remote Method Invocation, J2EE hides most of the low-level distribution details. However, J2EE is still known for its complexity from both the design and implementation perspectives. Although J2EE is designed to hide the complexity of distributed programming, it still suffers from abstraction overflow at the design level. While J2EE provides important services like persistence and transactions that ease application development, the efficiency of those applications is still left to developers. Sun has published a J2EE framework to help developers address these concerns [19]. J2EE (specifically version 2.1, the target of this research) also suffers from abstraction overflow at the code level. Enterprise Java Beans (EJBs) are the integral building blocks of the business tier. EJBs are intended to give developers the impression of writing sequential code instead of distributed code. Unfortunately, they fail in two ways. First, developers must write access interfaces for each EJB. These interfaces are an artifact of the distributed execution environment and are only used by the J2EE runtime; they are not implemented by any class in the application for reasons described in Section 4.1. The need for these interfaces and their connection to the application code is obscure and easily missed by developers. The second way beans fail to hide distributed code is the need for a name space to locate EJBs. This name space is provided by the Java Naming and Directory Interface (JNDI) service. Before a bean can be used, it must be located by a JNDI lookup and a handle to the bean must be created. In both of these fail-

2 ures, code that handles the distributed aspects of the application has polluted the Plain Old Java Object (POJO) abstraction and the application code. After the application has been developed, it must be deployed. This requires that deployment information be assembled into a deployment descriptor for each EJB. A deployment descriptor describes the bean to the container in which it will run. Writing descriptors manually is tedious, cumbersome, and error-prone. This paper presents RoadMapAssembler (RMA), a new development tool that provides a pattern-based approach to the abstraction overflow problems discussed above. For application developers, RMA incrementally builds up J2EE version 2.1 applications by composing patterns from the J2EE framework in an incremental, bottom-up fashion. From the deployment perspective, we have devised a way to use J2EE patterns to completely hide the deployment logic from application logic. The generated pattern code includes both the pattern implementation and all deployment logic, both internal and external. As a result, users can concentrate on their application code and not on the distributed execution environment. The research contributions of this paper are as follows. First, we use pattern information to generate not only pattern implementation code but also to generate pattern composition code (based on the J2EE framework). An important characteristic of pattern composition in RMA is that it only includes the patterns from the J2EE framework that are needed in the application. Second, RMA is able to generate more pattern implementation code than similar systems, notably method-level code between different patterns. This is a result of our bottom-up development approach, which ensures that the components that a pattern may be composed with must already exist and allows RMA to generate delegating methods. Third, we exploit pattern information to generate deployment descriptors, which must describe not just an individual EJB but also the EJBs with which it collaborates. Finally, we expand the role of an existing J2EE design pattern to completely hide the EJB name space and the process of obtaining handles to remote EJBs. RMA is built as an Eclipse plugin [13]. Eclipse has a built-in Java development environment, and has an open architecture development platform based on plugins to allow new tools and abstractions to be introduced. RMA can leverage existing features, such as refactoring and code completion. This paper is organized as follows. In Section 2, we present a demo application that was developed using our tool. In Section 3, we describe how pattern relationships are realized in RMA. In Section 4, we use our sample application to demonstrate how we hide the deployment logic. Section 5 is an initial evaluation of the benefits of RMA. The architecture of RMA is described in Section 6. Section 7 discusses some related work done in J2EE development tools, especially those done in a pattern-based fashion. Future work and conclusions are summarized in Section 8. 2 A Sample Application To demonstrate how RMA helps incrementally build up a web application and hides the deployment logic from application code, we present a simple web application to lay the ground for further discussion. Our sample code models an online astronomer s club, as shown in Figure 1. It consists of four simple use cases: Login, Register, ChangeInfo and ViewPlanetInfo. This example is simple but captures some essential J2EE patterns. By analysis, we can quickly identify four database tables: Client, Address, Planet, and Satellite. The Login use case accesses the Client table for password verification. The Register and ChangeInfo use cases need to access both the Client and Address tables. The View- PlanetInfo use case displays the contents of Planet and Satellite tables. Login, Register, and ChangeInfo are administrative use cases. We aggregate these use cases into the Admin use case to provide a centralized access point for administrative functions. Both the ChangeInfo and Register use cases need to read and write data from two database tables. However, the data in these tables is logically related so it would be useful present the data as one logical table to these two use cases, hiding the two finegrained databases from clients. In the ViewPlanetInfo use case, the amount of data returned could be large and the user may not view all of it at once. Further, the user could abandon browsing the data at any time. It would be better to deliver content only when it is accessed to reduce network overhead.

3 Login extends ChangeInfo Intercepting Filter Presentation Tier include include Front Controller Composite View Admin ClientTable View Helper include Register AddressTable Front Controller Dispatcher View Front Controller Service To Worker PlanetTable Business Delegate Business Tier Session Facade Service Locator ViewPlanetInfo SatelliteTable Transfer Object Assembler Value List Handler Figure 1: Use Cases for Sample Application 3 Framework Generation The relationship between design patterns and frameworks is intriguing. Both patterns and frameworks capture reusable practices in design. Frameworks are usually larger in scale and more concrete than design patterns. Despite the differences, frameworks and patterns are strongly related. Design patterns act as the micro-architectural units within a framework [10]. Patterns can be divided into three groups: creational patterns, structural patterns, and behavioural patterns [6]. Combining the concepts of framework and patterns, we can speculate if there is a framework that consists entirely of patterns as its subcomponents. The control flow of this framework would be dictated by the behavioural patterns, the structure of the classes and objects would be captured by the relationships between structural patterns, and the process of creating and assembling the framework objects would be dictated by the creational patterns. 3.1 The J2EE Framework Frameworks are partial implementations of the structure of a specific application, with GUIs being the most common example. J2EE also has a framework defined by Sun Microsystems [1], shown in Figure 2. It is split across three tiers to separate different parts of the overall application. The presentation tier provides a web-based user interface and displays the results of calls to the business logic, and is implemented using servlets and JSPs. The business tier, the main focus of this paper, provides business logic that processes client requests, and is usually built using EJBs. The integration tier Composite Entity Service Activator Transfer Object Data Access Object Integration Tier Figure 2: J2EE Framework (simplified from [1]) is primarily for database access. Each tier can be thought of as the first level of components as it may represent a container in which components for that tier run. It is interesting to note that the subcomponents of each tier are patterns. 3.2 Selected J2EE Patterns Before we discuss our pattern assembly process, we provide a brief overview of the important J2EE patterns that we support. These patterns cover the business and integration tier. We concentrate on the patterns that improve the efficiency of distributed code as well as the relationships between the patterns. Additional patterns that improve the abstraction for distribution are discussed in Section 4. More details on these patterns can be found in [1]. Transfer Value Object: The server-side business components access and manipulate business data to satisfy client requests. Clients access these results by invoking accessor methods on the business components. Fine-grained calls between clients and business components should be avoided to reduce network overhead. Rather than returning finegrained data, remote business components may pack their complete state into a single, coarsegrained transfer value object that is returned to the client. Clients can access the data they need with only one remote access. Data Access Object: Many real-world J2EE applications need to access persistent data. The type of the underlying data sources can range from a

4 simple file to a full commercial database system, where each source exposes a different API. A data access object (DAO) is used as a kind of adapter to decouple the business components from the data sources they use. In practice, there is a one-toone mapping between DAOs and database tables. A transfer value object containing instance variables for each field in the database table is associated with each DAO. DAOs are accessed directly from any EJB class that needs persistent data. Value List Handler: A query from a client may result in a large set of results being fetched from the database. In general, web applications show large result sets using multiple pages rather than all at once, as is done in search engines. Further, clients typically abandon browsing results if they do not find a good match in the first few results. Thus, it might not be necessary to send all results back to the client in one large message. Rather, it might be better to send them in small batches that are sent when the client accesses them. Further, frequently accessed data can be cached for some period of time to speed up accesses. The value list handler is ideal for both of these purposes. It is also useful for manipulating the result set, including sorting and grouping data items. A value list handler is generally associated with DAOs and EJBs. It manipulates and caches transfer value objects for both. Value Assembler: The value list handler is a homogeneous list of transfer value objects. In contrast, a value assembler aggregates different types of transfer value objects. The need for this pattern arises when the logical data model in one tier is different than the physical data model in the next. The value assembler encapsulates different types of transfer value objects to provide a single, consistent application data model that hides the underlying physical model. It also reduces network traffic as a client no longer has to communicate with several individual components to access different parts of the data model. Session Facade: In J2EE applications, the developer might not want to expose all business components or methods to clients for a variety of reasons. Logically related components can be aggregated into a single, logical component to simplify the interface between tiers and increase the granularity of communication. The session facade pattern provides a means of aggregating several small-grained business components into one larger-grained service. It is also a convenient place to add access control mechanisms for privileged services. The session facade aggregates any server-side objects. It can also be used for integration tier components. For instance, a session facade can combine several DAOs to provide a composite view of fine-grained data. 3.3 Pattern Assembly Process We will now use our sample astronomer s club application to show how patterns can be assembled into a complete application using RMA. Figure 3 shows a simplified class diagram of our example application. To keep the architecture simple, some classes are not shown. In particular, we have removed the low-level implementation details for EJBs. This detail is hidden behind the proxies in the diagram (LoginProxy, ChangeInfoProxy, etc.). These proxies will be discussed in Section Assembling the Sample Application Our construction process is bottom-up, starting at the integration tier and working up toward the presentation tier. The process of creating the astronomer s club application starts with constructing DAOs for the database tables. We create four DAOs: ClientDAO, AddressDAO, PlanetDAO, and SatelliteDAO. For each of these DAOs, RMA automatically creates one transfer value class with appropriate instance variables and accessor methods, and a primary key class for database management. RMA prompts the developer for necessary database connection parameters, such as the JNDI name for connecting the DAO to the underlying database system, connection string, and JDBC library. It also requests the name and type of all fields in the database table, some of which must be marked as the primary key. This information is used to produce code to connect applications to the database. To complete the DAO implementation, the developer inserts appropriate SQL query statements into the generated code. From Figure 1, this application has two main use cases, Admin and ViewPlanetInfo, in the business tier. The Admin use case contains three smaller use cases: Login, Register, and ChangeInfo. The Login case performs a simple validation of a submitted client ID and password matching against data stored in ClientTable. RMA provides a wizard to generate skeleton code for the EJB. The

5 Presentation Tier Business Tier Data Tier LoginProxy ClientTO AdminProxy login(v: ClientTO) : boolean changeinfo(ca: ClientInfoAggregator) : void dologin() : boolean ChangeInfoProxy ClientAddressAssembler ClientDAO ServletController register(ca: ClientInfoAggregator) : void dochangeinfo() : void RegisterProxy ClientInfoAggregator cto : ClientTO ato : AddressTO AddressTO AddressDAO doregister() : void PlanetTO PlanetInfoViewerProxy PlanetVListProxy PlanetDAO sublist(int s, int e)() : void SatelliteTO SatelliteVListProxy SatelliteDAO sublist(s: int,e: int) : List Figure 3: Simplified Architecture for Sample Application developer provides the class name and package, and writes the business methods and any create (or home) methods needed to initialize the EJB. For this example, the business methods in the Login EJB access client information from ClientDAO (using the associated transfer value object) and use it to validate the user. No additional home methods were required. For reasons we will examine later, accessing the ClientDAO to retrieve its transfer value object is simply a matter of calling methods on appropriate objects. The Register use case makes use of the Client- DAO and the AddressDAO, where both of these database tables make up the data model. However, the application model for Register uses one logical table that is the join of these two tables. This is an example of an application model differing from its underlying data model. To convert the data model to the application model, we apply the value assembler design pattern. In the value assembler wizard in RMA, a list of transfer value objects that are in the current application are presented. The developer selects a list of these transfer value objects that need to be aggregated into a new transfer value object. For our example, ClientTO and AddressTO are selected. For each transfer value object, the user also indicates which method in the associated DAO returns the transfer object that we want to aggregate. Note that the selected method may represent a query that returns multiple transfer value objects, forming a 1-to-many relationship. These methods are used by the new value assembler to populate a new transfer value object that is created to provide the application model. The selected accessor methods also make up the interface to the new transfer value object. In addition, the wizard allows the developer to specify the package and class information for both the value assembler class (the assembler class) and the transfer value object class (the aggregator class in Figure 3). Once the developer has completed the wizard for the value assembler, they have complete code for both the assembler and the new transfer value object. No user code is needed to complete the pattern implementation. In the architecture for our example, the results of applying the value assembler are the assembler class ClientAddressAssembler and the transfer value object class ClientInfoAggregator. Finally, the Register use case also requires a new EJB with the registration business methods, which is created just as the Login bean was above. These business methods use the aggregator class created with the value assembler for its application model.

6 The ChangeInfo use case is implemented in a similar manner as the Register case. However, the ChangeInfo use case updates user information. To do this, the developer can augment the value assembler created in the Register case to include accessors that set data in the ClientInfoAggregator class from the ClientAddressAssembler. The updated ClientInfoAggregator can be passed to ClientDAO and AddressDAO to update the registration information. It would be beneficial to have a centralized access point for the three administrative business components (Login, Register, and ChangeInfo). This simplifies the interface between the business and presentation tiers. It can also help increase the granularity of messages to reduce communication costs. To create this centralized access point, we apply the session facade design pattern to create the Admin bean from Figure 3. RMA provides wizards to quickly create a session facade, shown in Figures 4(a) and 4(b). The first wizard shows a list of EJBs that are in the current Eclipse project, and the user selects those that should be centralized in the new facade. For this application, we selected the Login, Register, and ChangeInfo beans. Once the beans are chosen, the user picks the business methods from each bean that the facade should expose. An alternate method name can be provided in the Delegator Name field to resolve any conflicts. The result of applying the session facade pattern is a new facade class, Admin in our example application. This class provides a basic facade, delegating methods to the proper method in the contained beans. This basic code can be augmented by the developer to add security considerations or to add higher-level methods that invoke methods across multiple EJBs contained in the facade. The final use case, ViewPlanetInfo, accesses PlanetDAO and SatelliteDAO. At the presentation tier, our web interface displays information about each planet and its satellites on separate web pages. The pages are displayed from the innermost planet to the outermost. As a result, it makes sense to cache the planet information from the database at the business tier and return the pages one at a time as the user requests them. This way, if the client decides to abandon viewing the information part way through the list of planets, then we have not incurred the overhead of sending the complete result set. To get this caching and incremental sending of results to the client, we apply the value list handler pattern twice, once for PlanetDAO and once for SatelliteDAO. To create the value list handler, an RMA wizard asks the user for the value transfer object to be cached and the accessor in the associated DAO that returns it. For the Planet- DAO portion of our example, we select PlanetTO and the PlanetDAO method that returns this object. From this specification, RMA generates the complete value list handler, PlanetVList in our case. This class is ready to use in an application without the need for additional user code Discussion The application development process with RMA uses an incremental, bottom-up approach. Thus, when developers apply patterns in upper tiers, they already have the lower tier components ready to use. This allows our wizards to collect appropriate information to create these upper tier patterns more easily. Examples of this include the use of the value assembler and the session facade above, where the needed collaborating patterns existed and could be combined as necessary. This feature also allows us to generate more concrete pattern implementation code, including method-to-method associations for both delegating methods between patterns and instantiating necessary collaborating objects. In assembling patterns into a complete application, there are three kinds of relationships that must be considered. First is implicit pattern relationships, such as the one between a transfer value object and its associated DAO, which are handled automatically. When a DAO is created, a transfer value object with instance variables for all fields in the database table is created. Further, the interfaces between components with implicit associations are either fixed or can be determined by examining the components, and the implementation is generally straightforward. These characteristics make it possible to generate source code for these associations, relieving the developer from having to implement trivial and tedious code. Second is explicit pattern relationships, which developers must create using RMA-provided wizards. An example of this relationship is the one between a session facade and the value assembler. More specifically, these are collaborations between patterns that are not always needed in an application. RMA does not require the use of all five of the supported patterns; developers apply only the

7 (a) Session facade: Selecting EJBs. (b) Session facade: Selecting facade methods. Figure 4: Wizards for the session facade. subset that are relevant to their application. This is important as it has been shown that the indiscriminate use of patterns can lead to performance problems [17]. Using the information gathered by the wizards, RMA is able to generate source code implementing these explicit collaborations as well, further simplifying the development process. As well, providing developers with the ability to incrementally add relevant patterns provides them with the flexibility needed to construct an efficient application architecture. The final relationship we can consider is application-specific collaborations between objects based on business logic. The association between the Register bean and ClientAddressAssembler in Figure 3 is an example. These relationships are not based on pattern relationships but rather on application needs. As a result, there is little code that can be generated to maintain these relationships beyond adding an instance variable and possibly accessor methods. As this code is part of the application, it is necessarily left to the developer. Pattern assembly can also be considered as the process of selecting patterns to play roles and fulfill constraints dictated by the J2EE framework [3]. RMA uses this idea to generate code to fulfill constraints when the code is either static boilerplate code or when the code can be generated based on user input or on context information derived from the patterns involved. 4 Hiding Deployment Logic After constructing an efficient architecture, we now concentrate on how to provide additional abstractions to hide the distributed nature of J2EE programs. Although J2EE version 2.1 hides some of the low-level details of distributed programming using Java RMI, its solution is incomplete. Some distributed aspects must still be addressed by developers. There are two types of deployment information that developers must consider: EJB definition and referencing, and deployment descriptor generation. This section describes these two problems and examines our solution that frees the developer from these details. 4.1 EJB Definition and Referencing The J2EE EJB architecture is based on Java RMI. As a result, EJBs require interfaces to export methods to remote clients. More specifically, an EJB consists of the following parts: an EJB bean class, a home interface, and a business interface. The EJB class provides the implementation of the business logic that makes up the application. The home interface exposes factory methods for creating and initializing bean instances. In a given application, there may be two home interfaces: one for local objects and one for remote clients. The business interface exposes the business logic implemented

8 by the bean. As with home interfaces, there can be local and remote business interfaces. Unfortunately, the interfaces have several characteristics that are counter-intuitive and make writing them error-prone. Most of these problems revolve around the fact that the EJB bean class does not implement these extra interfaces. This has several ramifications. First, it can be difficult for developers new to J2EE programming to understand the need or relationship between these classes since there is no explicit association. Second, since the bean class does not implement the interfaces, we cannot rely on compile-time checking for consistency. The obvious solution is for the bean class to implement the interfaces, but this is only possible for the local business interface. The remote interfaces add the checked exception RemoteException to the list of exceptions each method can throw, so any class implementing these interfaces must also add it. The bean class does not throw these remote exceptions and so cannot implement these interfaces. The home interfaces cannot be implemented by the bean class because the method names do not match. The bean class implements a set of methods with the name ejbcreate with different initialization arguments, where the home interfaces export the same set of methods renamed create. The mapping between the methods in the implementation class and those defined in the interfaces is done by the J2EE container. Developers must be aware of this mapping and be sure to use the correct names for the methods while still ensuring the remainder of the signatures match. This last characteristic can be particularly problematic. Once EJBs are correctly implemented, they must obtain references to each other in order to collaborate. Developers have to go through several steps, including a JNDI lookup, to get this reference. Figure 5 shows this process in detail. The code is straightforward but tedious as it must be done to obtain each EJB reference (though a reference can be cached for later use). However, it also requires the developer to manage the JNDI name space for the beans in the application. As a J2EE application grows in size, managing this name space can become cumbersome. The first way RMA improves EJB development is to free developers from writing the extra interfaces. We use Java reflection to extract the method signatures from the EJB class. Using EJB interface information as well as method naming convenprivate Client getclientbean(string jndihomename, String homeclassname) { ClientHome remotehome = null; Object objref, obj; Client cbean=null; // 1. Set up initial context for the name space. InitialContext initialcontext = new InitialContext(); try{ // 2. Look up EJB object using JNDI. objref = initialcontext.lookup(jndihomename); // 3. Check for compatibility. obj = PortableRemoteObject.narrow(objref, homeclassname); // 4. Downcast home object. remotehome = (ClientHome) obj; // 5. Initialize the bean. // There can be several create() methods with // different arguments to initialize the bean. cbean = remotehome.create(); catch (NamingException nex){ nex.printstacktrace(); catch(remoteexception rex){ rex.printstacktrace(); return cbean; Figure 5: Code for Accessing an EJB tions/requirements 1, we can easily identify EJBspecific methods. These are methods that are required by the J2EE container and should not be exported to clients. All methods named ejbcreate are used to construct the home interface with the appropriate method name mapping. All other public methods that are not EJB-specific are added to the business interface, though the user can change the interface to remove methods that they do not wish to export to remote users. This reflectionbased approach saves users from having to add tag information into method comments. Now that we have freed developers from having to create and maintain the extra interfaces, we can concentrate on simplifying the process of finding EJB references and managing the JNDI name space. Before doing this, we need to discuss an important design pattern that was not included in Sec- 1 In cases where an EJB-specific method is not part of the common EJB interface, the method must follow naming guidelines so the EJB container can locate it. For instance, since there are several ejbcreate methods with different arguments this method cannot be part of any interface, but the name must follow the guideline to be used by the container.

9 tion 3: the service locator. This pattern, which is defined in the J2EE framework blueprint, is used to cache JNDI names and handles to EJBs and other remote resources. In the case of EJBs, the service locator caches JNDI-name-to-EJBHome mappings for each EJB. That is, it caches the mapping between the name and the home object from step 3 in Figure 5. This home object is an object generated by the J2EE runtime that implements the home interface. The service locator, in its most common form, returns the EJB home object as a generic instance of Object and requires the application code to perform steps 4 and 5 in Figure 5. To completely hide the JNDI name space, the service locator pattern, and the extra interfaces from developers, we use a proxy solution [6] shown in Figure 6. In our solution, we use the standard version of a single service locator but with some small modifications. Our service locator maintains a separate accessor method for each EJB bean that must be managed. The method encapsulates the JNDI name so the user does not have to manage the set of names. Instead, when a new EJB is created in RMA, a new accessor method is automatically added to obtain a reference to it. This method can be deleted if the EJB is later removed. These accessor methods encapsulate an automaticallygenerated default JNDI name for that EJB, which can be as simple as replacing. with in the fully-qualified class name. The return type of these accessor methods is the downcast EJB home object, from step 4 in Figure 5. In addition, when a new EJB is created in RMA, a new proxy class is generated. The proxy class includes identical versions of the business methods for the EJB, which are delegated to the EJB bean object reference. To obtain that bean reference, the proxy class includes a constructor for each create method in the home interface, with the same arguments. The constructors use our service locator to obtain the home object for the bean and then call the corresponding create with the constructor arguments to get the bean reference. That is, the constructors implement the complete process in Figure 5, where steps 1 through 4 are done in the service locator and step 5 is done in the proxy constructor. Remote exceptions are caught in the proxy, making it look like a local object. All of the necessary information about the EJB can be derived using reflection in a similar manner to generating the home and business interfaces. Thus, an EJB reference is obtained by instantiating the proxy class. The service locator object encapsulates the JNDI name space and the proxy encapsulates the home and business interfaces and remote exceptions. As a result, the proxy appears as a normal, local POJO object. The developer can use the proxies, and hence the EJBs, without knowledge of the underlying distributed environment. Encapsulating remote exceptions in the proxy has a potential drawback in that applications cannot handle these exceptions if necessary. Some applications, like financial transaction systems or safety-critical software, need to respond to failures resulting from the distributed environment to provide their service. For now, RMA assumes that the J2EE runtime provides sufficient fault tolerance for the application. However, more precise exception handling can be implemented in the proxy code. Our proxy solution is similar to the proxy-based business delegate pattern [4] in the J2EE framework. The business delegate is used between the presentation tier and the business tier to hide the complexity of EJB lookups across the two tiers. The proxy generated by RMA can fulfill the role played by the delegate object, and can be used in place of the delegate. RMA has expanded the use of this proxy solution to simplify the process of obtaining references to EJBs throughout the complete application. We feel that all developers will benefit from this abstraction. 4.2 Descriptor Generation To deploy an EJB, the container in which it will run needs information about both the bean and any other beans it references. This information, or deployment descriptor, includes the home and business interfaces of the beans and their JNDI names. Our proxies hide these during development, so exposing them for deployment is unacceptable. Instead, RMA maintains a deployment file for each EJB in the application. When an EJB adds a reference to another, the deployment file is updated. When RMA generates an association between EJBs as a result of applying a pattern, it automatically updates the deployment files with necessary information about JNDI names and interfaces. The user can also add references between EJBs outside of pattern assembly using a wizard provided by RMA, which allows the user to add references based on proxy name. RMA can generate a proxy

10 Client use boolean dologin(string id, String pwd) { LoginBeanProxy login = new LoginBeanProxy(); return(login.login(id,pwd); LoginBeanProxy LoginBeanProxy(): LoginBeanProxy login(string id,string pwd): boolean ServiceLocator query jndinames: String getloginbeanremotehome(): LoginBeanRemoteHome public class LoginBeanProxy { public LoginBeanProxy() try { LoginBeanRemoteHome home = ServiceLocator.getLoginBeanRemoteHome(); bean = home.create(); catch(exception e) { e.printstacktrace(); use use manage LoginBeanRemoteInterface login(string id,string pwd): boolean LoginBeanRemoteHome create(): LoginBeanRemoteInterface public boolean login(string id,string pwd) { try { return bean.login(id,pwd); catch(remoteexception re) { re.printstacktrace(); LoginBeanRemoteInterface bean; Figure 6: POJO Proxy Pattern for EJBs imported from external libraries, so using proxies does not limit the use of legacy code. The individual files are assembled at packaging time to create a complete deployment file. 4.3 Combining the Abstractions We can assemble an application as a set of patterns with or without known pattern relationships among them. Each instance of a pattern is used in a POJO fashion. We hide the distributed nature of the application through code generation. The extra interfaces needed for an EJB class are automatically constructed by RMA. The EJB proxies hide these interfaces and the process of obtaining EJB references, including the service locator. In turn, the service locator hides the JNDI name space. To avoid exposing these generated elements at deployment time, we generate deployment descriptors for the application using captured or known pattern relationships to obtain the necessary information. This seamless combination of abstractions completely removes deployment logic from the development process and the application code. In the end, RMA produces an EAR file (a Java archive file) that is ready to be deployed. 5 Initial Evaluation of RMA Table 1 breaks down the code for our example application by pattern. Overall, RMA generates 1507 lines of code of the 2039 that make up the complete application, about 74%. Note that this percentage is a function of the problem and not an inherent property of the generated code, but it does suggest a reduction in development effort. Of the 532 lines of code supplied by the user, over 80% (438 lines) is needed for the data access objects. This code is responsible for constructing database queries and is necessarily application-specific. The transfer object assembler and value list handler needed code to initialize the database search criteria. The code in the session facade was needed to coordinate method invocations. Finally, where possible we generate stubs for business components to save some user effort. The last entry in the table reflects the code that the user had to insert. The pattern assembly process requires less than 10 minutes of supplying data to RMA wizards. The rest of the applications was completed in under two hours. A breakdown of the code generated for application deployment, totaling 660 lines, is shown in Figure 2. The code for the service locator is identical to that in Table 1. The interfaces for EJBs takes 139 lines. The largest portion, 377 lines (57%) of the deployment code is the proxy code. This generated code all shares the characteristic of being straightforward to write but are unavoidable as there is no single, reusable version. Being able to automatically generate this code, while guaranteeing its correctness, removes a significant burden from developers. To get a better sense of the benefits of RMA, we would like to better understand how the proportion of generated code against the total amount of code in an application changes as the complexity of an application increases. It would still be safe to deduce that as the complexity of the business logic increases, the percentage of generated code will fall. But we believe generating code is worthwhile for the following reasons. First, the generated code

11 Table 1: Code generated for J2EE patterns. The values are the sum for all pattern instances. Pattern Generated LOC User LOC Total Percent of user code Transfer Value Object % Data Access Object % Transfer Object Assembler % Value List Handler % Session Facade % Service Locator % Business Delegate % Business Components % Total % Table 2: Code generated for J2EE deployment. Category Lines of Code Percentage Service Locator Code % Interfaces Code % Proxy Code % Total % guarantees correctness, especially for pattern assembly. Second, as the code becomes more complicated, it will have more EJBs and DAOs in the application. Our simple example requires about 125 lines of transfer object code for each DAO and 90 lines of deployment code for all EJBs in the application. As the application becomes more complicated, these numbers will only grow because they are closely related to factors like the size of the database tables (number of elements in the tuples) and their number, and the number of business methods and variables in the classes. The total amount of time saved by not having to write this code in a large application that incorporates hundreds of EJBs and tables will be significant. In addition, it would be better to measure the difference in development time to understand how much effort is saved using RMA. 6 RMA Architecture RMA is implemented as a set of plugins in the Eclipse development environment. We chose Eclipse as our development platform because of its ubiquity, its flexibility in integrating new features as plugins, and its rich support for Java application development. RMA users can leverage features from other Java plugins, such as refactoring, code completion, and the task view 2 [13]. In its implementation, RMA was also able to leverage several Eclipse plugins. RMA extends and uses the Java Development Toolkit (JDT) [13] and Standard Widget Toolkit (SWT) [13] to provide support for J2EE application development. SWT provides a framework for creating and using wizards, the idiom used by Eclipse plugins to gather user input. JDT provides a complete Java development environment for editing, compiling, debugging, and testing applications. It also provides an API for parsing Java source files into a Document Object Model (DOM) tree so the Eclipse GUI can access and manipulate the different elements in a Java class. The DOM API also allows plugins to traverse and modify the tree, which can be used to manipulate Java source code. We use another Eclipse plugin called Java Emitter Templates (JET) to generate code and deployment descriptors [15]. Finally, we use the task view to highlight places in the generated code where the user may need to insert application-specific code. The architecture and work flow for RMA is shown in Figure 7. RMA provides a set of wizards that run in the Eclipse workbench. These wizards solicit information needed to construct an instance of a J2EE design pattern. Since RMA development is bottom up, the wizards generally present a list of existing methods and classes to the user, who must then select those that are needed to complete the desired design pattern. Where possible, RMA queries the workspace to create a list of valid selections for 2 The task view in Eclipse shows a list of outstanding development tasks to the user. The list can be used to quickly navigate to the relevant section of code. These may consist of compiler errors that need to be fixed or a to-do list. The latter is demarked by comments starting with the word TODO.

12 a given wizard. The dialogs in Figures 4(a) and 4(b) show the wizard for the session facade pattern. A session facade aggregates EJB classes and exports business methods. RMA uses this information to list only EJB classes in the first wizard and to list only business methods in the second. (Section 4.1 explained how to identify the business methods.) Other wizards gather relevant information for the other patterns from Section 3.2. The Artifact Extractor system combines the user input with information derived from the application code to construct a description of a concrete implementation of the selected pattern. This description is then passed to the Code Generator (implemented using JET) to produce both architectural Java code and deployment descriptors. For some patterns, the generated architectural code is incomplete and must be augmented with application-specific code by the user. The places where such code may be needed are marked with a special Eclipse task with the tag EJB-TODO. An extension to the basic Eclipse task view recognizes these new tags and places them in the list. Using a distinct tag allows users to easily distinguish RMArelated tasks from other tasks. The single service locator class is updated using the DOM tree API in JDT. RMA monitors the Eclipse workspace. When a new EJB is created, a new lookup method is added to the DOM tree for the service locator. Similarly, when an EJB is removed the lookup method can be deleted from the tree. The DOM tree is then used to generate the service locator class. Updates to EJBs must be reflected in the interfaces and descriptors. RMA uses listeners provided by Eclipse to note any changes to a bean class. The interfaces and descriptors are then refreshed to ensure they are consistent with the implementation. Eclipse compiles Java source files when they are created and modified. The complete application, consisting of the class files and the descriptor files, is assembled by the Packager component. The result is the EAR file that is ready to be deployed. 7 Related Work We can broadly categorize J2EE development tools as being either code-centric or architecture-centric. Code-centric tools focus on generating code for individual components without any regard for how they will be integrated or deployed. Examples include JBuilder [11] and WebSphere [8]. They produce stub EJB classes from bean interfaces, which the user must assemble into a complete application. XDoclet is an improvement in code-centric tools. Users add Javadoc-style tags that provide additional information needed by the J2EE runtime [18]. These tags indicate can indicate properties like which classes represent EJBs, which methods are creation and business methods, and which fields represent other EJBs. These tags are processed to produce the appropriate interfaces and deployment descriptors. However, the user must maintain these tags in their application, and they provide no help for creating an efficient architecture. Work is underway on a new J2EE specification, Version 3.0, that addresses some of the limitations in J2EE Version 2.1 programming [5]. This new specification takes advantage of metadata annotation facilities that are a new feature in Java [9], making it similar to the tag-based XDoclet above. In particular, home interfaces have been removed entirely; references to other beans are attained through dependency annotations. The developer can create a business interface to a bean if desired, but a default containing all public methods is created if no interface is provided. The interface no longer includes remote exceptions, so the bean class can safely implement it for compile-time checking. Deployment descriptors are also generated based on metadata annotations. Developers can override annotations by supplying XML-based descriptors where necessary. The code-centric efforts focus on removing the distributed artifacts in J2EE applications. RMA also provides support for creating an efficient architecture based on the proven strategies in the J2EE design patterns. Furthermore, RMA obviates the need to insert and maintain the tags that many codecentric tools require. Though these tags are an improvement over manual coding of the artifacts, they still represent some additional developer effort. Architecture-centric tools not only generate EJBs but also integrate them into larger architectural units. One example is Struts [2], which generates a Model-View-Controller architecture for the presentation tier. However, Struts only supports the presentation tier. Another example is Fred [7]. Fred uses roles and constraints (mentioned in Section 3.3.2) to maintain a list of outstanding tasks, similar to the task view in Eclipse [13]. This list

13 DAO + Transfer Value Object Wizard Session Facade + EJBs Wizard user input Roles & Some derivable constraints Value List Handler + DAO Wizard Transfer Value Assembler + DAO Wizard Eclipse IDE Pattern Wizards (Eclipse Plugin) produces Role-Class Matches Concrete Role Information produces Artifact Extractor (Java Reflection) uses produces Code Generator (JET Emitter) uses Known Pattern Relationship Constraints Legends: user input Architectural Code (.java) produces intermediate results uses javac Deployment Descriptor Files (.xml) process implemented by the third party produces Class Files uses uses Packager produces process implemented by us outputs Deployable Application EAR, JAR. produces inputs Figure 7: The architecture of RMA

14 guides the developer through the implementation of the J2EE framework. Other architecture-centric approaches are based on the Model Driven Architecture (MDA) specification from OMG [12]. These tools separate application code from the middleware that will execute it. Examples include realmethods [16], EclipseJ2EE [14], and OptimalJ [4]. Of these, EclipseJ2EE is the most ad-hoc; the user is responsible for creating the architecture. The other two allow applications to use J2EE patterns. These tools have a number of recurring problems. First, they only capture class-level relationships, ignoring method-level ones. The patterns in the J2EE framework are generally not useful in isolation; their composition creates a sound architecture. Ignoring method-level relationships limits the amount of concrete pattern code that can be generated, which requires more code from the user. Second, it is not clear if the user has access to the generated code. Though not addressed in this paper, we believe that such access is an important part of a good programming system. Complicating this is the automated application of design patterns by OptimalJ. We are concerned that this could make it difficult for developers to understand the complete architecture and work with it if necessary. RMA incorporates the advantages of both codecentric and architecture-centric approaches. From the code-centric perspective, we construct EJB classes, interfaces, and deployment information from the application code rather than from interface specifications as done in JBuilder and Web- Sphere. From the architecture-centric perspective, RMA uses roles and constraints to generate implementation code, unlike Fred which guides the user. This means the user concentrates on the application, which is likely their area of expertise, rather than on additional language artifacts needed to support the J2EE runtime. From the architecturecentric perspective, our pattern generation and assembly includes method-level associations, allowing us to generate more concrete code. Work is underway on a new J2EE specification, Version 3.0, that addresses some of the limitations in J2EE Version 2.1 programming [5]. This new specification takes advantage of metadata annotation facilities that are a new feature in Java [9]. In particular, home interfaces have been removed entirely; references to other beans are attained through dependency annotations. The developer can create a business interface to a bean if desired, but a default containing all public methods is created if no interface is provided. The interface no longer includes remote exceptions, so the bean class can safely implement it for compile-time checking. Deployment descriptors are now generated based on metadata annotations included in the source code, a new feature in Java 1.5 [9]. Developers can override annotations by supplying XMLbased descriptors where necessary. 8 Conclusions In this paper, we presented RoadMapAssembler, our J2EE development tool that incrementally constructs a pattern-based J2EE web application. We have shown that incremental construction can make use of more application and design pattern knowledge and produce more concrete code than the topdown MDA approach. RMA has distinguished itself from other pattern-based J2EE tools in that it places more emphasis on capturing pattern relationships than static code generation. We take advantage of these pattern relationships to hide the distributed nature of J2EE application development at both the architectural and code levels, hiding extra interfaces and the JNDI name space. We have also shown that pattern information can be used not just to produce a better application architecture, but also to free the developer from deployment logic. With tool support for J2EE patterns, deployment can be handled automatically. By removing the distributed aspects of J2EE development, developers can focus on their applications and not on the J2EE execution environment. Future work for RMA includes adding presentation tier patterns, evaluating usability, and extensibility. The omission of the presentation tier in RMA means that presentation tier developers do not benefit from our deployment descriptor generation. This also exposes the JNDI name space and access interfaces. Incorporating the presentation tier (by either adding the necessary patterns or adding an existing tool like Struts) will complete the development process. The sample astronomer s club application provides a simple example for discussion, but we need to implement larger applications to evaluate the benefits of using RMA to develop J2EE applications. Like other pattern-based programming tools, RMA will suffer if the set of