Demystifying J2EE

© 2006 Wellesley Information Services. All rights reserved.

Demystifying J2EE

John KiddKidd & Associates

2

What We’ll Cover …

• History and Goal of J2EE• Brief Architecture Overview• J2EE Containers• J2EE Component Technologies• J2EE Services• Servlets and JSPs• Enterprise Java Beans• Application Infrastructures• Alternative Technologies

3

Goal of J2EE Is to Specify a Platform

• It is a specification!• There are two basic focuses of the spec

Component model – the business code that you writeCore infrastructure – provides communication protocols, and the transaction and security capabilities

Don't Forget

4

History of J2EE

• In the beginning …Java May 1995Servlets May 1996EJB April 1997Jini January 1999

• Making it all work together … managing the release levelsJ2EE – June 1999

5

Addressing Difficulties of Large Applications

• The need to support:TransactionsResource-poolingSecurityThreadingPersistenceLifecycle management and more

• System programming at the expense of business logic• Developers have to become specialists• Proprietary APIs that result in non-portable code

ClientIssue

6

Addressing Difficulties of Large Applications (cont.)

• Need for special solutions to manage complexity Proprietary frameworks and middleware (re-inventingthe wheel)Need for standard APIs for enterprise computingMulti-tiered architecture in enterprise applications

7

“Enterprise” in J2EE

• So what is Enterprise?“Programming in the large” and “enterprise computing” differ from small-scale and academic computingLots of users, and the application has an “extended life”Deployed in heterogeneous computing environmentsNeeds to have versioning mechanismDeveloped by a team of developers over a long timeMaintainability, flexibility, reusability are major issues

8

What J2EE Means

• J2EE Platform A standard platform for hosting J2EE applications, specified as a set of required APIs, specifications, and policies

• J2EE Compatibility Test SuiteA suite of compatibility tests for verifying that a J2EE platform product is compatible with the J2EE platform standard

9

What J2EE Means (cont.)

• J2EE Reference ImplementationA reference implementation for demonstrating the capabilities of J2EE and for providing an operational definition of theJ2EE platform

• J2EE Application Programming ModelA standard programming model for developing multi-tier,thin-client applications

10

J2EE Application Model

• Defined by the specSpec driven

• J2EE Application Model is divided into three partsComponentsContainersServices

11

J2EE Platform

12



13

A Note About Architecture

• Get to know this acronym and what it means: MVC• Model – View – Controller• The idea is:

That we do not build hard interdependencies that are difficult to changeTo provide a development architecture that supports large as well as small teams

14

Introduction to MVC

• MVC for J2EE – really Model 2 JSP pattern from Sun• Common architectural pattern for building applications• Code for generating results is located in the View and

the ModelModel and View have no explicit knowledge of one anotherDecoupled by the ControllerReduces the impact of changes in one piece of code affecting anotherPerfect example is a View to generate output for different devices

15

The MVC Flow

1. User requests are handled bythe Controller

The Controller examines therequest to determine the businesslogic to execute

2. Business logic is locatedin the Model

Business logic executes andthen control is returned tothe Controller

3. Controller then looks up howthe data is to be displayed

User

Model

View

Controller

16

The MVC Flow (cont.)

4. The code that is responsible for displaying the results ofthe interaction is called the View

There is no business logic,only presentation logicOnce View processing iscompleted, control isreturned to the Controllerwhich returns to the userthe resulting page

User

Model

View

Controller

17

So, Why MVC?

• FlexibilityMore straightforward to add different Views to your applicationEasier to modify the data store of the Model due to the separation

• MaintainabilityApplication tiers are clearly defined with specific boundariesThe result is an application that is more straightforward to maintain, understand, and test

18

MVC Tiers

• ModelBusiness componentsProblem domain

• ViewDisplayUI

• ControllerProcess componentsServlets and Session EJBs

19

MVC Summary

• Tying together our component discussion and MVC:EJBs = Model (and sometimes some Controller)Servlets = Controllers (and some View)JSPs = View only!

Don't Forget

20

What We’ll Cover…


21

Containers

• What the heck is a container?All J2EE components depend on the runtime support of a system-level entity called a containerEssentially it is the operational environment that a component executes within

22

J2EE Containers

• Client• Applet• Web• EJB

23

Why the Need for the Container?

• Layer between client and component• Conceal complexity• Provide common system-level services like:

Transaction managementSecurityResource poolingDeploymentComponent lifecycle management

• Container defined by the specImplementation is distinct to the vendor — and they all doit differently!

24

Container

Container Example

Component

• Client Calls method in Component

• Call Intercepted by container

• Container makes call on behalf of client (Proxy)

• Client Calls method in Component

• Call Intercepted by container

• Container makes call on behalf of client (Proxy)

Client

25

J2EE Components and Containers

• Required logical relationships of architectural elements of the J2EE platform

Does not imply physical partitioning of theelements (machines, processes, or VMs, etc.)Note

26

J2EE Components and Containers (cont.)

27



28

J2EE Components

• A component is an application-level software unit• Components are the key focus of application developers

Don't Forget

29

J2EE Components (cont.)

• The layers of functionality in a J2EE application are encapsulated in components:

Business logic is encapsulated (for the most part) in EJBsClient interaction is presented through:

HTMLAppletsServlets/JSPsStand-alone Java Applications

• CommunicationThese components communicate via standardized protocols

30

J2EE Component Technologies

• Components are units of Java code that are deployed into a container

• In the J2EE spec there are basically three:Enterprise Java BeansJava ServletsJava Server Pages

• And one to come … Portlets

31

Java Servlets

• Java Components that run on a server Note: Not necessarily a Web server

• Have a request/response paradigm• Servlets can be chained• Servlets can interact with other Servlets on other servers

32

Java Servlets (cont.)

• Main purpose in life:Read any data sent from a clientCarry out a desired task by calling a DB or EJBFormat results as an HTML document (this is usually relegated to a JSP)Send document back to the client

33

Java Server Pages

• Allow you to generate dynamically generated content with static information

• JSPs are compiled into Servlets before being executed• Good component to separate presentation from logic

Leave the Web page design to the graphic artist/HTML expertProvides ability to insert dynamic content components(Java Beans) Can also use XML for page building and creation

• Provide tag extension via TagLibrariesCustom software you can create to extend the existing tags

34

Enterprise Java Beans (EJB)

• Server-side Components that encapsulate:Business logic (Session Beans)Data (Entity Beans)

• Reduce the complexity of building enterprise applications by:

Providing support for common middleware servicesTransactionsSecurityPersistenceDatabase connectivity

35

What We’ll Cover…


36

J2EE Service Technologies

• In order to facilitate the interaction between the different components and provide capabilities that are redundant (e.g., ones that you and I do not have to code for every component) the J2EE spec contains several services:

JNDI – Java Naming and Directory InterfaceJDBC – Java Database ConnectivityCORBA – Common Object Request Broker ArchitectureJTA – Java Transaction APIJTS – Java Transaction ServiceJMS – Java Message Service

37

Java Naming and Directory Interface (JNDI)

• Common Java API for accessing naming and directory services uniformly

• Does NOT specify a particular naming or directory service implementation

Different providers can be plugged in “underneath” the APIProviders exist for LDAP, NDS, DNS, etc.

38

JDBC

• Java API for accessing SQL databasesDBMS independent

• JDBC allows Java programs to:Establish a connectionSend SQL statementsProcess results

39

J2EE Communication Technologies

• Internet protocols – TCP/IP, HTTP 1.0, SSL 3.0 • Remote Method Invocation (RMI) protocols • Object Management Group protocols – JavaIDL

and RMI-IIOP• Messaging technologies – JMS, JavaMail• Data formats – HTML 3.2, Image Files, JAR, class

files, XML

40

CORBA

• Distributed object architecture (OMG)• Independent of programming language and platform• Java supports two types:

Java IDLRMI over IIOP

• Java IDL allows for interaction with any CORBA compliant system

• RMI over IIOP combines the programming ease of the Java Remote Method Invocation (RMI) API with CORBA’s Internet Inter-ORB Protocol (IIOP)

41

J2EE Transaction Services

• The J2EE platform handles many transaction detailsLike propagating and coordinating among multipletransaction managers

• Transactions can be propagated from a Web component to an Enterprise Bean

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

42

Declarative Transaction Management

• Container intercepts client calls and takes care of transaction management

• 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

43

JTA

• Java Transaction API is the application interface to transaction monitors

44

JTS

• Allows:Multiple invocations on multiple distributed objects to be treated as one unit of work

• Supports:Industry-standard two phase commit protocols

• Specifies:The relationship between a transaction manager and its participating resourcesThe responsibilities of these components throughout the critical completion phases of the transaction

• Applies:Transactional semantics to the distributed object world

45

J2EE Security Features

• Declarative security (authentication and authorization)• Security features declared at deployment

Not embedded in codeFlexible – just change and redeploy

• Role-based Access ControlUsers – groups mapped to roles

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

Fine grain – constraints specified on resources• Supports message integrity measures

46

J2EE Security Features (cont.)

47

JMS

• API for accessing Message-Oriented Middleware(MOM) systems

• Supports two messaging models:Point to pointPublish and subscribe

• JMS allows decoupled applications components to communicate asynchronously

48

JavaMail

• API for sending email in Java• Supports applications, such as e-commerce Web sites

Tip

49

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)

50

J2EE Deployment Services (cont.)

• A J2EE module consists of one or more J2EE components and one deployment descriptor of that component type

51

J2EE Platform Roles

• J2EE product provider • Application component provider • Application assembler • Application deployer• System administrator • Tool provider

52

Application Server

• Provides:All servicesAll containersExtensions to vendor-specific technologies

53



54

Servlets

• Java components that extend HTTP serverGeneration 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

55

Basic Servlet Demo

Demo

Basic Servlet

56

JSPs

• Text-based documents contain HTML, JSP tags, and Java code

• “Inside-Out” Servlets – declarative, presentation-oriented way of writing Servlets

• Utilize componentsJava BeansTag libraries

57

JSPs (cont.)

• Benefits:Easier to author (separate presentation from code)Easier for tools (J2EE standard)Designer-serviceable part

• Exploits:Server-side scriptingTemplatesEncapsulation of functionality

Solution

58

Basic JSP Demo

Demo

Basic JSP

59

Servlets or JSPs?

• Use JSPs for:Response generation

• Use Servlets for:Controller (FrontController design pattern)Service, or for generating binary content

60

Examples

• Displaying shopping cartJSP technology

• Generating images or chartsServlets

• Request processingBoth JSP and Servlet technologies are suitable

61



62

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

63

EJB Architecture

• The entire EJB world consists of the following:EJB containers that run on EJB serverEJB serverEJBs that run in these containersEJB clients and other auxiliary systems like the Java Naming and Directory Interface (JNDI ) and the Java Transaction Service (JTS)

64

Three Types of EJBs

• Session BeansMeant for client sessions and business logic

StatefulStateless

• Entity BeansProvide an abstract View of an entity (data model)

Bean manage persistenceContainer managed persistence

• Message Driven BeansActs as a message listener client to JMS queues or topics

65

Component Pieces of EJB Demo

Demo

Component Pieces of EJB

66

Client’s View of EJB

67

Client Code for EJB’s Demo

Demo

Client Code for EJBs

68

Message Driven Beans and JMS

• Provide loose coupling among heterogeneous systemsInteroperate with legacy systems that use messagingfor integrationInteroperate with B2B systems not based on the J2EETM platform

• Provide asynchronous communication

69

Message Driven Beans and JMS (cont.)

• Provide support for disconnected use ofEnterprise Beans

• New Enterprise Bean type — asynchronousActivated upon message arrivalStatelessNo home or remote interfaceBean implements javax.jms.MessageListener interfaceonMessage method contains business logicConfigured as listener for queue (point-to-point)/topic (publish-subscribe)

70

Message Driven Beans and JMS (cont.)

• JMS APIs for sending messages available to all Enterprise Beans

Use in point-to-point configurationsReliable queuingUse within pub/sub configurationsBeans publishing events

71

MDB EJB Demo

Demo

MDB EJB

72

Deployment

• DeploymentManaged by a descriptor

• The actual deployment process:Unique to each individual application server vendor

• If you do not use vendor-specific code:Your application can be deployed to ANY certified platform

73

The Certification Process

• The Reference Implementation (RI)Available for applications and app servers

• Compatibility Test Suite• 5824 Tests

SignatureAPIEnd-to-end

Client->EJB->DBMSIntegration

Client<->servlet | jsp<->EJB<->DBMS

74



75

Application Infrastructures

• J2EE provides a robust container ModelThe infrastructure that J2EE offers is at the system levelIt is a large leap from the J2EE containers to a business application

• There have to be some infrastructure component pieces that sit between the J2EE container Model and the business application

• Often termed a framework

76

Application Infrastructures (cont.)

• So how can I put all this together to provide an infrastructure on which I can build applications?

• There is a little secret about J2EE … there is no application infrastructure …

• So I build or utilize an existing framework

J2EE Specification

Your Business ApplicationCommon “Plumbing” Code that you

have to provide!

77

The Two Different “View” Framework Types

• Request-basedHang on the Web concepts of request/responseVery typical infrastructure

• Component-basedMore like developing thick client applicationsEvent-Model based

• Frameworks are focused mainly in the Controller part of your architecture

The “C” in MVC

78

Action/Request-Based

• FrameworksStrutsSpring MVCWebwork

Struts TIShale

79

Struts

• Pros:The “Standard” – lots of struts jobsLots of information and examplesHTML tag library is one of the bestIDE supportAJAX support exists

• Cons:ActionForms – they’re a painCan’t unit test – StrutsTestCase only does integrationProject has been rumored as “dead”

80

Spring MVC

• Pros:Lifecycle for overriding binding, validation, etc.Integrates with many View options seamlessly

JSP/JSTL, Tiles, Velocity, FreeMarker, Excel, XSL, PDFInversion of control makes it easy to testIDE support

• Cons:Configuration intensive — lots of XMLRequires writing lots of code in JSPsAlmost too flexible — no common parent Controller

81

WebWork

• Pros:Simple architecture – easy to extendTag library is easy to customize – backed by VelocityInterceptors are pretty slick

• Cons:Small communityDocumentation only recently written, so there arefew examplesClient-side validation immature

82

Basic Struts Demo

Demo

Basic Struts Application

83

Component-Based Frameworks – Pros

• Tapestry• Pros:

Very productive once you learn itTemplates are HTML –great for designersHealthy and smart user community

• JSF (Java Server Faces)• Pros:

J2EE Standard – lots of demand and jobsFast and easy todevelop withRich navigation frameworkIDE supportAJAX support exists

84

Component-Based Frameworks – Cons

• Tapestry• Cons:

Documentation very conceptual, rather than pragmaticSteep learning curve –very few examplesLong release cycles –major upgrades every year

Which may mean that it is so stable that none are needed

• JSF (Java Server Faces)• Cons:

Tag soup for JSPs (but this is relieved with Facelets)No single source for implementation

85

Basic JSF Demo

Demo

Basic JSF Application

86



87

The Mid-Tier (“Business Layer”)

• EJB?Typically, stateless Session Beans are used to componentize your business logicSolid runtime, transactional environment to run in

• But you have another very powerful option as well

88

Spring

• Dependency injection• Inversion of control• Oh my?

Fancy words, but a simple concept• OO Solutions involve many classes that are dependent

on one another• In the scenario when Class A uses Class B, how does A

get a reference to B?• Spring solves this problem … (and more)

Class AClass A Class BClass B

89

Basic Spring Demo

Demo

Basic Spring Application

90

Getting to Data

• You can write the SQL – you saw thatThat does not really fit the OO paradigm

• We need something to map SQL tables To fit the OO program

91

ORM

• Another Three Letter Acronym (TLA )• Object Relational Mapping (ORM)

Basically the process of mapping SQL-based data to Java ObjectsYou write no SQL

92

Benefits of ORM

• Abstract you from your data• Remove SQL from business code• Have a very well-defined “data tier” in your applications• There are many options for ORM – the top three:

EJBHibernateiBatis

93

Popular ORM Frameworks

• HibernateVery popular ORMExtremely powerfulHigh level of abstraction from your data

• iBatisIn comparison to hibernate, it is a little more low levelYou will actually write SQL, but it will not be stored in your codeWorks better with Stored Procedures than hibernate does (especially whenit comes to “out”parameters)

94

Basic Hibernate Demo

Demo

A Basic Hibernate Application

95

Resources

• Agilewww.agilemanifesto.org

• Testing/JUnitwww.junit.org

• Java @ Sunhttp://java.sun.com

• The ServerSidewww.theserverside.com

• JBosswww.jboss.org

• Apachewww.apache.org

96

7 Key Points to Take Home

• J2EE is just a spec – not owned by any one vendor• Learn the spec, not product!• EJBs are interesting, but not the current future• Spring/Hibernate and other frameworks are offering the

same and greater capabilities as traditional J2EE• If you are new to all of this, focus on Java and OO first• Learn in this order: Java->Servlets->JSP (EJB is

negotiable)• There is a lot of opportunity for Domino apps and J2EE

apps to mix and mingle!

97

Your Turn!

Questions?

How to Contact Me:John Kidd

[email protected]