CMP 436

1
CMP 436

• Introduction to
• Enterprise Computing and J2EE
• Fall 06
• Department of Mathematics
• and Computer Science
• Lehman 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 gt lifecycle management
• Access information services gt persistence,
  transaction management
• Many and varied operations gt security management
• Potential remote access gt 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 Standards

• EJB 1.0
• Session beans only, entity beans optional
• No 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.1
• Support for exposing EJBs as SOAP web services
• Timer 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 (_at_Stateless, _at_Stateful,
  _at_MessageDriven, _at_Entity)
• A bean is remotely or locally accessible
  (_at_Remote, _at_Local), transaction attributes
  (_at_TransactionAttribute), and security and method
  permissions (_at_MethodPermissions, _at_Unchecked,
  _at_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.

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 (contd)

• 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

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/mb
  eans-descriptor-howto.html
• http//www.jboss.com/?modulebbopviewforumf63

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 (contd)

• 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.
• Its 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 (contd)

• 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/Pa
  tterns/

28
(No Transcript)