J2EE

16
J2EE Kenneth M. Anderson CSCI 7818 - Web Technologies October 3, 2001

description

 

Transcript of J2EE

Page 1: J2EE

J2EE

Kenneth M. Anderson

CSCI 7818 - Web Technologies

October 3, 2001

Page 2: J2EE

Credit where Credit is Due

• Most (if not all) of the information in this presentation comes from– Enterprise JavaBeans– by Richard Monson-Haefel– O’Reilly & Associates, Inc.– © 1999 and 2000

Page 3: J2EE

J2EE

• Stands for “Java 2, Enterprise Edition”• It is a collection of standards

– JDBC, JNDI, JMX, JMS

• It is a component technology– Enterprise JavaBeans

• It is an “application server”– Following in the footsteps of Component

Transaction Monitors

Page 4: J2EE

History

• Distributed Objects– CORBA, DCOM, etc.– Three-tier scenario: presentation, business logic, and backend

databases• Hard to “get right” without the proper infrastructure

• Server-Side Components– Focuses on encapsulating “business rules” into objects in the

middle tier

• Component Transaction Monitors– Descendant of CORBA’s Object Request Broker

• provides discovery, persistence, event notification, transactions, etc. for three-tier or n-tier applications

Page 5: J2EE

Enterprise JavaBeans, Defined

• From Sun:– The Enterprise JavaBeans architecture is a component

architecture for the development and deployment of component-based distributed business applications. Applications written using the Enterprise JavaBeans architecture are scalable, transactional, and multi-user secure. These applications may be written once, and then deployed on any server platform that supports the Enterprise JavaBeans specification

Page 6: J2EE

Enterprise JavaBeans(shorter definition)

• From O’Reilly’s Enterprise JavaBeans book– Enterprise JavaBeans is a standard server-side

component model for component transaction monitors

• Aha! It’s a standard for building server-side components and deploying them in component transaction monitors

Page 7: J2EE

Distributed Objects Scenario

Client StubSkeleton

Server-SideComponent

Client-Side Network Middle Tier

invokes

returnresults

connect toremoteobject invoke

returnresults

returnresults

Stub and Skeleton are auto-generated; client “thinks” its making a localcall, most networking details are hidden from client; the main detailis obtaining a reference to the remote object naming service

Page 8: J2EE

Architectural Overview

• Two Types of Enterprise JavaBeans– Entity Beans

• Used to model business concepts such as customer, cruise ship, inventory item, etc.

– Session Beans• A server-side “representative” of the client; session

beans are responsible for managing processes or tasks; for instance in an airline reservation scenario, the session bean would be responsible for reserving a seat on a particular flight and verifying payment

Page 9: J2EE

Insight into Session Beans

EJB Server

Client UsingSession Beans

Client Usingonly Entity Beans

Page 10: J2EE

To Implement an Enterprise Bean

• Any enterprise bean must define two interfaces and one or two classes– Remote interface

• defines a bean’s external interface• must extend javax.ejb.EJBObject (which in turn extends

java.rmi.Remote)

– Home interface• The home interface defines a bean’s “life cycle” methods, eg.

create bean, remove bean, find bean, etc.• must extend javax.ejb.EJBHome which also extends

java.rmi.Remote

Page 11: J2EE

To Implement, continued…

• Bean Class– The java class that actually implements the bean’s external

interface, e.g. the bean class provides implementations for the bean’s “business methods”

– An entity bean must implement the javax.ejb.EntityBean interface, while a session bean must implement the (you guessed it) javax.ejb.SessionBean. Both of these interfaces extend javax.ejb.EnterpriseBean

• Primary Key– The primary key is a very simple class that provides a pointer into

a database; Only entity beans need a primary key. This class must implment java.io.Serializable (so the entity bean can automatically be sent to persistent storage)

Page 12: J2EE

Additional Info

• Clients never interact directly with a bean class, they use stubs (which connect to skeletons, which connect to “containers” which call the bean class…whew!)

• Why? This allows the application server to replicate bean instances (for performance reasons), manage transactions, etc.

• A bean also interacts with its server via a container interface: the container calls the bean’s life cycle methods, manages the bean’s persistence, etc.

Page 13: J2EE

Architecture DiagramClient

HomeInterface

HomeStub

RemoteInterface

EJBStub

EJB Server

EJB Container

Home Interface

EJBHome

Remote Interface

EJB Object

Bean Class

Page 14: J2EE

Benefits of an Application Server

• Resource Management– Instance Pooling and Swapping

• Server can invoke multiple instances of a bean to handle multiple incoming requests (pooling)

• An instance of a bean class can handle requests from multiple skeletons (swapping)

– Activation• if a bean is “stateful,” application servers automate

the process of saving and restoring bean state when a bean is deactived and later activated

Page 15: J2EE

Benefits of an Application Server

• Primary Services– Concurrency

• Beans are automatically thread safe; application servers handle concurrent access to a bean; They also handle reentrance

– Transactions• Bean operations can belong to a transaction and the application

server handles “rolling back” an application’s state if a partially completed transaction fails

– Persistence• Application servers can map beans into database entries (and back

again)

– Naming (bean discovery) and Security (encrypted communication and access control)

Page 16: J2EE

References

• Enterprise JavaBeans– by O’Reilly– ISBN: 1-56592-869-5

• Sun’s J2EE website– <http://java.sun.com/j2ee/>