Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
J2EE – ENTERPRISE DEVELOPMENT AND INTEROPERABILITY WITH NON-J2EE CLIENTS Sudha Balla, Betsy Cherian, and Lance Fiondella CSE 333 – Distributed Component Systems Dr. Steven A. Demurjian J2EE - Enterprise Development and Interoperability With Non-J2EE Clients J2EE - ENTERPRISE DEVELOPMENT AND INTEROPERABILITY WITH NON-J2EE CLIENTS Table of Contents TABLE OF CONTENTS ............................................................................................................ 2 1. INTRODUCTION .................................................................................................................................... 5 2. MOTIVATION ......................................................................................................................................... 6 3. JAVA TECHNOLOGY SURVEY .......................................................................................................... 8 3.1 SERVER-SIDE COMPONENT ARCHITECTURES ......................................................................... 8 3.1.1 Software Components .................................................................................................................. 9 3.1.2 Server-side Components .............................................................................................................. 9 Figure 3.1.2.a N-Tier Architecture (Three-tier application architecture) ........................................................ 11 3.1.3 Server-side Component Architecture Solutions ..........................................................................14 Figure 3.1.3.a The .Net Server-side Architecture ............................................................................................ 15 Figure 3.1.3.b The J2EE Server-side Architecture .......................................................................................... 15 Table 3.1.3.c A comparison of J2EE vs Microsoft .NET ................................................................................ 16 3.2 J2EE PLATFORM OVERVIEW ...............................................................................................................18 Figure 3.2.a: J2EE Environment .........................................................................................................18 Figure 3.2.b: J2EE Components and Containers ................................................................................19 Figure 3.2.c: The J2EE Technology Suite ...........................................................................................20 3.2.1 Java Servlet Technology .............................................................................................................21 3.2.2 JavaServer Pages ........................................................................................................................22 3.2.3 Enterprise JavaBean Components ..............................................................................................23 3.2.3.1 Session Beans ...................................................................................................................................... 24 3.2.3.2 Entity Beans ........................................................................................................................................ 24 3.2.3.3 Message-Driven Beans ........................................................................................................................ 25 3.2.4 J2EE Standardized Services........................................................................................................25 3.2.4.1 Communications Services ................................................................................................................... 26 3.2.4.2 Enterprise Services .............................................................................................................................. 28 3.2.4.3 Internet Services .................................................................................................................................. 29 3.3 EJB/CORBA INTEROPERABILITY ................................................................................................30 3.3.1 CORBA OVERVIEW ............................................................................................................................ 30 Fig 3.3.1.a CORBA Architecture .................................................................................................................... 32 3.3.2 RMI-IIOP ....................................................................................................................................33 Fig 3.3.2.a RMI client - CORBA server .......................................................................................................... 34 Fig 3.3.2.b CORBA client - RMI server ......................................................................................................... 35 Table 3.3.2.c Possible combinations in RMI-IIOP .......................................................................................... 37 3.3.3 ADVANTAGES OF EJB-CORBA INTEROPERABILITY ...........................................................37 3.3.4 INTEROPERABILITY SCENARIOS ...........................................................................................37 Fig 3.3.4.a CORBA client - EJB server........................................................................................................... 38 3.4 APPLICATION OF PATTERNS........................................................................................................39 3.4.1 Pattern Functionality ..................................................................................................................40 Figure 3.4.1.1: Presentation Tier Patterns ....................................................................................................... 41 Figure 3.4.1.2: Business Tier Patterns ............................................................................................................. 42 Figure 3.4.1.3: Integration Tier Patterns ......................................................................................................... 42 Figure 3.4.1.4: J2EE Pattern Relationships ..................................................................................................... 43 Figure 3.4.1.5: J2EE Patterns Framework ....................................................................................................... 44 3.4.2 Uses of Patterns in the DMVApp ................................................................................................45 3.4.2.1 Front Controller ................................................................................................................................... 45 3.4.2.2 View Helper ........................................................................................................................................ 45 3.4.2.3 Session Façade .................................................................................................................................... 45 3.4.2.4 Transfer Object.................................................................................................................................... 46 3.4.2.5 Transfer Object Assembler .................................................................................................................. 46 3.4.2.6 Data Access Object ............................................................................................................................. 47 2 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients 4. THE MOTOR VEHICLES DEPARTMENT PROTOTYPE ..............................................................47 4.1 LOGIN ..................................................................................................................................................48 4.2 MANAGE REGISTRATION/LICENSE.......................................................................................................48 4.3 REPORTS ..............................................................................................................................................49 4.4 ACCESS TO NON-JAVA CLIENTS (EJB / CORBA INTEROPERABILITY) .................................................49 4.5 APPLICATION ARCHITECTURE AND PATTERNS ....................................................................................49 Fig. 4.1 MVC Architecture in the DMV Prototype ......................................................................................... 49 5. CONCLUSION AND FUTURE WORK ...............................................................................................51 5.1 MILESTONES ACHIEVED ......................................................................................................................52 5.1.1 Individual overseeing document submitted .................................................................................52 5.1.2 Individuals collaborating on specific topic research ..................................................................53 5.1.3 Individual responsible for writing specific sections of report .....................................................53 5.1.4 Individual responsible for module implementation .....................................................................53 5.2 OBSERVED EXTENSIBILITY ..................................................................................................................53 5.3 TEAM EXPERIENCE ..............................................................................................................................54 REFERENCES ............................................................................................................................................56 BOOKS .......................................................................................................................................................56 INTERNET ..................................................................................................................................................58 APPENDIX ..................................................................................................................................................60 A.1 APPLICATION FLOW (SCREENWISE) ....................................................................................................60 A.1.1 Login.jsp .....................................................................................................................................60 A.1.2 MainMenu.jsp .............................................................................................................................60 A.1.3 RegMenu.jsp ...............................................................................................................................60 A.1.4 LicenseMenu.jsp .........................................................................................................................61 A.1.5 ReportMenu.jsp ..........................................................................................................................61 A.1.6 RegEdit.jsp..................................................................................................................................61 A.1.7 LicenseEdit.jsp............................................................................................................................61 A.1.8 RegReport.jsp .............................................................................................................................62 A.1.9 LicenseReport.jsp .......................................................................................................................62 A.2 PACKAGE STRUCTURE AND CLASSES ..................................................................................................63 A.2.1 CommonServices Module ...........................................................................................................63 A.2.2 Login Module..............................................................................................................................63 A.2.3 Registration Module ...................................................................................................................64 A.2.4 License Module ...........................................................................................................................64 A.2.5 Reports Module ..........................................................................................................................65 A.3 PROTOTYPE FIGURES ..........................................................................................................................66 A.3.1: DMVApp Automaton node label key .........................................................................................66 A.3.2: DMVApp Automaton .................................................................................................................66 A.3.3: DMVApp Automaton table ........................................................................................................67 A.3.4: DMVApp Data model ................................................................................................................68 A.3.5: DMVApp queries: type, state, and tables involved ....................................................................68 A.4 UML DIAGRAMS ................................................................................................................................69 A.4.1 Component Diagram ..................................................................................................................69 A.4.2 Use-Case Diagram .....................................................................................................................70 A.4.3 Deployment Diagram .................................................................................................................71 A.4.4 Class Diagram..........................................................................................................................72 A.4.4 Sequence Diagram – 1 ................................................................................................................73 A.4.4 Sequence Diagram – 2 ................................................................................................................74 A.4.5 DMVEJBModule.........................................................................................................................75 A.5 PROTOTYPE SCREEN SHOTS ......................................................................................................76 A.5.1 Login Screen ..............................................................................................................................76 A.5.2 Main Menu.................................................................................................................................77 3 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients A.5.3 A.5.4 A.5.5 A.5.6 A.5.7 A.5.8 A.5.9 Registration Menu .....................................................................................................................78 Registration Screen....................................................................................................................79 License Menu .............................................................................................................................80 License Screen ...........................................................................................................................81 Report Menu ..............................................................................................................................82 Pending Registrations Report ....................................................................................................83 Non-Java Client (C++ Application) Accessing Ejb In The Dmv Application ..........................84 List of Tables and Figures Figure 3.1.2.a N-Tier Architecture (Three-tier application architecture) ......................................................11 Figure 3.1.3.a The .Net Server-side Architecture ............................................................................................................ 15 Figure 3.1.3.b The J2EE Server-side Architecture .......................................................................................................... 15 Table 3.1.3.c A comparison of J2EE vs Microsoft .NET ................................................................................................ 16 Figure 3.2.a: J2EE Environment ..................................................................................................................................... 18 Figure 3.2.b: J2EE Components and Containers ............................................................................................................. 19 Figure 3.2.c: The J2EE Technology Suite ....................................................................................................................... 20 Fig 3.3.1.a CORBA Architecture .................................................................................................................................... 32 Fig 3.3.2.a RMI client - CORBA server ......................................................................................................................... 34 Fig 3.3.2.b CORBA client - RMI server ......................................................................................................................... 35 Fig 3.3.4.a CORBA client - EJB server .......................................................................................................................... 38 Figure 3.4.1.1: Presentation Tier Patterns ....................................................................................................................... 41 Figure 3.4.1.2: Business Tier Patterns............................................................................................................................. 42 Figure 3.4.1.3: Integration Tier Patterns ......................................................................................................................... 42 Figure 3.4.1.4: J2EE Pattern Relationships ..................................................................................................................... 43 Figure 3.4.1.5: J2EE Patterns Framework ....................................................................................................................... 44 A.3.1: DMVApp Automaton node label key .................................................................................................................. 66 A.3.2: DMVApp Automaton .......................................................................................................................................... 66 A.3.3: DMVApp Automaton table .................................................................................................................................. 67 A.3.4: DMVApp Data model .......................................................................................................................................... 68 A.3.5: DMVApp queries: type, state, and tables involved .............................................................................................. 68 A.4.1 Component Diagram ............................................................................................................................................. 69 A.4.2 Use-Case Diagram ................................................................................................................................................ 70 A.4.3 Deployment Diagram ............................................................................................................................................ 71 A.4.4 Class Diagram ....................................................................................................................................................... 72 A.4.4 Sequence Diagram – 1 .......................................................................................................................................... 73 A.4.4 Sequence Diagram – 2 .......................................................................................................................................... 74 A.4.5 DMVEJBModule .................................................................................................................................................. 75 A.5.1 Login Screen ......................................................................................................................................................... 76 A.5.2 Main Menu ............................................................................................................................................................ 77 A.5.3 Registration Menu ................................................................................................................................................. 78 A.5.4 Registration Screen ............................................................................................................................................... 79 A.5.5 License Menu ........................................................................................................................................................ 80 A.5.6 License Screen ...................................................................................................................................................... 81 A.5.7 Report Menu ......................................................................................................................................................... 82 A.5.8 Pending Registrations Report ................................................................................................................................ 83 A.5.9 Non-Java Client (C++ Application) Accessing Ejb In The Dmv Application……………………….84 4 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients 1. Introduction Enterprise software development has been steadily maturing for nearly a decade now. Technology advances have been made to improve server-side component architectures, the most popular standards[36] being Microsoft’s Distributed interNet Applications Architecture (DNA)[62], Sun Microsystems’ Java2 Platform Enterprise Edition (J2EE)[45,50] and Object Management Group’s CORBA standard[64]. While Microsoft’s DNA is a product, J2EE and CORBA are standards that enable service-based architectures for the enterprise. J2EE is a collection of enterprise technologies[7,33], in which portable, objectoriented, enterprise-class applications may be built. Many of the quality services offered by EJB[19,29,37] (an integral part of J2EE) and CORBA are nearly identical in functionality. EJB includes both Java/RMI and Java – IIOP[25] as middleware options. Sun and OMG[66] support EJB/CORBA interoperability and have produced standards for the same. The EJB/CORBA mapping specification and RMI-IIOP relieve EJB from being restricted to the Java platform, thus enabling EJB components to be exposed as CORBA objects making them well suited for cross-language interoperability. The team’s effort has been to focus on an in-depth analysis of the different technologies offered by J2EE for enterprise software development. And exploration of the interoperability of EJB with CORBA was conducted. A small prototype of a J2EE application was implemented as a proof-of-concept of these technologies and was developed on the Borland Enterprise Server v.5[63]. 5 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients The remainder of this paper is organized as follows: In section 2, an accelerated discussion of the factors in mastering J2EE and Java in general are given. Section 3 begins by introducing server-side architectures, provides a detailed assessment of the spectrum of Java technologies, covers important aspects of EJB and CORBA, and details some specific design pattern techniques utilized in the construction of the prototype application. Section 4 presents the Department of Motor Vehicles prototype application that implements some of the technologies surveyed in section 3, and is given in the form of a tutorial. Technical discussion is given wherever appropriate observations regarding development have been made. Section 5, the conclusion assesses Java2 Enterprise Edition for generic development tasks. A discussion of milestones achieved, observed extensibility, and the team experience are also provided. 2. MOTIVATION It has been over seven years since Java was introduced to the world of computing and many large organizations now have solutions developed on the foundation of J2EE technologies[10]. Sun promotes the free availability of learning resources and makes a significant proportion of their publications available to developers via the web[48]. In addition, several well-known publishers also have excellent series for the individual programmer’s personal learning preference[44,48,68]. Sun’s core learning path[8,9,38] is a compact set of their online series and facilitates the pursuit of corporate certification[21]. The developer must possess solid Java Standard Edition skills[3,14,22,40] in order to make the successful transition to the J2EE technology suite. 6 Additional J2EE - Enterprise Development and Interoperability With Non-J2EE Clients references further reinforce the necessary skills for this ever growing and evolving language[11,12,23]. Like other corporate entities, Sun produces a comprehensive technical set of material and J2EE training texts[2,7,18,19,29,33,37] that serve as a comprehensive introduction to core functionality of the language. When attempting to look beyond distributed object computing in faulttolerant networking environments, it is important that individuals assessing J2EE technologies maintain an objective opinion about general language facilities. Sun has grown into many popular niches of commercial computing, providing Java with a growing set of diverse libraries[28] that can be integrated with J2EE technologies, and this has further reinforced the popularity of the language. It is perhaps most promising that the scientific capacities of Java are also maturing, gaining the approval of the computer science community in areas including: architecture[17], compiler theory[6,16,17,41], 3D graphics[4,24,32,34,35,39], security[13], and Real-time[5]. It is important to maintain an objective research perspective on the state of development of Java2 Enterprise Edition and the Java technologies in general. This project has had the beneficial effect of determining the role Java plays as an educational language, problem-solving skill for the workplace, and research tool for academia. The J2EE Technologies are a rich set of solutions for all three of these domains and focus on the classical facilities has provided insight into the true maturation of Java. 7 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients 3. JAVA TECHNOLOGY SURVEY This section presents a survey of J2EE technologies. Server-side component architectures[67] are presented followed by an introduction to Servlets and Java Server Pages[7]. Enterprise Java Bean components[19] are described, providing a discussion of Session and Entity Beans. The J2EE Standardized Services are broken down into three categories: Communication, Enterprise, and Internet services. Special attention is given to Remote Method Invocation[25] a member of the Communication services. The focus centers on CORBA Interoperability[31,64] and Exposing EJB to non-Java Clients[26,30]. Other Communication, Enterprise, and Internet services of J2EE are treated with a uniform level of detail[46], and design patterns[1] utilized in the prototype are illustrated. 3.1 SERVER-SIDE COMPONENT ARCHITECTURES In this section, we present issues surrounding server-side development, emphasize the need for a standardized architecture, analyze the most popular Server-side Component Architecture standards that exist and conclude where J2EE fits in the whole scenario. The purpose is to show the similarities and the differences between J2EE and the other competing technologies and to what situations each of these technologies are suitable in enterprise application development. 8 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients 3.1.1 Software Components A software component is code that implements a set of well-defined interfaces, a manageable, discrete chunk of logic that cannot run alone but can be used as a puzzle piece to solve some larger problem. A well-defined component architecture supplies the standards necessary for developing the components, container that manages the deployed components and tools for deploying and maintaining the components thus enabling developers to employ a “divide-and-conquer” approach to programming. This approach has the following advantages: Vendors can provide a set of common services that most components will need, thus saving development and deployment time Component developers can simply outsource the services needed to other products written by professionals who are experts in writing these services Users save time by buying instead of building Deployment is strengthened as these common products are written by domain experts 3.1.2 Server-side Components A server-side deployment is software written to support concurrent users performing operations simultaneously, securely, reliably and efficiently. A wellwritten deployment has a logical software partitioning into layers. Each layer has a different role in the overall deployment, and within each layer there can be one or more components. These layers are pure abstractions and may or may not correspond to physical distribution. A typical layer partitioning is as follows: 9 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients Presentation layer: Components dealing with user interfaces and user interaction are placed in this layer. This layer of a web-based application in Java would use servlets, JSPs and/or applets. Business logic layer: Components that work together to solve business problems are in this layer. Data layer: One or more databases that contain the stored state of data required by the application is in this layer. An N-tier architecture deployment is one where there is a physical separation between each of the layers discussed above. A three-tiered web-based application as shown in Figure 3.1.2.a is an example for this architecture. Each of the above-mentioned layers could further be decomposed to allow various parts of the system to scale independently. 10 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients Presentation layer WEB SERVER I n s e c u r e Firewall + Tier boundary APPLICATION SERVER WITH COMPONENT CONTAINER Business logic Layer Tier boundary Data layer Database Figure 3.1.2.a N-Tier Architecture (Three-tier application architecture) 11 S e c u r e z o n e J2EE - Enterprise Development and Interoperability With Non-J2EE Clients N-tier architectures have the following characteristics: Deployment costs are low – it is cheaper to deploy and configure software in a controlled server-side environment than to deploy software on all the user terminals Database switching costs are low Low costs in business logic migration Securing deployments using firewalls is possible Resource pooling is possible Performance slowdown is localized Errors are localized Communication performance suffers Maintenance costs are high But multi-tier deployments need code that would: Broker method requests Perform resource pooling Handle lifecycle of the components Handle the logic to load-balance communications between each tier Deal with ramifications of two or more clients concurrently accessing the same component Reroute client requests to other machines in case of failure Provide secure environment and deal with unauthorized accesses 12 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients Application servers provide these middleware services, thus allowing enterprises to purchase these services and focus on the application development. But each application server available in the market had been providing these middleware services in a non-uniform, proprietary way as there has never been a clear definition of what middle-tier components are. This results in the following disadvantages to enterprises: Once an application sever is chosen the code is locked to that particular vendor’s solution Reduces portability Hampers commerce of components as a customer cannot combine a component written to one application server with another written for a different application server Thus, there arises a need for a standard architecture for the server-side components that would describe a well-formed interface between the application server and the components themselves. The advantages of such a standard architecture would be: Components could be managed in a portable way Component vendors could be relieved of issues about external overhead such as resource pooling, networking, security etc. Necessary elements of enterprise-class deployments are externalized to application server vendors, providing common services to all component developers Components could be switched between various application servers 13 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients 3.1.3 Server-side Component Architecture Solutions The three major standards that evolved as server-side component architectures are, OMG’s CORBA Standard[64] Sun Microsystem’s J2EE Standard[50] Microsoft’s .NET Architecture[62] Of the above three, CORBA is an open distributed object-computing infrastructure and is a specification based on technologies proposed by the software industry. It is the most used middleware in the non-Windows market. The CORBA Component Model (CCM) is the component model extension of CORBA. The CCM can be summarized as the multi-language form of EJB, but .Net and J2EE are a suite of technologies. They enable organizations to simplify complex problems with the development, deployment, and management of multi-tier enterprise solutions. The following figures 3.1.3.a and 3.1.3.b are brief descriptions, and Table 3.1.3.c is a comparison of both the technologies. 14 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients Business System Rich Client Application Web Client Container ASP.NET .Net Managed Components Host Integration Server 2000 Legacy Systems or Databases or Other Business Systems Figure 3.1.3.a The .Net Server-side Architecture Java Client Application Business System Web Client Container Servlets and JSPs EJBs Connectors Legacy Systems or Databases or Other Business Systems Figure 3.1.3.b The J2EE Server-side Architecture 15 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients Table 3.1.3.c A comparison of J2EE vs Microsoft .NET Feature J2EE .Net Type of technology Standard Product Dynamic Web Pages JSP ASP.NET Middle Tier Components EJB .Net Managed Components Database Access JDBC SQL/J ADO.NET SOAP, WSDL, UDDI Yes Yes Implicit Middleware (load balancing, etc.) Yes Yes Middleware vendors 30+ vendors – IBM, BEA, Inprise etc. Microsoft Interpreter JRE CLR State Management Services Provided. Helps in less coding and RAD Not provided Persistence Servives (Entity Beans) Provided. Enables developers to write applications without coding data access logic, resulting in leaner, database-independent applications that are easier to build and maintain. Not provided Single-vendor Solution Many legacy systems are written by J2EE vendors like IBM or BEA. J2EE offers a single-vendor solution from the legacy integration perspective, since you can re-use existing relationships with those vendors. Users with existing Microsoft-based systems – it is easy to go ahead with .Net 16 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients Support for existing systems Specifies the JCA producing a marketplace of adapters that will greatly ease enterprise application integration. Integration with packaged applications and legacy systems such as Siebel, Oracle, or SAP without ever leaving the Java programming environment. There is no analog to the JCA of J2EE, but some legacy integration is possible through the Host Integration Server 2000, COM Transaction Integrator, MSMQ and BizTalk Server 2000. Portability Runs on a variety of platforms Only runs on Windows Tools Sun’s Forte, WebGain’s Visual Café, IBM’s VisualAge for Java, Borland’s JBuilder, etc. are available but are not as powerful as VS.NET. Visual Studio.NET is a very powerful IDE Scalability No restriction of the hardware and hence easier for organizations to maintain when they use different hardware than Win32. Supports Win32 only, a greater number of machines are needed than a comparable J2EE deployment due to processor limitations. This multitude of machines may be difficult for organizations to maintain. From the Table 3.1.3.c we can summarize J2EE to be advantageous over .NET in the following ways: J2EE is a proven platform while .NET is a rewrite of Microsoft’s previous technologies and introduces risk as with any first-generation technology J2EE lets enterprises take advantage of existing hardware they may have J2EE gives platform neutrality, including Windows and good portability. 17 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients J2EE has a better legacy integration through the Java Connector Architecture (JCA) J2EE lets the use of any operating system enterprises prefer, such as Windows, UNIX, or mainframe. Developers can use the environment they are most productive in. In conclusion, while both platforms will have their own market-share, we feel most customers will reap greater wins with J2EE. We feel the advantages outweigh those offered by Microsoft.NET. 3.2 J2EE Platform Overview The J2EE platform has been designed to provide server-side and clientside support for developing enterprise, multi-tier applications. Figure 3.2.a: J2EE Environment 18 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients Such applications are typically configured as a client tier to provide the user interface, one or more middle-tier modules that provide client services and business logic for an application, and backend enterprise information systems providing data management. Figure 3.2.a illustrates the various components and services that make up a typical J2EE environment. One sees from the illustration that clients negotiate with a web or EJB container to access data stored in an enterprise information system. It is this middle-tier that provides J2EE the desired neutrality in encapsulation of client data. Figures 3.2.b and 3.2.c show in much greater detail the technologies that form the J2EE suite and how they interact. There are many APIs[46], which go into the web and EJB containers from the middle-tier of Figure 3.2.a. Figure 3.2.b: J2EE Components and Containers 19 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients RMI (Communication) - Simple Distributed Communications API - RMI-IIOP adds CORBA interoperability J2SE (Core service) - Core Java platform language and services such as io, util, applets, and JFC EJB (Core service) - Component Standard - Defines the overall server-side architecture JNDI (Enterprise) - Provides a namespace for finding components and resources JMS (Communication) - Asynchronous invocations - Publish/ subscribe or Point-to-point - Transactional messages JDBC (Enterprise) - Provides unified API for accessing relational databases JTA / JTS (Enterprise) - JTA defines the high-level interface for demarcating transactional boundaries - JTS defines the low-level interfaces between transaction participants J2EE JavaMail (Communication) - Allows E-mail operations in a cross-platform, crossprotocol fashion Servlets and JSPs (Core service) - Request/ Response oriented network components - Used in web server for clientside interaction JCA (Enterprise) - Provides access to EIS Java IDL (Communication) - CORBA provides language interoperability - Integration with existing systems XML (Internet) - Describes EJB components - Format for JSP scripts Figure 3.2.c: The J2EE Technology Suite 20 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients One also sees that Java2 Standard Edition is a foundation for all of these solutions. The J2EE technology suite’s ability to facilitate enterprise application development is detailed in forthcoming sections. 3.2.1 Java Servlet Technology Java Servlets[15,20] are the mechanism for generating dynamic web content. They may be thought of as Java applets for servers. Servlets are platform independent unlike CGI scripts, and enable the development of more pleasant user interfaces. Servlets exhibit better performance than CGI scripts as they are persistent. In addition, more complex interaction with requesting clients is possible because of the well-defined API, enabling a higher degree of flexibility. Servlets run in a container, which manages its interaction with clients simultaneously enabling the servlet to access services from Java including the entire set of Standard Edition APIs. Some of the most important of this include JDBC, JNDI, RMI and JavaBean technologies. Information about specific clients or sessions may be implemented to defeat the challenges of the stateless HTTP protocol. Commonly, a web browser makes a request to a web server through HTTP. The web server processes the request by giving the request to the servlet container, which in turn gives the request to a specific servlet. receives this request object. The servlet Once the servlet has processed the input parameters it may return a response object. During this process, the servlet may 21 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients use a context object to save information usable by other servlets, and read a session object to determine a client state. The servlet specification defines the concept of a web application, which is a collection of servlets, JavaServer Pages, HTML pages, and supporting content such as images when deployed together make a complete solution. JavaServer Pages another important aspect of the web application shall now be discussed. 3.2.2 JavaServer Pages JavaServer Pages(JSP)[27,43] utilize Java Servlet technology to simplify well organized dynamic web content. Static and dynamic web content is separated by JSP pages, which define the static HTML template, and embeds invocations to Java code. The four elements of a JSP and their roles are as follows: 1. Text elements may be standard HTML or XML content and represent the static portion of the page. 2. Directives are instruction to the JSP processor, which compiles them for efficiency. 3. Tags invoke computations. JavaBeans to generate dynamic content or perform Tags encapsulate functionality and provide the power and extensibility of the JSP paradigm. The may do such useful and routine operations as embedding dynamic distributed database queries and generation of their associated reports. 4. Scripting elements enable the developer to go beyond standard tags and define additional interaction and functionality. 22 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients The JSP model hides the complexity of programming in Java from the page designer enabling them to develop sophisticated web-sites with little or no knowledge of programming. This clean layering allows servlet developers to focus on functionality, and JSP designers to concentrate on web-site layout. 3.2.3 Enterprise JavaBean Components Enterprise JavaBean(EJB) Components[18,19,29,37] are at the center of the J2EE framework. The EJB component model is a server-side technology for developing and deploying components containing the business logic of an enterprise application. Enterprise beans are scalable, transactional, and multiuser secure. EJBs further promote the layering of development from the layers already specified by JSPs and Servlets. EJB technology is a stable business logic solution and removes the computer science performance issues of transaction processing, security, load balancing, connection pooling, and other application server issues from the development process. These details are implemented by a J2EE product provider and allow encapsulation of legacy technologies. By clearly specifying the division of clients and components at the method level, containers are able to manage transactions that occur among components and servers. EJB is a clientneutral standard. Developers may therefore concentrate on business logic implementing a set of callback interfaces. Deployment descriptors are XML files describing how transactions, security, and installation specific details are to be handled by an EJB application that give them their “Write Once, Run Anywhere” property, and provides client transparency. 23 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients A client’s view of an Enterprise Bean is provided through its home and remote interfaces. A bean’s home interface provides methods for instantiating a bean. A bean’s remote interface implements the business logic methods for the component. A client may invoke a home interface, while the remote interface performs the computationally intensive data processing at the server where the data resides. Transactions come in several varieties. They may take place external to a transaction. They may be forced to perform a transaction upon invocation. They may also participate in the transaction of a calling Bean. In addition to container and client managed transactions they may supervise transaction through the Java Transaction API(JTA)[61]. 3.2.3.1 Session Beans As the name suggests, Session beans have a limited lifetime. Stateless session beans do not preserve state between calls. Any client can use any instance of a stateless bean at any time under the control of the container. Their lightweight attributes make managing them very easy. Stateful session beans keep track of session data and are associated with specific clients. Saving and restoring state are properties of stateful session beans. 3.2.3.2 Entity Beans Entity beans represent persistent objects like database entries. Entity beans are design to be robust. The EJB specification indicates that a bean and its references survive a crash of its container. This is achieved by storing the state in the database. Each container provides a class in order to provide meta- 24 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients data to the client. Persistence is either container or bean managed. In the former, the DBMS may be responsible or Java serialization may be relied upon. In the latter, retained fields must be explicitly indicated and the bean is responsible for storage and retrieval. 3.2.3.3 Message-Driven Beans Message-driven beans were introduced in the EJB 2.0 standard, and have been available since J2EE 1.3. They provide a means of constructing loosely coupled applications that are capable of communicating indirectly using the queuing and subscription models supported by JMS. This is a more flexible way of supporting some application configurations, and is more realistic for heavily congested networks. 3.2.4 J2EE Standardized Services The containers supporting the J2EE components provide three types of services: communication, enterprise, and Internet services. Communication services include: Remote Method Invocation over Internet Inter-ORB Protocol(RMI-IIOP)[52] Java Interface Definition Language(Java IDL)[51] Java Message Service(JMS)[57,58] JavaMail[54,55] Enterprise services include: Java Database Connectivity(JDBC)[40,49,56] Java Transaction API(JTA)[61] Java naming and directory services(JNDI)[59,60] Java Connector Architecture(JCA) Internet services include: HyperText Transfer Protocol(HTTP) 25 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients Transport Control Protocol/Internet Protocol(TCP/IP) Secure Socket Layer(SSL) Extensible Markup Language(XML) 3.2.4.1 Communications Services To support distributed applications with containers running on multiple machines and enable more efficient communication J2EE has a set of communication technologies: Remote Method Invocation over Internet Inter-ORB Protocol(RMI-IIOP), Java Interface Definition Language(Java IDL), Java Message Service(JMS), and JavaMail. These provide facilities for performing network communication, sending messages and invoking services. The J2EE platform supports the JRMP protocol, the use of which guarantees interoperability with CORBA servers[26,30,31] written in almost any supported language. J2EE also includes a mandatory RMI-IIOP bridge that makes J2EE application servers able to talk to both CORBA and RMI clients and servers. It uses the Java IDL as the API for calling CORBA services. JavaIDL is now required as part of both the J2SE and J2EE environments. RMI-IIOP is an easier alternative to JavaIDL. JavaIDL allows interfaces to be defined in the Java instead of the Interface Definition Language. The remote interface may be converted to IDL and implemented or invoked in another language if desired. RMI-IIOP is Java Remote Method Invocation technology run over Internet Inter-Orb Protocol, and delivers CORBA distributed computing capabilities to the Java2 platform. It attempts to combine the best features of Java RMI technology with those of CORBA technology. It provides flexibility by allowing developers to pass any serializable Java object between application 26 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients components. Like CORBA, RMI over IIOP is based on open standards defined with the participation of hundreds of vendors and users in the Object Management Group[66]. It uses IIOP as its communication protocol. IIOP eases legacy application and platform integration by allowing application components written in C++, Smalltalk, and other CORBA supported languages to communicate with components running on the Java platform. The EJB specifications[53] state that EJB components must be able to run over both RMI and RMI-IIOP. The addition of RMI-IIOP as an on-the-wire protocol for EJB components greatly enhances capacity for the integration of the J2EE environment into existing corporate infrastructures, many of which are already significantly CORBA intensive. Also, EJBs have the ability to be exposed as CORBA components that may be accessed by non-Java Clients, thus relieving the EJBs of the constraint that they remain Java based. Our technology review effort, has attempted to explain how this interoperability is achieved attempts were made to use this technique in our prototype application by exposing an EJB component as a CORBA component to be accessed by a non-Java client. Unlike JavaIDL and RMI-IIOP, Java Message Service is an asynchronous message service. This permits the queuing of messages. JMS also supports publish-and-subscribe messaging where subscribers may request and publishers may send messages respectively. The JavaMail API supports a form of asynchronous messaging known as electronic mail. JavaMail supports the most commonly used Internet mail protocols. 27 Programming with this API permits J2EE - Enterprise Development and Interoperability With Non-J2EE Clients developers to provide services that send mail messages (e.g. notify a user of the progress of an online book order). 3.2.4.2 Enterprise Services To facilitate DBMS access and enterprise computing resources, J2EE supports a set of enterprise services including: Java Database Connectivity(JDBC), Java Transaction API(JTA), Java naming and directory services(JNDI), Java Connector Architecture(JCA). JDBC is Java’s Database Connectivity specification. Users write Structured Query Language(SQL) statements to manipulate database data from and to their Java solutions. JDBC supports stored procedures, transactions, connections, and user authentication. Other optional portions of the API’s specification provide for more robust fault-tolerance when performing database related operations. JTA, the transaction API for J2EE provides support for transaction integrity for EJB containers. Transactions have beginnings, commitments, and roll-back checkpoints. It also enables coordination of distributed transaction on replicated and fragmented systems. JNDI, Java naming and directory services, exposes an interface for performing directory operations, including association of attributes with objects and locating objects using their attributes. JDBC data sources and JTA objects are stored in a JNDI naming environment. The JNDI naming context allows a container to provide an environment to its components. JNDI promotes sharing of corporate directory services. 28 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients The J2EE connector architecture defines an integration standard for J2EE components with other enterprise resources. Connectors are intended to solve the problem of integrating m EJB container implementations with n enterprise information system products without building m x n separate bridges. The connector architecture assists with integration of security and transaction contexts and the flow of control between the two systems. 3.2.4.3 Internet Services J2EE supports Hypertext Transfer Protocol(HTTP), Transport Control Protocol/Internet Protocol(TCP/IP), and Secure Socket Layer(SSL) to access Internet services. TCP/IP (Transport Control Protocol over Internet Protocol) provides a mechanism to establish connections and reliably deliver streams of data between Internet hosts. HTTP (HyperText Transfer Protocol) is the basis of Internet browsers and Web servers. A client makes an HTTP request to a server, and HTML hypertext is returned via HTTP. SSL (Secure Socket Layer) provides a secure mechanism for clients to access hosts on the Internet, without someone eavesdropping or tampering with the messages. Extensible Markup Language(XML) has been supported since J2EE 1.3. This self-describing data format facilitates exchange of information, and this new technology is being used in applications from data exchange between businesses over the Internet to advanced multi-agent research in academia and government. 29 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients 3.3 EJB/CORBA INTEROPERABILITY Any Server-side component technology would be incomplete if it did not support integration with legacy systems. EJB enables rapid development of portable, enterprise-class server-side applications. On the other hand, CORBA is a very important technology and is quite useful for advanced middleware development, cross-language support and legacy integration. Many of the concepts in EJB came out of CORBA. CORBA offers a much broader suite of middleware features, but learning the complex APIs is very difficult. Combining the advantages of EJBs with those of CORBA allows existing applications written in non-Java languages such as C++, COBOL etc. to access the EJB components. In this section we would try to bring out how EJB and CORBA complement each other, where EJB gets its edge over CORBA, where CORBA would be still depended on, benefits of EJB / CORBA interoperability, interoperability scenarios 3.3.1 CORBA OVERVIEW CORBA is a standard for developing distributed object systems formulated by OMG, a consortium of companies that began in 1989. The well-known CORBAcompliant products that implement the CORBA specification available in the market are Borland’s VisiBroker and Iona’s Orbix. 30 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients The advantages of CORBA are It is not controlled by one organization. Many organizations have invested in its success. So any changes in the specification is with the consent of this group of companies, preventing it from become a standard for any specific product or architecture. It is language-independent. This enables legacy integration and crosslanguage support. The disadvantages of CORBA could be summarized as Slow-moving: As it is under the control of many organizations, the time taken to adopt a new feature is too long. Steep learning curve: The standard is so vast that to master it takes great effort and time. Apart from being a standard to writing distributed object systems, there is a set of services that CORBA offers, published by OMG as the CORBA Object Services (CORBAServices or COS). Some of the services are COS Naming, the CORBA Naming Service is a technology similar to JNDI that enables looking up CORBA objects by name, allowing identification of objects across the network by a human-readable string. CORBA Event Service allows asynchronous communications between CORBA object. An object can subscribe to certain types of events through this service and be notified when such events occur. Object Transaction Service (OTS) enables transactions to be performed by CORBA objects. 31 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients Concurrency Control Service enables multiple clients concurrently interact with a resource by obtaining locks on it. Security Service adds security features to CORBA systems through mechanisms such as user and object identification, authorization, access control, confidentiality etc. The CORBA architecture can be depicted as follows: CLIENT CORBA Object Implementation CORBA Object Interface CORBA Stub CORBA Skeleton ORB ORB Network via IIOP Fig 3.3.1.a CORBA Architecture A specification for CORBA components(CCM) is now available that adds component features to CORBA objects, allowing them to function similar to EJBs. 32 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients The CCM specification has been formulated with an intention that CORBA components and EJBs can reside together, thus making it possible that A CORBA component could appear as if it were an EJB An EJB could appear as if it were a CORBA component Thus CORBA is important for the following reasons: Legacy Integration: Existing legacy systems written in languages like C++ and COBOL could be preserved and reused by wrapping them as CORBA objects allowing them to be called from any application. Advanced middleware services: CORBA standard provides for many advanced middleware services not available in EJB under the J2EE. EJBs exposed to CORBA clients: Clients written using CORBA APIs in languages such as C++ or Smalltalk could access EJBs, thus making EJBs available to non-Java applications. Our EJB-CORBA interoperability section focuses on this feature as this lifts the restriction that EJBs must be solely Java-based. It in fact generalizes EJBs and makes them well suited for cross-language interoperability. We explain how this is achieved in the following sub-sections and give its implementation in our prototype application. 3.3.2 RMI-IIOP Remote Method Invocation(RMI) is a communications package for performing distributed computing in Java. The default protocol layer for communication used by RMI behind the scenes is Java Remote Method Protocol(JRMP). On the other hand, CORBA uses Internet Inter-ORB 33 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients Protocol(IIOP) as its default protocol layer for communications. CORBA ORBs use the IIOP to communicate with each other, as shown in Fig 3.3.1.a. RMI and CORBA are very similar technologies, with RMI being built specifically for very simple distributed applications in Java and CORBA as a robust distributed object standard to allow language interoperability. Unfortunately, these two technologies have been highly incompatible. A major portion of a program coded for the RMI API needs to be rewritten if there is a need to switch to CORBA and vice versa. This prohibits code reuse. Ideally it would be desirable to RMI CLIENT CORBA Object Implementation RMI Remote Object Interface RMI Stub CORBA Skeleton ORB ORB Network via IIOP Fig 3.3.2.a RMI client - CORBA server 34 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients CORBA CLIENT RMI Object Implementation CORBA Object Interface CORBA Stub RMI Skeleton ORB ORB Network via IIOP Fig 3.3.2.b CORBA client - RMI server Combine client-side Java RMI with server-side CORBA (Fig. 3.3.2.a) and Combine client-side CORBA with server-side JavaRMI.(Fig. 3.3.2.b) This necessitates a bridge between RMI and CORBA. The RMI-IIOP (RMI over IIOP) is the unification of RMI and CORBA to achieve this bridge. It is Java Remote Method Invocation technology run over Internet Inter-Orb Protocol and delivers CORBA distributed computing capabilities to the Java2 platform. It combines the best features of Java RMI technology with those of CORBA technology. Like Java RMI, RMI over IIOP speeds distributed application development by allowing developers to work completely in the Java programming 35 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients language. It provides flexibility by allowing developers to pass any serializable Java object between application components. Like CORBA, RMI over IIOP is based on open standards defined with the participation of hundreds of vendors and users in the Object Management Group. It uses IIOP as its communication protocol. IIOP eases legacy application and platform integration by allowing application components written in C++, Smalltalk, and other CORBA supported languages to communicate with components running on the Java platform. The advantages of RMI-IIOP could be summarized as follows: Code reusability of programs coded with the RMI API and the CORBA API, lessening the impact of switching between the two technologies. Code written in any CORBA compliant language could call the RMI object implementations. RMI clients can be integrated to legacy systems. IIOP makes RMI more robust RMI object implementations can be invoked dynamically using CORBA’s Dynamic Invocation Interface(DII). Table 3.3.2.c shows the possible combinations using RMI-IIOP. The EJB 2.0 specification states that EJB components must be able to run over both RMI and RMI-IIOP. The addition of RMI-IIOP as an on-the-wire protocol for EJB components would greatly assist the integration of the J2EE environment into existing corporate infrastructures, most of which are quite CORBA intensive. Also, EJBs could be exposed as CORBA components that 36 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients could be accessed by non-Java Clients, thus relieving the EJBs of the constraint that they could be only Java based. CLIENT SERVER RMI client with RMI-IIOP Stub RMI Server with RMI-IIOP skeleton RMI client with RMI-IIOP Stub CORBA object implementation CORBA client RMI Server with RMI-IIOP skeleton CORBA client CORBA object implementation Table 3.3.2.c Possible combinations in RMI-IIOP 3.3.3 ADVANTAGES OF EJB-CORBA INTEROPERABILITY There are several advantages that come with the interoperability between EJBs and CORBA. Some of them are: Non-Java clients written in any CORBA compliant language can call the EJBs In a single transaction clients can mix calls to both CORBA objects and EJBs. 3.3.4 INTEROPERABILITY SCENARIOS Typical interoperability scenarios are: EJBs integrated with legacy applications in CORBA compliant languages – In this scenario, the client application is wrapped with a CORBA layer thus exposing them as CORBA object implementations. EJBs communicate with these CORBA objects through the IIOP. EJBs exposed as CORBA components to non-Java clients – In this scenario, the client is written in a language that is CORBA compliant. The clients access the EJBs through the IIOP. Our prototype application 37 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients exposes one of its EJB (TrafficViolationSB – a session bean) to a nonJava application (C++ client application). Fig. 3.3.4.a shows the interoperability scenario of a CORBA client with an EJB server. CORBA CLIENT EJB Object Implementation EJB Remote Interface CORBA Stub RMI-IIOP Skeleton ORB ORB Network via IIOP Fig 3.3.4.a CORBA client - EJB server CORBA / EJB Client Example: The following code sample shows the C++ CORBA client accessing the TrafficViolationSB session bean that enables points to be accrued to a specified Driver’s License whenever a ticket is issued for violating the rules of the road. 38 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients try { CORBA::ORB_var orb = CORBA::ORB_init(argc, argv); CORBA::LongLong lic; CORBA::Long pts; cout << "Enter License Number: "; cin >> lic; cout << "Enter Points: "; cin >> pts; cout << "Accessing the naming service" << endl; CORBA::Object_ptr o = orb->resolve_initial_references("NameService"); cout << "Getting the naming context" << endl; CosNaming::NamingContext_var context = CosNaming::NamingContext::_narrow(o); cout << "Assigning name" << endl; CosNaming::Name name; name.length(1); name[0].id = CORBA::string_dup("TrafficViolationSB"); name[0].kind = CORBA::string_dup(""); cout << "Resolving the home interface" << endl; CORBA::Object_var object = context->resolve(name); com::uconn::dmv::lic::beans::TrafficViolationSBHome_var ctvsbhome = com::uconn::dmv::lic::beans::TrafficViolationSBHome::_narrow(object); cout << "Creating a new instance" << endl; com::uconn::dmv::lic::beans::TrafficViolationSB_ptr ctvsb = ctvsbhome->create(); cout << "Calling method on TrafficViolationSB" << endl; CORBA::Long r = ctvsb->incrementPointsAccrued(lic,pts); if(r==0) cout << "Points successfully accrued" << endl; else cout << "Points accrual failed" << endl; } catch(const CORBA::Exception& e) { cout << "Exception: " << e << endl; } 3.4 APPLICATION OF PATTERNS The J2EE Patterns[1,42] are a collection of J2EE-based solutions to common problems encountered by enterprise application developers. A pattern is a recurring solution to a problem in a context. It factors central issues of a set of similar problems, offering insight into general solutions that represent an clear distillation of theory and variation in practice. A pattern is documented in a template form. Several have been compiled together into a collection called the Sun Java Center J2EE Patterns Catalog[47], which uses a tiered approach to divide the J2EE patterns according to functionality. The "Rule of Three", as it is 39 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients known in the pattern community serves as a guide for transitioning a candidate pattern into the pattern catalog. According to this rule, a solution remains a candidate pattern until it has been verified in at least three different systems. 3.4.1 Pattern Functionality Presentation Tier patterns(Figure 3.4.1.1) contain the patterns related to Servlets[15,20] and JSP[27,43] technology. Business Tier patterns(Figure 3.4.1.2) contain the patterns related to the enterprise beans technology[19,29,37]. Integration Tier patterns(Figure 3.4.1.3) contain the patterns related to JMS[57,58] and JDBC[40,49,56]. Patterns are documented at an appropriately high level of abstraction. At the same time, each pattern includes various strategies that provide lower-level implementation details. Through the strategies, each pattern documents a solution at multiple levels of abstraction. The patterns catalog provides prosaic code fragments and advice for implementing these patterns. The following figures provide brief descriptions of the Presentation, Business, and Integration Tiers respectively, and Figure 3.4.1.4 shows the interconnections among them. 40 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients Figure 3.4.1.1: Presentation Tier Patterns Pattern Name Brief Synopsis Decorating Filter Facilitates pre and post-processing of a request Front Controller Provides a centralized controller for managing the handling of a request View Helper Encapsulates logic that is not related to presentation formatting into Helper components Composite View Creates an aggregate View from atomic subcomponents Service To Worker Combines a Dispatcher component in coordination with the FrontController and View Helper Patterns. Dispatcher View Combines a Dispatcher component in coordination with the FrontController and View Helper Patterns, deferring many activities to View processing. 41 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients Figure 3.4.1.2: Business Tier Patterns Business Delegate Decouples presentation and service tiers, and provides a façade and proxy interface to the services. Value Object Exchanges data between tiers. Session Facade Hides business object complexity, centralizes workflow handling. Aggregate Entity Represents a best practice for designing coarsegrained entity beans. Value Object Assembler Builds composite value object from multiple data sources. Value List Handler Manages query execution, results caching and result processing. Service Locator Hides complexity of business service lookup and creation, locates business service factories. Figure 3.4.1.3: Integration Tier Patterns Data Access Object Abstracts data sources, provides transparent access to data. Service Activator Facilitates asynchronous processing for EJB components. 42 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients Figure 3.4.1.4: J2EE Pattern Relationships 43 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients Figure 3.4.1.5: J2EE Patterns Framework Figure 3.4.1.5 above shows each J2EE pattern and the connection between the roles of each pattern clarifying how the patterns connect together to form a framework. The dotted and solid lines between patterns indicate relationship dependencies. The dotted lines show optional dependencies, while the solid lines indicate required dependencies. The primary theme of the pattern catalog is its support of the J2EE platform. For the project, the Patterns Catalog was explored in detail 6 patterns were identified which served as a basis for the prototype application developed. 44 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients 3.4.2 Uses of Patterns in the DMVApp The following patterns have been used in the construction of the prototype application. The application is a small subset of the functionality an Department of Motor Vehicles office requires. Selected patterns are listed below: 3.4.2.1 Front Controller For the Front Controller, the J2EE Patterns catalog advocates using: “a Controller as the initial point of contact for handling a request. The Controller manages the handling of the request, including invoking security services such as authentication and authorization, delegating business processing, managing the choice of an appropriate view, handling errors, and managing the selection of content creation strategies. The Controller provides a centralized entry point that controls and manages web request handling.” The Front Controller is implemented in the prototype as a Servlet and serves as the single entry point to the entire application. 3.4.2.2 View Helper This promotes the separation of presentation formatting logic and data access logic. “A view contains formatting code, delegating its processing responsibilities to its helper classes, implemented as JavaBeans or custom tags. Helpers also store the view's intermediate data model and serve as business data adapters.” The View Helper is implemented with a JSP. Business logic is encapsulated inside scriptlets and through the creation of custom-tags. 3.4.2.3 Session Façade The Session Façade is intended to provide a simpler interface to the clients by encapsulating all the complex interactions between business components. This assists in the prevention of tight coupling among these components, which would lead to direct dependence between clients and 45 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients business objects. It helps in the reduction of method invocations between client and server resulting in improved network performance, while also preventing misuse of business objects. The Catalog specifies “Use a session bean as a facade to encapsulate the complexity of interactions between the business objects participating in a workflow. The Session Facade manages the business objects, and provides a uniform coarsegrained service access layer to clients.” A Session Bean implements the Session Façade. 3.4.2.4 Transfer Object The Transfer Object is used to exchange data between tiers. In EJB Applications, every method call to the Bean is remote; therefore using multiple calls to get methods that return single attribute values degrades network performance and is inefficient for obtaining data values from an enterprise bean. The Catalog suggests “Use a Transfer Object to encapsulate the business data. A single method call is used to send and retrieve the Transfer Object. When the client requests the enterprise bean for the business data, the enterprise bean can construct the Transfer Object, populate it with its attribute values, and pass it by value to the client.” 3.4.2.5 Transfer Object Assembler The Transfer Object Assembler is used to build composite value objects from multiple data sources. “Use a Transfer Object Assembler to build the required model or submodel. The Transfer Object Assembler uses Transfer Objects to retrieve data from various business objects and other objects that define the model or part of the model.” 46 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients The Transfer Object Assembler constructs a composite Transfer Object that represents data from different business components. The Transfer Object caries the data for the model to the client in a single method call. 3.4.2.6 Data Access Object J2EE Applications typically use persistent data at some point. “The DAO is used to abstract data sources and provide transparent access to data. Use a Data Access Object (DAO) to abstract and encapsulate all access to the data source. The DAO manages the connection with the data source to obtain and store data.” The DAO implements the access mechanism required to work with the data source. The data source could be of any kind, however the business component that relies on the DAO uses the simpler interface exposed by the DAO for its clients. The DAO completely hides the data source implementation details from its clients. 4. THE MOTOR VEHICLES DEPARTMENT PROTOTYPE As a proof-of-concept, a small prototype application has been developed, and provides a few common services provided by the Department of Motor Vehicles (DMV)[65]. The DMV application (DMVApp) enables authenticated users to manage common tasks such as vehicle registration, issuance of licenses, and generation of pertinent reports. This section is presented in the form of a “first-use” tutorial for the DMVApp which implements some of the technologies surveyed in section 3. In addition to the tutorial, technical discussion is given wherever appropriate observations regarding development have been made 47 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients 4.1 Login The user is first required to login to the system where an initial authentication/verification is performed. After successful login, the user is presented with a menu of choices from which he must select a task to perform. These include managing registration data, managing license data, and the generation of reports. 4.2 Manage Registration/License When managing data, the user may choose to add new records for the appropriate type of data, or update existing records. To maintain simplicity of implementation, while retaining user-friendliness, when the user is performing and update they may merely enter the appropriate key value via the user interface and select an edit option. Both edit and add selections transition the user to the same data management screen, however, in the case when the user is updating an existing record the pertinent data returned from a successful query is displayed within the appropriate fields, otherwise the fields are naturally blank. Since the type of data manipulation (add/edit) has been pre-specified and is maintained unknown to the user, once finished with the record the submit event performs the appropriate query, executing the original appropriate behavior as specified by the user. The user may add and/or edit any number of records in the registration and license management portions of the application. This activity effectively entails associating vehicles with a registration, and people with a license while preserving related integrity constraints. When finished managing data the user may return to a main menu and generate reports. 48 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients 4.3 Reports Two reports have been incorporated and are demonstrative of the functionality offered by the application. These are registration and license renewal mailing reminders. 4.4 Access to non-Java Clients (EJB / CORBA Interoperability) The application allows its non-Java Client (assumed to be Traffic Violation Control Department’s application that manages road violations – a C++ application) to increment points to Driver’s Licenses whenever a ticket is issued for a violation. 4.5 Application Architecture and Patterns The J2EE technologies used to develop each tier of the architecture are Java Server Pages (JSP), Servlet, EJBs and Java Classes. Model-View Controller(MVC) architecture is adopted in the design of the application with the Servlet and the Handler classes acting as the Controller, the JSPs and the View helper classes as the View and the EJBs and Domain classes as the Model (Fig. 4.1). CONTROLLER (SERVLET & HANDLER) VIEW (JSPs & VIEW HELPER) MODEL (EJBs & Domain classes) Fig. 4.1 MVC Architecture in the DMV Prototype 49 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients The J2EE design patterns used in the application are: Front Controller – The DMVControlServlet in the application acts as the Front Controller. All the client requests arrive at this servlet and its service method processes these requests by delegating it to appropriate handlers of the different modules namely – login, registration, license and report. The result of such processing is the next view(JSP) that has to be sent as the response to the client browser. The servlet dispatches a forward to the corresponding view. Thus the DMVControlServlet serves as the Front Controller for the application. View Helper – The classes LoginView, RegView, LicView and RepView in the application act as the View helpers. They contain within themselves relevant information on login, registration, license and report modules respectively that the JSPs retrieve while generating responses to the client requests. Session Façade – The session beans in the application act as the Session Façade. All interaction between the handler classes and the entity beans or the data access object happen through the session beans. This allows a coarse grained approach thus reducing the network overheads that would arise by way of adopting a fine grained approach. Transfer Object – By using domain classes (Value Object) in the application, the return values from the session beans are not handles to the Entity beans anymore, but the value object themselves. Thus, the handlers need not make network calls to retrieve data but could instead 50 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients use the data set in the value objects. This again results in a coarse grained approach. Transfer Object Assembler – The session beans act as the Transfer Object Assemblers in the prototype as they retrieve data from the entity bean and set them onto Transfer Objects. Data Access Object – The RepDAO class in the application is the data access object that serves the report module to retrieve multiple records from the database. This class contains the appropriate methods with the necessary data logic to access and retrieve data from the database using JDBC. The performance is sacrificed by the use of entity beans where multiple records are retrieved from the database. The use of the DAO eliminates this drawback. 5. CONCLUSION AND FUTURE WORK Our analysis of the server-side component architectures gave us a clear insight of the competing standards. We understood that CORBA accommodates a wide range of languages and offers sophisticated middleware services in its specification, but its vast APIs and complexity in programming would be major hurdles for this standard to monopolize the distributed computing environment and also for enterprises to depend entirely on it for their application development. While J2EE and .NET have a suite of similar technologies under them, for the reason that .NET is marketed as a product and is not platform independent, it has many disadvantages when compared with J2EE in the real world of enterprises having heterogeneous infrastructure. 51 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients Our survey of the J2EE technology suite enabled us to visualize the demands of development of enterprise class applications, the numerous technologies that play a part in fulfilling the need of different legacy, information systems integration and interoperability scenarios that need to bridge between different vendor technologies. We could understand the purpose of each of the APIs in the J2EE suite, the issues each of these APIs address and the vital role they play in enterprise application development. The attempt to expose EJBs to non-Java client gave us the opportunity to explore and understand the importance of the CORBA to J2EE and the vision behind the origin of RMI-IIOP. J2EE design patterns are proven ways of application design and gave us an insight into practical implementation. We were able to understand the role of a good design and the pitfalls of wrong approaches. 5.1 Milestones Achieved Individual and team-work is broken down in several ways: 1. 2. 3. 4. Individual overseeing document submitted Individuals collaborating on specific topic research Individual responsible for writing specific sections of report Individual responsible for module implementation 5.1.1 Individual overseeing document submitted Semester Project Requirements and Specification Mid-Semester Project Report Final Project Report Final Presentation 52 Sudha Betsy Lance Sudha J2EE - Enterprise Development and Interoperability With Non-J2EE Clients 5.1.2 Individuals collaborating on specific topic research Primary contributor in bold: Server-side Component Architectures Sudha The J2EE Technologies Lance, Betsy and Sudha EJB/CORBA Interoperability and Exposing EJB to Sudha and Lance non-Java Clients J2EE Patterns Betsy Prototype Application Sudha and Betsy 5.1.3 Individual responsible for writing specific sections of report This includes body sections of the final report and its appendicies: 3.1 Server-side component architectures 3.2 J2EE Platform Overview 3.3 EJB/CORBA 3.4 Applications of Patterns 4. The Motor Vehicles Department Prototype A.1 Application Flow (Screenwise) A.2 Package structure and classes A.3 Prototype figures A.4 UML diagrams A.5 Prototype screenshots Sudha Lance Sudha Betsy Sudha Sudha Sudha Lance Sudha Sudha 5.1.4 Individual responsible for module implementation Sudha and Betsy 5.2 Observed Extensibility While our team looked into specific component based technologies under the J2EE suite like the Servlets, JSPs (web components) and EJBs(business components), we were unable to critically analyze the use of other technologies in the suite. Given the numerous enterprise issues that J2EE addresses, we 53 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients believe that it would be appropriate if each of these technologies are dealt with in detail as a separate project by itself. Otherwise, we were able to complete what we had planned for as the scope of this project. Our implementation has a Win32 console based C++ application client for the demonstration of EJB exposed to non-Java client. This could be extended if this client is a COM+ component developed in C++ or C#, in which case the EJB would be exposed to a wide range of Microsoft specific application clients (developed in VB, C++, ASPs etc.). With the fact that both Microsoft and Sun Microsystems promoting web services, it would be a topic of great interest to look into as it would simplify interoperability issues between the two techology suites. However, this is at its infant stages and the transformations it goes through has to be carefully observed. 5.3 Team Experience The team had significantly different backgrounds, and this made coordination of the project difficult at times though the entire process was educational for all. Communication was in general open and honest and this proved very useful in allocation of work. Had this not been the case there could have been significant problems with the completion of the work. So this diversity had both positive and negative influences, though overall a significant amount of learning and cooperation took place. individual was different. The technical background of each There were several problems encountered when attempting to utilize enterprise tools that not all members were familiar with. This 54 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients combined with the lack of professional programming experience in Java by certain team members made the programming work significantly unbalanced. Everyone learned a significant amount for his or her own sake, and in general the project served a unique purpose for each individual. 55 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients REFERENCES Books [1] Alur, D., Malks, D., Core J2EE Patterns: Best Practices and Design Strategies, Prentice Hall Professional Technical, June 2001. [2] Austin, C., Pawlan, M., Advanced Programming for the Java™ 2 Platform, Addison-Wesley, August 2000. [3] Barker, J., Beginning Java Objects: From Concepts to Code, Wrox Press, 2000. [4] Barrilleaux, J., 3D Users Interfaces with Java 3D, Manning, 2001. [5] Bellella G. et al., The Real-Time Specification for Java™, Addison-Wesley, June 2000. [6] Bloch, J., Effective Java™ Programming Language Guide, Addison-Wesley , June 2001. [7] Bodoff, S., Pawlan, M., Haase, K., Jendrock, E., The J2EE Tutorial with Cdrom, AddisonWesley, March 2002. [8] Campione M., Walrath K., Huml A., The Java™ Tutorial Third Edition, Addison-Wesley, April 2001. [9] Campione M., Walrath K., Huml A., The Java™ Tutorial Continued: The Rest of the JDK™, Addison-Wesley, January 2001. [10] Cattell, R., Inscore, J., Enterprise Partners, J2EE™ Technology in Practice: Building Business Applications with the Java™ 2 Platform, Enterprise Edition, Addison-Wesley, June 2001. [11] Chan, P., The Java™ Developers Almanac 2000, Addison-Wesley, 2000. [12] Chan, P., Lee, R., Kramer, D., The Java™ Class Libraries, Second Edition, Volume 1: Supplement for the Java™ 2 Platform, Standard Edition, v1.2, Addison-Wesley, May 1999. [13] Gong, L., Inside Java™ 2 Platform Security: Architecture, API Design, and Implementation, Addison-Wesley, June 1999. [14] Hart, J., Java J2SE 1.4: Core Platform Update, Wrox Press, March 2002. [15] Hunter, J., Crawford, W., Java Servlet Programming, O'Reilly & Associates, Incorporated, April 2001. [16] Kanerva, J., The Java™ FAQ, Addison-Wesley, July 1997. [17] Lindholm T., The Java™ Virtual Machine Specification, Second Edition, Addison-Wesley, April 1999. [18] Matena, V., Stearns, B., Applying Enterprise JavaBeans™: Component-Based Development for the J2EE™ Platform, Addison-Wesley, December 2000. [19] Monson-Haefel, R. Loukides, M. Ed., Enterprise JavaBeans, O'Reilly & Associates, Incorporated, August 1999. 56 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients [20] Moss, K., Java Servlets, The McGraw-Hill Companies, June 1999. [21] Mughal K., Rasmussen, R., A Programmer’s Guide to Java™ Certification: A Comprehensive Primer, Addison-Wesley, 1999. [22] Mukhar, K., Lauinger T. Carnell, J. et al., Beginning Java Databases: JDBC, SQL, J2EE, EJB, JSP, XML, Wrox Press, 2001. [23] Palmer, G., Java Programmer’s Reference, Wrox Press, 2000. [24] Palmer, I., Essential Java 3D fast, Springer, 2001. [25] Pitt, E., McNiff, K., java.rmi: The Remove Method Invocation Guide, Addison-Wesley, 2001. [26] Pritchard, J., COM and CORBA, Side by Side: Architectures, Strategies, and Implementations, Addison-Wesley, June 1999. [27] Professional JSP, various authors, ISBN 81-7366-211-8 [28] Riggs, R., Taivalsaari, A., VandenBrink M., Programming Wireless Devices with the Java™ 2 Platform, Micro Edition, Addison-Wesley, June 2001. [29] Roman, E., Mastering Enterprise JavaBeans and the Java 2 Platform, Enterprise Edition, Wiley, John & Sons, Incorporated, September 1999. [30] Rosen, M., Curtis, D., Foody, D., Integrating CORBA and COM Applications, Wiley, John & Sons, Incorporated, September 1998. [31] Rosenberger, J. L., Sams Teach Yourself CORBA in 14 Days, Sams, December 1997. [32] Selman, D., Java 3D Programming, Manning, 2002. [33] Singh, I., Johnson, M., Stearns, B., Designing Enterprise Applications with the J2EE Platform 2nd ed., Addison-Wesley, April 2002. [34] Sowizral, H., Rushforth, K.,Deering, M., The Java 3D™ API Specification, Second Edition, Addison-Wesley, December 2000. [35] Sun Microsystem, Inc., Java™ Look and Feel Design Guidelines, Addison-Wesley, August 1999. [36] Sørensen, C.-F., A Comparison of Distributed Object Technologies, The Norwegian University of Science and Technology, 2001. [37] Valesky, T. C., Enterprise JavaBeans: Developing Component-Based Distributed Applications, Addison-Wesley, May 1999. [38] Walrath K., Campione M., The JFC Swing Tutorial: A Guide to Constructing GUIs, AddisonWesley, July 2001. [39] Walsh, A. Java 3D™: API Jump-Start, Prentice Hall, 2002. [40] White S., Fisher M., Cattell R., Hamilton G., Hapner M., JDBC API Tutorial and Reference, Second Edition Universal Data Access for the Java 2 Platform, Addison-Wesley, September 1999. 57 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients [41] Wilson, S., Java™ Platform Performance: Strategies and Tactics, Addison-Wesley, June 2000. Internet [42] http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/ [43] http://j2ee.masslight.com/ [44] http://java.oreilly.com [45] http://java.sun.com [46] http://java.sun.com/apis.html [47] http://java.sun.com/blueprints/patterns/catalog.html [48] http://java.sun.com/docs/books/ [49] http://java.sun.com/docs/books/tutorial/jdbc/index.html [50] http://java.sun.com/j2ee/ [51] http://java.sun.com/j2se/1.3/docs/guide/idl/index.html [52] http://java.sun.com/j2se/1.3/docs/guide/rmi-iiop/index.html [53] http://java.sun.com/products/ejb/docs.html [54] http://java.sun.com/products/javamail/FAQ.html [55] http://java.sun.com/products/javamail/index.html [56] http://java.sun.com/products/jdbc/faq.html [57] http://java.sun.com/products/jms/faq.html [58] http://java.sun.com/products/jms/tutorial/index.html [59] http://java.sun.com/products/jndi/faq.html [60] http://java.sun.com/products/jndi/tutorial/ [61] http://java.sun.com/products/jta/index.html [62] http://msdn.microsoft.com/ [63] http://www.borland.com/besappserver/index.html [64] http://www.corba.org/ [65] http://www.dmv.org [66] http://www.omg.org 58 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients [67] http://www.theserverside.com/home/index.jsp [68] http://www.wrox.com 59 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients APPENDIX A.1 Application Flow (screenwise) A.1.1 Login.jsp Login Screen User submits username and password After check, if user is an authenticated user then MainMenu.jsp is the response Else response is Login.jsp 2 A.1.2 MainMenu.jsp Main Menu Screen User chooses one of the three menu options Registration License Reports The response is 3, 4 or 5 respectively 3 4 5 A.1.3 RegMenu.jsp Registration Menu Screen User chooses one of the two menu options New Registration Edit existing Registration The response is RegEdit.jsp 60 6 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients A.1.4 LicenseMenu.jsp License Menu Screen User chooses one of the two menu options New License Edit existing License The response is LicenseEdit.jsp 7 A.1.5 ReportMenu.jsp Report Menu Screen User chooses one of the two menu options Pending Registrations Expired Licenses The response is LicenseEdit.jsp 8 A.1.6 RegEdit.jsp Registration Screen User enters all the details for a registration (if new) or changes any detail on a registration (if existing) The response is RegMenu.jsp (with an appropriate message of success or failure of the operation performed – insert or update) 3 A.1.7 LicenseEdit.jsp License Screen User enters all the details for a license (if new) or changes any detail on a license (if existing) The response is LicenseMenu.jsp (with an appropriate message of success or faiure of the operation performed – insert or update) 61 4 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients A.1.8 RegReport.jsp Pending Registration Report Screen A report on pending registrations appears. A.1.9 LicenseReport.jsp Expired Licenses Report Screen A report on expired licenses appears. 62 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients A.2 Package Structure and Classes Package structure and the classes with their public methods are hereunder. As of now only the public methods are mentioned. A.2.1 CommonServices Module Package : com.uconn.dmv.common.view Class: CommonView Method : set and get methods for the common view data like a message on screen etc. Package : com.uconn.dmv.common.handler Class: CommonHandler Method : some methods required in common by all Handler classes (eg.) saveObjectInSession() and getObjectFromSession() when we want to store some objects in session and retrieve them. Package : com.uconn.dmv.common.util Class: CommonServices Method : some methods required in common by all Handler classes (eg.) some date manipulation methods etc. A.2.2 Login Module Package : com.uconn.dmv.login.servlets Class: LoginServlet Method : service() Package : com.uconn.dmv.login.beans Class: LoginSB, LoginEB Package : com.uconn.dmv.login.view Class: LoginView extends CommonView Method : set and get methods for the data member LoginInfo object Package : com.uconn.dmv.login.domain Class: LoginInfo Method : set and get methods for the username and password data members Package : com.uconn.dmv.login.handler Class: LoginHandler extends CommonHandler Method : processRequest() JSPs for this module will be Login.jsp and MainMenu.jsp 63 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients A.2.3 Registration Module Package : com.uconn.dmv.reg.servlets Class: RegServlet Method : service() Package : com.uconn.dmv.reg.beans Class: RegSB, RegEB, VehicleEB Package : com.uconn.dmv.reg.view Class: RegView extends CommonView Method : set and get methods for the data member Registration object Package : com.uconn.dmv.reg.domain Class: Registration, Vehicle Method : set and get methods for the data members of each of the classes Registration Class attributes: regNo, Vehicle, dateOfIssue, dateOfCancellation, status (pending, active, expired, cancelled) Vehicle Class attributes: vin, make, model, year, color, etc. Package : com.uconn.dmv.reg.handler Class: RegHandler extends CommonHandler Method : processRequest() createRegistration() editRegistration() updateRegistration() JSPs for this module will be RegMenu.jsp and RegEdit.jsp A.2.4 License Module Package : com.uconn.dmv.license.servlets Class: LicenseServlet Method : service() Package : com.uconn.dmv.license.beans Class: LicenseSB, LicenseEB, PersonEB Package : com.uconn.dmv.license.view Class: LicenseView extends CommonView Method : set and get methods for the data member License object 64 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients Package : com.uconn.dmv.license.domain Class: License, Person Method : set and get methods for the data members of each of the classes License Class attributes: licenseNo, Person, dateOfIssue, validity, status (valid, invalid), pointsAccured Person Class attributes: ssn, lname, fname, mname, dob, address, phone Package : com.uconn.dmv.license.handler Class: LicenseHandler extends CommonHandler Method : processRequest() createLicense() editLicense() updateLicense() JSPs for this module will be LicenseMenu.jsp and LicenseEdit.jsp A.2.5 Reports Module Package : com.uconn.dmv.reports.servlets Class: ReportServlet Method : service() Package : com.uconn.dmv.reports.beans Class: ReportSB Package : com.uconn.dmv.reg.view Class: ReportView extends CommonView Method : set and get methods for the ArrayList - reportList (of Registration or License objects) Package : com.uconn.dmv.reports.dao Class: ReportDAO Method : data access methods to retrieve registrations or licenses for the reports with the respective user criteria Package : com.uconn.dmv.reports.handler Class: ReportHandler extends CommonHandler Method : processRequest() getRegistrationReport() getLicenseReport() JSPs for this module will be RegReport.jsp and LicenseReport.jsp 65 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients A.3 Prototype Figures Figures A.3.1, A.3.2, and A.3.3 formally illustrate the application as a finite state automaton where Prototype Figure A.3.1 is a legend for the states at the level of the Java Server Pages: 1:Login.jsp 3:RegMenu.jsp 5:ReportMenu.jsp 7:LicenseEdit.jsp 9:LicenseReport.jsp 2:MainMenu.jsp 4:LicenseMenu.jsp 6:RegEdit.jsp 8:RegReport.jsp 10:Farewell.jsp A.3.1: DMVApp Automaton node label key Figure A.3.2 is the automaton at the level of the Java Server Pages: A.3.2: DMVApp Automaton 1 2 3 6 10 4 7 5 8 9 66 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients Figure A.3.3 is the related transition table describing the user interface events generating the actions. This transition table encompasses how rejected user input and query failure are to be handled by exceptions in a graceful fashion. A.3.3: DMVApp Automaton table State 1 1 1 2 2 2 2 3 3 3 4 4 4 5 5 5 6 6 7 7 8 9 Event failed login successful login exit logout registration license reports main menu edit/query failed new or edit/query successful main menu edit/query failed new or edit/query successful main menu pending registrations expired licenses submit UI validation or query failed submit UI validation or query failed dismiss dismiss Next State 1 2 10 1 3 4 5 2 3 6 2 4 7 2 8 9 3 6 4 7 5 5 Figures A.3.4 and A.3.5 depict the data model of the application and a list of the queries executed respectively. Figure A.3.5 specifies 9 queries that the system will implement, the type of query, the state of the automaton in which this occurs, and the tables involved in the query. 67 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients A.3.4: DMVApp Data model A.3.5: DMVApp queries: type, state, and tables involved Query # 1. 2. 3. 4. 5. 6. 7. 8. 9. I S x x U x x x x x x x D state 1 3 6 6 4 7 7 5 5 68 tables user registration, vehicle registration registration license, person license license registration, vehicle license, person J2EE - Enterprise Development and Interoperability With Non-J2EE Clients A.4 UML Diagrams A.4.1 Component Diagram 69 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients A.4.2 Use-Case Diagram 70 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients A.4.3 Deployment Diagram 71 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients A.4.4 Class Diagram 72 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients A.4.4 Sequence Diagram – 1 73 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients A.4.4 Sequence Diagram – 2 74 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients A.4.5 DMVEJBModule 75 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients A.5 PROTOTYPE SCREEN SHOTS A.5.1 LOGIN SCREEN 76 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients A.5.2 MAIN MENU 77 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients A.5.3 REGISTRATION MENU 78 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients A.5.4 REGISTRATION SCREEN 79 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients A.5.5 LICENSE MENU 80 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients A.5.6 LICENSE SCREEN 81 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients A.5.7 REPORT MENU 82 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients A.5.8 PENDING REGISTRATIONS REPORT 83 J2EE - Enterprise Development and Interoperability With Non-J2EE Clients A.5.9 NON-JAVA CLIENT (C++ APPLICATION) ACCESSING EJB IN THE DMV APPLICATION 84