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 [email_address] [email_address] [email_address]
Organization of presentation
Introduction and Motivation(Lance)
Server-side component architectures(Sudha)
J2EE Platform overview(Lance)
J2EE Standardized Services(Betsy)
The Department of Motor Vehicles Prototype(Sudha)
Introduction - Assessment
Java has been around for over 7 years now.
Server-side component architectures
Microsoft’s .NET product
Sun Microsystems’ Java2 Platform Enterprise Edition (J2EE) standard
Object Management Group’s CORBA standard
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 .
Motivation – SE to EE
Large organizations utilize J2EE.
Motivation - …
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.
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
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
Server-side Component Architectures ( Three-tier Web-based Application Architecture ) Presentation layer Business logic Layer Data layer WEB SERVER APPLICATION SERVER WITH COMPONENT CONTAINER Database Secure zone Insecure Firewall + tier boundary tier boundary
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
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 vendor’s solution
Hampers commerce of components
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
Server-side Component Architectures (Standards)
OMG’s CORBA Standard
Sun Microsystem’s J2EE Standard
Microsoft’s .NET Architecture
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
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
Server-side Component Architectures (Standards – J2EE vs .NET)
J2EE was found advantageous over .NET:
a proven platform while .NET is a rewrite of Microsoft’s 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
J2EE Platform Overview - Environment
J2EE Platform Overview - Components and Containers
“ .. 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
Patterns - Tiers
Contains the patterns related to Servlets and JSP technology.
Contains the patterns related to the enterprise beans technology
Contains the patterns related to JMS and JDBC
J2EE Pattern Relationships
Presentation Tier Combines a Dispatcher component in coordination with the FrontController and View Helper Patterns, deferring many activities to View processing. Dispatcher View Combines a Dispatcher component in coordination with the FrontController and View Helper Patterns. Service to Worker Creates an aggregate View from atomic sub-components Composite View Encapsulates logic that is not related to presentation formatting into Helper components View Helper Provides a centralized controller for managing the handling of a request Front Controller Facilitates pre and post-processing of a request Decorating Filter Brief Synopsis Pattern Name
Business Tier Hides complexity of business service lookup and creation, locates business service factories. Service Locater Manages query execution, results caching and result processing. Value List Handler Builds composite value object from multiple data sources. Value Object Assembler Represents a best practice for designing coarse-grained entity beans. Aggregate Entity Hides business object complexity, centralizes workflow handling. Session Facade Exchanges data between tiers. Value Object Decouples presentation and service tiers, and provides a façade and proxy interface to the services. Business Delegate
Integration Tier Facilitates asynchronous processing for EJB components. Service Activator Abstracts data sources, provides transparent access to data. Data Access Object
Use of Patterns in DMV App
The following patterns were used in the DMV Application:
Application Prototype Application Flow and Patterns(1) This flow is followed by the Login, Registration and License Modules
Application Prototype Application Flow and Patterns(2) This flow is followed by the Report Module
Application Prototype EJB exposed to non-Java Clients Non-Java Client (C++ Application) TrafficViolationSB (Session Bean) LicenseEB (Entity Bean) Looks up the SB as a CORBA component Finds the License and increments its points DMV Database Updates the database TrafficViolation Application DMV Application
Application Prototype EJB exposed to non-Java Clients