J2EE Platform Architecture: An End-to-End Solution for Building Enterprise Applications, Slides of Java Programming

Download J2EE Platform Architecture: An End-to-End Solution for Building Enterprise Applications and more Slides Java Programming in PDF only on Docsity!

52 cs420Fall 2010

J2EE is an end to end

Architecture

J2EE Platform Architecture

53 cs420 Fall 2010

B2B Applications

B2C Applications

Web Services

Wireless Applications

Application Server Enterprise Information Systems

Existing Applications

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.

N-tier J2EE Architecture

55 cs420 Fall 2010

Web Tier EJB Tier

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

J2EE Containers and

Components

Fall 2010 cs420 56

58 cs420 Fall 2010

Components

Handle

z Concurrency z Security z Availability z Scalability z Persistence z Transaction z Life-cycle management z Management

z Presentation z Business Logic

Containers

Handle

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

59 cs420 Fall 2010

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

J2EE Application Development Lifecycle

61 cs420 Fall 2010

Write and compile component code Servlet, JSP, EJB Write deployment descriptors for components 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

62 cs420 Fall 2010

Creation Assembly Deployment Created by Component Developer

Assembled and Augmentedby Application Assembler

Processed by Deployer Deploy

Enterprise Components

J2EE Container

J2EE Modules J2EE APP

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.

The Deployment Descriptor

64 cs420 Fall 2010

` 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

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 Anatomies

Fall 2010 cs420 65

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.