Distributed Information Systems Lecture 16 - JavaEEArchitectures, Lecture notes of Computers and Information technologies

Download Distributed Information Systems Lecture 16 - JavaEEArchitectures and more Lecture notes Computers and Information technologies in PDF only on Docsity!

Java EE Application

Architectures

Dr Liz Bacon

Java EE Architectures (1)

-^

Ref:

http://java.sun.com/javaee/5/docs/tutorial/doc/

-^

Java EE is designed to support applications thatimplement enterprise services for customers,employees, suppliers etc. who make demandson, or contributions to, the enterprise.

-^

These applications are inherently complex,potentially accessing data from a variety ofsources and distributing applications to a varietyof clients.

-^

To better control and manage theseapplications, the business functions to supportthese various users are conducted in the

middle

tier.

Java EE Architectures (3)

•^

Designing a system is complex and will involve manyparties e.g. managers, architects, designers,programmers, testers, and database experts.

-^

These architectures are typically defined using an object-oriented software development process e.g. RUP usingUML, Extreme Programming.

-^

Java EE does not typically get involved in the earlystages of developing a functional requirements spec orobject-oriented analysis.

-^

The focus of this lecture is on application architecturerather than the Enterprise wide architecture which couldalso include hardware and networking requirements etc.

EJB Architecture

-^

The Java EE application environment includesmany technologies such as JavaServer Pagesand Servlets but the heart of a Java EEapplication is Enterprise JavaBeans (EJB).

-^

The Enterprise JavaBeans architecture is:^ – Component architecture– Used for the development of component-based

distributed applications

• Scalable– Transactional– Multi-user secure– Can be written once and deployed on any server

platform that supports the Java EE specification.

Tiers

•^

Java EE adopts a layered approach to structuringapplications called Tiers. This helps reduce couplingbetween different parts of the system and improvemaintainability.

-^

Note that interaction should only occur between adjacentlayers.

-^

So how many layers or tiers should we have? There isno absolute right and wrong, but most designs have atleast a client tier and a business tier.

-^

Java EE multi-tiered applications and are typicallydistributed over three locations:^ – The client machines– The Java EE server machine– The database or legacy machines at the back end.

Allocation of Tiers to Machines

Web Components

• These are typically either servlets or JSP

pages and can include HTML pages

Business Components

• Business code - logic that solves or meets

the needs of a particular business domainsuch as banking

• Are handled by enterprise beans running

in the business tier

Client, Web, Business and EIS Tiers

Container Types and Machines

Container Services

•^

Containers

are the interface between a component and

the low-level platform-specific functionality that supportsthe component.

-^

In order to run, a component must be assembled into amodule and deployed to its container.

-^

The container also manages non-configurable servicessuch as enterprise bean and servlet life cycles, databaseconnection resource pooling, data persistence, andaccess to the Java EE platform APIs

-^

The assembly process involves specifying containersecurity and transaction management services needed.

J2EE Design Patterns

• There are 21 J2EE patterns:

• 15 in the original design, see

http://java.sun.com/blueprints/corej2eepattern s/Patterns/index.html

for details

• Details of the other 6 newer patterns can be

found at: http://java.sun.com/developer/technicalArticle s/J2EE/J2EEevolution/

The Front Controller Design Pattern

-^

In the web tier, the system has to generate lots of webpages and receive requests from lots of web users.

-^

If the processing is not undertaken centrally then there isno single point for e.g. authenticating that a user isallowed to access the page they have requested.

-^

This would result in duplicate code as each page takesresponsibility to do the check itself.

-^

Navigating from one view to another will also generatespaghetti like code as pages forward queries to eachother which will be difficult to maintain.

-^

The Front Controller pattern proposes centralized accesspoint for all web page requests to manage systemservices, content retrieval, view management, andnavigation.

Intercepting Filter Pattern (1)

-^

When a request enters a Web application, itoften must pass several entrance tests prior tothe main processing stage. For example,^ – Has the client been authenticated?– Does the client have a valid session?– Is the client's IP address from a trusted network?– Does the request path violate any constraints?– What encoding does the client use to send the data?– Do we support the browser type of the client?

Intercepting Filter Pattern (2)

•^

Some of these checks are tests, resulting in a yes or noanswer that determines whether processing willcontinue.

-^

Other checks manipulate the incoming data stream intoa form suitable for processing.

-^

Solution is to create pluggable filters to process commonservices in a standard manner without requiring changesto core request processing code.

-^

The filters intercept incoming requests and outgoingresponses, allowing pre-processing and post-processing.

-^

We are able to add and remove these filtersunobtrusively, without requiring changes to our existingcode.