Slides

Introduction to Enterprise Computing and J2EE

1

CMP 436


Fall 06Department of Mathematics and Computer ScienceLehman College, CUNY


2

Introduction to Enterprise Computing


3

Enterprise Computing Environments

The term enterprise stands for the entire business activity of an organization. perhaps distributed over a number of sites and structured as a

number of units, with varying amounts of dependence between the units.

Large organizations in general have specific goals for their enterprise information systems, including: Time-to-market Portability Diverse Environments Interoperability, Assembly, and Integration Lower cost

Three key evolutions of the enterprise IS architecture Single-tier: traditional mainframe architecture. Two –tier: client-server model. Three-tier or N-tier: distribute software components over a set of

machines all of which comprise a part of the application.


4

Single Tier Architecture Dumb terminals are directly connected to a mainframe Centralized model (as opposed to the distributed model)

Presentation, business logic, and data access are intertwined in one monolithic mainframe application

Pros: No client side management is required Data consistency is easy to achieve

Cons: Functionality (presentation, data model, business logic) intertwined,

difficult for updates, maintenance, and code reuse


5

Two-Tier Architecture

Fat clients talking to back-end database SQL queries sent, raw data returned Presentation, business logic and data model

processing logic are in the client application. Pros:

DB product independence (compared to single-tier model)

Execution efficiency Cons:

Presentation, data model, business logic are intertwined (at client side), difficult for updates and maintenance.

Data Model is “tightly coupled” to every client: If DB Schema changes, all clients break.

Updates have to be deployed to all clients making System maintenance nightmare.

DB connection for every client, thus difficult to scale

Raw data transferred to client for processing causes high network traffic


6

Three-Tier Architecture (Socket, RPC-based)

Thinner client: business & data model separated from presentation Business logic and data access logic reside in middle tier server

while client handles presentation. Middle tier server is now required to handle system services

Concurrency control, threading, transaction, security, persistence, multiplexing, performance, etc.

Pros: Business logic can change more flexibly than 2-tier model.

Most business logic components reside in the middle-tier server.

Cons: Complexity is introduced in the middle-tier server. Client and middle-tier server is more tightly coupled (than the

three-tier object based model). Difficult to reuse code (compared to object model based)


7

Three-Tier Architecture (Remote Object based)

Business logic and data model are objects Business logic and data model are now described in abstraction

(interface language). Object models used: CORBA, RMI, DCOM

Interface language in CORBA is IDL Interface language in RMI is Java interface See WebService part1 lecture note about CORBA, RMI, DCOM

Pros: More loosely coupled than RPC model Code could be more reusable

Cons: Complexity in the middle-tier still need to be addressed.


8

Three-Tier Architecture (Web Server based)

Browser handles presentation logic Browser talks to Web server via HTTP protocol Business logic and data model are handled by web compoenets (CGI,

Servlet/JSP, ASP). Web components generate dynamic contents.

Pro: Ubiquitous and almost universal client types

Zero client management Support various client devices

(E.g., J2ME-enabled cell-phones)

Cons: Complexity in the middle-tier still need to be addressed.


9

Business Components In the Middle Tier Business components that perform enterprise-wide business are residing

and operating in the middle tier. Managing business components in the middle-tier need services for

handling Lots of requests => lifecycle management Access information services => persistence, transaction management Many and varied operations => security management Potential remote access => distributed objects

Three evolutionary streams are merged in the enterprise computing environment.

Server-side business application environments Mainframes, databases, TP monitors

Design and development paradigms OOP, UML, OO languages, component principles

Distributed application elements RPC, remote objects (RMI, CORBA)

Need to have middle tier that can manage enterprise-wide distributed business components with quality services outlined above.


10

Services Required by the Middle-tier Server (in Java Environments)

Lifecycle services For flexible, extensible, scalable component management Container manages instances, based on deployment and

component callbacks Transaction services

Based on the Java Transaction API (JTA) which is based on and supports the X/Open XA model

The X/Open XA interface is a specification that describes the protocol for transaction coordination, commitment, and recovery between a transaction manager and one or more resource managers.

Persistence services Needs to handle the data persistence. Ideally business components

developers do not need to handle the database access logic. Instead, it will be dealt with by the middle-tier server.

Security services J2EE Declarative and programmatic security

Distributed access services: RMI or CORBA IIOP


11

Enterprise JavaBeans (EJBs) EJBs are server components designed to encapsulate business logic, and

to keep developers from having to provide system-level services. The EJB Specification defines an architecture for managing transactional,

distributed business objects in an n-tier architecture. Provides a set of contracts between the server container and the

component developer. Server vendors focus on system-level services. Developers focus on business logic.

EJBs are J2EE components. Deployment model, general application assembly model applies Basic elements are Java stuff

EJBs are managed components. A collection of related objects that operate in an environment with well-

specified services and contracts JavaBean + [remote object (local, remote)] + runtime services Services are accessed through the container. Contracts exist between the component, its container, and its clients.

Contracts maintain the integrity of the services. EJBs are business components.


12

Evolving EJB StandardsEJB 1.0

Session beans only, entity beans optionalNo deployment descriptor format defined

EJB 1.1 Session and entity beans required XML-based deployment descriptors Contracts tightened up, a few API changes

EJB 2.0 New message-driven beans New container-managed persistence scheme (EJB-QL)Local client interfaces

EJB 2.1Support for exposing EJBs as SOAP web servicesTimer services added to container for time-based business logic (e.g.,

run a query in five minute, etc).


13

Why EJB 3.0? Engineering principle "Everything should be made as simple as

possible." The same can be said for enterprise software development.

EJB 2.1 Framework is overly too complex EJB 3.0 is the next revision of the Enterprise Java Beans

specification. One of the most significant changes in EJB 3.0 is the introduction of a standard Object/Relational mapping (ORM) specification and the move to POJO (Plain Old Java Object) based persistence.

The EJB 3.0 framework is a standard framework defined by the Java Community Process (JCP) and supported by all major J2EE vendors. EJB 3.0 makes heavy use of Java annotations (java.lang.annotation) Enables declarative programming to greater extent Imperative (how) vs. declarative (what)


14

JDO versus Hibernate (EJB 3.0) Two competing ORM technologies (for data persistence)

JDO vs Hibernate What was wrong with JDO (Java Data Objects based on XML-

based metadata)? Still open debates JDO is not a very appropriate model for ORM The JDO specification is just absurdly over-complex There are some problems right at the heart of the JDO

specification that are simply not easy to fix (still same in JDO2.0) EJB 3 expert group's decision to develop their own POJO

persistence solution (based on Hibernate http://www.hibernate.org/) rather than adopting JDO.

Hibernate is a powerful and high performance object/relational persistence mapping and query service for Java.

Hibernate supports the EJB 3.0/JSR-220 persistence standardization effort.


15

EJB 3.0 Features EJB 3.0 (forthcoming)

The EJB 3.0 Specification defines a variety of annotation types such as those that specify a bean's type (@Stateless, @Stateful, @MessageDriven, @Entity)

A bean is remotely or locally accessible (@Remote, @Local), transaction attributes (@TransactionAttribute), and security and method permissions (@MethodPermissions, @Unchecked, @SecurityRoles).

There are many more annotations defined in the specification than these. Annotations for the EJB 3.0 annotation types generate interfaces required

by the class as well as references to objects in the environment. Based on so called POJO (Plain Old Java Objects) and POJI (Plain Old Java

Interfaces). JNDI is no longer required to get references to resources and other objects

in an enterprise bean's context (it can still be used if desired). A developer can use resource and environment reference annotations in

the bean class. Open source and commercial implementations of pre-release EJB 3.0 specifications

are in part available from JBoss and Oracle. JBOSS 4.0.3 or higher to conduct limited experiment with EJB 3.0.


16

Spring vs. EJB 3.0 http://www.springframework.org/ The Spring framework is a popular but non-standard open source

framework. It is primarily developed by and controlled by Interface21 Inc. The architecture of the Spring framework is based upon the Dependency

Injection (DI) design pattern. A class may have dependencies on other classes to perform useful tasks.

The class can create its own dependencies, or the dependencies can be injected into the class instance. Removing the responsibility for creating dependencies from a class is called Dependency Injection (or Inversion of Control.)

The dependencies can be attached by either setting properties or using a constructor function to setup all dependencies at instantiation.

Spring can work standalone or with existing application servers and makes heavy use of XML configuration files.

The EJB 3.0 framework is a standard framework defined by the Java Community Process (JCP) and supported by all major J2EE vendors.

EJB 3.0 makes heavy use of Java annotations (java.lang.annotation) Enables declarative programming to greater extent Imperative (how) vs. declarative (what)


17

J2EE Brief Overview

To understand where the EJB technology stands


18

J2EE Summary The Java 2 Enterprise

Edition (J2EE) is a Java-based, service-oriented framework.

The goal is to allow developers to focus on solving business problems, rather than on developing system services. This provides for separation of business logic from system services.

J2EE technologies are organized by the services that they provide.

Service J2EE Technolgies

Web Servlets, JSPs, JSFs

Database JDBC

Naming/Directory JNDI

Messaging JMS

Email JavaMail, JAF

Distributed Components

EJB

Transactions JTA, JTS

Connections JCA

Web Services JAX-RPC, SAAJ, JAXR

XML Processing JAXP, JAXB

Management, monitoring, pluggin

Java Management Extension (JMX MBeans) J2EE1.5

Security JAAS


19

Message Oriented Middleware (MoM)

Transfers messages between applications Does not consider the content of messages

Asynchronous communication Direct or queued

Queued (buffered) communication can support wireless clients. Examples

Sun Microsystems JMSystem Microsoft: MSMQ IBM: Websphere MQ

Traditional MoM systems are message queue based (one-to-one). Event based systems and publish/subscribe are one-to-many.

One object monitors another object. Reacts to changes in the object Multiple objects can be notified about changes.


20

MoM (cont’d) Event-based systems address problems with synchronous

operation and polling (remember MoM is inherently asynchronous infrastructure). For this, a logically centralized services mediates events.

Enables anonymous communication

Push versus Pull May be implemented using RPC, unicast, multicast, broadcast

Three main components Observer, Notifier, Event channel (borrowed from CORBA

Event/Notification Service) Filtering can improve scalability / accuracy for content-based

routing. (good research problems in Modern Information Storage and

Retrieval)


21

JMS 1.1 API Asynchronous

messaging support for Java

Point-to-point messaging One-to-one

Topic-based publish/subscribe

SQL for filtering messages at the topic event queue

One-to-many Message types

Map, Object, Stream, Text, and Bytes

Durable subscribers Event stored at server

if not deliverable Transactions with

rollback See javax.jmx

Common Point-to-Point

Publish/

Subscribe

ConnectionFactory

QueueConnectionFactory

TopicConnectionFactory

Connection QueueConnection

TopicConnection

Destination Queue Topic

Session QueueSession

TopicSession

MessageProducer

QueueSender

TopicPublisher

MessageConsumer

QueueReceiver

TopicSubscriber


22

JMS Messaging


23

JCA (Connectors) 1.5 API The J2EE Connector architecture provides

a Java solution to the problem of connectivity between various application servers and EISs (legacy EISs) already in existence.

EIS vendors no longer need to customize their product for each application server. Application server vendors who conform to the J2EE Connector architecture

do not need to add custom code whenever they want to add connectivity to a new EIS.

APIs provide (see javax.resource) Connection Management

Transaction Management

Security

Resource Lifecycle Management

Work Management (using container-managed threads) Asynchronous communication


24

JMX Java Management Extensions (JMX) technology provides

the tools for building distributed, Web-based, modular and dynamic solutions for managing and monitoring devices, applications, and service-driven networks

By design, this standard is suitable for adapting legacy systems, implementing new management and monitoring solutions, and plugging into those of the future.

JMX architecture consists of three component layers Instrumentation layer: contains MBeans (Managed Beans) and

their manageable resources Agent layer: Contains JMX agents used to expose the MBeans Distributed layer: contains components that enable management

applications to communicate with JMX agents. See more at

http://java.sun.com/products/JavaManagement/ http://jakarta.apache.org/tomcat/tomcat-5.0-doc/mbeans-descript

or-howto.html http://www.jboss.com/?module=bb&op=viewforum&f=63


25

J2EE Key Elements (for Defining J2EE)

J2EE consists of four key elements: Specification Reference implementation Compatibility Test Suite (CTS) Blueprints & patterns

The J2EE specification Outlines what services must be provided by a vendor that

wants to advertise being J2EE compliant. These specifications typically outline minimum

requirements. The specification often defines the API to be provided to

developers.


26

J2EE Key Elements (cont’d) The J2EE SDK provides a Reference Implementation (RI) of J2EE

specification. It is a fully-functional J2EE server that provides all of the J2EE

services described in the various specifications. It’s used to demonstrate the feasibility of creating a J2EE server

that conforms to the specifications. The J2EE 1.4 SDK is also known as Sun Java System Application

Server Platform. It is a fully J2EE 1.4 platform-compatible server for the development and deployment of production-grade J2EE applications.

The Compatibility Test Suite (CTS) Used to evaluate a given vendor product to ensure that it meets

the requirements described within the J2EE specifications. Any vendor that wishes to market its product as being J2EE

compliant must submit it for evaluation against the CTS.


27

J2EE Key Elements (cont’d)

The J2EE Blueprints are an effort by the Sun Java Development Center to document best practices involving the user of the different J2EE technologies. These blueprints are similar to design patterns. Represent design principles as opposed to pre-fabricated

solutions to common problems J2EE patterns have been documented by many

professionals working with both Sun as well as in industry. See http://java.sun.com/blueprints/corej2eepatterns/Patterns/


28

Slides

Technology

business data model

middle tier server

middletier server

business logic components

presentation business

objects business logic

middletier need services

data model processing