Mid Term Report



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

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

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

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) 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

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].

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 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.

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.

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 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.

Firewall + Tier boundary

Tier boundary

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

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

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

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.

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

| | | |

|Feature |J2EE |.Net |

|Type of technology |Standard |Product |

|Dynamic Web Pages |JSP | |

|Middle Tier Components |EJB |.Net Managed Components |

|Database Access |JDBC SQL/J | |

|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 |Not provided |

| |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 written by J2EE |Users with existing Microsoft-based systems|

| |vendors like IBM or BEA. J2EE offers a |– it is easy to go ahead with .Net |

| |single-vendor solution from the legacy | |

| |integration perspective, since you can | |

| |re-use existing relationships with those | |

| |vendors. | |

|Support for existing systems |Specifies the JCA - producing a marketplace|There is no analog to the JCA of J2EE, but |

| |of adapters that will greatly ease |some legacy integration is possible through|

| |enterprise application integration. |the Host Integration Server 2000, COM |

| |Integration with packaged applications and |Transaction Integrator, MSMQ and BizTalk |

| |legacy systems such as Siebel, Oracle, or |Server 2000. |

| |SAP without ever leaving the Java | |

| |programming environment. | |

|Portability |Runs on a variety of platforms |Only runs on Windows |

|Tools |Sun’s Forte, WebGain’s Visual Café, IBM’s |Visual is a very powerful IDE |

| |VisualAge for Java, Borland’s JBuilder, | |

| |etc. are available but are not as powerful | |

| |as . | |

|Scalability |No restriction of the hardware and hence |Supports Win32 only, a greater number of |

| |easier for organizations to maintain when |machines are needed than a comparable J2EE |

| |they use different hardware than Win32. |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.

• 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 .

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.

[pic]

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.

[pic]

Figure 3.2.b: J2EE Components and Containers

J2EE

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 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.

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.

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- 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)

• 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 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 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.

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.

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.

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.

• 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:

CORBA Object Interface

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

• 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.

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 Remote Object Interface

Network via IIOP

Fig 3.3.2.a RMI client - CORBA server

CORBA Object Interface

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 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 |

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.

EJB Remote Interface

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 > lic;

cout > pts;

cout ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download