J2ee Overview

03/19/2007

Introduction to Java EE (J2EE) 1

.

1

03/19/2007

Session Objectives ?

?

?

Understanding the value propositions of J2EE 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 2

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 applications. 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 services.

2

03/19/2007

Agenda ? ?

? ? ? ?

? ? ?

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

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.

3

03/19/2007

What is J2EE?

4

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

4

03/19/2007

Enterprise Computing Challenges Portability Diverse Environments Time-to-market Core Competence Assembly Integration

Key Technologies J2SE™ J2EE™ JMS Servlet JSP Connector XML Data Binding XSLT

Products App Servers Web Servers Components Databases Object to DB tools

Legacy Systems Databases TP Monitors EIS Systems 5

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 requirements. 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 architecture? These are all valid questions and issues of enterprise computing today. The good news is J2EE is specifically designed to address all these issues.

5

03/19/2007

What Is the J2EE? l

l l

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

6

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.

6

03/19/2007

The Java™ Platform

Java Technology Enabled Devices

Java Technology Enabled Desktop

Workgroup Server

High-End Server

7

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 secure. Also note that the “Enterprise Edition” box in the graphic extends into the standard edition, that is, Enterprise edition is built over standard edition.

7

03/19/2007

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

Optional Packages

Optional Packages

Java 2 Enterprise Edition (J2EE)

Java 2 Standard Edition (J2SE)

Personal Basis Profile

JVM

Personal Profile

Foundation Profile

MIDP

CDC

CLDC KVM * Under development in JCP

Java Card APIs CardVM

8

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.

8

03/19/2007

What Makes Up J2EE? ? ? ?

? ? ? ?

API and Technology specifications Development and Deployment Platform Standard and production-quality implementation Compatibility Test Suite (CTS) J2EE brand J2EE Blueprints Sample codes 9

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.

9

03/19/2007

Evolution of Enterprise Application Frameworks 10

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.

10

03/19/2007

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 11

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.

11

03/19/2007

About Enterprise Applications ?

Things that make up an enterprise application – – – –

?

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 12

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 services. 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.

12

03/19/2007

Single Tier (Mainframe-based)

?

?

?

Dumb terminals are directly connected to mainframe Centralized model (as opposed distributed model) 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.

13

03/19/2007

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

14

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.

14

03/19/2007

Two-Tier SQL request SQL response

?

Fat clients talking to back end database –

?

Database

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 terminals. 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.

15

03/19/2007

Two-Tier ?

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 16

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.

16

03/19/2007

Three-Tier (RPC based) RPC request RPC response

?

SQL response

Database

Thinner client: business & data model separated from presentation –

?

SQL request

Business logic and data access logic reside in middle tier server while client handles presentation

Middle tier server is now required to handle system services –

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

03/19/2007

Three-tier (RPC based): Pros & Cons ?

Pro: –

Business logic can change more flexibly than 2tier 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 tightlycoupled (than the three-tier object based model) Code is not really reusable (compared to object model based) 18

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.

18

03/19/2007

Three-Tier (Remote Object based) Object request Object response

?

SQL request SQL response

Database

Business logic and data model captured in objects – Business logic and data model are now described in “abstraction” (interface language)

?

Object models used: CORBA, RMI, DCOM – –

Interface language in CORBA is IDL Interface language in RMI is Java interface

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.

19

03/19/2007

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 addressed

20

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.

20

03/19/2007

Three-Tier (Web Server) HTML request HTML response

? ? ?

WEB Server

SQL request SQL response

Database

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) 21

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 system.

21

03/19/2007

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 addressed 22

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.

22

03/19/2007

Trends ?

?

?

Moving from single-tier or two-tier to multitier architecture Moving from monolithic model to objectbased application model Moving from application-based client to HTML-based client

23

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.

23

03/19/2007

Single-tier vs. Multi-tier Single tier l

l

No separation among presentation, business logic, database Hard to maintain

Multi-tier l

l

Separation among presentation, business logic, database More flexible to change, i.e. presentation can change without affecting other tiers

24

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.

24

03/19/2007

Monolithic vs. Object-based Monolithic l l

1 Binary file Recompiled, relinked, redeployed every time there is a change

Object-based l l l

l l

l

Pluggable parts Reusable Enables better design Easier update Implementation can be separated from interface Only interface is published

25

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.

25

03/19/2007

Outstanding Issues & Solution ? ?

Comlexity at the middle tier server still remains Duplicate system services still need to be provided for the majority of enterprise applications – – –

?

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 26

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.

26

03/19/2007

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 lock-in Example: Tuxedo, .NET 27

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.

27

03/19/2007

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

28

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 industry-standard. 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 architecture.

28

03/19/2007

Why J2EE?

29

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.

29

03/19/2007

Platform Value to Developers ?

Can use any J2EE implementation for development and deployment – –

?

Vast amount of J2EE community resources –

?

Use production-quality standard implementation which is free for development/deployment Use high-end commercial J2EE products for scalability and fault-tolerance 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 components 30

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 money.

30

03/19/2007

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 31

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.

31

03/19/2007

Platform Value to Business Customers ? ?

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 32

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

32

03/19/2007

J2EE APIs & Technologies 33

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.

33

03/19/2007

J2EE 1.4 APIs and Technologies ? ? ?

? ? ? ? ?

J2SE 1.4 (improved) JAX-RPC (new) Web Service for J2EE J2EE Management J2EE Deployment JMX 1.1 JMS 1.1 JTA 1.0

? ? ? ? ? ? ? ? ?

Servlet 2.4 JSP 2.0 EJB 2.1 JAXR Connector 1.5 JACC JAXP 1.2 JavaMail 1.3 JAF 1.0 34

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.

34

03/19/2007

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 35

35

03/19/2007

Servlet & JSP (JavaServer Pages) 36

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

36

03/19/2007

What is a Servlet? ?

? ?

Java ™ objects which extend the functionality of a HTTP server Dynamic contents generation Better alternative to CGI, NSAPI, ISAPI, etc. – – – –

Efficient Platform and server independent Session management Java-based 37

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 standardbased, 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.

37

03/19/2007

Servlet vs. CGI Request RequestCGI1 CGI1 Request RequestCGI2 CGI2 Request RequestCGI1 CGI1 Request RequestServlet1 Servlet1 Request RequestServlet2 Servlet2 Request Servlet1

Child Childfor forCGI1 CGI1

CGI CGI Based Based Webserver Webserver

Child Childfor forCGI2 CGI2 Child Childfor forCGI1 CGI1

Servlet ServletBased BasedWebserver Webserver JVM JVM

Servlet1 Servlet1 Servlet2 Servlet2

38

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.

38

03/19/2007

What is JSP Technology? ?

Enables separation of business logic from presentation – – –

? ?

Presentation is in the form of HTML or XML/XSLT Business logic is implemented asJava Beans or custom tags Better maintainability, reusability

Extensible via custom tags Builds on Servlet technology 39

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

03/19/2007

EJB (Enterprise Java Beans) 40

40

03/19/2007

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, …

41

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.

41

03/19/2007

Why EJB Technology? ?

?

Leverages the benefits of component-model on the server side Separates business logic from system code –

?

Provides framework for portable components – –

?

Container provides system services Over different J2EE-compliant servers Over different operational environments

Enables deployment-time configuration –

Deployment descriptor 42

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.

42

03/19/2007

EJB Architecture

43

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

03/19/2007

Enterprise JavaBeans Enterprise JavaBeans

Synchronous communication Session Bean

Stateless

Entity Bean

Asynchronous communication Message-Driven Bean

Stateful

Bean managed Persistence (BMP)

Container managed Persistence (CMP)

44

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.

44

03/19/2007

JMS (Java Message Service) 45

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.

45

03/19/2007

Java Message Service (JMS) ?

Messaging systems (MOM) provide – – –

?

Benefits of Messaging systems –

? ?

De-coupled communication Asynchronous communication Plays a role of centralized post office Flexible, Reliable, Scalable communication systems

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.

46

03/19/2007

Connector Architecture 47

47

03/19/2007

Connector Architecture ?

Defines standard API for integrating J2EE technology with EIS systems –

?

Before Connector architecture, each App server has to provide an proprietary adaptor for each EIS system –

?

CICS, SAP, PeopleSoft, etc.

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) Adaptors 48

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 J2EE compliant application servers.

48

03/19/2007

m x n Problem Before Connector Architecture m

n

App Server1

SAP

App Server2

EIS 2

App Server3

EIS3

App Server

EIS4

49

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.

49

03/19/2007

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

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.

50

03/19/2007

JAAS: Authentication ?

Pluggable authentication framework – – – –

?

Userid/password Smartcard Kerberos Biometric

Application portability regardless of authentication schemes underneath – –

JAAS provides authentication scheme independent API Authentication schemes are specified Login configuration file, which will be read by JAAS

51

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 authentication. 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.

51

03/19/2007

JAAS Pluggable Authentication

52

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.

52

03/19/2007

JAAS: Authorization ?

Without JAAS, Java platform security are based on – –

?

The JAAS API augments this with –

?

Where the code originated Who signed the code Who’s running the code

User-based authorization is now possible 53

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.

53

03/19/2007

Other J2EE APIs & Technologies 54

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

54

03/19/2007

JNDI ? ?

Java Naming and Directory Interface Utilized by J2EE applications to locate resources and objects in portable fashion – –

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 deployed. 55

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.

55

03/19/2007

JDBC ?

Provides standard Java programming API to relational database –

?

Uses SQL

Vendors provide JDBC compliant driver which can be invoked via standard Java programming API

56

56

03/19/2007

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 vendors 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.

57

03/19/2007

J2EE Deployment (JSR-88) - J2EE 1.4 Tools IDEs

Standard Deployment API (Universal Remote)

J2EE Platforms

Vendor Deploy Tools

Management Tools 58

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.

58

03/19/2007

JMX JMX API into the J2EE 1.4 platform

Dynamic Deployment

JMX JMX App J2EE App Server

JMX defacto

A single technology for the J2EE platform 59

59

03/19/2007

JACC (Java Authorization Contract for Containers) - J2EE 1.4 ?

?

Defines contract between J2EE containers and authorization policy modules –

Provider configuration subcontract

–

Policy configuration subcontract

–

Policy enforcement subcontract

Enable application servers to integrate with enterprise user registries and authorization policy infrastructure 60

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.

60

03/19/2007

J2EE is an End-to-End Architecture 61

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.

61

03/19/2007

The J2EE Platform Architecture B2B Applications Existing Applications

B2C Applications

Web Services

Application Server Wireless Applications

Enterprise Information Systems 62

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.

62

03/19/2007

J2EE is End-to-End Solution Firewall Client

J2EE Application Server Enterprise JavaBeans™

Client

Enterprise Information Systems (EIS): Relational Database,

Client

Web Server JSP, Servlets

Client Client HTML/XML

Client Tier

Middle Tier

Enterprise JavaBeans

Legacy Applications, ERP Systems

Other Services: JNDI, JMS, JavaMail™

Enterprise Information Tier 63

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.

63

03/19/2007

N-tier J2EE Architecture

Web Tier

EJB Tier

64

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

64

03/19/2007

J2EE Component & Container Architecture 65

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.

65

03/19/2007

J2EE Containers & Components

JavaMail JAF

JDBC

JAF

JTA

JavaMail

EJB

JMS

JTA

JMS

App Client Container App HTTP/ Client HTTPS

JNDI

J2SE

RMI

RMI/IIOP

Servlet

JSP

JNDI

HTTP/ HTTPS

EJB Container

JDBC

Applet

Web Container

RMI/IIOP

Applet Container

J2SE

J2SE

JDBC

RMI/IIOP

JMS

JNDI

RMI

J2SE

Database 66

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..

66

03/19/2007

Containers and Components Containers Handle l l l l l l l

l

Concurrency Security Availability Scalability Persistence Transaction Life-cycle management Management

Components Handle l l

Presentation Business Logic

67

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.

67

03/19/2007

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 68

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 way. 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.

68

03/19/2007

J2EE Application Development & Deployment Life Cycle 69

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

69

03/19/2007

J2EE Application Development Lifecycle ?

Write and compile component code –

?

Write deployment descriptors for components –

?

?

Servlet, JSP, EJB

From Java EE 5, you can use annotations

Assemble components into ready-todeployable package Deploy the package on a server 70

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-todeployable package. Then the package gets deployed over J2EE platform.

70

03/19/2007

Life-cycle Illustration Creation Created by Component Developer

Assembly J2EE Modules

Deployment

Assembled and Augmented J2EE APP by Application Assembler

Processed by Deployer Deploy

J2EE Container

Enterprise Components

71

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

03/19/2007

J2EE Development Roles ?

Component provider –

? ? ?

Application assembler Deployer Platform provider –

? ?

Bean provider

Container provider

Tools provider System administrator 72

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 others. System administrator performs management and administration of the overall system. Again platform vendors might provide their own administration and management tools.

72

03/19/2007

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 customization) –

?

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

73

03/19/2007

J2EE Application Anatomies 74

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.

74

03/19/2007

Possible J2EE Application Anatomies Web Server

EJB Server

DB & EIS Resources

Browser

Web Server

EJB Server

Stand-alone

75

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 applications.

75

03/19/2007

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, JDBC/Connector

?

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.

76

03/19/2007

Which One to Use? ?

Depends on several factors –

Requirements of applications

–

Availability of EJB tier

–

Availability of developer resource

77

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 nontechnical factors such as availability of EJB tier or availability of developer resource.

77

03/19/2007

J2EE 1.4 Standard Implementation, Compatibility Suite, Brand 78

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

78

03/19/2007

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

79

N

79

03/19/2007

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

80

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.

80

03/19/2007

J2EE Application Verification Kit (J2EE AVK) ?

How can I test my J2EE application portability? •

?

Self verification of application – –

?

Obtain the J2EE RI 1.3.1 and the J2EE Application Verification Kit (J2EE AVK) Static verification Dynamic verification

Obtain the tests results, verify that all criteria are met 81

Another very important development in J2EE community is making sure J2EE applications are in fact portable over various J2EE compliant platforms. 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.

81

03/19/2007

Compatible Products for the J2EE Platform (Brand) ATG Bea Systems Borland Computer Associates Fujitsu Hitachi HP IBM IONA

iPlanet Macromedia NEC Oracle Pramati SilverStream Sybase Talarian Trifork 82

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.

82

03/19/2007

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 83

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.

83

03/19/2007

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 84

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 customers.

84

03/19/2007

J2EE Blueprint & Pet Store Application

85

85

03/19/2007

J2EE Blueprint ?

Best practice guidelines, design patterns and design principles –

?

Covers all tiers – – – –

?

MVC pattern Client tier Web tier Business logic (EJB) tier Database access tier

Sample codes come with J2EE 1.4 SDK –

Java Pet Store, Adventure builder 86

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 documentation.

86

03/19/2007

Why J2EE for Web Services? 87

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.

87

03/19/2007

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 88

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

03/19/2007

Web Services Model Over J2EE Rich Clients

J2EE Server JSP™/ JavaServlet API / EJB™ XMLP/SOAP

JSP MIDP Devices

DBMS

XMLP/SOAP XHTML/WML

EJB

HTML/XML

Browsers

JDBC

JMS Connectors

Existing Existing Apps Apps

XMLP/SOAP

Services 89

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.

89

03/19/2007

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) 90

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.

90

03/19/2007

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 91

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.

91

03/19/2007

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 Java)

?

EJB 2.1 92

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.

92

03/19/2007

How to Get Started

93

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.

93

03/19/2007

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 (netbeans.org) ? 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 94

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.

94

03/19/2007

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 frameworks) JUnit (for unit testing) Log4j (for logging) Many more 95

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.

95

03/19/2007

Step3: Next Step (For Advanced J2EE Programmers) ?

There is no shortage of quality J2EE online resources – – –

java.sun.com/j2ee www.theserverside.com www.javapassion.com/j2ee/J2EEresources.html#J2 EEResourceSites

96

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 www.theserverside.com, which is a very popular J2EE knowledge website.

96

03/19/2007

Summary & Resources 97

97

03/19/2007

Summary ?

? ? ?

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

98

03/19/2007

Resources ?

J2EE Home page –

?

J2EE 1.4 SDK –

?

java.sun.com/j2ee/1.4/download.html#appserv

J2EE 1.4 Tutorial –

?

java.sun.com/j2ee

java.sun.com/j2ee/1.4/download.html#appserv

J2EE Blueprints –

java.sun.com/blueprints/enterprise/index.html 99

99

03/19/2007

NetBeans Resources ?

NetBeans IDE Homesite –

?

http://www.netbeans.org

NetBeans IDE Tutorials/Articles Master index –

http://www.javapassion.com/netbeans /masterindex.html

100

100

03/19/2007

Passion! 101

.

101