J2EE ENTERPRISE DEVELOPMENT AND INTEROPERABILITY WITH NONJ2EE CLIENTS

1
J2EE - ENTERPRISE DEVELOPMENT AND
INTEROPERABILITY WITH NON-J2EE CLIENTS
presented by Sudha Balla, Betsy Cherian and Lance
Fiondella Semester Project CSE333 Distributed
Component Systems (FALL 2002) Instructor Prof.
Steven A. Demurjian Department of Computer
Science and Engineering University of Connecticut
ballasudha_at_engr.uconn.edu Betsy_at_engr.uconn.edu fio
ndella_at_gtemail.net
2
Organization of presentation

• Introduction and Motivation(Lance)
• Server-side component architectures(Sudha)
• J2EE Platform overview(Lance)
• J2EE Standardized Services(Betsy)
• EJB/CORBA(Sudha)
• J2EE Patterns(Betsy)
• The Department of Motor Vehicles Prototype(Sudha)
• Conclusion(Sudha)

3
Introduction - Assessment

• Java has been around for over 7 years now.
• Server-side component architectures
• Microsofts .NET product
• Sun Microsystems Java2 Platform Enterprise
  Edition (J2EE) standard
• Object Management Groups CORBA standard

4
Introduction - Benefits

• Enterprise JavaBeans includes both Java/RMI and
  RMI IIOP as middleware options.
• Sun and OMG 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, enabling EJB components to be exposed
  as CORBA objects making them well suited for
  cross-language interoperability.

5

6
Motivation SE to EE

• Large organizations utilize J2EE.

7
Motivation -

8
Motivation Academic perspective

• Maintain an objective research perspective on the
  state of development of Java2 Enterprise Edition
  and Java technologies in general.
• Determine the role Java plays as an educational
  language, problem-solving skill for the
  workplace, and research tool for academia.
• Focus on the classical facilities provides
  insight into the true maturation of Java.

9
Server-side Component Architectures(Overview)

• Issues surrounding server-side development
• The need for standardized architecture
• Popular server-side architecture standards
• Similarities and differences between J2EE and
  other competing technologies
• Enterprise Application Development and these
  technologies

10
Server-side Component Architectures(Software
Components)

• What are software components?
• What is a component architecture?
• Divide-and-conquer approach and its advantages
• Saves development and deployment time
• Services could be simply outsourced
• Users save time by buying instead of building
• Deployment is strengthened as the common products
  are developed by domain experts

11
Server-side Component Architectures(Server-side
Components)

• What is a server-side deployment?
• Logical layers in the deployment
• Presentation Layer
• Business logic Layer
• Data Layer
• Layers are pure abstractions and may or may not
  correspond to physical distribution
• a N-tier architecture deployment is one where
  there is a physical separation between each of
  the layers
• Each of the layers could further be decomposed to
  allow various parts of the system to scale
  independently

12
Server-side Component Architectures(Three-tier
Web-based Application Architecture)
Insecure
WEB SERVER
Presentation layer
Firewall tier boundary
APPLICATION SERVER WITH COMPONENT CONTAINER
Business logic Layer
Secure zone
tier boundary
Database
Data layer
13
Server-side Component Architectures(N-Tier
Architectures)

• PRO
• Deployment costs are low
• 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
• CON
• Communication performance suffers
• Maintenance costs are high

14
Server-side Component Architectures(Demands of a
multi-tier deployment)

• Handle lifecycle of the components
• Perform resource pooling
• Broker method requests
• 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 WERE BORN AS A SOLUTION TO
  THESE ISSUES

15
Server-side Component Architectures(Role of
Application Servers)

• provide the middleware services
• allow enterprises buy the services
• aid in rapid the application development
• Anomalies and problems
• Vendor specific middleware services
• Once an application sever is chosen the code is
  locked to that particular vendors solution
• Reduces portability
• Hampers commerce of components

16
Server-side Component Architectures(Need for a
standard)

• The standard would describe a well-formed
  interface between the application server and the
  components themselves
• Components could be managed in a portable way
• Components could be switched between various
  application servers
• 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

17
Server-side Component Architectures(Standards)

• OMGs CORBA Standard
• Sun Microsystems J2EE Standard
• Microsofts .NET Architecture

18
Server-side Component Architectures(Standards
J2EE vs .NET)
Java Client Application
Business System
Web Client
Container
Servlets and JSPs
EJBs
Connectors
Legacy Systems or Databases or Other Business
Systems
The J2EE Server-side Architecture
19
Server-side Component Architectures(Standards
J2EE vs .NET)
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
The .NET Server-side Architecture
20
Server-side Component Architectures(Standards
J2EE vs .NET)

• J2EE was found advantageous over .NET
• a proven platform while .NET is a rewrite of
  Microsofts previous technologies and introduces
  risk as with any first-generation technology
• lets enterprises take advantage of existing
  hardware they may have
• gives platform neutrality, including Windows and
  good portability
• has a better legacy integration through the Java
  Connector Architecture (JCA)
• lets the use of any operating system enterprises
  prefer, such as Windows, UNIX, or mainframe

21
J2EE Platform Overview - Environment
22
J2EE Platform Overview - Components and Containers
23
(No Transcript)
24
J2EE Platform Overview Java Servlet
Technology(1)

• Mechanism for generating dynamic web content.
• They may be thought of as Java applets for
  servers.
• platform independent, pleasant user interfaces,
  better performance due to persistent well-defined
  API for flexibility.

25
J2EE Platform Overview Java Servlet
Technology(2)

• Web browser ? HTTP request ? web server
• Web server ? gives request to servlet container?
  gives request to specific servlet
• Servlet receives request object.
• Servlet processes. (may return a response object)
  
• During process, servlet may use a context object
  to save information usable by other servlets, and
  read a session object to determine a client state.

26
J2EE Platform Overview JavaServer Pages(1)

• Utilize Java Servlet technology to simplify well
  organized dynamic web content.
• JSP pages define the static HTML template, and
  embeds invocations to Java code.
• Useful and routine operations like embedding
  dynamic distributed database queries and
  generation of their associated reports.
• Hides the complexity of programming in Java from
  the page designer

27
Enterprise JavaBean Components(1)

• A server-side technology for developing and
  deploying components containing the business
  logic of an enterprise application.
• Allows encapsulation of legacy technologies.
• EJB is a client-neutral standard.

28
Enterprise JavaBean Components Entity Beans

• Represent persistent objects like database
  entries.
• EJB specification indicates that a bean and its
  references survive a crash of its container.
  (achieved by storing the state in the database or
  through serialization)
• Container provides a class in order to provide
  meta-data to the client.

29
Enterprise JavaBean Components - Message-Driven
Beans

• A basis for constructing loosely coupled
  applications capable of communicating indirectly
  using the queuing and subscription models
  supported by JMS.
• More flexible and realistic for heavily congested
  networks.

30
Enterprise JavaBean Components - Session Beans

• Limited lifetime as the name suggests
• If stateless wont preserve state between calls
• Saving and restoring state are properties of
  stateful session beans

31
J2EE Technology Suite
32
J2EE Standardized Services

• The containers supporting the J2EE components
  provide three types of services
• Communication
• RMI-IIOP
• Java IDL
• JMS
• Java Mail
• Enterprise
• JDBC
• JTA
• JNDI
• JCA
• Internet
• HTTP
• TCP/IP
• SSL
• XML

33
Communication Services

• JavaIDL, RMI-IIOP
• Allows objects written in Java to to invoke CORBA
  objects using IIOP. Provides interoperability
  with CORBA objects.
• JMS
• API for asynchronous messaging
• JavaMail
• Provides an API for electronic mail

34
Enterprise Services

• JDBC
• API for DB independent connectivity between J2EE
  and other datasources
• JTA
• The transaction API for J2EE which guarantees
  transactional integrity
• JNDI
• Provides a naming environment, facilitates
  directory operations
• JCA
• Mandatory with v.1.3 of J2EE. Helps to integrate
  different EJB containers with different EIS.

35
Internet Services

• For access to Internet services, J2EE supports
  the following protocols
• TCP/IP
• HTTP
• SSL
• XML
• J2EE v.1.3. supports XML functionality.

36
EJB CORBA INTEROPERABILITY (Overview)

• 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

37
EJB CORBA INTEROPERABILITY (CORBA Overview)
CLIENT
CORBA Object Implementation
CORBA Object Interface
CORBA Skeleton
CORBA Stub
ORB
ORB
Network via IIOP
CORBA Architecture
38
EJB CORBA INTEROPERABILITY (CORBA Services)

• COS Naming
• CORBA Event Service
• Object Transaction Service (OTS)
• Concurrency Control Service
• Security Service

39
EJB CORBA INTEROPERABILITY (CORBA)

• Advantages
• not controlled by one organization
• language-independent
• Disadvantages
• Slow-moving
• Steep learning curve

40
EJB CORBA INTEROPERABILITY (OMGs CCM
Specification)

• adds component features to CORBA objects
• similar to EJBs
• intention that CORBA components and EJBs can
  reside together
• a CORBA component could appear as if it were an
  EJB
• an EJB could appear as if it were a CORBA
  component

41
EJB CORBA INTEROPERABILITY (Why is CORBA
important for EJBs?)

• Legacy Integration
• Advanced middleware services
• EJBs exposed to CORBA clients (the highlight of
  this interoperability section)

42
EJB CORBA INTEROPERABILITY (RMI and IIOP)

• Remote Method Invocation(RMI) is a communications
  package for performing distributed computing in
  Java
• default protocol layer for communication used by
  RMI is Java Remote Method Protocol(JRMP)
• CORBA uses Internet Inter-ORB Protocol(IIOP) as
  its default protocol layer for communications
• RMI and CORBA are very similar technologies

43
EJB CORBA INTEROPERABILITY (RMI and CORBA)

• Problems
• RMI - built specifically for Java and CORBA
  built to allow language interoperability
• two technologies are highly incompatible
• 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
• prohibits code reuse
• Ideal Scenarios
• Combine client-side Java RMI with server-side
  CORBA
• Combine client-side CORBA with server-side Java
  RMI
• Need bridge between RMI and CORBA
• Solution RMI over IIOP

44
EJB CORBA INTEROPERABILITY (RMI and CORBA
Ideal Scenarios)
RMI CLIENT
CORBA Object Implementation
CORBA CLIENT
RMI Object Implementation
RMI Remote Object Interface
CORBA Object Interface
CORBA Skeleton
RMI Stub
RMI Skeleton
CORBA Stub
ORB
ORB
ORB
ORB
Network via IIOP
Network via IIOP
Scenario 1
Scenario 2
45
EJB CORBA INTEROPERABILITY (RMI over IIOP)

• unification of RMI and CORBA
• RMI run over IIOP (instead of JRMP)
• delivers CORBA distributed computing capabilities
  to the Java2 platform
• speeds distributed application development
  completely in Java
• code reusability of programs coded with the RMI
  API and the CORBA API
• lessens the impact of switching between the two
  technologies
• IIOP eases legacy application and platform
  integration
• IIOP makes RMI more robust

46
EJB CORBA INTEROPERABILITY (RMI over IIOP
Combinations)

• CLIENT
• RMI client with RMI-IIOP Stub
• RMI client with RMI-IIOP Stub
• CORBA client
• CORBA client

• SERVER
• RMI Server with RMI-IIOP skeleton
• CORBA object implementation
• RMI Server with RMI-IIOP skeleton
• CORBA object implementation

47
EJB CORBA INTEROPERABILITY (EJB Specification)

• EJB components must be able to run over both RMI
  and RMI-IIOP
• RMI-IIOP as an on-the-wire protocol for EJB
  components
• Advantages to J2EE
• greatly assist the integration of the J2EE
  environment into existing corporate
  infrastructures, most of which are quite CORBA
  intensive
• EJBs could be exposed as CORBA components that
  could be accessed by non-Java Clients
• relieves EJBs off the constraint that they could
  be only Java based

48
EJB CORBA INTEROPERABILITY (Scenarios)
RMI-IIOP CLIENT
EJB Object Implementation
CORBA CLIENT
EJB Object Implementation
EJB Remote Object Interface
EJB Remote Object Interface
RMI-IIOP Skeleton
RMI IIOP Stub
RMI-IIOP Skeleton
CORBA Stub
ORB
ORB
ORB
ORB
Network via IIOP
Network via IIOP
Scenario 1
Scenario 2
49
Patterns - Definition

• Definition
• .. are a collection of J2EE based solutions to
  common problems... They extract the core issues
  of each problem, offering solutions that
  represent an applicable distillation of theory
  and practice.
• a recurring solution to a problem in a context
• Repository of patterns is called the Design
  Pattern Catalog
• Documented according to a template
• Organized in tiers

50
Patterns - Tiers

• Presentation Tier
• Contains the patterns related to Servlets and JSP
  technology.
• Business Tier
• Contains the patterns related to the enterprise
  beans technology
• Integration Tier
• Contains the patterns related to JMS and JDBC

51
J2EE Pattern Relationships
52
Presentation Tier
53
Business Tier
54
Integration Tier
55
Use of Patterns in DMV App

• The following patterns were used in the DMV
  Application
• Front Controller
• View Helper
• Session Façade
• Transfer Object
• Transfer Object Assembler
• Data Access Object

56
Application Prototype(Overview)

• JBuilder7 Enterprise
• JDataStore
• BES 5
• MS VC 5.0 (for non-Java Client)
• MVC architecture

CONTROLLER (SERVLET HANDLER)
MODEL (EJBs Domain classes)
VIEW (JSPs HELPER)
57
Application PrototypeUse Case Diagram
58
Application PrototypeDeployment Diagram
59
Application PrototypeEJBs in the DMV Application
60
Application PrototypeClass Diagram
61
Application PrototypeApplication Flow and
Patterns(1)
This flow is followed by the Login, Registration
and License Modules
62
Application PrototypeApplication Flow and
Patterns(2)
This flow is followed by the Report Module
63
Application PrototypeEJB exposed to non-Java
Clients
Non-Java Client (C Application)
TrafficViolation Application
Looks up the SB as a CORBA component
TrafficViolationSB (Session Bean)
DMV Application
Finds the License and increments its points
LicenseEB (Entity Bean)
Updates the database
DMV Database
64
Application PrototypeEJB exposed to non-Java
Clients
65
Application PrototypeScreen shots(1)
   


66
Application PrototypeScreen shots(2)