1 / 44

Introduction

Introduction. Goals : An appreciation of the Java 2 Enterprise Edition platform Where it fits in the larger scheme of things (software engineering) Broad overview with occasional dive into specifics Two part presentation : J2EE : Infrastructure, component models, APIs …

noe
Download Presentation

Introduction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Introduction Goals : • An appreciation of the Java 2 Enterprise Edition platform • Where it fits in the larger scheme of things (software engineering) • Broad overview with occasional dive into specifics Two part presentation : • J2EE : Infrastructure, component models, APIs … • EJB mechanics, some key design principles …)

  2. Outline • Evolution of J2EE • J2EE Defined • J2EE Services • J2EE Scenarios • Application Clients, Servlets and JSPs • EJBs and declarative management • Roadmap

  3. Software Engineering Evolution Evolution : • Procedural abstractions, libraries as delivery mechanism, waterfall model • Managing complexity with OO paradigm, iterative development model • Concept of software components with versioning and container

  4. ‘Enterprise’ in J2EE • ‘Programming in the large’ and ‘enterprise computing’ : differ from small-scale and academic computing • Lots of users and the application has an ‘extended life’ • Deployed on heterogeneous computing environments • Needs to have versioning mechanism • Developed by a team of developers over long time • Maintainability, Flexibility, Reusability are major issues • Difficulties • Needs to support transactions, resource-pooling, security, threading, persistence, life-cycle management etc… • System programming at the expense of business logic • Developers have to become specialists • Proprietary APIs result in non-portable code • Need for special solutions to manage complexity • Proprietary frameworks and middleware • Need for standard APIs for enterprise computing • Multi-tiered architecture in enterprise applications

  5. What is J2EE ? • Java started shipping in 3 editions starting in 1999, dubbed – J2SE (Java 2 Standard Edition) : – J2ME (Java 2 Micro Edition) : – J2EE (Java 2 Enterprise Edition) : • Goal of J2EE is to specify a platform (it is a SPECIFICATION) – Component model – Core infrastructure • J2EE means : • J2EE Platform - A standard platform for hosting J2EE applications, specified as a set of required APIs, specifications and policies. • J2EE Compatibility Test Suite - A suite of compatibility tests for verifying that a J2EE platform product is compatible with the J2EE platform standard. • J2EE Reference Implementation - A reference implementation for demonstrating the capabilities of J2EE and for providing an operational definition of the J2EE platform. • J2EE Application Programming Model - A standard programming model for developing multi-tier, thin-client applications.

  6. J2EE Platform Architecture • Component • A component is an application level software unit. • The J2EE platform supports the following types of components : • Applets, • Application clients, • Web components and • Enterprise Java Beans (EJBs) • Container • All J2EE components depend on the runtime support of a system-level entity called a container. • Containers provide components with services such as • life cycle management, • security, • deployment • threading

  7. J2EE Platform TM J2EE Patterns 7

  8. J2EE Components and Containers • Required logical relationships of architectural elements of the J2EE platform • Does not imply physical partitioning of the elements (e.g., machines, processes or VMs etc.)

  9. J2EE APIs

  10. J2EE Platform Roles • J2EE Product Provider • Application Component Provider • Application Assembler • Application Deployer • System Administrator • Tool Provider

  11. J2EE Naming Services • Provides components with access to a JNDI naming environment • Allows a component to be customized without the need to access or change the component's source code. • JNDI API is independent of JNDI SPI • Doesn’t matter how the ‘virtual enterprise directory’ is implemented

  12. 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) • A J2EE module consists of one or more J2EE components and one deployment descriptor of that component type.

  13. J2EE Transaction Services • J2EE transactions are flat (not nested) • The J2EE platform handles many transaction details, such as propagating and coordinating among multiple transaction managers. • Web components are not designed to be transactional. • Transactions are propagated from a Web component to an enterprise bean only when the Web component starts the transaction. • Transaction 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 • UserTansaction gives fine grained control but is prone to oversight (unreleased resources, timeouts, rollbacks) • It is preferable to use container managed transactions

  14. DeclarativeTransaction Management • Container intercepts client calls and takes care of transaction management • Remember old TP monitors (e.g., Tuxedo, Encina) ? • An Object Transaction Monitor is one of the most important new offerings in J2EE • 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 • Weblogic 6.0 has Tuxedo built-in, iAS 6.0 has Encina built-in

  15. J2EE Security Features • Declarative Security (authentication and authorization) • Security features declared at deployment • Not Embedded in code • Flexible, just change and redeploy • Role-Based Access Control • Users, groups mapped to roles • Containers intercept requests/method invocations, enforce access control policy • Fine grain - constraints specified on resources • Supports message integrity measures

  16. J2EE Communication Technologies • Internet protocols TCP/IP HTTP 1.0 SSL 3.0 • Remote Method Invocation protocols • Object Management Group protocols JavaIDL RMI-IIOP • Messaging technologies JMS, JavaMail • Data formats HTML 3.2, Image Files, JAR, class files,XML

  17. J2EE Application Scenario • Client tier supports a variety of client types, both outside and inside of corporate firewalls. • Middle tier supports client services through Web containers in the Web tier and supports business logic component services through Enterprise JavaBeans (EJB) containers in the EJB tier. • Enterprise information system (EIS) tier supports access to existing information systems

  18. J2EE Application Configurations • Stand-alone Client <> EJB Container <> RDBMS/EIS Resources : This configuration is the first step in the evolutionary migration from a two-tier client server system. • Browser <> Web Container <> RDBMS/EIS Resources : This configuration is popular in small scale web applications that are not supposed to serve an unpredictable number of users and is more appropriate for systems that reside within the intranet of an organization. This is suitable for applications where use of an application server is overkill. • Browser <> Web Container <> EJB Container <> RDBMS/EIS Resources : This configuration is the recommended full-blown architecture where the application has to be robust and scalable with a multitude of users demanding the maximum performance out of the system.

  19. Client options

  20. Servlets and JSPs Servlets : • Java Components that extend HTTP Server • Generation 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 JSPs : • Text-based documents contain HTML, JSP tags, Java code • “Inside-Out” Servlets, declarative, presentation-oriented way of writing Servlets. • Benefits: • Easier to Author (separate presentation from code) • Easier for Tools (J2EE standard) • Designer-serviceable part • Exploits: • Server-Side Scripting • Templates • Encapsulation of Functionality

  21. Servlets or JSPs ? • Use JSP’s for response generation • Use Servlets for controller (FrontController Design Pattern) • Use Servlets for service or for generating binary content • Example • Displaying shopping cart => use JSP technology • Generating images or charts=> use Servlets • Request processing => both JSP and Servlet technologies are suitable

  22. Approaches to Content Generation

  23. 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. • Consists of • EJB server, • EJB containers that run on EJB server • EJBs that run in these containers • EJB clients and other auxiliary systems like the Java Naming and Directory Interface (JNDI ) and the Java Transaction Service (JTS). • Three Types of EJBs • Session Beans : meant for client sessions and business logic • Stateful • Stateless • Entity Beans : Provide an abstract view of an entity (data model) • Bean Manage Persistence • Comtainer Managed Persistence • Message Driven Beans : Act as a message listener client to JMS queues or topics

  24. Client’s view of EJB • Home Interface : Has create, remove and find methods • Remote Interface : Has the business methods • The Bean Implementation : Has the implementation

  25. Anatomy of an EJB Client Code : Context context = new InitialContext (props); //JNDI Initialization ForumSessionServerHome fssh; // Home reference declaration fssh = (ForumSessionServerHome) context.lookup("apps/ForumSessionServer"); //JNDI lookup ForumSessionServer server; // Remote reference declaration server = fssh.create ("driver", "location", "pass", "tablename"); // Remote interface reference obtd.

  26. Statechart of Session Bean

  27. Statechart of Entity Bean

  28. Message Driven Beans and JMS • Provide loose coupling among heterogeneous systems • Interoperate with legacy systems that use messaging for integration • Interoperate with B2B systems not based on the J2EE TM platform • Provide asynchronous communication • Provide support for disconnected use of enterprise beans • New enterprise bean type – Asynchronous • Activated upon message arrival • Stateless • No home or remote interface • Bean implements javax. jms. MessageListenerinterface • onMessagemethod contains business logic • Configured as listener for queue (point-to-point)/ topic (publish-subscribe) • JMS APIs for sending messages available to all enterprise beans • Use in point- to- point configurations • Reliable queuing • Use within pub/ sub configurations • Beans publishing events

  29. B-2-B Application Scenario • Peer-level interactions between both Web and EJB containers • At present, this is a more tightly coupled solution most suitable for intranet environments • JMS and SOAP are gaining in popularity • Message driven bean in the EJB Container listening to JMS messsages

  30. Some Transaction Attributes Required Default Mandatory RequiresNew Unconditinal Commit Required NotSupported RM not supported By J2EE product

  31. Deployment Descriptor : Example

  32. Security Descriptors : Examples

  33. J2EE : What it is not Still required are • The need to analyze, model and design the ‘application’ • The analysis and conceptual design of the application which should be platform-independent Use help from • Design patterns of solutions instead of reinventing the wheel • J2EE Blueprints for a higher level of abstraction • At a more concrete level, try J2EE Design Patterns Remember • There are J2EE compliant vendor products BUT there is no J2EE compliant ‘application’ !

  34. J2EE Application Configurations • Stand-alone Client <> EJB Container <> RDBMS/EIS Resources : This configuration is the first step in the evolutionary migration from a two-tier client server system. • Browser <> Web Container <> RDBMS/EIS Resources : This configuration is popular in small scale web applications that are not supposed to serve an unpredictable number of users and is more appropriate for systems that reside within the intranet of an organization. This is suitable for applications where use of an application server is overkill. • Browser <> Web Container <> EJB Container <> RDBMS/EIS Resources : This configuration is the recommended full-blown architecture where the application has to be robust and scalable with a multitude of users demanding the maximum performance out of the system.

  35. EJBs Revisited • EJBs are generally Remote Distributed Objects • They work across JVMs and are portable distributed components • EJBs are generally based on RMI • Remote EJBs have stubs and skeletons that are generated for marshalling. • They have some standard methods such as ejbCreate(), ejbRemove(), ejbLoad(), ejbStore(), … etc. • The bean implementation class is the one where all business methods are • Use where the application dictates robustness and scalability and physical deployment on a heterogeneous computing environment • Each EJB server is a separate JVM (separate process) • Web Server with a Servlet Engine serves the purpose of web container • Try Tomcat from www.apache.org (free) • Application Servers come with EJB Server which has EJB container and lots of tools that help you to build and deploy a J2EE application • Try J2EESDK1.3 from java.sun.com or jboss from www.jboss.org (both are free)

  36. Session Beans Stateful session beans are to be used to • Hold business logic specific to a single client • Represent non-persistent state • Use as a Facade, single point of entry • Representing workflow between business objects • Shopping cart bean example Stateless session beans are used to • To provide service objects • e.g., mailing service • To provide procedural view of data • Caller provides all the input, and gets all the output • To operate on multiple data entities at a time, • e.g., updating inventory for a bunch of items

  37. Entity Beans • Use entity beans for multi-user data centric operations • Represent persistent data • One logical record in the database • e.g., account, order,… • Providing concurrent access to multiple clients • Providing robust, long-lived data • Survives server crashes • Don't map database tables one-to-one to remote entity beans. • Map “Business Entities” • Two ways to use entity beans for persistence • BMP : You code it yourself (inside ejbCreate(), ejbRemove(), ejbLoad() and ejbStore()) • CMP : Let the container do it for you (Define ‘cmp’ and ‘cmr’ fields in an abstract class); this is the preferred way

  38. Entity Bean (Contd.)

  39. A Major Design Issue • How to design persistence in J2EE ? • Servlets using JDBC/JDO • Stateless Session Bean using JDBC • Entity Bean with BMP • Entity Bean CMP • Some factors affecting the design decision are • Time to market • Maintainability • Reuse • Performance • Useful Design Tips • JDBC code in session bean : simple, quick, performance, lightweight • JDBC code in DAO coupled to session bean’s domain object : maintain, reuse, easy CMP migration, lightweight • JDBC code in DAO coupled to entity bean’s details object : maintain, reuse, easier migration and conceptual integrity

  40. J2EE vs .Net • Analogies

  41. J2EE vs .Net • Comparitive Analysis Is J2EE an obvious choice over .Net NO Key Issues to consider… • Backward Compatibility • Standard vs Proprietary • Platform dependence • Existing developer base and infrastructure • Complexity of applications • GUI rich vs Mission critical

  42. Explore the J2EE Patterns • Use solution patterns to standard problems of application design learnt from experience • Design Patterns by Eric Gamma et al • Guidelines and best practices for designing n-tier enterprise applications with J2EE • Consists of: • Java Series books : • Designing Enterprise Applications with the Java ™ 2 Platform Enterprise Edition (downloadable) • J2EE Patterns • A sample application “Java Pet Store” Demo • Illustrates blueprints guidelines • Starting point for your application http://java.sun.com/j2ee/

  43. J2EE Patterns

  44. Explore J2EE • Everything is available off http://java.sun.com/j2ee • Blueprints : • A Java Series book : Designing Enterprise Applications with the Java ™ 2 Platform Enterprise Edition (downloadable) • A sample application“Java Pet Store” Demo http://java.sun.com/j2ee/blueprints • Simplified J2EE guide available at http://java.sun.com/j2ee/white/j2ee_guide.pdf • Useful Enterprise Java URLs : • www.theserverside.com • www.onjava.com • www.javaworld.com

More Related