Dibyendu Baksi, PhD

1
Dibyendu Baksi, PhD Java Architect, Sun Java
Center, Sun Microsystems, Inc. 3655, North Point
Parkway, Suite 600, Alpharetta, GA
30005 Dibyendu.Baksi_at_sun.com
2
Introduction

• Goals
• An appreciation of the Java 2 Enterprise Edition
  platform
• Where it fits in the larger scheme of things
  (software engineering)
• Broad overview with occasional dive into
  specifics
• Two part presentation
• J2EE Infrastructure, component models, APIs
  11/12
• Design issues and persistence options in J2EE
  (Session Beans, CMP/BMP of Entity Beans, J2EE
  Patterns, JDBC, JDO, Data Caching, Session/State
  Management, ) 11/14

3
Part I Outline

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

4
Software Engineering Evolution

• Perspective
• Computer Science (Algorithmics !) really made
  tremendous progress
• Data structures algorithms
• OS design
• Compiler and database design
• Computer Organization and Architecture
• Theory of computation
• Electrical Engineering hardware design has
  progressed a lot and is consistently keeping
  pace with Moores Law
• In comparison, Software Engineering has seen
  very slow progress
• Spectacular failures, costs are rising and
• Fred Brooks The Mythical Man Month is as
  relevant today as it was in the 60s
• Evolution
• Procedural abstractions, libraries as delivery
  mechanism, waterfall model
• Managing complexity with OO paradigm, iterative
  development model
• Concept of software components with versioning
  and container

5
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

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

7
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

8
J2EE Platform
TM
J2EE
Patterns
8
9
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.)

10
J2EE APIs

11
J2EE Platform Roles

• J2EE Product Provider
• Application Component Provider
• Application Assembler
• Application
• Deployer
• System Administrator
• Tool Provider

12
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
• Doesnt matter how the virtual enterprise
  directory is implemented

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

14
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

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

16
J2EE Security Features

• 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

17
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

18
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

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

20
Client options
21
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

22
Servlets or JSPs ?

• Use JSPs 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

23
Approaches to Content Generation
24
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

25
Clients view of EJB

• Home Interface Has create, remove and find
  methods
• Remote Interface Has the business methods
• The Bean Implementation Has the implementation

26
Anatomy of an EJB
Client Code Context context new
InitialContext (props) //JNDI
Initialization ForumSessionServerHome fssh //
Home reference declaration fssh
(ForumSessionServerHome) context.lookup("apps/Foru
mSessionServer") //JNDI lookup ForumSessionServer
server // Remote reference declaration server
fssh.create ("driver", "location", "pass",
"tablename") // Remote interface reference
obtd.
27
Statechart of Session Bean
28
Statechart of Entity Bean
29
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

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

31
Some Transaction Attributes
Required Default
Mandatory
RequiresNew Unconditinal Commit Required
NotSupported RM not supported By J2EE product
32
Deployment Descriptor Example
33
Security Descriptors Examples
34
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 !

35
J2EE Road Map A Community Process "

• J2EE v1.3 Specification Request
• Submitted February 1, 2000
• Public Draft
• First Release June 2000
• Proposed Final Draft
• Released October 2000
• FCS Q3 of CY2001
• Participation by
• http//java.sun.com/j2ee/

Community
36
Thank You