240 likes | 406 Views
QoS-Aware Application Server Architecture. Giorgia Lodi ( lodig@cs.unibo.it ) Department of Computer Science University of Bologna A.Amoroso,V.Ghini, N. Mezzetti, F. Panzieri. System Model Auction Scenario J.J.J.: J2EE, JBOSS, JONAS QoS-Aware Containers Deployment phase
E N D
QoS-Aware Application Server Architecture Giorgia Lodi (lodig@cs.unibo.it) Department of Computer Science University of Bologna A.Amoroso,V.Ghini, N. Mezzetti, F. Panzieri
System Model Auction Scenario J.J.J.: J2EE, JBOSS, JONAS QoS-Aware Containers Deployment phase Configuration Service Run Time Support Service References Summary
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 (1/2)
System Model (2/2) Application1 Application2(Auction) Application3 … Applicationn ASP Application Serverz Application Servera Application Serverb Application Serverc …. Application Serverb Application Serverz Middleware Platform …. OSX Linux Solaris Pentium PPC Sparc network
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 (1/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 (possiblythrough WAN technology). Auction Scenario (2/3)
Auction Scenario (3/3) CSP bidder SLA seller contract contract Netscape E-BAY Explorer Tapas Plug-in Tapas Plug-in http request http request SLAng SLA SLA TTP CRA SLA ASP Tapas platform SLAng SLA RMI/IIOP Tapas platform SSP RMI/IIOP RMI/IIOP Tapas monitor Tapas monitor RMI/IIOP RMI/IIOP Tapas platform Tapas platform RMI/IIOP SLAng ISP SLA Tapas monitor DB DB router network
J2EE 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. J.J.J.: J2EE, JBOSS, JONAS
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: Platform tiers
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: Containers
Every container is responsible for using the underlying middleware services (e.g. JMS, JTS, JAAS, JDBC, etc…). All these services rely on J2SE. New 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: Services & Containers
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: Resource Adapter & Data Tier
Client tier Java application Java applet HTML client Application container Applet container RTSS plug-in RTSS plug-in Services Services RTSS plug-in J2SE J2SE HTTP HTTP,SSL Web tier J 2 S E CS servlet JSP RMI//IIOP RTSS I S P ENS Services Web container RMI//IIOP Business tier JMS A.C. Session Bean MDB RMI//IIOP Managers A.C. S.C. Resource Adapter Resource Adapter Entity Bean TransactionConnectionSecurity JMS EJB container CS RTSS CS RTSS Services ENS ENS J2SE J2SE JDBC/SQLJ Proprietary protocol JDBC/SQLJ Data tier EIS DB J2EE: QoS-aware Containers Client machine J2EE server EIS server
RTSS CS The JBOSS JMX Microkernel Data Sources Remote Management JTS/JTA Security JMX Implementation EJB Container Databases Java Server Pages JMS
JONAS Architecture Jonas J2EE Server Servlets JSP SB EB Jadmin servlets MDB EJB Container Web Container REGISTRY SECURITY DATABASE DATABASE TRANSACTION JMX RTSS MAIL JMS EJB WEB JMX EAR CS
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 (1/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. Packaging (2/2)
Coding/Deploying/Running (Trust and QoS parameters derived from SLA) .xml Files .class Application Developer EAR Code Deployment Descriptors Deployer Parses Deployment Descriptors Deployment Configures environment Application Runner TAPAS Runs application (monitoring and adaptation) ASP
SLS(A) getAvailability(SLS) reserve() getAvalability(SLS) reserve() Configuration Services (CS) (1/3) AS1 AS2 Local Resource Monitor Local Resource Monitor Booking SLS(A): % Booking SLS(A): % getState() getState() Discovery Negotiation Reservation CS Discovery Negotiation Reservation CS AS3 Local Resource Monitor Booking SLS(A): % getState() Discovery Negotiation Reservation CS
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) (2/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(); Configuration Service (CS) (3/3)
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) (1/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(); Run Time Support Service (RTSS) (2/2)
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. References