Figure 3.1.2.a N-Tier Architecture (Three-tier application ...

4,219
-1

Published on

Published in: Technology, Education
1 Comment
0 Likes
Statistics
Notes
  • Be the first to like this

No Downloads
Views
Total Views
4,219
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
143
Comments
1
Likes
0
Embeds 0
No embeds

No notes for slide

Figure 3.1.2.a N-Tier Architecture (Three-tier application ...

  1. 1. 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
  2. 2. 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..........................................................................................16 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..........................................................................................................19 Figure 3.2.b: J2EE Components and Containers.................................................................................20 Figure 3.2.c: The J2EE Technology Suite............................................................................................21 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.....................................................................................................42 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
  3. 3. 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
  4. 4. J2EE - Enterprise Development and Interoperability With Non-J2EE Clients 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 List of Tables and Figures Figure 3.1.2.a N-Tier Architecture (Three-tier application architecture)........................................................... Figure 3.1.3.a The .Net Server-side Architecture............................................................................................................... Figure 3.1.3.b The J2EE Server-side Architecture.............................................................................................................. Table 3.1.3.c A comparison of J2EE vs Microsoft .NET.................................................................................................... Figure 3.2.a: J2EE Environment........................................................................................................................................ Figure 3.2.b: J2EE Components and Containers............................................................................................................... Figure 3.2.c: The J2EE Technology Suite.......................................................................................................................... Fig 3.3.1.a CORBA Architecture....................................................................................................................................... Fig 3.3.2.a RMI client - CORBA server............................................................................................................................. Fig 3.3.2.b CORBA client - RMI server............................................................................................................................. Fig 3.3.4.a CORBA client - EJB server.............................................................................................................................. Figure 3.4.1.1: Presentation Tier Patterns........................................................................................................................... Figure 3.4.1.2: Business Tier Patterns................................................................................................................................ Figure 3.4.1.3: Integration Tier Patterns............................................................................................................................. Figure 3.4.1.4: J2EE Pattern Relationships........................................................................................................................ Figure 3.4.1.5: J2EE Patterns Framework.......................................................................................................................... A.3.1: DMVApp Automaton node label key........................................................................................................................ A.3.2: DMVApp Automaton................................................................................................................................................ A.3.3: DMVApp Automaton table....................................................................................................................................... A.3.4: DMVApp Data model.............................................................................................................................................. A.3.5: DMVApp queries: type, state, and tables involved................................................................................................... A.4.1 Component Diagram................................................................................................................................................. A.4.2 Use-Case Diagram.................................................................................................................................................... A.4.3 Deployment Diagram................................................................................................................................................ A.4.4 Class Diagram.......................................................................................................................................................... A.4.4 Sequence Diagram – 1.............................................................................................................................................. A.4.4 Sequence Diagram – 2.............................................................................................................................................. A.4.5 DMVEJBModule....................................................................................................................................................... A.5.1 Login Screen............................................................................................................................................................. A.5.2 Main Menu................................................................................................................................................................ A.5.3 Registration Menu..................................................................................................................................................... A.5.4 Registration Screen................................................................................................................................................... A.5.5 License Menu............................................................................................................................................................ A.5.6 License Screen.......................................................................................................................................................... A.5.7 Report Menu............................................................................................................................................................. A.5.8 Pending Registrations Report................................................................................................................................... A.5.9 Non-Java Client (C++ Application) Accessing Ejb In The Dmv Application………………………. 4
  5. 5. 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] aπnd 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, object- oriented, 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
  6. 6. 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. Additional 6
  7. 7. 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 set of technical 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 fault- tolerant 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
  8. 8. 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
  9. 9. 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 well- written 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 9
  10. 10. J2EE - Enterprise Development and Interoperability With Non-J2EE Clients or more components. These layers are pure abstractions and may or may not correspond to physical distribution. A typical layer partitioning is as follows: • 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
  11. 11. J2EE - Enterprise Development and Interoperability With Non-J2EE Clients I n s Presentation e WEB SERVER layer c u r e Firewall + Tier boundary APPLICATION SERVER Business logic S WITH COMPONENT Layer e CONTAINER c u r e Tier boundary z o n e Data layer Database Figure 3.1.2.a N-Tier Architecture (Three-tier application architecture) 11
  12. 12. 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 12
  13. 13. J2EE - Enterprise Development and Interoperability With Non-J2EE Clients • Provide secure environment and deal with unauthorized accesses 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 13
  14. 14. J2EE - Enterprise Development and Interoperability With Non-J2EE Clients • Components could be switched between various application servers 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
  15. 15. 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 15
  16. 16. J2EE - Enterprise Development and Interoperability With Non-J2EE Clients Figure 3.1.3.b The J2EE Server-side Architecture 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 Yes Yes balancing, etc.) Middleware vendors 30+ vendors – IBM, BEA, Microsoft Inprise etc. Interpreter JRE CLR State Management Provided. Helps in less Not provided Services coding and RAD Persistence Servives Provided. Enables Not provided (Entity Beans) developers to write applications without coding data access logic, resulting in leaner, database-independent applications that are easier to build and maintain. Single-vendor Solution Many legacy systems are Users with existing written by J2EE vendors Microsoft-based systems like IBM or BEA. J2EE – it is easy to go ahead offers a single-vendor with .Net solution from the legacy integration perspective, since you can re-use 16
  17. 17. J2EE - Enterprise Development and Interoperability With Non-J2EE Clients existing relationships with those vendors. Support for existing Specifies the JCA - There is no analog to the systems producing a marketplace JCA of J2EE, but some of adapters that will legacy integration is greatly ease enterprise possible through the Host application integration. Integration Server 2000, Integration with COM Transaction packaged applications Integrator, MSMQ and and legacy systems such BizTalk Server 2000. as Siebel, Oracle, or SAP without ever leaving the Java programming environment. Portability Runs on a variety of Only runs on Windows platforms Tools Sun’s Forte, WebGain’s Visual Studio.NET is a Visual Café, IBM’s very powerful IDE VisualAge for Java, Borland’s JBuilder, etc. are available but are not as powerful as VS.NET. Scalability No restriction of the Supports Win32 only, a hardware and hence greater number of easier for organizations machines are needed to maintain when they than a comparable J2EE use different hardware deployment due to than Win32. 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 17
  18. 18. J2EE - Enterprise Development and Interoperability With Non-J2EE Clients • J2EE lets enterprises take advantage of existing hardware they may have • J2EE gives platform neutrality, including Windows and good portability. • 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 client- side support for developing enterprise, multi-tier applications. 18
  19. 19. J2EE - Enterprise Development and Interoperability With Non-J2EE Clients Figure 3.2.a: J2EE Environment 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. 19
  20. 20. J2EE - Enterprise Development and Interoperability With Non-J2EE Clients Figure 3.2.b: J2EE Components and Containers RMI (Communication) J2SE (Core service) EJB (Core service) Simple Distributed - Core Java platform Component Standard Communications API language and services Defines the overall server-side RMI-IIOP adds CORBA such as io, util, applets, architecture interoperability and JFC JMS (Communication) JNDI (Enterprise) - Asynchronous invocations - Provides a namespace for - Publish/ subscribe or finding components and Point-to-point resources - Transactional messages JTA / JTS (Enterprise) JDBC (Enterprise) J2EE - JTA defines the high-level - Provides unified API for interface for demarcating accessing relational transactional boundaries databases - JTS defines the low-level interfaces between transaction participants JavaMail (Communication) - Allows E-mail operations JCA (Enterprise) in a cross-platform, cross- - Provides access to EIS protocol fashion Servlets and JSPs (Core service) Java IDL (Communication) XML (Internet) - Request/ Response oriented - CORBA provides language - Describes EJB components network components interoperability - Format for JSP scripts - Used in web server for client- - Integration with existing side interaction systems 20
  21. 21. J2EE - Enterprise Development and Interoperability With Non-J2EE Clients Figure 3.2.c: The J2EE Technology Suite 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. The servlet receives this request object. Once the servlet has processed the input parameters it may return a response object. During this process, the servlet may 21
  22. 22. 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 JavaBeans to generate dynamic content or perform computations. 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
  23. 23. 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 multi- user 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 client- neutral 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
  24. 24. 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
  25. 25. 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: 25
  26. 26. J2EE - Enterprise Development and Interoperability With Non-J2EE Clients • HyperText Transfer Protocol(HTTP) • 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
  27. 27. 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. Programming with this API permits 27
  28. 28. 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
  29. 29. 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
  30. 30. 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 CORBA- compliant products that implement the CORBA specification available in the market are Borland’s VisiBroker and Iona’s Orbix. 30
  31. 31. 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 cross- language 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
  32. 32. 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. The CCM specification has been formulated with an intention that CORBA components and EJBs can reside together, thus making it possible that 32
  33. 33. J2EE - Enterprise Development and Interoperability With Non-J2EE Clients • 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 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. 33
  34. 34. J2EE - Enterprise Development and Interoperability With Non-J2EE Clients 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 CORBA CLIENT RMI Object Implementation 34
  35. 35. J2EE - Enterprise Development and Interoperability With Non-J2EE Clients 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 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 35
  36. 36. J2EE - Enterprise Development and Interoperability With Non-J2EE Clients 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 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 36
  37. 37. J2EE - Enterprise Development and Interoperability With Non-J2EE Clients 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 exposes one of its EJB (TrafficViolationSB – a session bean) to a non- Java 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 37
  38. 38. J2EE - Enterprise Development and Interoperability With Non-J2EE Clients 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. 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; 38
  39. 39. J2EE - Enterprise Development and Interoperability With Non-J2EE Clients 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 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. 39
  40. 40. J2EE - Enterprise Development and Interoperability With Non-J2EE Clients 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
  41. 41. J2EE - Enterprise Development and Interoperability With Non-J2EE Clients Figure 3.4.1.1: Presentation Tier Patterns Pattern Brief Synopsis Name Decorating Facilitates pre and post-processing of a request Filter Front Provides a centralized controller for managing the Controller handling of a request View Helper Encapsulates logic that is not related to presentation formatting into Helper components Composite Creates an aggregate View from atomic sub- View components Service To Combines a Dispatcher component in coordination with Worker the FrontController and View Helper Patterns. Dispatcher Combines a Dispatcher component in coordination with View the FrontController and View Helper Patterns, deferring many activities to View processing. 41
  42. 42. J2EE - Enterprise Development and Interoperability With Non-J2EE Clients Figure 3.4.1.2: Business Tier Patterns Business Decouples presentation and service tiers, and Delegate 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 Represents a best practice for designing coarse- Entity grained entity beans. Value Object Builds composite value object from multiple data Assembler sources. Value List Manages query execution, results caching and result Handler 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 Abstracts data sources, provides transparent access Object to data. Service Activator Facilitates asynchronous processing for EJB components. Figure 3.4.1.4: J2EE Pattern Relationships 42
  43. 43. J2EE - Enterprise Development and Interoperability With Non-J2EE Clients 43
  44. 44. 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
  45. 45. 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
  46. 46. 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 coarse- grained 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
  47. 47. 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
  48. 48. 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
  49. 49. 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 MODEL (JSPs & VIEW HELPER) (EJBs & Domain classes) Fig. 4.1 MVC Architecture in the DMV Prototype The J2EE design patterns used in the application are: 49
  50. 50. J2EE - Enterprise Development and Interoperability With Non-J2EE Clients • 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
  51. 51. 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
  52. 52. 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. Individual overseeing document submitted 2. Individuals collaborating on specific topic research 3. Individual responsible for writing specific sections of report 4. Individual responsible for module implementation 5.1.1 Individual overseeing document submitted Semester Project Requirements and Specification Sudha Mid-Semester Project Report Betsy Final Project Report Lance Final Presentation Sudha 52
  53. 53. 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 Sudha 3.2 J2EE Platform Overview Lance 3.3 EJB/CORBA Sudha 3.4 Applications of Patterns Betsy 4. The Motor Vehicles Department Sudha Prototype A.1 Application Flow (Screenwise) Sudha A.2 Package structure and classes Sudha A.3 Prototype figures Lance A.4 UML diagrams Sudha A.5 Prototype screenshots 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

×