Infrastructure for Automatic Dynamic Deployment of J2EE applications in Distributed Environments

1. file Infrastructure for Automatic Dynamic Deployment of J2EE applications in Distributed Environments A. Akkerman, A. Totok, V. Karamcheti Computer Science Department New York University

2. Motivation • J2EE application deployment • complex • have to: • configure application components • configure and start required system components (services) • consistently maintain configuration data: • JNDI names • IP addresses • port numbers • Need a tool for automating the deployment process

3. Infrastructure Overview • Main features • distinguishes between application and system components • supports inter-component connectivity specification • addresses application component dependencies on system components (services) • enables reuse of components and services • Utilizes componentized application server architecture (e.g., JBoss, JOnAS) • incremental (hot) service and application component deployment/undeployment • Deployment descriptor manipulation • Fully J2EE-compliant

4. Components • Application components • web-tier components (servlets, JSPs) • treated as a single component • EJBs • collocated through local interfaces – as a single component • JDBC Data Sources • JMS messaging destinations (topics, queues) • System components (system services) • JMS Messaging service • Transaction Manager service • Components should be registered with the infrastructure

5. Architecture Description Languages • Component Description Language • component and link description • components have ports (required and provided) • a flexible type system for semantic consistency • component port types as interfaces to component functionality (e.g., Catalog, Item) • link types as communication protocols (e.g., EJBLink, DataSourceLink) • a declaration and expression language for configurable component properties • Component Replica Assembly Language • to assemble component replicas into application deployments

6. Component Description Language <componentname="CatalogEJB"> <requires> <portname="PortToItem" type="Item" link-type="jboss.system.EJBLink"> <propertyname="EJBObjectJNDI"> ${EJBObjectJNDI@jboss.system.EJBLink} </property> </port> </requires> <provides> <portname="InvocationPort" type="Catalog" link-type="jboss.system.EJBLink"> <propertyname="EJBObjectJNDI">Catalog-${systemId}</property> </port> </provides> </component> • Declaration and expression mechanisms for component properties • properties are used to configure deployment descriptors • component dependency specification • propagation of property values between components through links

7. Architecture Description Languages • Component Description Language • component and link description • components have ports (required and provided) • a flexible type system for semantic consistency • component port types as interfaces to component functionality (e.g., Catalog, Item) • link types as communication protocols (e.g., EJBLink, DataSourceLink) • a declaration and expression language for configurable component properties • Component Replica Assembly Language • to assemble component replicas into application deployments

8. Component Replica Assembly Language <deployment-pathpath-id="..."> <component-replicareplicaId="93" name="CatalogEJB" targetId="hostB"> <port-configurationname="PortToItem" .../> </component-replica> <component-replicareplicaId="57" name="ItemEJB" targetId="hostA"> <port-configurationname="InvocationPort" .../> </component-replica> <link-replicareplicaId="152" link-type="jboss.system.EJBLink" __sourceEndpoint_id="93" __sourceEndpoint_portId="PortToItem" __destEndpoint_id="57" __destEndpoint_portId="InvocationPort"/> </deployment-path> • Assembly of component replicas into application deployments (deployment paths) • Mapping of component replicas onto application server nodes

9. Architecture

10. Infrastructure Usage • Initialization • System components and application registration • written in the Component Description Language • Writing the deployment path specification • written in the Component Replica Assembly Language • Preparing deployment path • component configuration process • Deployment of prepared path • Management of deployed path

11. Application Registration

12. Infrastructure Usage • Initialization • System components and application registration • written in the Component Description Language • Writing the deployment path specification • written in the Component Replica Assembly Language • Preparing deployment path • component configuration process • Deployment of prepared path • Management of deployed path

13. Preparing Deployment Path component (replica) configuration process

14. Component Configuration Process • A deployment specification is a DAG • link direction from required to provided ports • Configuration process • leaf-to-root post-order processing of the DAG • leaf components have no required ports, but may depend on system components • Component reuse • a component replica can be reused for several deployment paths, if its subgraph of referenced components can be reused • achieves: • decreased resource utilization • decreased deployment overhead • no need for component data consistency management

15. Infrastructure Usage • Initialization • System components and application registration • written in the Component Description Language • Writing the deployment path specification • written in the Component Replica Assembly Language • Preparing deployment path • component configuration process • Deployment of prepared path • Management of deployed path

16. Deployment of Prepared Path d e p l o y

17. Infrastructure Usage • Initialization • System components and application registration • written in the Component Description Language • Writing the deployment path specification • written in the Component Replica Assembly Language • Preparing deployment path • component configuration process • Deployment of prepared path • Management of deployed path

18. Implementation • JBoss • micro-kernel architecture, based on the JMX specification • Infrastructure modules • Agent Serviceon every node (Agent MBean) • oneXmlBlaster Service • XmlBlaster is a MOM middleware server (XML-based, search, persistence, etc.) • works as persistence storage • any number of Deployment Unit Factory Services • generate deployable bundles (JARs, WARs, EARs) • contain bulky codebases, other application content • implemented as a J2EE Web application (J2EE WAR) • GUI-based client tool • compose and edit deployment specifications (Component Replica Assembly) • Replication Management Service client • bundled with the Replication Management Service, but their codebases are decoupled

19. Usage Experience • Java PetStore, RUBiS, TPC-W-NYU • augmented with messaging functionality • Successful several-node deployments • Projects used in: • “Mutable Services” project • service distribution infrastructure for component-based applications • www.cs.nyu.edu/pdsg • “Efficiently Distributing Components in Wide Area Environments” D.Llambiri, A.Totok, V.Karamcheti, ICDCS’2003

20. Miscellaneous • 3+ years in development and usage • Tools/projects the infrastructure utilizes • JBoss • XmlBlaster • Castor • Jelly • Graph Editing Framework (GEF) • Available for download • http://www.cs.nyu.edu/pdsg • follow the “Software” tab

21. Discussion • Replication Manager Service and XmlBlaster back-end are centralized • single points of failure • Not failure-resistant • no support for atomic deployments • Application reconfiguration through component deployment/undeployment • the only thing to do, because J2EE does not support dynamic reconfiguration • active monitoring/micro reboots - Pinpoint/JAGR

22. file Thank You!