Plan 1. Application Servers 2. Servlets, JSP, JDBC 3. J2EE: Vue - - PowerPoint PPT Presentation

Department of Informatics

Plan

• 1. Application Servers
• 2. Servlets, JSP, JDBC
• 3. J2EE: Vue d’ensemble
• 4. Distributed Programming
• 5. Enterprise JavaBeans
• 6. Prise de recul critique

Department of Informatics

J2EE: Vue d'ensemble

• 1. Repositionnement de la plateforme

Java

• 2. Vue d'ensemble de J2EE
• 3. Services garantis par J2EE
• 4. Relation avec EJB
• 5. Déploiement XML
• 3. J2EE: Vue d'ensemble

Department of Informatics

Java 2 Platform

Java 2 Platform, Micro Edition (J2ME)

For consumer devices, small memory devices like

smartcards, pagers, handhelds, cellular phones,…

Java 2 Platform, Standard Edition (J2SE)

Contains the J2SDK (Software Development Kit)

and the J2RE (Java Runtime Environment)

Programming platform aimed at networked-

• riented enterprise applications

Java 2 Platform, Enterprise Edition (J2EE)

For multi-tier server-oriented enterprise

applications

• 3. J2EE: Vue d'ensemble

3.1 Repositionnement de la plateforme Java

Department of Informatics

J2EE: Vue d’ensemble

• 3. J2EE: Vue d'ensemble

3.2 Vue d'ensemble de J2EE

Department of Informatics

Architecture J2EE

• 3. J2EE: Vue d'ensemble

3.2 Vue d'ensemble de J2EE

Department of Informatics

Services standards garantis par J2EE

2.

Enterprise JavaBeans 2.0: spécification complète des composants

3.

Servlets 2.3: Servlets

4.

JavaServer Pages 1.2

5.

JDBC 2.0: connectivité bases de données

6.

Java Naming and Directory Service (JNDI) 1.2: service de nommage

7.

JavaMail 1.2: courrier électronique

8.

Java Message Service (JMS) 1.0.2: service messagerie

9.

Java API for XML Processing (JAXP) 1.1

10.

Java Connector Architecture (JCA) 1.0: intégration à des SI existants

11.

Java Authentication and Authorization Service (JAAS) 1.0: authentification et autorisation

12.

Java Transaction API (JTA) 1.0.1: service de transactions

• 3. J2EE: Vue d'ensemble

3.3 Service garantis par J2EE

Department of Informatics

Services standards J2EE (2)

Enterprise JavaBeans Technology 2.0

An Enterprise JavaBeans (EJB) component or

enterprise bean is a body of code with fields and methods to implement modules of business logic. You can think of an enterprise bean as a building block that can be used alone or with other enterprise beans to execute business logic on the J2EE server.

There are three kind of enterprise beans:

• Session beans (often stateless)
• Entity beans (offer persistence)
• Message-driven bean
• 3. J2EE: Vue d'ensemble

3.3 Service garantis par J2EE

Department of Informatics

Services standards J2EE (3)

Java Servlet Technology 2.3

Java Servlet technology lets you define HTTP-

specific servlet classes.

A servlet class extends the capabilities of servers

that host applications accessed by way of a request-response programming model.

Although servlets can respond to any type of

request, they are commonly used to extend the applications hosted by Web servers.

• 3. J2EE: Vue d'ensemble

3.3 Service garantis par J2EE

Department of Informatics

Services standards J2EE (4)

JavaServer Pages Technology 1.2

JavaServer Pages technology lets you put snippets

• f servlet code directly into a text-based

document.

A JSP page is a text-based document that contains

two types of text: static template data, which can be expressed in any text-based format such as HTML, WML, and XML, and JSP elements, which determine how the page constructs dynamic content.

• 3. J2EE: Vue d'ensemble

3.3 Service garantis par J2EE

Department of Informatics

Services standards J2EE (5)

JDBC API 2.0

The JDBC API lets you invoke SQL

commands from Java programming language methods.

The JDBC API has two parts:

• an application-level interface used by the

application components to access a database,

• and a service provider interface to attach a

JDBC driver to the J2EE platform.

• 3. J2EE: Vue d'ensemble

3.3 Service garantis par J2EE

Department of Informatics

Services standards J2EE (6a)

Java Naming and Directory Interface 1.2

• The JNDI provides naming and directory functionality. It

provides applications with methods for performing standard directory operations, such as associating attributes with

• bjects and searching for objects using their attributes. Using

JNDI, a J2EE application can store and retrieve any type of named Java object.

• Because JNDI is independent of any specific implementations,

applications can use JNDI to access multiple naming and directory services, including existing naming and directory services such as LDAP, NDS, DNS, and NIS. This allows J2EE applications to coexist with legacy applications and systems.

• 3. J2EE: Vue d'ensemble

3.3 Service garantis par J2EE

Department of Informatics

Services standards J2EE (6b)

JNDI = Java Naming and Directory Interface

Annuaire hiérarchique distribué Accès unifié au DNS, LDAP, NIS, système de

fichiers,…

Nécessaire pour trouver des objets à distance Accès au EJB home uniquement par JNDI Permet reconfiguration des EJB sans modification

dans le code

• 3. J2EE: Vue d'ensemble

3.3 Service garantis par J2EE

Department of Informatics

Services standards J2EE (6c)

• 3. J2EE: Vue d'ensemble

3.3 Service garantis par J2EE

Department of Informatics

Services standards J2EE (7)

JavaMail API 1.2

J2EE applications can use the JavaMail API to send

e-mail notifications. The JavaMail API has two parts: an application-level interface used by the application components to send mail, and a service provider interface.

The J2EE platform includes JavaMail with a service

provider that allows application components to send Internet mail.

• 3. J2EE: Vue d'ensemble

3.3 Service garantis par J2EE

Department of Informatics

Services standards J2EE (8)

Java Message Service 1.0.2

The JMS is a messaging standard that allows

J2EE application components to create, send, receive, and read messages. It enables distributed communication that is loosely coupled, reliable, and asynchronous.

• 3. J2EE: Vue d'ensemble

3.3 Service garantis par J2EE

Department of Informatics

Services standards J2EE (9)

Java API for XML Processing 1.1

XML is a language for representing text-based data

so the data can be read and handled by any program or tool. Programs and tools can generate XML documents that other programs and tools can read and handle.

The Java API for XML Processing ("JAXP") supports

processing of XML documents using DOM, SAX, and

• XSLT. JAXP enables applications to parse and

transform XML documents independent of a particular XML processing implementation.

• 3. J2EE: Vue d'ensemble

3.3 Service garantis par J2EE

Department of Informatics

Services standards J2EE (10)

J2EE Connector Architecture 1.0

• The J2EE Connector architecture is used by J2EE tools

vendors and system integrators to create resource adapters that support access to enterprise information systems that can be plugged into any J2EE product.

• A resource adapter is a software component that allows J2EE

application components to access and interact with the underlying resource manager.

• Because a resource adapter is specific to its resource

manager, there is typically a different resource adapter for each type of database or enterprise information system.

• 3. J2EE: Vue d'ensemble

3.3 Service garantis par J2EE

Department of Informatics

Java Authentication and Authorization

Service 1.0

The Java Authentication and Authorization Service

("JAAS") provides a way for a J2EE application to authenticate and authorize a specific user or group

• f users to run it.

JAAS is a Java programming language version of

the standard Pluggable Authentication Module (PAM) framework that extends the Java 2 Platform security architecture to support user-based authorization.

Services standards J2EE (11)

• 3. J2EE: Vue d'ensemble

3.3 Service garantis par J2EE

Department of Informatics

Services standards J2EE (12)

Java Transaction API 1.0

• The Java Transaction API ("JTA") provides a standard

interface for demarcating transactions.

• The J2EE architecture provides a default auto commit to

handle transaction commits and rollbacks. An auto commit means that any other applications viewing data will see the updated data after each database read or write operation.

• However, if your application performs two separate database

access operations that depend on each other, you will want to use the JTA API to demarcate where the entire transaction, including both operations, begins, rolls back, and commits.

• 3. J2EE: Vue d'ensemble

3.3 Service garantis par J2EE

Department of Informatics

Déploiement

One of the biggest changes between EJB 1.0 and 1.1

is the introduction of XML deployment descriptors, that means, from a procedural to a descriptive way to describe deployment.

XML deployment descriptors are much easier to edit,

even without special tools for editing XML files. An XML deployment descriptor is simple enough that it's easy to create a descriptor using nothing more than your favorite text editor, be it Notepad, Emacs, or vi.

We will further discuss what goes into an XML

deployment descriptor; in particuliar we will see how to write deployment descriptors for our beans.

• 3. J2EE: Vue d'ensemble

3.5 Déploiement XML

Department of Informatics

Plan

• 1. Application Servers
• 2. J2EE: Vue d’ensemble
• 3. Servlets, JSP, JDBC
• 4. Distributed Programming
• 5. Enterprise JavaBeans
• 6. Prise de recul critique

Department of Informatics

Distributed Programming

• 1. General concepts of RMI (Remote

Method Invocation)

• 2. Java RMI
• 3. Concrete code examples
• 4. Distributed Programming

Department of Informatics

Distributed Programming

Component Transaction Monitors (CTM) are based on

distributed object technologies.

All distributed object protocols are built on the same

basic architecture, which is designed to make an

• bject on one computer look like it's residing on a

different computer.

Distributed object architectures are based on a

network communication layer that is really simple. Essentially, there are three parts to this architecture: the business object, the skeleton, and the stub.

• 4. Distributed Programming

4.1 General Concepts of RMI

Department of Informatics

RMI mechanism

TCP/IP S t u b

Interface

" S e r v e r "

• b

j e c t " C l i e n t "

• b

j e c t

Interface

S k e l e t

• n

Client Server RMI

• 4. Distributed Programming

4.1 General Concepts of RMI

Department of Informatics

Proxy Pattern

+request() Proxy +request() «interface» Subject realSubject.request(); +request() RealSubject

Client

Subject RealSubject

+myOperation() MyObjectImpl_Stub

Proxy

+myOperation() «interface» MyObject invokes myOperation(a,b) on the remote MyObjectImpl object, then it has an indirect reference "host ID and local host address on host" +myOperation() MyObjectImpl

Client

• The Proxy

Pattern found in the original "Desing Patterns" book.

• The remote

proxy as it is applied in RMI. The stub object is a proxy for the real object.

• 4. Distributed Programming

4.1 General Concepts of RMI

Department of Informatics

Parameter passing

Distribution complicates parameter

passing: parameters are passed via a message and not via a local stack.

Issues include:

Pointers are related to an address space Composite types: embedded pointers need

to be flattened and reconstructed

• 4. Distributed Programming

4.1 General Concepts of RMI

Department of Informatics

Marshalling / Unmarshalling

Marshalling:

Done by client (i.e. the caller / stub) Packing the parameters into a message Flatten structures (e.g. objects) Perform representation conversions if necessary Also done by server (i.e. callee) for returning the

results

Unmarshalling:

Done by receiver of message (skeleton on server

side and stub on client side) to extract parameters

• 4. Distributed Programming

4.1 General Concepts of RMI

Department of Informatics

Stubs and Skeletons Generation

Writing (un)marshalling code is bug-prone

Communication code has many details Structure of code is very mechanical

Solution

Stubs and Skeletons can be automatically generated from a description of the code to be remotely invoked. For example :

A separated Interface Definition Language (IDL) A description automatically generated from the

code itself.

• 4. Distributed Programming

4.1 General Concepts of RMI

Department of Informatics

Finding the server

One approach is a

Object Manager Naming Service:

• Associate a name with

each server object

• When a server object

starts, it registers with a naming service using the name

• When the client wants to

find the server object, it asks the naming service

• 4. Distributed Programming

4.1 General Concepts of RMI

Department of Informatics

Java RMI

• In Java, stubs and skeletons are mechanically generated from

the business object class, by using the rmic compiler.

• The RMI Registry serves the role of the Object Manager and

Naming Service. The registry runs on the host that is serving

• bjects.
• Marshalling is done with the serialization mechanism.

Serialization provides a means of writing/reading the state of an

• bject to/from a stream:
• All primitive types can be saved in a stream.
• The class of an object to be saved in a stream must implement

java.io.Serializable.

• The stream is annotated with a codebase pointing to the source

where the classes needed for deserialization can be downloaded from.

• 4. Distributed Programming

4.2 Java RMI

Department of Informatics

Java RMI parameter passing

There are two types of parameters to

consider (both to input and return results):

Remote object, i.e., implementing

java.rmi.Remote

Non-remote objects

• 4. Distributed Programming

4.2 Java RMI

Department of Informatics

Remote Objects as Parameters

The target receives a reference to the client stub

implementing the remote interface.

Enables access to unnamed remote objects:

• Client creates a remote object and passes it as a parameter
• n a remote method.
• Server returns a remote object as the result of a remote

method.

Enables peers and not just client-server:

• Client invokes a remote method, passing a remote object

that it implements as a parameter.

• When server invokes a method on this parameter it is using a

client stub, this results in a callback to original client.

• 4. Distributed Programming

4.2 Java RMI

Department of Informatics

Non-Remote Objects As Parameters

Objects are passed by value (a copy of the object is

sent to the server)

Java Object Serialization used to copy parameters:

• Non-remote-object parameters of a remote interface must be

Serializable

Use of Serialization gives different semantics than

normal Java parameter passing:

• Given remote method:

Object identity(Object o) { return o; }

• Then:
• != remote.identity(o);
• 4. Distributed Programming

4.2 Java RMI

Department of Informatics

Dynamic Classloading

RMI Registry

2 5

HTTP Server

Interface + Stub Class files

(on hard disk)

1 6

Client

(knows the remote interface of the server)

4

1.

HTTP server must be running and serving the correct classes

2.

The RMI Registry must be running

3.

Server object is registered with RMI Registry

Naming.rebind(o,"a");

4.

Clients looks up the server object

Naming.lookup("a");

5.

Thanks to the codebase annotation, the client requests the stub class file to the HTTP server

6.

The HTTP server sends the class file.

7.

The client can now invoke methods remotely 7

• 4. Distributed Programming

4.2 Java RMI

Server

• bject "a"

(implements a remote interface)

3

Department of Informatics

General Preview

anArithServerMain anArithApp aNaming

• bj = lookup("a");

anArithImpl

• bj = new ArithImpl()
• bj.add(10,7);

rebind("a", obj);

• 4. Distributed Programming

4.3 Concrete Code Examples

• Consider the simplest RMI example: a server object offering a

single method to add two ints.

• This sequence diagram, shows a global preview of how this

example works.

Department of Informatics

Business object interface

First of all, one have to define the

interface of the business object.

public interface ArithInterface extends java.rmi.Remote { int add(int a, int b) throws java.rmi.RemoteException; }

• 4. Distributed Programming

4.3 Concrete Code Examples

Department of Informatics

Business object implementation

Implement the business interface:

import java.rmi.RemoteException; import java.rmi.server.UnicastRemoteObject; public class ArithImpl extends UnicastRemoteObject implements ArithInterface { public ArithImpl() throws RemoteException {} public int add(int a, int b) throws RemoteException { return a+b; } }

• 4. Distributed Programming

4.3 Concrete Code Examples

Department of Informatics

Main server application

Write the server main application:

import java.rmi.Naming; public class ArithServerMain { public static void main(String argv[]) { try { ArithImpl obj = new ArithImpl(); Naming.rebind("//"+134.21.9.144+"/ArithServer", obj); } catch (Exception e) { System.out.println("ArithErr: " + e.getMessage()); } } }

• 4. Distributed Programming

4.3 Concrete Code Examples

Department of Informatics

The client application

Write the client application:

import java.rmi.RMISecurityManager; import java.rmi.Naming; public class ArithApp { public static void main(String argv[]) { System.setSecurityManager(new RMISecurityManager()); int result = 0; try { ArithInterface obj = (ArithInterface) Naming.lookup("//"+134.21.9.144+"/ArithServer"); result = obj.add(10, 7); } catch (Exception e) { System.out.println("ArithAppErr: "+e.getMessage()); } System.out.println("+a+" + "+b+" is: "+result); } }

• 4. Distributed Programming

4.3 Concrete Code Examples

Department of Informatics

Make the example run

1.

Compile all your stuff

2.

Generate the stub, with the rmic compiler:

rmic –v1.2 ArithImpl

3.

Make the files ArithInterface.class and ArithImpl_Stub.class accessible through an HTTP Server

4.

Launch rmiregistry

5.

Start the server application indicating the right codebase (the

• ne of the HTTP server of point 3.)

java –Djava.rmi.server.codebase=http//134.21.9.144:2001/ ArithServerMain

6.

Start the client application

java –Djava.security.policy=java.policy ArithApp

• 4. Distributed Programming

4.3 Concrete Code Examples