Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. CMP 436 <ul><li>Introduction to </li></ul><ul><li>Enterprise Computing and J2EE </li></ul><ul><li>Fall 06 </li></ul><ul><li>Department of Mathematics </li></ul><ul><li>and Computer Science </li></ul><ul><li>Lehman College, CUNY </li></ul>
  2. 2. Introduction to Enterprise Computing
  3. 3. Enterprise Computing Environments <ul><li>The term enterprise stands for the entire business activity of an organization. </li></ul><ul><ul><li>perhaps distributed over a number of sites and structured as a number of units, with varying amounts of dependence between the units. </li></ul></ul><ul><li>Large organizations in general have specific goals for their enterprise information systems, including: </li></ul><ul><ul><li>Time-to-market </li></ul></ul><ul><ul><li>Portability </li></ul></ul><ul><ul><li>Diverse Environments </li></ul></ul><ul><ul><li>Interoperability, Assembly, and Integration </li></ul></ul><ul><ul><li>Lower cost </li></ul></ul><ul><li>Three key evolutions of the enterprise IS architecture </li></ul><ul><ul><li>Single-tier: traditional mainframe architecture. </li></ul></ul><ul><ul><li>Two –tier: client-server model. </li></ul></ul><ul><ul><li>Three-tier or N-tier: distribute software components over a set of machines all of which comprise a part of the application. </li></ul></ul>
  4. 4. Single Tier Architecture <ul><li>Dumb terminals are directly connected to a mainframe </li></ul><ul><li>Centralized model (as opposed to the distributed model) </li></ul><ul><ul><li>Presentation, business logic, and data access are intertwined in one monolithic mainframe application </li></ul></ul><ul><li>Pros: </li></ul><ul><ul><li>No client side management is required </li></ul></ul><ul><ul><li>Data consistency is easy to achieve </li></ul></ul><ul><li>Cons: </li></ul><ul><ul><li>Functionality (presentation, data model, business logic) intertwined, difficult for updates, maintenance, and code reuse </li></ul></ul>
  5. 5. Two-Tier Architecture <ul><li>Fat clients talking to back-end database </li></ul><ul><ul><li>SQL queries sent, raw data returned </li></ul></ul><ul><ul><li>Presentation, business logic and data model processing logic are in the client application. </li></ul></ul><ul><li>Pros: </li></ul><ul><ul><li>DB product independence (compared to single-tier model) </li></ul></ul><ul><ul><li>Execution efficiency </li></ul></ul><ul><li>Cons: </li></ul><ul><ul><li>Presentation, data model, business logic are intertwined (at client side), difficult for updates and maintenance. </li></ul></ul><ul><ul><li>Data Model is “tightly coupled” to every client: If DB Schema changes, all clients break. </li></ul></ul><ul><ul><li>Updates have to be deployed to all clients making System maintenance nightmare. </li></ul></ul><ul><ul><li>DB connection for every client, thus difficult to scale </li></ul></ul><ul><ul><li>Raw data transferred to client for processing causes high network traffic </li></ul></ul>
  6. 6. Three-Tier Architecture (Socket, RPC-based) <ul><li>Thinner client: business & data model separated from presentation </li></ul><ul><ul><li>Business logic and data access logic reside in middle tier server while client handles presentation. </li></ul></ul><ul><li>Middle tier server is now required to handle system services </li></ul><ul><ul><li>Concurrency control, threading, transaction, security, persistence, multiplexing, performance, etc. </li></ul></ul><ul><li>Pros: </li></ul><ul><ul><li>Business logic can change more flexibly than 2-tier model. </li></ul></ul><ul><ul><ul><li>Most business logic components reside in the middle-tier server. </li></ul></ul></ul><ul><li>Cons: </li></ul><ul><ul><li>Complexity is introduced in the middle-tier server. </li></ul></ul><ul><ul><li>Client and middle-tier server is more tightly coupled (than the three-tier object based model ). </li></ul></ul><ul><ul><li>Difficult to reuse code (compared to object model based) </li></ul></ul>
  7. 7. Three-Tier Architecture (Remote Object based) <ul><li>Business logic and data model are objects </li></ul><ul><ul><li>Business logic and data model are now described in abstraction (interface language). </li></ul></ul><ul><li>Object models used: CORBA, RMI, DCOM </li></ul><ul><ul><li>Interface language in CORBA is IDL </li></ul></ul><ul><ul><li>Interface language in RMI is Java interface </li></ul></ul><ul><ul><li>See WebService part1 lecture note about CORBA, RMI, DCOM </li></ul></ul><ul><li>Pros: </li></ul><ul><ul><li>More loosely coupled than RPC model </li></ul></ul><ul><ul><li>Code could be more reusable </li></ul></ul><ul><li>Cons: </li></ul><ul><ul><li>Complexity in the middle-tier still need to be addressed. </li></ul></ul>
  8. 8. Three-Tier Architecture (Web Server based) <ul><li>Browser handles presentation logic </li></ul><ul><ul><li>Browser talks to Web server via HTTP protocol </li></ul></ul><ul><ul><li>Business logic and data model are handled by web compoenets (CGI, Servlet/JSP, ASP). </li></ul></ul><ul><ul><li>Web components generate dynamic contents. </li></ul></ul><ul><li>Pro: </li></ul><ul><ul><li>Ubiquitous and almost universal client types </li></ul></ul><ul><ul><ul><li>Zero client management </li></ul></ul></ul><ul><ul><li>Support various client devices </li></ul></ul><ul><ul><ul><li>(E.g., J2ME-enabled cell-phones) </li></ul></ul></ul><ul><li>Cons: </li></ul><ul><ul><li>Complexity in the middle-tier still need to be addressed. </li></ul></ul>
  9. 9. Business Components In the Middle Tier <ul><li>Business components that perform enterprise-wide business are residing and operating in the middle tier. </li></ul><ul><li>Managing business components in the middle-tier need services for handling </li></ul><ul><ul><li>Lots of requests => lifecycle management </li></ul></ul><ul><ul><li>Access information services => persistence, transaction management </li></ul></ul><ul><ul><li>Many and varied operations => security management </li></ul></ul><ul><ul><li>Potential remote access => distributed objects </li></ul></ul><ul><li>Three evolutionary streams are merged in the enterprise computing environment. </li></ul><ul><ul><li>Server-side business application environments </li></ul></ul><ul><ul><ul><li>Mainframes, databases, TP monitors </li></ul></ul></ul><ul><ul><li>Design and development paradigms </li></ul></ul><ul><ul><ul><li>OOP, UML, OO languages, component principles </li></ul></ul></ul><ul><ul><li>Distributed application elements </li></ul></ul><ul><ul><ul><li>RPC, remote objects (RMI, CORBA) </li></ul></ul></ul><ul><li>Need to have middle tier that can manage enterprise-wide distributed business components with quality services outlined above. </li></ul>
  10. 10. Services Required by the Middle-tier Server (in Java Environments) <ul><li>Lifecycle services </li></ul><ul><ul><li>For flexible, extensible, scalable component management </li></ul></ul><ul><ul><li>Container manages instances, based on deployment and component callbacks </li></ul></ul><ul><li>Transaction services </li></ul><ul><ul><li>Based on the Java Transaction API (JTA) which is based on and supports the X/Open XA model </li></ul></ul><ul><ul><ul><li>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. </li></ul></ul></ul><ul><li>Persistence services </li></ul><ul><ul><li>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. </li></ul></ul><ul><li>Security services </li></ul><ul><ul><li>J2EE Declarative and programmatic security </li></ul></ul><ul><li>Distributed access services: </li></ul><ul><ul><li>RMI or CORBA IIOP </li></ul></ul>
  11. 11. Enterprise JavaBeans (EJBs) <ul><li>EJBs are server components designed to encapsulate business logic, and to keep developers from having to provide system-level services. </li></ul><ul><li>The EJB Specification defines an architecture for managing transactional, distributed business objects in an n-tier architecture. </li></ul><ul><ul><li>Provides a set of contracts between the server container and the component developer. </li></ul></ul><ul><ul><li>Server vendors focus on system-level services. </li></ul></ul><ul><ul><li>Developers focus on business logic. </li></ul></ul><ul><li>EJBs are J2EE components. </li></ul><ul><ul><li>Deployment model, general application assembly model applies </li></ul></ul><ul><ul><li>Basic elements are Java stuff </li></ul></ul><ul><li>EJBs are managed components. </li></ul><ul><ul><li>A collection of related objects that operate in an environment with well-specified services and contracts </li></ul></ul><ul><ul><li>JavaBean + [remote object (local, remote)] + runtime services </li></ul></ul><ul><ul><li>Services are accessed through the container. </li></ul></ul><ul><ul><li>Contracts exist between the component, its container, and its clients. </li></ul></ul><ul><ul><ul><li>Contracts maintain the integrity of the services. </li></ul></ul></ul><ul><li>EJBs are business components. </li></ul>
  12. 12. Evolving EJB Standards <ul><li>EJB 1.0 </li></ul><ul><ul><li>Session beans only, entity beans optional </li></ul></ul><ul><ul><li>No deployment descriptor format defined </li></ul></ul><ul><li>EJB 1.1 </li></ul><ul><ul><li>Session and entity beans required </li></ul></ul><ul><ul><li>XML-based deployment descriptors </li></ul></ul><ul><ul><li>Contracts tightened up, a few API changes </li></ul></ul><ul><li>EJB 2.0 </li></ul><ul><ul><li>New message-driven beans </li></ul></ul><ul><ul><li>New container-managed persistence scheme (EJB-QL) </li></ul></ul><ul><ul><li>Local client interfaces </li></ul></ul><ul><li>EJB 2.1 </li></ul><ul><ul><li>Support for exposing EJBs as SOAP web services </li></ul></ul><ul><ul><li>Timer services added to container for time-based business logic (e.g., run a query in five minute, etc). </li></ul></ul>
  13. 13. Why EJB 3.0? <ul><li>Engineering principle &quot;Everything should be made as simple as possible.&quot; The same can be said for enterprise software development. </li></ul><ul><li>EJB 2.1 Framework is overly too complex </li></ul><ul><li>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. </li></ul><ul><li>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) </li></ul><ul><ul><li>Enables declarative programming to greater extent </li></ul></ul><ul><ul><li>Imperative (how) vs. declarative (what) </li></ul></ul>
  14. 14. JDO versus Hibernate (EJB 3.0) <ul><li>Two competing ORM technologies (for data persistence) </li></ul><ul><ul><li>JDO vs Hibernate </li></ul></ul><ul><li>What was wrong with JDO (Java Data Objects based on XML-based metadata)? Still open debates </li></ul><ul><ul><li>JDO is not a very appropriate model for ORM </li></ul></ul><ul><ul><li>The JDO specification is just absurdly over-complex </li></ul></ul><ul><ul><li>There are some problems right at the heart of the JDO specification that are simply not easy to fix (still same in JDO2.0) </li></ul></ul><ul><li>EJB 3 expert group's decision to develop their own POJO persistence solution (based on Hibernate http:// / ) rather than adopting JDO. </li></ul><ul><li>Hibernate is a powerful and high performance object/relational persistence mapping and query service for Java. </li></ul><ul><li>Hibernate supports the EJB 3.0/JSR-220 persistence standardization effort. </li></ul>
  15. 15. EJB 3.0 Features <ul><li>EJB 3.0 (forthcoming) </li></ul><ul><ul><li>The EJB 3.0 Specification defines a variety of annotation types such as those that specify a bean's type (@Stateless, @Stateful, @MessageDriven, @Entity) </li></ul></ul><ul><ul><li>A bean is remotely or locally accessible (@Remote, @Local), transaction attributes (@TransactionAttribute), and security and method permissions (@MethodPermissions, @Unchecked, @SecurityRoles). </li></ul></ul><ul><ul><li>There are many more annotations defined in the specification than these. </li></ul></ul><ul><ul><li>Annotations for the EJB 3.0 annotation types generate interfaces required by the class as well as references to objects in the environment. </li></ul></ul><ul><ul><li>Based on so called POJO (Plain Old Java Objects) and POJI (Plain Old Java Interfaces). </li></ul></ul><ul><ul><li>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). </li></ul></ul><ul><ul><li>A developer can use resource and environment reference annotations in the bean class. </li></ul></ul><ul><li>Open source and commercial implementations of pre-release EJB 3.0 specifications are in part available from JBoss and Oracle. </li></ul><ul><ul><li>JBOSS 4.0.3 or higher to conduct limited experiment with EJB 3.0. </li></ul></ul>
  16. 16. Spring vs. EJB 3.0 <ul><li>http:// / </li></ul><ul><li>The Spring framework is a popular but non-standard open source framework. It is primarily developed by and controlled by Interface21 Inc. </li></ul><ul><ul><li>The architecture of the Spring framework is based upon the Dependency Injection (DI) design pattern. </li></ul></ul><ul><ul><li>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.) </li></ul></ul><ul><ul><li>The dependencies can be attached by either setting properties or using a constructor function to setup all dependencies at instantiation. </li></ul></ul><ul><ul><li>Spring can work standalone or with existing application servers and makes heavy use of XML configuration files. </li></ul></ul><ul><li>The EJB 3.0 framework is a standard framework defined by the Java Community Process (JCP) and supported by all major J2EE vendors. </li></ul><ul><li>EJB 3.0 makes heavy use of Java annotations (java.lang.annotation) </li></ul><ul><ul><li>Enables declarative programming to greater extent </li></ul></ul><ul><ul><li>Imperative (how) vs. declarative (what) </li></ul></ul>
  17. 17. J2EE Brief Overview To understand where the EJB technology stands
  18. 18. J2EE Summary <ul><li>The Java 2 Enterprise Edition (J2EE) is a Java-based, service-oriented framework. </li></ul><ul><li>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. </li></ul><ul><li>J2EE technologies are organized by the services that they provide. </li></ul>JAX-RPC, SAAJ, JAXR Web Services JAXP, JAXB XML Processing Java Management Extension (JMX MBeans) J2EE1.5 Management, monitoring, pluggin JCA Connections JAAS Security JTA, JTS Transactions EJB Distributed Components JavaMail, JAF Email JMS Messaging JNDI Naming/Directory JDBC Database Servlets, JSPs, JSFs Web J2EE Technolgies Service
  19. 19. Message Oriented Middleware (MoM) <ul><li>Transfers messages between applications </li></ul><ul><ul><li>Does not consider the content of messages </li></ul></ul><ul><li>Asynchronous communication </li></ul><ul><li>Direct or queued </li></ul><ul><ul><li>Queued (buffered) communication can support wireless clients. </li></ul></ul><ul><li>Examples </li></ul><ul><ul><li>Sun Microsystems JMSystem </li></ul></ul><ul><ul><li>Microsoft: MSMQ </li></ul></ul><ul><ul><li>IBM: Websphere MQ </li></ul></ul><ul><li>Traditional MoM systems are message queue based (one-to-one). </li></ul><ul><li>Event based systems and publish/subscribe are one-to-many. </li></ul><ul><ul><li>One object monitors another object. </li></ul></ul><ul><ul><li>Reacts to changes in the object </li></ul></ul><ul><ul><li>Multiple objects can be notified about changes. </li></ul></ul>
  20. 20. MoM (cont’d) <ul><li>Event-based systems address problems with synchronous operation and polling (remember MoM is inherently asynchronous infrastructure). </li></ul><ul><ul><li>For this, a logically centralized services mediates events. </li></ul></ul><ul><ul><ul><li>Enables anonymous communication </li></ul></ul></ul><ul><li>Push versus Pull </li></ul><ul><ul><li>May be implemented using RPC, unicast, multicast, broadcast </li></ul></ul><ul><li>Three main components </li></ul><ul><ul><li>Observer, Notifier, Event channel (borrowed from CORBA Event/Notification Service) </li></ul></ul><ul><li>Filtering can improve scalability / accuracy for content-based routing. </li></ul><ul><ul><li>( good research problems in Modern Information Storage and Retrieval ) </li></ul></ul>
  21. 21. JMS 1.1 API <ul><li>Asynchronous messaging support for Java </li></ul><ul><li>Point-to-point messaging </li></ul><ul><ul><li>One-to-one </li></ul></ul><ul><li>Topic-based publish/subscribe </li></ul><ul><ul><li>SQL for filtering messages at the topic event queue </li></ul></ul><ul><ul><li>One-to-many </li></ul></ul><ul><li>Message types </li></ul><ul><ul><li>Map, Object, Stream, Text, and Bytes </li></ul></ul><ul><li>Durable subscribers </li></ul><ul><ul><li>Event stored at server if not deliverable </li></ul></ul><ul><li>Transactions with rollback </li></ul><ul><li>See javax.jmx </li></ul>TopicSubscriber QueueReceiver MessageConsumer TopicPublisher QueueSender MessageProducer TopicSession QueueSession Session Topic Queue Destination TopicConnection QueueConnection Connection TopicConnectionFactory QueueConnectionFactory ConnectionFactory Publish/ Subscribe Point-to-Point Common
  22. 22. JMS Messaging
  23. 23. JCA (Connectors) 1.5 API <ul><li>The J2EE Connector architecture provides </li></ul><ul><ul><li>a Java solution to the problem of connectivity between various application servers and EISs (legacy EISs) already in existence. </li></ul></ul><ul><li>EIS vendors </li></ul><ul><ul><li>no longer need to customize their product for each application server. </li></ul></ul><ul><ul><li>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. </li></ul></ul><ul><li>APIs provide (see javax.resource) </li></ul><ul><ul><li>Connection Management </li></ul></ul><ul><ul><li>Transaction Management </li></ul></ul><ul><ul><li>Security </li></ul></ul><ul><ul><li>Resource Lifecycle Management </li></ul></ul><ul><ul><li>Work Management (using container-managed threads) </li></ul></ul><ul><ul><li>Asynchronous communication </li></ul></ul>
  24. 24. JMX <ul><li>Java Management Extensions (JMX) technology provides </li></ul><ul><ul><li>the tools for building distributed, Web-based, modular and dynamic solutions for managing and monitoring devices, applications, and service-driven networks </li></ul></ul><ul><ul><li>By design, this standard is suitable for adapting legacy systems, implementing new management and monitoring solutions, and plugging into those of the future. </li></ul></ul><ul><li>JMX architecture consists of three component layers </li></ul><ul><ul><li>Instrumentation layer: contains MBeans (Managed Beans) and their manageable resources </li></ul></ul><ul><ul><li>Agent layer: Contains JMX agents used to expose the MBeans </li></ul></ul><ul><ul><li>Distributed layer: contains components that enable management applications to communicate with JMX agents. </li></ul></ul><ul><li>See more at </li></ul><ul><ul><li> </li></ul></ul><ul><ul><li> </li></ul></ul><ul><ul><li> bb&op = viewforum&f =63 </li></ul></ul>
  25. 25. J2EE Key Elements (for Defining J2EE) <ul><li>J2EE consists of four key elements: </li></ul><ul><ul><li>Specification </li></ul></ul><ul><ul><li>Reference implementation </li></ul></ul><ul><ul><li>Compatibility Test Suite (CTS) </li></ul></ul><ul><ul><li>Blueprints & patterns </li></ul></ul><ul><li>The J2EE specification </li></ul><ul><ul><li>Outlines what services must be provided by a vendor that wants to advertise being J2EE compliant. </li></ul></ul><ul><ul><li>These specifications typically outline minimum requirements. </li></ul></ul><ul><ul><li>The specification often defines the API to be provided to developers. </li></ul></ul>
  26. 26. J2EE Key Elements (cont’d) <ul><li>The J2EE SDK provides a Reference Implementation (RI) of J2EE specification. </li></ul><ul><ul><li>It is a fully-functional J2EE server that provides all of the J2EE services described in the various specifications. </li></ul></ul><ul><ul><li>It’s used to demonstrate the feasibility of creating a J2EE server that conforms to the specifications. </li></ul></ul><ul><li>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. </li></ul><ul><li>The Compatibility Test Suite (CTS) </li></ul><ul><ul><li>Used to evaluate a given vendor product to ensure that it meets the requirements described within the J2EE specifications. </li></ul></ul><ul><ul><li>Any vendor that wishes to market its product as being J2EE compliant must submit it for evaluation against the CTS. </li></ul></ul>
  27. 27. J2EE Key Elements (cont’d) <ul><li>The J2EE Blueprints are an effort by the Sun Java Development Center to document best practices involving the user of the different J2EE technologies. </li></ul><ul><ul><li>These blueprints are similar to design patterns. </li></ul></ul><ul><ul><li>Represent design principles as opposed to pre-fabricated solutions to common problems </li></ul></ul><ul><li>J2EE patterns have been documented by many professionals working with both Sun as well as in industry. </li></ul><ul><ul><li>See </li></ul></ul><ul><ul><li> </li></ul></ul>