Introduction to Java EE (J2EE) by kmb15358

VIEWS: 113 PAGES: 101


                 Introduction to
                 Java EE (J2EE)



                         Session Objectives
                         ?   Understanding the value propositions of
                         ?   Getting a big picture of J2EE architecture
                             and platform
                         ?   Getting high-level exposure of APIs and
                             Technologies that constitute J2EE
                             –   You don't have to understand the details
                         ?   Understanding why J2EE is a great
                             platform for development and deployment
                             of web services

             These are the session objectives.

             At the end of this session, I expect you to get a big picture of J2EE
             architecture and platform. So I am trying to cover J2EE at 10,000 feet
             level. in this session.

             I also expect you to understand the value propositions of J2EE, that is, why
             J2EE is the platform of choice for building and deploying enterprise

             I will also cover all the major API's and technologies that constitute J2EE
             in this session so that you know what they are and how they are related to
             each other.

             Finally, I will talk about why J2EE is the platform of choice not only for
             building we-based based enterprise applications but also building web


                 ?   What is J2EE?
                 ?   Evolution of Enterprise Application Development
                 ?   Why J2EE?
                 ?   J2EE Platform Architecture
                 ?   J2EE APIs and Technologies
                 ?   Standard Impl (J2EE 1.4), Compatibility Test Suite
                 ?   BluePrints
                 ?   J2EE and Web Services
                 ?   How to get started

             This is the agenda of this session. First, we will briefly talk about what J2EE
             architecture and platform is. Then, we will talk about how the enterprise
             application development framework has evolved into J2EE architecture of
             today. Then we will talk about value-propositions of J2EE not only from
             developer standpoint but also from user and business standpoint. Then we will
             spend some time talking about J2EE platform architecture during which we
             will talk about 3 or 4 tier architectures. We will then spend various J2EE APIs
             and technologies that make up the J2EE architecture. The rest of the
             presentation will be devoted to standard implementation, compatibility test
             suite and blue prints. The last part of this presentation is to let people know on
             how to get started on learning J2EE technology.


                             What is J2EE?


             Now let's talk what J2EE really is, first.


                         Enterprise Computing
                            Challenges            Key            Products
                        Portability          Technologies     App Servers
                        Diverse              J2SE™            Web Servers
                        Environments         J2EE™            Components
                        Time-to-market         JMS            Databases
                        Core Competence        Servlet        Object to DB
                        Assembly               JSP            tools
                        Integration            Connector
                                               Data              Systems
                                                              TP Monitors
                                                              EIS Systems

        So what is enterprise computing? What are the challenges that enterprise application
        developers like yourselves are facing today? We all know the enterprise computing
        has come a long way from the old, mainframe-based, monolithic model where
        everything is lumped up together through the client-server model of early 1990s
        where fat clients are talking to backend databases directly to the current model where
        applications are web-based, n-tier, well-distributed over the heterogeneous
        environment where software are to be built as objects and components.
        And of course, the set of challenges you face have changed as well. For a start, the
        applications you are building have to be portable, scalable, reliable, secure,
        maintainable, and of course, they have to function in high-performance. And they also
        have to be adaptable and flexibile to accommodate the constant changes in business
        Given the challenges you face, you also have to decide which key technologies and
        products and architeural platform to use in order to meet those challenges. The
        problem is there are simply too many of them and it is hard to come up with your own
        architecture or framework where everything is in a well-integrated and cohesive form.
        Another important issue you ask yourself is integration of legacy systems. That is,
        how are you going to integrate the existing database and EIS systems into the overall
        These are all valid questions and issues of enterprise computing today. The good
        news is J2EE is specifically designed to address all these issues.


                     What Is the J2EE?

                    l   Open and standard based platform
                    l   developing, deploying and managing
                    l   n-tier, Web-enabled, server-centric,
                        and component-based enterprise


             What is J2EE? In short, it is an open, standard-based, development and
             deployment platform for building n-tier, web-based and server-centric, and
             component-based enterprise applications.


                                 The Java™ Platform

                               Java Technology   Java Technology   Workgroup   High-End
                               Enabled Devices   Enabled Desktop    Server      Server


             By now, most of you know there are three flavors of Java - Micro Edition,
             Standard Edition, and Enterprise Edition. These three flavors of Java represent
             three distinct target market segments each of which has unique issues and
             requirements that need to be addressed somewhat differently.

             Micro Edition addresses of market segment of small devices such as PDAs, cell
             phones and settop boxe, which are typically constrained in terms of memory space
             and processing power.

             Standard Edition represents the Java that we all know and love, a Java for desktop
             and workgroup server environments that require a full feature functionalities
             including rich graphical user interface.

             Enterprise Edition covers the Java platform for developing and deploying
             enterprise qualitiy applications which are typically transactional, reliable and

             Also note that the “Enterprise Edition” box in the graphic extends into the standard
             edition, that is, Enterprise edition is built over standard edition.


                        The Java TM Platform
                                                    Java 2 Platform Micro Edition
                                                               (J2ME TM)



                                                      Personal       Personal
                         Java 2       Java 2         Basis Profile    Profile
                        Enterprise   Standard
                         Edition      Edition           Foundation Profile            MIDP
                         (J2EE)       (J2SE)                                                         Java
                                                                 CDC                 CLDC            Card

                                                  JVM                                 KVM           CardVM

                                                                       * Under development in JCP

             This is another picture that shows three flavors of Java
             technology. Java is being used at JavaCard at one end and
             at the supercomputer at the other end.

             The key point in this picture is that the syntax and semantics
             of Java programming language is preserved regardless of
             which edition you use. And regardless where it is being
             used, it provides the secure, portable, and robust application
             development and deployment platform.


                          What Makes Up J2EE?
                          ?   API and Technology specifications
                          ?   Development and Deployment Platform
                          ?   Standard and production-quality
                          ?   Compatibility Test Suite (CTS)
                          ?   J2EE brand
                          ?   J2EE Blueprints
                          ?   Sample codes


             So now some of you might be ready to ask “What exactly do I get from J2EE?” .
             This slide shows the list of things that come with J2EE.

             First and foremost, J2EE is a set of API and technology specifications. And we
             will see the detailed list of APIs and technologies of J2EE in the following slide.

             J2EE also provides you with a standard development and deployment platform.
             What does this mean? From developer’s perspective, it means is that J2EE
             provides a standard framework of building server components. From platform
             vendors’ perspective, it means their platforms should be able to run any
             applications that uses J2EE-compliant APIs.

             Reference implementation and compatibility suite. Just like any other Java
             initiative based on Java community process, J2EE also comes with its own
             reference implementation and compatibility test suite. J2EE is also a brand of all
             compliant products. That is, J2EE compliant app servers are stamped with J2EE
             branding after they passed regorous J2EE compatibility testing.

             Finally, J2EE also provides something unique called J2EE BluePrints, which is a
             documentation and sample program in which best practice guidelines and design
             principles for building J2EE-based enterprise applications are described in detail.


                             Evolution of
                        Enterprise Application


             OK, we just took a look at the evolution of distributed computing from a
             very high level. Now let's talk about the evolution of enterprise
             application framework and see how things have evolved into an
             architecture like J2EE. As you will see, there have been quite a bit of
             evolution before we arrive an architecture like J2EE.


                          Evolution of Enterprise
                          Application Framework
                           ?   Single tier
                           ?   Two tier
                           ?   Three tier
                               –   RPC based
                               –   Remote object based
                           ?   Three tier (HTML browser and Web server)
                           ?   Proprietary application server
                           ?   Standard application server

             The evolution of enterprise application framework starts from single-tier
             mainframe based model in the beginning, moved to first phase of distributed
             framework, two-tier client server model, then three tier model.

             Within the three-tier model, there are two communication models. First one is
             based on RPC (Remote Procedure Call) model in which non-object-based
             procedures are invoked by the client. The other model incorporates the
             concept of object in which remote object is accessed by the client.

             When the Internet took off, the three tier model takes a very radical
             transformation in which HTML browser talks to a Web server, which then talks
             to backend database or enterprise information systems.

             The next two phases are advent of the concept of application server, first, app
             server based on proprietary architecture and API and the next phase is where
             we are today with open standard based app server architecture, which is what
             J2EE is all about.


                          About Enterprise Applications
                           ?   Things that make up an enterprise
                               –   Presentation logic
                               –   Business logic
                               –   Data access logic (and data model)
                               –   System services
                           ?   The evolution of enterprise application
                               framework reflects
                               –   How flexibly you want to make changes
                               –   Where the system services are coming from

             Now if you think about the things that make up a typical enterprise application,
             they include presentation logic, business logic, data access logic, and system

             The presentation logic deals with how to present information to the end-users.
             The business logic includes the business logic of the application. And the data
             access logic deals with accessing data in the back-end database. The system
             services includes security, caching, logging, transaction, and other services that
             typical enterprise application would use.

             Now the way the enterprise application framework evolves reflects how
             flexibly you want to make changes in the presentation logic, business logic and
             data access and data models. The other factor reflects how the system services
             are provided by the framework.


                     Single Tier (Mainframe-based)

                       ?   Dumb terminals are directly connected to
                       ?   Centralized model (as opposed distributed
                       ?   Presentation, business logic, and data
                           access are intertwined in one monolithic
                           mainframe application                       13

             In the beginning of computing era, the model is pretty much a single
             tier model in which dumb terminals are directly connected to a
             mainframe. Here the mainframe is centralized point of computing
             intelligence in which presentation, business logic, and data access are
             all intertwined in a single monolithic mainframe application.


                          Single-Tier: Pros & Cons
                          ?   Pros:
                              –   No client side management is required
                              –   Data consistency is easy to achieve
                          ?   Cons:
                              –   Functionality (presentation, data model, business
                                  logic) intertwined, difficult for updates and
                                  maintenance and code reuse


             In a single tier model, because the clients are dumb terminals and do not have
             any processing logic what so ever, there is no client side management required.
              Also because the data access logic is in complete control of the mainframe
             application, the data consistency is easy to achieve.

             Now the negative side of single tier model is that there is no separation among
             presentation, business logic, and data access. This doesn't facilitate code re-use
             because all functionality is mixed together. Changing data or business logic
             may affect every part of the application, making changes (for example, adding
             new functionality or bug fixes) difficult task.



                      ?   Fat clients talking to back end
                          –   SQL queries sent, raw data returned
                      ?   Presentation,Business logic and Data
                          Model processing logic in client
                          application                                   15

             The next evolution phase is two-tier model. The two tier model
             appears along with the advent of personal computer, which was
             increasingly used as client platform of choice replacing dumb

             In two-tier model, fat clients are talking to backend database by
             using some database access protocol such as SQL.

             The clients are called “fat” clients because the clients have to
             maintain presentation logic, business logic, and have to have
             detailed understanding on data model of the backend data and how
             to access it.


                          ?   Pro:
                              –   DB product independence (compared to single-tier model)
                          ?   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

             The advantage of using two-tier model is that it provides database
             independence and database access protocol is standard SQL language
             compared to single-tier model.

             Yet, it has very significant disadvantages as well. First, the presentation,
             business logic and data model are now intertwined, this time, at the client side,
             thus suffers same problem of difficult maintenance and updates. Second,
             because the data model of the server also has to be maintained at the client,
             every time there is a data model change, for example, a schema change, then all
             the clients need to be updated. This could be a very serious deficiency if the
             number of clients are in the range of thousands even in the range of hundreds.

             Now since each client has to have a database connection, it would be rather
             difficult to scale in that it is not possible to provide “connection
             pooling”scheme., which is typical mechanism for supporting scalability.

             Because the data is in the form of raw data, there could be very high demand
             on network bandwidth.


                                Three-Tier (RPC based)
                                               RPC request           request
                                               RPC response         SQL

                            ?   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
                                 –   Concurrency control, threading, transaction, security,
                                     persistence, multiplexing, performance, etc.         17

             The “difficult to upgrade clients” problem of two-tier model triggers the
             advent of next one, three-tier model.

             The most distinguishing characteristic of three tier model is that now there is
             a separation between presentation logic from the other two. That is, the
             presentation logic is handled at the client while business and data access
             logic are handled at the middle tier server. In this sense, the clients of three-
             tier model is thinner than the ones in two-tier model. And the changes of
             business logic and data model can be done more flexibly than two-tier model
             because the only place the changes need to be reflected are at the middle-tier
             server not at the clients.

             The three tier model, however, introduces an interesting problem of its own.
             Now because the middle-tier server receives service requests from many
             clients at the same time, the middle-tier now has to deal with various system
             level issues such as concurrency control, threading, transaction, security,
             persistence, multiplexing, performance, and so on.

             Now as mentioned before, the three tier model can be further divided into
             RPC-based and Remote object based. In RPC based model, the clients and
             the middle-tier server are more tightly coupled than the object model because
             they have to agree upon on the implementation level (rather than interface
             level of remote object based model.)                                                17

                         Three-tier (RPC based): Pros & Cons
                          ?   Pro:
                              –   Business logic can change more flexibly than 2-
                                  tier model
                                   ?   Most business logic 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)
                              –   Code is not really reusable (compared to object
                                  model based)

             So the benefit of using three-tier model over two-tier model is again the
             business logic and data model can be more easily changed.

             Now the downside of the three-tier model is that now the middle-tier server has
             to deal with complex system level issues as mentioned in the previous slide.
             And compared to object-based three tier model, it is more tightly coupled
             because change of implementation on either side might require change on the
             other. And since it is not really object-mode based, the code is not reusable.


                     Three-Tier (Remote Object based)

                                        Object request      SQL
                                        Object              SQL
                                        response            response

                        ?   Business logic and data model captured in
                            – 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         19

             Now the next evolution is remote object-based three tier model.
             The key difference of this model from the three tier RPC model is
             that now the business logic and data model are captured in objects,
             which means they can be expressed in the abstract terms.

             For example, the most popular remote object model is CORBA and
             RMI. In the case of CORBA, the business logic is abstractly
             expressed in IDL (Interface Definition Language) while in the case
             of RMI, it is in the form of Java interface type.


                          Three-tier (Remote Object
                          based): Pros & Cons
                          ?   Pro:
                              –   More loosely coupled than RPC model
                              –   Code could be more reusable
                          ?   Cons:
                              –   Complexity in the middle-tier still need to be


             The advantage of this approach is that now the client and the server are more
             loosely coupled than RPC model because the only agreement they have to have
             is abstract description of the service. How they are implemented either at the
             client or at the server do not impact each other. So implementation change at
             the server side should not force a change on the client side, for example, as
             long as the interface definition remains the same. And because the code is in
             the form of object, reusability can be increased.

             However, the issue that the server still has to deal with system level services
             still remain the same.


                       Three-Tier (Web Server)
                                 HTML request    WEB      request
                                 HTML response            SQL

                   ?   Browser handles presentation logic
                   ?   Browser talks Web server via HTTP protocol
                   ?   Business logic and data model are handled by
                       “dynamic contents generation” technologies
                       (CGI, Servlet/JSP, ASP)

             Now a completely different three-tier model has emerged as
             the browser has become one of the most pervasive form of
             user interface at the client platform. In this model, the
             browser basically provides common presentation logic. And
             the browser and the server communicates using a standard
             protocol, HTTP. And the business logic and data model are
             captured in dynamic contents generation technologies such as
             CGI, servlet/JSP, or ASP. These technology components in
             turn talk to backend database or enterprise information


                          Three-tier (Web Server based):
                          Pros & Cons
                          ?   Pro:
                              –   Ubiquitous client types
                              –   Zero client management
                              –   Support various client devices
                                   ?   J2ME-enabled cell-phones
                          ?   Cons:
                              –   Complexity in the middle-tier still need to be


             Now the obvious reason browser is popular is that the presentation logic and
             the communication model between the clients and the server are based on
             standards, HTML browser and HTTP protocol respectively. And you certainly
             have less to worry about as far as client management is concerned.

             Another advantage of this model is because HTML and HTTP are standards,
             any client types, for example, J2ME-enabled cell-phones, can communicate
             with the server via HTTP.

             The downside is that the middle-tier complexity still needs to be addressed.


                      ?   Moving from single-tier or two-tier to multi-
                          tier architecture
                      ?   Moving from monolithic model to object-
                          based application model
                      ?   Moving from application-based client to
                          HTML-based client


             So based on this evolution, we can observe a few trends. First, moving from a
             single tier or two-tier model to multi-tier model. Second, moving from the
             monolithic code to object-based application model. Lastly, HTML browser
             based clients are taking some strong hold.


                              Single-tier vs. Multi-tier
                                    Single tier                 Multi-tier
                               l   No separation         l   Separation among
                                   among presentation,       presentation,
                                   business logic,           business logic,
                                   database                  database
                               l   Hard to maintain      l   More flexible to
                                                             change, i.e.
                                                             presentation can
                                                             change without
                                                             affecting other tiers


        Now let's compare the single-tier model against multi-tier model. In a single tier model
        or even two-tier model, there is no separation among presentation, business, and data
        access logic, which makes it harder to maintain the code while in multi-tier model, there
        are separation among those three functionality. And because they are separated, a
        change in one area should not impact the others, which provides much more flexible
        way of maintaining the code.


                                   Monolithic vs. Object-based

                                   Monolithic             Object-based
                              l   1 Binary file       l   Pluggable parts
                              l   Recompiled,         l   Reusable
                                  relinked,           l   Enables better
                                  redeployed every        design
                                  time there is a     l   Easier update
                                  change              l   Implementation
                                                          can be separated
                                                          from interface
                                                      l   Only interface is

        Now let's compare monolithic model and object-based model. In a monolithic model,
        everything is intertwined. This means every time you make a change, the whole thing
        has to be recompiled and re-linked and redeployed. In the object-based model, things
        are more flexible and reusable. Again, the implementation can change without affecting
        the other programs residing in different tiers as long as interface remains the same.


                          Outstanding Issues & Solution
                          ?   Comlexity at the middle tier server still remains
                          ?   Duplicate system services still need to be
                              provided for the majority of enterprise
                              –   Concurrency control, Transactions
                              –   Load-balancing, Security
                              –   Resource management, Connection pooling
                          ?   How to solve this problem?
                              –   Commonly shared container that handles the above
                                  system services
                              –   Proprietary versus Open-standard based

             Now the issue of “middle tier still need to deal with system level issues such as
             concurrency control and resource management” still remains the same.
             Furthermore, since every application has to deal with these issues, there could
             be duplication among the applications in the area of system services.

             So what could be the solution? The solution is to come up with an architecture
             or framework where the common container which can be shared among all
             applications provide system services mentioned above.

             And that is where next evolution has occurred, initially with proprietary form
             and later on based on an open-standard.


                            Proprietary Solution
                        ?   Use "component and container" model
                             –   Components captures business logic
                             –   Container provides system services
                        ?   The contract between components and
                            container is defined in a well-defined but
                            with proprietary manner
                        ?   Problem of proprietary solution: Vendor
                        ?   Example: Tuxedo, .NET

             So in both proprietary and standard based model, the idea is to use component
             and container model in which business logic is captured as components and the
             container provide host execution environment where system services are also
             provided. Of course, the proprietary model locks you in a single product and
             single vendor and the examples are good old Ttuxedo and of course .NET is
             another prime example of this.


                              Open and Standard Solution
                          ?   Use "component and container" model in
                              which container provides system services
                              in a well-defined and as industry standard
                          ?   J2EE is that standard that also provides
                              portability of code because it is based on
                              Java technology and standard-based Java
                              programming APIs


             Open and standard based solution is that a standard specification defines the
             contract of the component and container model in a well-defined and in an

             And J2EE is that standard. And because it is based on Java technology, the
             portability of code also can be achieved regardless underlying OS or hardware


                                  Why J2EE?


             OK, by now, I assume you get the sense of how enterprise application
             architecture has evolved into what it is today, namely open standard
             basedJ2EE framework.

             Now I would like to spend some time talking about the concrete value that
             J2EE provides to different players in the scene of enterprise computing.


                      Platform Value to Developers
                      ?   Can use any J2EE implementation for
                          development and deployment
                          –   Use production-quality standard implementation
                              which is free for development/deployment
                          –   Use high-end commercial J2EE products for
                              scalability and fault-tolerance
                      ?   Vast amount of J2EE community resources
                          –   Many J2EE related books, articles, tutorials,
                              quality code you can use, best practice
                              guidelines, design patterns etc.
                      ?   Can use off-the-shelf 3rd-party business

             First, let's talk about J2EE platform value to developers.

             Now with J2EE, developers do not have to be tied up with particular vendor
             platform because they can use any J2EE-compliant implementation as their
             development platform while application portability is still guaranteed. For
             example, you can use freely available J2EE implementations such as Sun Java
             System App Server Platform Edition for development while you might want to
             use high-end commercial platforms for actual production deployment
             especially when scalability, reliability, fault-tolerance, and high-performance
             are important factors.

             Second,J2EE is, for that matter, Java, is all about community. There is vast
             amount of J2EE community resource that be leveraged by J2EE developers, for
             example, books, articles, tutorials, and quality code that you can use, best
             practice guidelines and design patterns people have spent time to develop. If
             you think about it, these are very significant value.

             Thirdly, because J2EE is based on component model, that is, 3rd party
             components can be used to build enterprise applications thus saving time and


                     Platform Value to Vendors
                    ?   Vendors work together on specifications
                        and then compete in implementations
                        –   In the areas of Scalability, Performance,
                            Reliability, Availability, Management and
                            development tools, and so on
                    ?   Freedom to innovate while maintaining the
                        portability of applications
                    ?   Do not have create/maintain their own
                        proprietary APIs

             So what are the J2EE value proposition to vendors? First vendors work
             together on creating specifications and then they compete in implementations.
             And the areas they compete include scalability, performance, reliability,
             availability, management and development tools, and so on.

             This way, vendors have freedom to innovate in their implementations while
             maintaining the portability of their applications. So bottom line is that vendors
             can influence the future of Java while they can continue to innovate.

             And vendors are free from having to maintain their own proprietary APIs.
             Instead they focus on better implementations.


                     Platform Value to Business
                     ?   Application portability
                     ?   Many implementation choices are possible
                         based on various requirements
                         –   Price (free to high-end), scalability (single CPU to
                             clustered model), reliability, performance, tools,
                             and more
                         –   Best of breed of applications and platforms
                     ?   Large developer pool


             Now what about the business customers? First and foremost, to customers,
             application portability is guaranteed, which means they can choose best of
             breed applications as well as best of breed platforms based on many criteria, for
             example, price, scalability, reliability, and performance, and tools, and so on.

             There are large developer pool they can tap with. And then they can use many
             quality open source implementations such Tomcat, Struts, Cocoon, and Axis
             and so on, over the J2EE platform


                                 J2EE APIs &


             Now let's talk J2EE APIs and technologies. I don't intend to give detail
             description of these technologies here since we have the remaining
             sessions talking about these technologies in detail. But I want to give you
             a big picture so that you understand where these individual technologies fit
             in under the big picture of J2EE. So if you don't understand the details of
             these technologies, don't worry about it. Instead just get some sense on the
             roles these technologies play for particular application requirements.


                      J2EE 1.4 APIs and Technologies
                      ?   J2SE 1.4 (improved)        ?   Servlet 2.4
                      ?   JAX-RPC (new)              ?   JSP 2.0
                      ?   Web Service for            ?   EJB 2.1
                          J2EE                       ?   JAXR
                      ?   J2EE Management            ?   Connector 1.5
                      ?   J2EE Deployment            ?   JACC
                      ?   JMX 1.1                    ?   JAXP 1.2
                      ?   JMS 1.1                    ?   JavaMail 1.3
                      ?   JTA 1.0                    ?   JAF 1.0

             So this is the summary slide of all Java APIs and technologies that will be
             part of J2EE 1.4. I put it here for your reference. The ones in red color
             are newly added features while the ones in blue color are the ones whose
             functionality is enhanced from the previous version.


             Java EE 5
             ?       JAX-WS 2.0 & JSR 181
                 ?   Java Persistence
             ?       EJB 3.0
             ?       JAXB 2.0
             ?       JavaSever Faces 1.2 – new to Platform
             ?       JSP 2.1 – Unification w/ JSF 1.2
             ?       StAX – Pull Parser – new to Platform



                           Servlet &
                    JSP (JavaServer Pages)

             OK. Let's talk about servlet and JSP, which are cornerstone technologies of


                             What is a Servlet?
                         ?    Java ™ objects which extend the
                              functionality of a HTTP server
                         ?    Dynamic contents generation
                         ?    Better alternative to CGI, NSAPI, ISAPI,
                              –   Efficient
                              –   Platform and server independent
                              –   Session management
                              –   Java-based

             What is Servlet? A servlet is a Java object that extends the functionality of
             HTTP server by providing the capability of dynamic contents generation.

             Now you might remember that people used to use CGI for dynamic contents
             generation. “What is wrong with CGI?” Lots of things. First, inefficiency. In
             CGI, every HTTP request from client results in a creating of a new process,
             even if they are from a same client, which is quite inefficient and of course
             because of that, cannot scale to handle large number of clients at the same time.

             The servlet technology is designed to solve these problems associated with
             using CGI, or proprietary APIs such as NSAPI or ISAPI. For example, Servlet
             handles the HTTP client requests much more efficiently than CGI because it
             does not have to create new process every time there is a new client request.
             Instead, it creates a new thread. Because it is Java and because it is standard-
             based, most of the web servers out there support servlet. It also handles session
             management for you so that you don’t have to deal with it yourself. By being
             Java code, it is cross-platform technology as opposed to vendor-specific or
             product-specific technologies such as NSAPI or ISAPI.


                             Servlet vs. CGI
                               Request CGI1
                               Request CGI1                            Child for CGI1
                                                                       Child for CGI1
                               Request CGI2           CGI
                               Request CGI2          Based             Child for CGI2
                                                      Based            Child for CGI2
                               Request CGI1
                               Request CGI1                            Child for CGI1
                                                                       Child for CGI1

                               Request Servlet1
                               Request Servlet1           Servlet Based Webserver
                                                          Servlet Based Webserver
                               Request Servlet2                            Servlet1
                               Request Servlet2
                               Request Servlet1                            Servlet2


             This picture shows difference between CGI and servlet-based model. In CGI, for
             every HTTP request, a new process has to be created while in servlet model, it is
             the thread that gets created in the same Java VM (Virtual Machine) and that thread
             can stay there for serving other requests.


                        What is JSP Technology?
                    ?   Enables separation of business logic
                        from presentation
                         –   Presentation is in the form of HTML or
                         –   Business logic is implemented asJava
                             Beans or custom tags
                         –   Better maintainability, reusability
                    ?   Extensible via custom tags
                    ?   Builds on Servlet technology

        JSP, Java Server Pages, was introduced as a follow-on technology to the Servlet. Even though
        the Servlet solves many problems associated with CGI for dynamic contents generation, it has
        one downside. The downside is that, under Servlet, the presentation, typically HTML pages, has
        to be generated as part of the servlet Java code, for example, using printf statement. What this
        means is that whenever you have to make some change to the presentation, the Java code has to
        be changed and then recompiled, redeployed. This in turn result in maintenance problem of your
        applications. Also it makes web-page prototyping effort rather a difficult task.

        JSP is designed to address of this shortcoming of the Servlet while maintaining all the benefits of
        Servlet. That is, it provides a clear separation between the presentation and business logic code.
        That is, the presentation will be designed by Web page designers in the form of either HTML or
        XML or JSP page while the business logic will be implemented by Java programmers either in
        the form of Java Beans or custom tags. This separation will result in a better maintainability of
        both presentation pages and business code. And because the business logic is encapsulated into
        Java beans or custom tags, it increased reusability of the code as well.

        I mentioned about custom tags. Custom tags are basically specialized Java beans which
        encapsulate the application-specific business logic. The functionality of enterprise applications
        can be extended by building more custom tags.

        Finally, JSP technology is built over servlet. In fact, JSP pages when deployed get converted
        into servlet first. Because it is built over servlet, it maintains all the benefits of servlet. For
        example, all the ready-to-use objects in a servlet such as session objects can be also available to
        JSP page designers and custom tag developers.                                                39

             (Enterprise Java


                           What is EJB Technology?
                          ?   A server-side component technology
                          ?   Easy development and deployment of
                              Java technology-based application
                              that are:
                              –   Transactional, distributed, multi-tier,
                                  portable, scalable, secure, …


             What is EJB? In short, it is a server-side component technology, which enable
             the easy development and deployment of Java-based enterprise applications in
             the form of components that have to be enterprise-quality, meaning they are
             transactional, distributed, multi-tier, portable, scalable, secure, and reliable, and
             the list can go on.


                            Why EJB Technology?
                            ?   Leverages the benefits of component-model
                                on the server side
                            ?   Separates business logic from system code
                                –   Container provides system services
                            ?   Provides framework for portable components
                                –   Over different J2EE-compliant servers
                                –   Over different operational environments
                            ?   Enables deployment-time configuration
                                –   Deployment descriptor


             Why EJB? By providing a standard component model on the server side, it leverages all the
             benefits that are inherent in component technology, for example, simplified development and
             deployment and reuse of the code.

             Another key benefit of EJB is the separation of business logic from system code. That is, the EJB
             server platform provides all the system services such as resource management, transaction
             coordination and persistence management. Since the system services are provided by the server
             platform itself, you, as a developer, can now focus your development effort to building business
             logic components rather than system code.

             Because EJB is built around industry-standard component framework, because it is based on
             Java, it allows portability of your components. That is, the business logic components you build
             will be portable across different vendors’ server platforms as well as different operational
             environments without any change in your code or without even recompiling. It is truly binary
             portability we are talking about.

             Now you might want to ask? How do these components adapt themselves to the different
             operational environments? That is, different operational environments have different
             requirements on security policy, they have different databases in place , different transactional
             model maybe have to be used. How do you instruct your business components to a different
             behavior without actual change of code? It is done by what is called deployment descriptor. The
             deployment descriptor is essentially an XML file that specifies the runtime behavioral
             characteristics of your business component. And it gets constructed or changed at the time of
             deployment not at the time of code development.


                                EJB Architecture


             This picture shows a somewhat simplified architecture of EJB. We will talk about
             the concept of containers and components later on. But a key architectural concept
             of EJB is that there is a separation of business logic components from the hosting
             execution environment in which those components are running. The business logic
             components under EJB architecture are represented as EJB beans while the hosting
             environment is represented by EJB container (sometimes called as EJB server).

             As a business component developer, you have to write three Java files and a
             deployment descriptor. First you have to write EJB home interface which defines
             the methods that will be used by clients in order to create and locate your bean
             through the container. Second, you have to write EJB remote interface which
             defines the business methods of your bean. Finally, you will build your bean and
             deployment descriptor which specifies which Java interface is home interface and
             which Java interface is remote interface, and which class is in fact your bean class.

             Now container, at the time of deployment of your beans, will create two internal
             and intermediary objects, EJB home object and EJB remote object. These objects
             are implementation of home and remote interface you have defined. So when the
             client wants to invoke some business methods of the EJB bean you created, it is
             actually talking to these two intermediary objects instead. Why this indirection?
             This is to allow the container to intercept the calls so that it can provide system
             services such as security, transaction, persistence, resource management, life cycle
             management, and so on.                                                            43

                     Enterprise JavaBeans
                                              Enterprise JavaBeans

                            Synchronous communication           Asynchronous communication
                          Session Bean        Entity Bean            Message-Driven Bean

                       Stateless   Stateful

                                    Bean managed      Container managed
                                     Persistence         Persistence
                                        (BMP)               (CMP)

             Now EJB has three bean type - session bean, entity bean, and message
             driven bean. And session bean can be either stateful or stateless session
             bean. And entity bean can be either bean managed or container managed.

             And you as a developer choose which bean type to use depending on the
             needs and requirements of your application. For example, you use session
             bean when you have to have a client session and you use entity beans to
             reflect persistent data and you use message driven bean to receive
             messages in an asynchronous fashion. And we will talk about these bean
             types and their usage in gory detail later in this course.


                                 (Java Message

              Now let’s talk about JMS, Java Messaging Service. The Java Message Service
             (JMS) API has been developed by Sun working in close cooperation with the
             leading enterprise messaging vendors.


                                 Java Message Service (JMS)
                             ?   Messaging systems (MOM) provide
                                  –   De-coupled communication
                                  –   Asynchronous communication
                                  –   Plays a role of centralized post office
                             ?   Benefits of Messaging systems
                                  –   Flexible, Reliable, Scalable communication
                             ?   Point-to-Point, Publish and Subscribe
                             ?   JMS defines standard Java APIs to
                                 messaging systems                                           46

      Messaging has been around for quite a while even before JMS as a way to build reliable, flexible, and scalable
      communication system. Some of you might have heard the term, Message-Oriented-Middleware, or MOM in
      short. In fact, in the mainframe world, product like IBM’s MQ_Series has been around for quite a while.
      Now let’s talk about the concept of messaging and get some sense of what it is and why you want to use it and
      when you want to use it.

      Messaging enables de-coupled communication (or sometimes called loosely coupled communication) in that
      the sender does not have to know the details of the receiver, for example, the sender does not have to know
      whether a receiver is a live process or not or the location information of it such as IP address or port number.
      Instead the sender and receiver of messages communicate via an intermediary communication framework
      called messaging system. This is a departure from tightly-coupled communication systems such as RPC,
      socket, or RMI in which the communicating parties are talking each other directly instead of an intermediary
      server. In this sense, messaging server functions like a post office. It provides an asynchronous
      communication in that a sender of a message does not have to wait for an acknowledgment from the receiver.
      Or the receiver of the message can be notified when a message arrives. And because the sender and receiver
      are de-coupled, the only means of communication is via sending and receiving messages.

      The benefits of using messaging system is that it provides a flexible, reliable, and scalable communication
      systems. For example, it provides flexible communication system because the sender and receiver do not have
      to know each other, it provides reliable communication system because the intermediary server handle
      persistently maintain the message until there is an acknowledgment from the receiver. It is scalable because
      the system can handle larger number of clients by adding more server capability at the messaging system itself.

      I mentioned that under the model of de-coupled communication, there is an intermediary communication
      framework called messaging system. And it is this underlying messaging system, by playing a role of a post
      office, that provides necessary support so that applications can send or receive messages.



                           Connector Architecture
                           ?   Defines standard API for integrating J2EE
                               technology with EIS systems
                               –   CICS, SAP, PeopleSoft, etc.
                           ?   Before Connector architecture, each App
                               server has to provide an proprietary adaptor
                               for each EIS system
                               –   m (# of App servers) x n (# of EIS's) Adaptors
                           ?   With Connector architecture, same adaptor
                               works with all J2EE compliant containers
                               –   1 (common to all App servers) x n (# of EIS's)

             As more businesses move towards an e-business strategy, integration with
             existing Enterprise Information Systems (EIS) becomes a key to success.
             Enterprises with successful e-businesses need to integrate their existing EISs
             with new web-based applications. They need to extend the reach of their EISs
             to support business-to-business (B2B) transactions.

             Before the J2EE Connector architecture was defined, no specification for the
             Java platform addressed the problem of providing a standard architecture for
             integrating EISs to J2EE application server in a standard-fashion. Most EIS
             vendors and application server vendors use non-standard vendor-specific
             adaptors to provide connectivity between application servers and enterprise
             information systems.

             The J2EE Connector architecture provides a Java solution to the problem of
             connectivity between the many application servers and EISs already in
             existence. By using the J2EE Connector architecture, 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 enterprise
             information system. So it solves the m (appservers) times n (enterprise
             information systems) adaptor problem. That is with connector architecture, the
             number of adaptors that need to be developed are the same number of
             enterprise information systems since a common adaptor can be used for all         48
             J2EE compliant application servers.

                             m x n Problem Before
                             Connector Architecture
                                     m                      n
                                   App                     SAP
                                   App                      EIS
                                  Server2                    2

                                   App                     EIS3
                                   App                     EIS4


             So this picture shows the m times n adaptor problem before connection
             architecture. Again, the connector architecture will reduce it to 1 times n
             adaptor scenario.


                           JAAS (Part of J2SE 1.4)
                              (Java Authentication &
                              Authorization Service)

             Now let's talk about a bit on JAAS, Java Authentication and Authorization
             Service. It is now part of J2SE 1.4. That is, every J2SE 1.4 should have JAAS.
             Before J2SE 1.4, it used to be an optional package and J2EE 1.3 specifies that
             JAAS is to be supported by any J2EE 1.3 compliant implementation.


                        JAAS: Authentication
                        ?   Pluggable authentication framework
                            –   Userid/password
                            –   Smartcard
                            –   Kerberos
                            –   Biometric
                        ?   Application portability regardless of
                            authentication schemes underneath
                            –   JAAS provides authentication scheme independent
                            –   Authentication schemes are specified Login
                                configuration file, which will be read by JAAS

             JAAS addresses both authentication and authorization. So let's talk about
             authentication aspect of JAAS first.

             JAAS provides pluggable authentication framework. It is expected that
             different business organizations would employ different authentication
             schemes. Examples of authentication schemes they might use include
             userid/password based authentication, smartcard, Kerberos, or Biometric

             The idea of JAAS pluggable authentication framework is to allow Java
             application that performs the authentication to be portable regardless of the
             underlying authentication schemes. So JAAS provides authentication
             scheme independent API that can be used by the Java application. There is
             also login configuration file that contains information on the authentication
             schemes that are deployed for a particular operational environment. And
             this login configuration file will be read by JAAS runtime.


                        JAAS Pluggable Authentication


             This picture shows the pluggable authentication framework of JAAS. The
             application uses the API that is provided by the JAAS runtime
             implementation. So the boxes of purple color represents the
             implementation code that is provided by the JAAS. And this code reads
             the login configuration file during runtime. And each authentication
             scheme should provide a class file that is compliant to loginModule service
             provider interface that JAAS architecture defines.


                        JAAS: Authorization
                        ?   Without JAAS, Java platform security are
                            based on
                            –   Where the code originated
                            –   Who signed the code
                        ?   The JAAS API augments this with
                            –   Who’s running the code
                        ?   User-based authorization is now possible


             In terms of authorization, JAAS now adds the concept of “who is running
             the code” to the matrix of access control. Before JAAS, the access control
             is based on two things: where the code originated and who signed the
             code. Now with JAAS, the access control is based on three things: where
             the code come from, who signed the code, and who is running the code.
             So with JAAS, user-based authorization is finally possible.


                            Other J2EE APIs &

             Now let's go over other Java programming APIs and technologies that
             constitute J2EE.


                            ?   Java Naming and Directory Interface
                            ?   Utilized by J2EE applications to locate
                                resources and objects in portable
                                 –   Applications use symbolic names to find
                                     object references to resources via JNDI
                                 –   The symbolic names and object references
                                     have to be configured by system
                                     administrator when the application is

             JNDI stands for Java naming and directory interface and it is a common method for
             locating resources or objects under J2EE framework.

             JNDI is utilized by J2EE applications to locate resources and objects in a portable
             fashion. That is, in your application, you are using a symbolic name to refer an object
             assuming that symbolic name has been configured to real object reference or
             resource by the system administrator. Because the system administrator can
             configure the association of the symbolic name and actual object at the time of
             deployment, the code portability is still assured.


             ?   Provides standard Java programming
                 API to relational database
                  –   Uses SQL
             ?   Vendors provide JDBC compliant
                 driver which can be invoked via
                 standard Java programming API



                        J2EE Management (JSR-77)
                        ?   Management applications should be able to
                            discover and interpret the managed data of
                            any J2EE platform
                        ?   Single management platform can manage
                            multiple J2EE servers from different
                        ?   Management protocol specifications ensure
                            a uniform view by SNMP and WBEM
                            management stations
                        ?   Leverages JMX                                      57

        With J2EE 1.2 and recently with 1.3, pretty much all architectural components that
        are considered as fundamental aspects of J2EE have been standardized. During the
        past year or so, J2EE community also has been working on tools standardization
        mainly in the areas of management, deployment, performance bench mark, and
        portability because they felt that as more and more J2EE applications and platforms
        are being deployed, these issues are increasingly becoming more important.

        So let's talk about, the J2EE Management Specification effort, JSR-77, first. The goal
        of JSR-77 is to provide server vendors and tool vendors with a standard model for
        managing the J2EE Platform.

        What are the things J2EE management is trying to address? First, management
        applications should be able to discover managed objects and then interpret the data
        collected in a standard fashion.

        Second, a single management platform should be able to manage multiple J2EE
        servers which might be from different vendors.

        Thirdly, uniform view should be presented regardless what management protocols
        are used to access the data. For example, whether data is collected using SNMP or
        WBEM, the data should be consistent.

        Finally it leverages JMX (Java Management Extension), which is an framework and
        APIs for creating Java based management agents.

                        J2EE Deployment (JSR-88) - J2EE 1.4
                              Tools                             J2EE Platforms
                               IDEs          Deployment API
                                           (Universal Remote)

                           Vendor Deploy



             Now let's talk about J2EE deployment.

             J2EE platform vendors currently implement their own proprietary
             deployment interface to their server because there is no standard
             deployment API. This makes it cumbersome for companies who need to
             deploy J2EE applications over J2EE platforms from different vendors,
             because they must run the different deploy tool for different servers.

             A standard deployment API will enable any J2EE application to be
             deployed by any deployment tool that uses the deployment APIs onto any
             J2EE compatible environment. In this sense, the standard deployment API
             functions as a universal remote control that can be used to perform the
             deployment process over multiple J2EE platforms from different vendors.


                 JMX API into              Dynamic Deployment
             the J2EE 1.4 platform


                 J2EE App Server

                                               JMX defacto

                  A single technology for the J2EE platform



                        JACC (Java Authorization Contract
                        for Containers) - J2EE 1.4
                        ?   Defines contract between J2EE
                            containers and authorization policy
                            –   Provider configuration subcontract
                            –   Policy configuration subcontract
                            –   Policy enforcement subcontract
                        ?   Enable application servers to integrate
                            with enterprise user registries and
                            authorization policy infrastructure

             JACC, Java authorization contact for containers, defines a contract
             between J2EE containers and authorization policy modules such that
             container authorization functionality can be provided as appropriate to
             suit the operational environment.

             The contract defined by JACC specification is divided into three
             subcontracts - provider configuration subcontract, policy configuration
             subcontract, policy enforcement subcontract. Taken together, these
             subcontracts describe the installation and configuration of authorization
             providers such that they will be used by containers in performing their
             access decisions.

             The end result is that now application servers are well integrated with
             enterprise user registries and authorization policy infrastructure.


                      J2EE is an End-to-End


             Now let's talk about J2EE as an end-to-end architecture. One important
             aspect of J2EE as an architecture is that it covers end-to-end. That is, it
             covers from the client tier on the left all the way to the enterprise
             information systems on the rightmost tier.


                        The J2EE Platform Architecture

                           B2C                                    Applications

                                         Application Server
                         Wireless                                   Enterprise
                        Applications                               Information


             This is somewhat simplified J2EE platform architecture. The key point in
             the picture is that regardless of who is the user of the service that is
             provided by the J2EE, that is, whether it is B2B application, or B2C
             application, or web services client, or J2ME based wireless devices, J2EE
             platform is the platform of choice for implementation because it provides
             highly scalable, highly available, highly reliable, and high performing
             implementation platform regardless of the fact that whether the services
             are exposed as web services or not.


                                 J2EE is End-to-End Solution
                                                Client      Server

                                                                          Enterprise       Information
                                                                         JavaBeans™       Systems (EIS):
                                  Client                                                    Relational
                                                            Web           Enterprise         Legacy
                                 Client                    Server         JavaBeans        Applications,
                                                                                          ERP Systems
                                                                        Other Services:
                                                                          JNDI, JMS,       Enterprise
                                           Client         Middle          JavaMail™       Information
                                            Tier           Tier                                Tier


      I mentioned that J2EE is about building n-tier, web-based enterprise applications. That is, J2EE
      provides an end-to-end architecture covering from the client tier on the left side to the middle tier
      where Web server and Application servers reside and enterprise information tier on right side
      which connects the middle tier systems to the backend enterprise information systems such as
      relational databases, and legacy applications.

      The clients can be either a full-blown Java applications or applet running inside a browser. Or
      more typically, the client could be a just regular HTML or XML browser communicating with the
      web server through HTTP. Another form of client that is getting more pervasive in an enterprise
      environment is 3rd-party application which performs B2B transaction with your application
      typically through XML. On the other side of the spectrum, the client could be wireless phones or
      cell phones with some kind of communication facilities. The clients could reside either behind the
      firewall or within the firewall. The point here is that J2EE architecture accommodate these diverse
      set of client types.

      The middle tier typically contain web servers and application servers. In actual deployment, they
      could be running in a single physical platform or on multiple platforms. In some cases where
      reliability and scalability are important, there could be multiple web servers and application
      servers. The web server receives HTTP requests from the clients and handle dynamic content
      generation through either JSP or servlet or both. The JSP or servlet can then delegate any business
      logic processing to enterprise java beans running on the application server.

      The key point here is that J2EE provides an end-to-end solution and deals with all these tiers with
      open and standard technologies.


                         N-tier J2EE Architecture

                                           Web Tier      EJB Tier


             This picture shows the same architecture in which web-tier and EJB tier are more
             clearly divided.


                       Component & Container


             OK, one of the most significant architectural characteristics of J2EE, in my
             mind, is its component and container model. So let's talk about it in a bit
             more detail.


                           J2EE Containers & Components
                            Applet Container                                  Web Container                                          EJB Container

                                 Applet                  HTTP/          JSP               Servlet                 RMI                       EJB



                                                                                     JavaMail                                               JavaMail



                                 App Client                                            JAF
                                 Container                                                                                                   JAF
                                   App      HTTP/                                J2SE
                                  Client    HTTPS


                                      J2SE                                                                                            J2SE


        This is what I call the J2EE Container & components diagram. As this diagram
        illustrates, containers and components are the key concepts of J2EE.

        As for the relationship between components and containers, as you might have
        guessed it, the components are running within containers. That is, the containers
        provides the host execution environments for the components. In this picture, the
        components are colored in green and the containers are in purple. The types of
        components within J2EE environment are
        •Client components that are running on client either as a stand-alone or applet
        • JSP or servlet as web components running inside web container
        •EJB beans as business components running inside EJB container

        And you developers are responsible for the implementation of these components. On
        the other hand, the containers are provided by the platform vendors. The containers
        provide runtime system services such as life-cycle management of the components,
        transaction coordination, persistence management, resource pooling

        The containers are also responsible for providing the enterprise APIs, shown in gold,
        and the distributed communication protocols, shown in brown.
        In a typical multi-tier, thin client enterprise application, most of the development
        effort will be focused on building web-tier components at web-tier and enterprise
        Java beans at EJB tier..

                                 Containers and Components
                                        Containers                      Components
                                         Handle                           Handle
                                    l   Concurrency                 l   Presentation
                                    l   Security                    l   Business Logic
                                    l   Availability
                                    l   Scalability
                                    l   Persistence
                                    l   Transaction
                                    l   Life-cycle
                                    l   Management

      We touched upon the roles of container and components a bit in the previous slide. Now let’s compare
      the tasks that are being performed by containers and the ones performed by components side by side. As
      we talked about in the previous slide, the platform vendors provide containers while you, as application
      developers, develop your applications in the form of components and deploy them over the containers. As
      you probably will notice, many of the tasks that the containers perform are system services that a typical
      enterprise application would need.

      First., container handles concurrency. That is, it handles concurrent access from multiple clients to your
      business component so that you don’t have to deal with it. Each platform vendor might use different
      synchronization schemes to support concurrency, however. Second, containers provide built-in security
      framework so that implementing secure applications can be a matter of configuring some options on
      authentication and access control at the time of deployment not at the time of code development. Next,
      availability and scalability. We mentioned already that platform vendors compete in their
      implementations especially in the area of availability and scalability. For example, one J2EE container
      vendor might provide high availability by maintaining session state on a persistent storage. Another
      vendor might choose to implement it in a different way.

      Persistence and transaction can be also handled by the container if you choose to do so. Or you might
      want to implement them on your own in your code, if more customized behavior is desired. Life-cycle
      management. Containers handle the creation and destruction of your component instances according to
      its own implementation scheme. Finally management and administration, some vendors might provide
      better management tool for managing and administering various resources in the container.

      So what do you have to do as developers? Very little really. You handle only presentation and focus
      majority of your development effort on building business components.


                    Containers & Components

                    ?   Containers do their work invisibly
                        – No complicated APIs
                        – They control by interposition
                    ?   Containers implement J2EE
                        – Look the same to components
                        – Vendors making the containers have great
                          freedom to innovate


             This container based architecture is the key to J2 EE’s
             simplicity and flexibility.

             It decouples the component from the container so both are
             free to handle their part of the problem in the most effective

             As the slide says, containers don’t have complicated API’s,
             they exert their control transparently.

             This gives the container vendors great flexibility to provide
             innovation that is immediately accessible to all components.


                             J2EE Application
                        Development & Deployment
                                Life Cycle


             Now let's talk about J2EE application development and deployment life
             cycle and roles involved in this life cycle


                            J2EE Application
                            Development Lifecycle
                            ?   Write and compile component code
                                –   Servlet, JSP, EJB
                            ?   Write deployment descriptors for
                                –   From Java EE 5, you can use annotations
                            ?   Assemble components into ready-to-
                                deployable package
                            ?   Deploy the package on a server

             The development life cycle of J2EE application is not that much
             different from the one of other Java application except that there are
             certain J2EE specific aspects such as deployment descriptor.

             First, as a component developer, you write and compile component
             code. The component code again can be servlet, JSP, EJB.

             Then, you a write deployment descriptor again as a component
             developer. As mentioned previously, deployment descriptor is an XML
             file that describes your J2EE components.

             Then these J2EE components will be assembled into a ready-to-
             deployable package.

             Then the package gets deployed over J2EE platform.


                                Life-cycle Illustration
                                 Creation                    Assembly                 Deployment
                                 Created by   J2EE Modules   and Augmented J2EE APP    Processed
                                 Component                   by Application            by Deployer
                                  Developer                    Assembler


                                                                           J2EE Container



             This is a bit more detailed description of the process.

             The first step is to create all the necessary business and web components. For
             example, developers build business logic components such as EJB beans. They
             might also get involved in building servlets or Java beans or custom tags of
             JSP pages. UI designers also create web pages at this stage. One important
             point here is that you don’t have to build everything yourself. That is, you
             might want to purchase 3rd-party, off-the-shelf business components instead of
             building your own. After all, that is the whole point of component technology.
             Again, this is possible because of the open and standard based component
             technologies such as EJB and J2EE.

             Next step is to assemble these business and web components into an J2EE
             application. This step is performed by an application assembler. His role is
             basically to create a package that contains all the necessary components and
             descriptors that describe those components.

             Finally this assembled application gets deployed in a operational environment
             by a deployer. The role of deployer is to take the application package that was
             assembled and then deploy it in a particular operational environment.
             Typically the deployer will set or tune configuration parameters of deployment
             descriptors in order to achieve the behavioral characteristics that is desired in
             a particular operational environment.                                                        71

                               J2EE Development Roles
                           ?   Component provider
                                –   Bean provider
                           ?   Application assembler
                           ?   Deployer
                           ?   Platform provider
                                –   Container provider
                           ?   Tools provider
                           ?   System administrator


             Roles. In the previous slide, we talked about the steps involved in building J2EE-based
             enterprise application. And along with the process, we identified a few development roles
             already. First, the component provider, or sometimes called bean provider, create business
             components. These people are Java programmers who also understand the business domain.
             I assume most of the audience here are going to play the role of component provider.

             As we talked about, an application assembler assembles business components and web
             components into a ready-to-deployable package and the deployer then deploys it in a
             particular operational environment.

             We also talked about platform vendors, who actually provides platform implementations.
             Sometimes they are called container providers. And there are many platform vendors that
             now provide both commercial or freely available versions of J2EE compliant platforms.

             There are a few more roles. Tools provider. Typically the same platform vendor will
             provide tools for development and deployment of J2EE applications. As I said before, tools
             is one area platform vendors might compete and want to differentiate themselves from the

             System administrator performs management and administration of the overall system. Again
             platform vendors might provide their own administration and management tools.


                     The Deployment Descriptor
                     ?   Gives the container instructions on how
                         to manage and control behaviors of the
                         J2EE components
                         – Transaction
                         – Security
                         – Persistence
                     ?   Allows declarative customization (as
                         opposed to programming
                         –   XML file
                     ?   Enables portability of code                    73

             We already talked about the concept of deployment descriptor.
             The concept of deployment descriptor is critical in
             understanding J2EE architecture because it is this deployment
             descriptor that enables the portability of J2EE application.

             So deployment descriptor is an XML file that specifies runtime
             instruction to the container regarding how system services are to
             be handled, for example, transaction, security, life-cycle, state
             management, persistence, and so on.

             It is called declarative customization because you are specifying
             the instruction in the XML file rather than in the code


                              J2EE Application


             Now I would like to spend sometime talking about various ways J2EE
             applications can be created. As you will see there is no single fixed way of
             developing J2EE applications. Some people think that in order to build
             J2EE application, you have to use EJB. That is not really true. Using EJB
             is just one way of building J2EE application.


                           Possible J2EE Application
                                                Web Server    EJB Server

                                                                            DB & EIS

                                  Browser       Web Server   EJB Server



        So this slide shows several different ways J2EE application can be built. Different
        forms of J2EE application can be built by combining the path between tiers.

        One of the most common forms of J2EE application is represented in combined
        red arrows. In this form, browser talks to web tier in which servlet and and JSP
        components are created and deployed and these web tier components then talk to
        EJB tier in which EJB beans are created and deployed and these EJB beans in turn
        talk to backend databases or enterprise information systems.

        Another common form is browser talks to web-tier and then the web-tier
        components talk to directly to backend databases or enterprise information
        systems. It is represented by red arrow between browser and web server and then
        dark brown arrow between web server and backend database.

        It is also possible that the client could be standalone application, which can talk to
        directly to web-tier, EJB tier, or even directly to backend databases.

        Also web tier components and EJB tier components can use components deployed
        in other web-tier or EJB tiers.

        The point of this slide is to show that there are several different ways to build J2EE

                   J2EE Application Anatomies
                   ?   4-tier J2EE applications
                       – HTML client, JSP/Servlets, EJB, JDBC/Connector
                   ?   3-tier J2EE applications
                       – HTML client, JSP/Servlets, JDBC
                   ?   3-tier J2EE applications
                       – EJB standalone applications, EJB,
                   ?   B2B Enterprise applications
                       – J2EE platform to J2EE platform through the
                         exchange of JMS or XML-based messages          76

             So this slide is just recapturing what I just said. So depending
             on how you build J2EE applications, they can be in fact in
             several different forms.


                    Which One to Use?
                    ?   Depends on several factors
                        –   Requirements of applications
                        –   Availability of EJB tier
                        –   Availability of developer resource


             Now you might want to ask which form of J2EE application
             should I build? The answer is of course “it depends”. It
             depends on the requirements of application or even non-
             technical factors such as availability of EJB tier or availability
             of developer resource.


                             J2EE 1.4
                      Standard Implementation,
                      Compatibility Suite, Brand


             Now let's talk other aspects of J2EE, reference implementation,
             compatibility test suite, and J2EE branding.


                 Standard Implementation
                 ?   Under J2EE 1.4 SDK, it is Sun Java
                     Application Server Platform Edition 8
                 ?   Production-quality J2EE 1.4 compliant
                     app server
                 ?   Free to develop and free to deploy
                 ?   Seamless upgrade path to Sun Java
                     Application Server Enterprise Edition




                          Compatibility Test Suite (CTS)
                          ?   Ultimate Java™ technology mission:
                              –   Write Once, Run Anywhere™
                              –   My Java-based application runs on any
                                  compatible Java virtual machines
                              –   My J2EE based technology-based
                                  application will run on any J2EE based
                                  Compatible platforms


             Compatibility test suite. The idea is simple. Just like any JVM has to go
             through quite a bit of compatibility testing to make sure “write once and run
             anywhere” Java paradigm works, any platform that wants to be stamped with
             “J2EE compliance” has to pass the J2EE compatibility test suite. This in turn
             ensures the portability of your applications over any J2EE compliant platforms.


                        J2EE Application Verification Kit
                        (J2EE AVK)
                        ?   How can I test my J2EE application
                            •   Obtain the J2EE RI 1.3.1 and the J2EE
                                Application Verification Kit (J2EE AVK)
                        ?   Self verification of application
                            –   Static verification
                            –   Dynamic verification
                        ?   Obtain the tests results, verify that all
                            criteria are met

             Another very important development in J2EE community is making sure
             J2EE applications are in fact portable over various J2EE compliant

             The reason this is important is that the reality has been that J2EE platform
             vendors provide various extensions as product differentiator in a sense at
             the expense of the portability of the applications.

             Now you have a way to verify if an application you are writing is in fact
             bit by bit portable by running them with J2EE application verification kit
             along with J2EE reference implementation.


                         Compatible Products
                         for the J2EE Platform (Brand)
                           ATG               iPlanet
                           Bea Systems       Macromedia
                           Borland           NEC
                           Computer          Oracle
                             Associates      Pramati
                           Fujitsu           SilverStream
                           Hitachi           Sybase
                           HP                Talarian
                          IBM                Trifork

             There are the list of J2EE vendors as of March 2002.

             Many of these products are application servers, but tools vendors such as
             TogetherSoft, WebGain, and Borland have also made the commitment to
             J2EE compatibility. With their experience in modeling and Rapid
             Application Development, these vendors will help make developing J2EE
             applications easier and faster.

             Again, this is what J2EE branding is all about. We believe having J2EE
             branding give customers of J2EE products high-level of assurance of
             quality and compatibility.


                       The J2EE Platform “Ecosystem,”
                       Application Servers and…
                        ?   Tools
                            –   IDE’s: Borland JBuilder Enterprise, WebGain
                                Visual Cafe’, IBM Visual Age for Java™, Forte™
                                for Java™, Oracle JDeveloper, Macromedia Kawa
                            –   Modeling, Performance, Testing, etc.
                        ?   Enterprise Integration: Connectors,
                            Java Message Service (JMS) API, XML
                        ?   Components
                        ?   Frameworks
                        ?   Applications

             So J2EE community itself built an ecosystem in which many different
             commercial vendors, open source community, and individual developers
             are working together to develop many different parts of J2EE starting
             from application servers and then tools, connectors, components, and
             frameworks, and finally applications, and so on. And I believe this
             ecosystem is only possible because of openness of J2EE.


                          Major Investment in
                          Compatibility by the Industry
                         ?   Sun has spent scores of engineer years
                             developing tests
                         ?   Licensees have spent scores of engineer
                             years passing the tests
                         ?   Testing investment on top of specification
                             investment, implementation investment,
                             business investments
                         ?   In total, tens of millions of dollars invested in
                             J2EE platform compatibility by the industry

             As mentioned before, ensuring compatibility among J2EE products is
             important. This slides lists a few important investments that J2EE
             community as a whole has made to ensure the compatibility.

             First, Sun invested huge amount of its engineering resource to create
             compatibility test kit. And licensees also spent scores of their engineering
             years to make sure their products are J2EE compliant.

             Overall, the investment dollars for ensuring the J2EE compatibility by the
             J2EE community and industry is something that is not talked about that
             much but that is really a hidden value proposition to many J2EE


              J2EE Blueprint &
             Pet Store Application



                             J2EE Blueprint
                         ?   Best practice guidelines, design patterns
                             and design principles
                              –   MVC pattern
                         ?   Covers all tiers
                              –   Client tier
                              –   Web tier
                              –   Business logic (EJB) tier
                              –   Database access tier
                         ?   Sample codes come with J2EE 1.4 SDK
                              –   Java Pet Store, Adventure builder

        Now J2EE Blueprints. In addition to the customary trio of specifications: reference
        implementation and compatibility test suite, J2EE comes with something called
        blueprints. This is something unique about J2EE.

        Blueprint specifies the best practice guidelines, design patterns and design principles
        that will help you to build production-quality enterprise applications . And one of the
        design patterns it talks about is so-called MVC pattern, which stands for Model,
        View, and Controller pattern.

        Blueprint covers all the tiers including client-tier, web-tier, business logic-tier, and
        database access tier. And on each tier, it describes several design options along with
        their their pros and cons. For example, on the client tier, it talks about a variety of
        client types and their pros and cons. On the web tier, it talked about the most
        effective way of using servlet and JSP. On the business logic tier, it talks about
        when to use session beans and when to use entity beans and how they can be used
        together in order to achieve the desired application behavior. On the database access
        tier, it introduces concepts such as Value objects and Data Access Objects (DAO) as
        optimization techniques.

        It also comes with a sample e-commerce application called Java Pet Store which
        demonstrates and exercises the design guidelines that are described in the

                                  Why J2EE
                              for Web Services?


             So far we have talked about what is J2EE and why J2EE is the platform of
             choice for development and deployment of web-based, multi-tier,
             transactional, component-based enterprise applications. Now let's talk
             about why we believe J2EE is the best platform for the development and
             deployment of web services.


                           Why J2EE for Web Services?
                           ?   Web services is just one of many
                               service delivery channels of J2EE
                               –   No architectural change is required
                               –   Existing J2EE components can be easily
                                   exposed as Web services
                           ?   Many benefits of J2EE are preserved
                               for Web services
                               –   Portability, Scalability, Reliability
                               –   No single-vendor lock-in

        Now, let's talk about the motivation for using J2EE as development and deployment
        platform for web services.

        As most of you already know, J2EE is an open standard platform for building enterprise
        applications in which business logic are captured and deployed as components. J2EE is
        also an end-to-end architecture where there are multiple programming models to
        implement and deploy these business logic. That is, there is servlet, there is JSP, there are
        EJB beans, and there is JMS. All these programming models provide somewhat different
        ways of implementing and deploying business logic over J2EE and you as developers
        choose one ore more of these programming models according to the needs and
        requirements of your applications.

        Now if you think about it, web services model is just another way of exposing the
        business logic of these components. What this means is there is no architectural or code
        change required to expose the existing J2EE components as web services . For example,
        as a service provider, in addition to exposing business functions captured in EJB beans
        by EJB remote interface over RMI/IIOP, you can also expose them via WSDL and handle
        the service by receiving SOAP message and send the result back in SOAP messages.

        What it means is that the existing J2EE components can be exposed as web services
        without any change in their code which also means the key benefits of J2EE such as open
        and standard platform, portability of code, availability of highly scalable and highly
        reliable platform products, are still preserved. And most of all, you can still choose the
        best of breed J2EE platform or J2EE applications including web services components
        without compromising the code portability.                                           88

                          Web Services Model Over J2EE
                              Rich Clients     J2EE Server JSP™/ JavaServlet API / EJB™

                                                                     JSP         JDBC

                          MIDP               XMLP/SOAP
                                                                     EJB                     Apps

                               Browsers                  XMLP/SOAP



             This picture shows how Web services model is supported over J2EE
             platform. The implementation of web services will leverage the existing
             programming models such as servlet and EJB. On the J2EE platform, the
             Java APIs for web services, for example, JAX-RPC and JAXM will
             enable SOAP based communication with various types of clients
             including J2ME-enabled devices and standalone applications.


                          Where Are We Now?
                          ?   Java APIs for Web Services are being
                              developed very rapidly
                              •   Web services support on WUST (WSDL, UDDI,
                                  SOAP) ready now
                              •   Next layer Web services work in progress
                          ?   Tools are available now for exposing existing
                              J2EE components as Web services
                          ?   J2EE community has defined overall
                              framework for Web Services (J2EE 1.4, Web
                              services for J2EE)

        So J2EE has proved itself as the platform of choice for building enterprise applications.
        Now what about web services? Where are we now and where are we going in terms of
        using J2EE as Web services platform?

        As many of you already know, Java community is feverishly working on defining Java
        APIs for web services. And THE primary platform that these Java APIs are designed
        for is J2EE. At this point, Web services based on WUST trio, SOAP, WSDL, UDDI are
        well supported. And the next layer of web services stack are being worked on right
        now. And we will talk about those Java APIs for web services later on in this session.

        Tool vendors already have products out there that you can use to expose existing J2EE
        components such as EJBs as web services by basically providing a tool that can
        generate WSDL document from those EJB beans and from the WSDL, a client stub can
        be generated which knows how to send and receive SOAP messages in order to use the
        service defined in WSDL. So you can expose business functions that you already have
        in J2EE as web services right now.

        Finally J2EE community is in the works to define overall Web services framework for
        J2EE through J2EE 1.4 and JSR 109 for the sake of portability of Web services. And we
        will talk about this in detail in the rest of this session.


                          Design Goals J2EE 1.4 Web
                          Services Framework
                          ?   Portability of Web services component
                              –   Over different vendor platform
                              –   Over different operational environment
                          ?   Leveraging existing J2EE programming
                              models for service implementation
                          ?   Easy to program and deploy
                              –   High-level Java APIs
                              –   Use existing deployment model

        So what are the design goals of J2EE web services framework?
        I already explained the container and component model of J2EE. And one of the
        benefits of building application as components is its portability. And the same benefit
        applies to web services as well. That is, the web services components will be portable
        over different vendor platforms as well as different operational environments in the
        same way other J2EE components such as EJBs, JSP and servlets are portable over
        different vendor platforms and different operational environments.

        Another important goal is that the existing J2EE programming models such as EJBs and
        servlets or message driven beans should be leveraged for service implementation.

        Next, we want to make sure that building and deploying web services is easy. What that
        means is that programmers will be able to use high-level Java APIs for building web
        services instead of dealing with low-level plumbings and the existing deployment
        model such as based on deployment descriptor will be used for web services component
        as well.


                      J2EE 1.4 Web Services Framework
                      ?   J2EE 1.4 (JSR 151)
                      ?   Web services for J2EE (JSR 109)
                      ?   JAX-RPC (JSR 101)
                      ?   JAXR (Java API for XML Registries)
                      ?   SAAJ (SOAP with Attachments API for
                      ?   EJB 2.1

             So J2EE 1.4 provides the umbrella framework for web services in which various
             individual web services related work are combined to provide well-integrated
             web services support for J2EE.

             And those individual web services initiative include Web services for J2EE effort,
             JSR 109, JAX-RPC, SAAJ, JAXR, EJB 2.1, and Connector Architecture 1.5 for
             providing JAXM provider as one of the provider.


                             How to Get Started


             OK, we have talked about J2EE until now more from concept and
             architecture perspective. So now let's talk about how you can get started
             with J2EE.


                         Step1: For Beginners and
                         Intermediate J2EE Programmers
                          ?   Follow along with this course
                          ?   Start using J2EE IDE of your choice
                          ?   Try open source IDE's
                              –   NetBeans IDE 5.0 (
                                   ? Excellent out of the box J2EE support

                                   ? We will use NetBeans IDE 5.0 or NetBeans IDE 5.5

                                     as our default IDE in this course
                                   ?   Lots of tutorials
                              –   Eclipse

             Once you get to a point where you feel comfortable with building basic J2EE
             application leveraging all the programming models that are available in the
             architecture, you can try to use commercially or freely available J2EE IDE's.
             Sun has Sun ONE Studio 4 Enterprise Edition (EE), which is downloadable for
             60 day free trial. Sun ONE Studio site also has a bunch of sample applications
             you can play around. You are also welcome to try other vendors' tools.


                          Step2: Next Step (For Advanced
                          J2EE Programmers)
                          ?   Learn practical open-source solutions
                              –   Spring framework (for light-weight framework)
                              –   Hibernate (for O/R mapping)
                              –   JDO (for transparent persistence)
                              –   Struts, WebWork, Tapestry (for Web-tier
                              –   JUnit (for unit testing)
                              –   Log4j (for logging)
                              –   Many more

             There are several useful open-source solutions for building production quality
             J2EE applications. Examples include Spring framework for light-weight
             framework, Hibernamte for object to relational database mapping, JDO for
             transparent persistence, Struts/WebWor/Tapestry for web-tier frameworks,
             Junit for unit testing, and Log4j for logging.


                         Step3: Next Step (For Advanced
                         J2EE Programmers)
                         ?   There is no shortage of quality J2EE
                             online resources


             Once you become a J2EE programmer, there is no shortage of resources that
             you can leverage to further enhance your J2EE knowledge. One good site is
   , which is a very popular J2EE knowledge website.


             Summary &



             ?   J2EE is the platform of choice for
                 development and deployment of n-tier,
                 web-based, transactional, component-
                 based enterprise applications
             ?   J2EE is standard-based architecture
             ?   J2EE is all about community
             ?   J2EE evolves according to the needs
                 of the industry



             ?   J2EE Home page
             ?   J2EE 1.4 SDK
             ?   J2EE 1.4 Tutorial
             ?   J2EE Blueprints



             NetBeans Resources
             ?   NetBeans IDE Homesite
             ?   NetBeans IDE Tutorials/Articles
                 Master index







To top