giorgia lodi ( [email protected] ) department of computer science university of bologna

Dortmund, 10 - 11 February 2003

Giorgia Lodi ([email protected])Department of Computer Science

University of Bologna

A.Amoroso,V.Ghini, N. Mezzetti, F. Panzieri

mailto:[email protected]

2Dortmund, 10 - 11 February 2003

Summary

• System Model• Auction Scenario• J.J.J.: J2EE, JBOSS, JONAS• QoS-Aware Containers• Deployment phase• Configuration Service• Run Time Support Service• References


System Model (1/2)

• An ASP can host different applications (e.g. auction application, video conference, games, etc…).

• Some applications might communicate with each other.• The middleware platform, inside the ASP, consists of a

group of Application Servers.• The Application Servers communicate with each other.• An application can consist of a certain number of

components hosted by different Application Servers.• The ASP is a cluster of different machines connected by

a network and running possibly heterogeneous Operating Systems.

• In a single machine, more than one application server can be in execution concurrently (e.g. emulation of a cluster).


System Model (2/2)

Application Serverz

Application Serverb

Application1 Application2

(Auction)Application3 Applicationn …

ASP

Middleware Platform

….

network

….Application Servera

OSX Linux SolarisPentium

SparcPPC

Application Serverb

Application Serverc

Application Serverz


Auction Scenario (1/3)

• An end-user (seller, bidder) registers with an application owner (e.g. E-bay) by signing a contract.

• The contract entitles the end-user to use the auction application.

• The end-user may access the auction through HTTP requests and may use a piece of software which controls contract’s rights and obbligations.

• The application owner asks ASP (e.g. Adesso) for hosting the auction application: they establish a SLA between each other.

• The SLA can be described using SLAng, which is a notation generator.

• The ASP hosts the application providing a suitable platform through which the auction is executed.


Auction Scenario (2/3)

• The ASP may have a SLA with: - a SSP for using data storage resources. The SSP has a

monitor used to control whether the SLA specifications are honoured

- an ISP for using network resources. The ISP has a monitor used to control whether the SLA specifications are honoured.

• The ASP makes available a set of services/resources for running the application.

• The services/resources may communicate with each other using some protocol such as RMI/IIOP (possibly through WAN technology).


Auction Scenario (3/3) bidder seller

E-BAY contract

http request http request

contract

Tapas Plug-in

Tapas Plug-in

Netscape Explorer

SLA

ASPRMI/IIOP

Tapas platform

Tapas platform

Tapas platform

Tapas platform

RMI/IIOPRMI/IIOP

RMI/IIOP

RMI/IIOP RMI/IIOP

SLAng

SLAng SLA

SSP

SLASLAng

network

ISP router DB DB

Tapas monitor

Tapas monitor

Tapas monitor

TTP CRASLA SLA

SLA CSP


J.J.J.: J2EE, JBOSS, JONASJ2EE• It uses a multitiered distributed application model. • The application logic is divided into components according to

function.• Components make up the J2EE application. • Components are installed in different machines depending on which

tier the application component belongs to.JBOSS• It is an open source application server. • It integrates and develops a set of services for a full J2EE-based

implementation. • It is a microkernel based server and uses Java Management

eXtension (JMX) for sofware integration.JONAS• It is a pure Java open source application server conforming to the

J2EE specifications, as Jboss.≠ architecture (JMX), additional services.


J2EE: Platform tiers

• The platform provided is multitiered.• Client tier components run on the client machine.• Web tier and Business tier components run on the J2EE

server. Web tier and Business tier form the Middleware tier.

• Data tier runs on the Enterprise Information System servers.

• Client machines, J2EE servers and EIS servers interact with each other using the network provided by an ISP.


J2EE: Containers • A client tier component can be: - an application client running in an Application Container - a HTML client - a Java applet running in an Applet Container.• HTML client and Java applet interact with Web components

(e.g. servlets, JSPs) using some protocol (e.g. HTTP, SSL).• Web Components run in a Web Container.• Web Components and Java applications interact with EJBs

through RMI/IIOP.• EJBs (session beans, entity beans, message driven beans) run

in an EJB Container.


J2EE: Services & Containers • Every container is responsible for using the underlying

middleware services (e.g. JMS, JTS, JAAS, JDBC, etc…).

• All these services rely on J2SE.

NewNew• New services added in order to provide QoS-aware

containers: - Configuration Service (CS) and Run Time Support Service (RTSS).• CS and RTSS use group communication technology (e.g.,

Event Notification System (ENS)).


J2EE: Resource Adapter & Data Tier• A Resource Adapter is a component running in

any J2EE server that implements the J2EE Connector Architecture for a specific EIS.

• A Resource Adapter is analogous to a JDBC driver: they provide API in order to access a resource outside the J2EE server.

• Two types of “contracts” (i.e., APIs) implemented by a Resource Adapter:– Application Contract (A.C.) defines the API through

which an EJB or a Web Component accesses the EIS– System Contract (S.C.) links the resource adapter to

the connection, transaction and security services.


J2EE: QoS-aware Containers Client machine

J2EE server

EIS server

Data tierEISDB

JDBC/SQLJ JDBC/SQLJProprietary protocol

I

S

P

Java application

Application container HTML client

Client tierJava applet

Applet container

J2SE J2SERTSS plug-in

RTSS plug-in

RTSS plug-inServices Services

HTTP HTTP,SSLWeb tier

Business tier

servlet

Web container

JSPJ

2

S

E

CSRTSS

RMI//IIOP

J2SE

EJB container

Session Bean

Entity Bean

MDB

CS RTSS

RMI//IIOP

JMS

JMSResource Adapter

RMI//IIOP

ServicesENS

ENS

Services

ManagersTransactionConnectionSecurity

Resource Adapter

J2SE

CS RTSSENS

A.C.

A.C. S.C.


The JBOSS JMX Microkernel

JMX ImplementationJMX Implementation

JTS/JTA Security

EJB Container Databases Java Server Pages JMS

Remote Management

Data Sources RTSS

CS


JONAS Architecture

EJB Container Web Container

SB

MDB

EB

Jonas J2EE Server

JMX

EAR

CS

RTSS

REGISTRY

JMS

Servlets JSP

Jadmin servlets

DATABASE

DATABASE

JMX

WEB

MAIL

EJB

SECURITY

TRA

NSA

CTION


Packaging (1/2)

• J2EE components are packaged separately and bundled into a J2EE application for deployment.

• A J2EE application and each of its modules has its own deployment descriptor.

• A deployment descriptor is a XML document that describes a component’s deployment settings.

• An enterprise bean module deployment descriptor declares transactions attributes and security permissions for an enterprise bean.

• At run time, the J2EE server reads the deployment descriptor and acts upon the components accordingly.


Packaging (2/2)

• A J2EE application with all of its modules is delivered in an Enterprise Archive (EAR) file.

• An EAR file is a standard Java Archive (JAR).• Each EJB JAR file contains a deployment descriptor, the

enterprise bean files and related files.• Each application client JAR file contains a deployment

descriptor, the class files for the application client and related files.

• Each Web Archive (WAR) file contains a deployment descriptor, the Web component files and related resources.


Coding/Deploying/Running(Trust and QoS parameters derived from SLA)

.xml

Files

.class

Application Developer

ASP

Deployer

Deployment

TAPAS Application Runner

Configures environment

Runs application (monitoring and adaptation)

EARCode

Deployment Descriptors

Parses Deployment Descriptors


Configuration Services (CS) (1/3)Local Resource

MonitorLocal Resource

Monitor

Local Resource Monitor

getState() getState()

getState()

AS1 AS2

AS3

SLS(A)

Discovery

Negotiation

Reservation

CS

Discovery

Negotiation

Reservation

CS

getAvailability(SLS)

reserve()

reserve()

getAvalability(SLS)

Booking SLS(A): %

Booking SLS(A): %

Booking SLS(A): %

Discovery

Negotiation

Reservation

CS


Configuration Service (CS) (2/3)

• Discovery of available resources:– assess availability (e.g., load, network bandwidth, …)– Resource Monitor maintains state of local resources.

• CS – starts at application server start up time– is “enabled”, at deployment time, by:

Object platform = enable_CS(SLS);


Configuration Service (CS) (3/3)• Enabled CS, with input = SLS, declares itself as

coordinator of the group of CSs.• Discovery:

– Coordinator sends a request for the availability to its peers using some method like:

Object State = getAvailability(SLS);• Negotiation:

– Every CS books its own resources– CS produces an agreed QoS contract (i.e., contract between the

application and the middleware platform).• Reservation:

– Coordinator confirms reservation of the resources.• CS stopped with the following: disable_CS();


Run Time Support Service (RTSS) (1/2)• It models the adaptive behaviour of our architecture. • It requires the use of monitors.• Monitors check the resource states as well as the

requirements, within SLAs, to fulfill.• A monitor, Resource Monitor, checks the resources and

the QoS requirements.• Resource Monitor maintains the resource states and the

QoS requirements state in persistent objects.• Persistent objects are used for producing log files,

statistical analysis as well as irrefutable proofs.• If it detects any changes, it may adopt some adaptive

strategy to reconfigure the environment.


Run Time Support Service (RTSS) (2/2)

• Adaptive strategies may trigger a re-negotiation with the CS.– Callback mechanisms, through which communicate with the

application (e.g. handlers at the application layer), used when no adpative strategies can be applied.

• Resource Monitor enabled using:

Identity RM = enable_RM (CS, SLS, AgreedQoS);

• The RTSS stopped with: disable_RTTS();


References• D.Lamanna, J.Skene and W.Emmerich ``SLAng: A Language for

Defining Service Level Agreements'' London, January 2003.• S.Bodoff, D.Green, E. Jendrock, M. Pawlan and B. Stearns ``The J2EE

Manual'', Sun Microsystems Inc., 2001.• B.Shannon "Java 2 Platform Enterprise Edition v.1.4" Sun Microsystem

Inc., 2001.• http://www.jboss.org/• http://www.objectweb.org/jonas/current/doc/JOnASWP.html• W.Beckman, J.Crowcroft, P.Gevros and M.Oleneva ``TAPAS

Deliverable D1'', University of Cambridge and Adesso AG, 2002-10-17.

• Scott Stark and the Jboss Group ``JBOSS Administration and Development Second Edition'', Atlanta, USA, November 10 2002, Jboss Version 3.0.4.

• E. Checcet and J. Marguerite "JONAS v.2.4 Tutorial" Rice University INRIA, France.

giorgia lodi ( [email protected] ) department of computer science university of bologna

Documents