J2EE Application Server

Confidential
Introduction

Confidential
Outline

 Evolution of J2EE
 J2EE Defined
 J2EE Services
 J2EE Scenarios
 Application Clients, Servlets and JSPs
 EJBs and declarative management
 Roadmap

Confidential
‘Enterprise’ in J2EE

 ‘Programming in the large’ and ‘enterprise computing’ :

differ from small-scale and academic computing
 Lots of users and the application has an ‘extended life’
 Deployed on heterogeneous computing environments
 Needs to have versioning mechanism
 Developed by a team of developers over long time
 Maintainability, Flexibility, Reusability are major issues

 Difficulties
 Needs to support transactions, resource-pooling, security, threading, persistence,
life-cycle management etc…
 System programming at the expense of business logic
 Developers have to become specialists
 Proprietary APIs result in non-portable code

 Need for special solutions to manage complexity

 Proprietary frameworks and middleware
 Need for standard APIs for enterprise computing
 Multi-tiered architecture in enterprise applications

Confidential
What is J2EE ?

 Java started shipping in 3 editions starting in 1999, dubbed

– J2SE (Java 2 Standard Edition) :
– J2ME (Java 2 Micro Edition) :
– J2EE (Java 2 Enterprise Edition) :

 Goal of J2EE is to specify a platform (it is a SPECIFICATION)

– Component model
– Core infrastructure

 J2EE means :
 J2EE Platform - A standard platform for hosting J2EE applications, specified as a set
of required APIs, specifications and policies.
 J2EE Compatibility Test Suite - A suite of compatibility tests for verifying that a J2EE
platform product is compatible with the J2EE platform standard.
 J2EE Reference Implementation - A reference implementation for demonstrating the
capabilities of J2EE and for providing an operational definition of the J2EE platform.
 J2EE Application Programming Model - A standard programming model for
developing multi-tier, thin-client applications.

Confidential
J2EE Platform Architecture

 Component
 A component is an application level software unit.
 The J2EE platform supports the following types of components :
 Applets,
 Application clients,
 Web components and
 Enterprise Java Beans (EJBs)
 Container
 All J2EE components depend on the runtime support of a system-level
entity called a container.
 Containers provide components with services such as
 life cycle management,
 security,
 deployment
 threading

Confidential
J2EE Platform

TM
J2EE Patterns

Confidential
J2EE Components and Containers

• Required logical relationships of architectural elements of the J2EE platform

• Does not imply physical partitioning of the elements (e.g., machines, processes or VMs etc.)

Confidential
J2EE APIs

Confidential
J2EE Platform Roles

 J2EE
Product
Provider
 Applicati
on
Compon
ent
Provider
 Applicati
on
Assembl
er Confidential
J2EE Naming Services

 Provides components with access to a JNDI naming environment

 Allows a component to be customized without the need to access or change the
component's source code.
 JNDI API is independent of JNDI SPI
 Doesn’t matter how the ‘virtual enterprise directory’ is implemented

Confidential
J2EE Deployment Services

 J2EE deployment services allow components and applications to be customized at

the time they are packaged and deployed.
 A J2EE application consists of one or more J2EE modules and one J2EE application
deployment descriptor (EAR file)
 A J2EE module consists of one or more J2EE components and one deployment
descriptor of that component type.

Confidential
J2EE Transaction Services

 J2EE transactions are flat (not nested)

 The J2EE platform handles many transaction details, such as propagating and
coordinating among multiple transaction managers.
 Web components are not designed to be transactional.
 Transactions are propagated from a Web component to an enterprise bean only when
the Web component starts the transaction.
 Transaction can be container managed, i.e., declarative during deployment with
attributes such as REQUIRED, MANDATORY etc.
 Transactions can also be bean managed i.e. via the
javax.transaction.UserTransaction
 UserTansaction gives fine grained control but is prone to oversight (unreleased
resources, timeouts, rollbacks)
 It is preferable to use container managed transactions

Confidential
Declarative Transaction Management

 Container intercepts client calls and takes care of transaction management

 Remember old TP monitors (e.g., Tuxedo, Encina) ?
 An Object Transaction Monitor is one of the most important new offerings in J2EE
 Declarative transactions and security are achieved using deployment descriptors
 Transactions and security properties of an app controlled by changing deployment
descriptors
 Application servers have built in transaction monitors
 Weblogic 6.0 has Tuxedo built-in, iAS 6.0 has Encina built-in

Confidential
J2EE Security feature

• Declarative Security (authentication and authorization)

• Security features declared at deployment

• Not Embedded in code

• Flexible, just change and redeploy
• Role-Based Access Control

• Users, groups mapped to roles

• Containers intercept requests/method invocations, enforce access control policy

• Fine grain - constraints specified on resources

• Supports message integrity measures

Confidential
J2EE Communication Technologies

 Internet protocols TCP/IP HTTP 1.0 SSL 3.0

 Remote Method Invocation protocols
 Object Management Group protocols JavaIDL RMI-IIOP
 Messaging technologies JMS, JavaMail
 Data formats HTML 3.2, Image Files, JAR, class files,XML

Confidential
J2EE Application Scenario

• Client tier supports a variety of client types, both outside and inside of corporate firewalls.

• Middle tier supports client services through Web containers in the Web tier and supports business
logic component services through Enterprise JavaBeans (EJB) containers in the EJB tier.
• Enterprise information system (EIS) tier supports access to existing information systems

Confidential
J2EE Application Configurations

 Stand-alone Client <> EJB Container <> RDBMS/EIS Resources : This configuration is the first step in
the evolutionary migration from a two-tier client server system.
 Browser <> Web Container <> RDBMS/EIS Resources : This configuration is popular in small scale web
applications that are not supposed to serve an unpredictable number of users and is more appropriate
for systems that reside within the intranet of an organization. This is suitable for applications where use
of an application server is overkill.
 Browser <> Web Container <> EJB Container <> RDBMS/EIS Resources : This configuration is the
recommended full-blown architecture where the application has to be robust and scalable with a
multitude of users demanding the maximum performance out of the system.

Confidential
Client options

Confidential
Servlets and JSPs

Servlets :
 Java Components that extend HTTP Server
 Generation of dynamic content
• Managed by a Container
• Output can be HTML, XML, WML, or any other content type
 Loaded on Demand
 Unloaded at Any Time
 Mapped to URLs
 Important abstractions
 Request, Response, Servlet Context, Sessions
JSPs :
 Text-based documents contain HTML, JSP tags, Java code
 “Inside-Out” Servlets, declarative, presentation-oriented way of writing Servlets.
 Benefits:

• Easier to Author (separate presentation from code)

• Easier for Tools (J2EE standard)
• Designer-serviceable part
 Exploits:

• Server-Side Scripting
• Templates
• Encapsulation of Functionality

Confidential
Servlets or JSPs ?

 Use JSP’s for response generation

 Use Servlets for controller (FrontController Design Pattern)
 Use Servlets for service or for generating binary content
 Example
 Displaying shopping cart => use JSP technology
 Generating images or charts=> use Servlets
 Request processing => both JSP and Servlet technologies are suitable

Confidential
Approaches to Content Generation

Confidential
Enterprise Java Beans

 A specification for creating server-side scalable, transactional, multi-user secure enterprise-level applications.
 Provides a consistent component architecture framework for creating distributed n-tier middleware.
 Consists of

 EJB server,
 EJB containers that run on EJB server
 EJBs that run in these containers
 EJB clients and other auxiliary systems like the Java Naming and Directory
Interface (JNDI ) and the Java Transaction Service (JTS).
 Three Types of EJBs
 Session Beans : meant for client sessions and business logic
 Stateful
 Stateless

 Entity Beans : Provide an abstract view of an entity (data model)

 Bean Manage Persistence
 Comtainer Managed Persistence

 Message Driven Beans : Act as a message listener client to JMS queues or

topics

Confidential
Client’s view of EJB

Confidential
Anatomy of an EJB

 Client Code :

 Context context = new InitialContext (props); //JNDI Initialization

 ForumSessionServerHome fssh; // Home reference declaration
 fssh = (ForumSessionServerHome) context.lookup("apps/ForumSessionServer"); //JNDI lookup
 ForumSessionServer server; // Remote reference declaration
 server = fssh.create ("driver", "location", "pass", "tablename"); // Remote interface reference obtd.

Confidential
Statechart of Session Bean

Confidential
Statechart of Entity Bean

Confidential
Message Driven Beans and JMS

 Provide loose coupling among heterogeneous systems

 Interoperate with legacy systems that use messaging for integration

 Interoperate with B2B systems not based on the J2EE TM platform
 Provide asynchronous communication
 Provide support for disconnected use of enterprise beans
 New enterprise bean type – Asynchronous

 Activated upon message arrival

 Stateless
 No home or remote interface
 Bean implements javax. jms. MessageListener interface
 onMessage method contains business logic
 Configured as listener for queue (point-to-point)/ topic (publish-subscribe)
 JMS APIs for sending messages available to all enterprise beans

 Use in point- to- point configurations

 Reliable queuing
 Use within pub/ sub configurations
 Beans publishing events

Confidential
B-2-B Application Scenario

 Peer-level interactions between both Web and EJB containers

 At present, this is a more tightly coupled solution most suitable for intranet environments
 JMS and SOAP are gaining in popularity
 Message driven bean in the EJB Container listening to JMS messages

Confidential
Some Transaction Attributes

Required Mandatory
Default

RequiresNew NotSupported
Unconditinal RM not supported
Commit Required By J2EE product

Confidential
Deployment Descriptor : Example

Confidential
Security Descriptors : Examples

Confidential
J2EE : What it is not

Still required are

 The need to analyze, model and design the ‘application’

 The analysis and conceptual design of the application which should be platform-independent

Use help from

 Design patterns of solutions instead of reinventing the wheel

 J2EE Blueprints for a higher level of abstraction
 At a more concrete level, try J2EE Design Patterns

Remember

 There are J2EE compliant vendor products BUT there is no J2EE compliant ‘application’ !

Confidential
Thanks

Confidential