OSMOSE/ObjectWeb
Generic Deployment Framework (GDF)
Specification
Date: June 21,2004
Version: 0.1
Status: draft
Authors: Didier Donsez, Vincent Lestideau (UJF-IMAG-LSR-ADELE)
Contributors:
1 Introduction
This document is the first draft for
the Deployment Framework API specification. This framework is
mainly a set of interfaces. It must/could be implemented as different
personalities for each targeted platform (J2EE, OSGi, CCM, Fractal,
ProActive, DCUP, .NET ...).
Please send comments to the Deployment Mailing List:
deployment@objectweb.org
2 Motivations
2.1 Generic deployment Framework
The Generic Deployment Framework (GDF) must be independent to
a particular platform.
GDF must be able to deploy :
- applications for one of these platforms: OSGi, J2EE, CCM, Fractal, ProActive, DCUP or .NET
- "heterogeneous" applications deployed on several platforms
- platforms them self on operation systems (Linux, ...)
2.2 Multi-personalities
Algorithms and dependencies are either platform specific or
common to the different platforms. Deployment can be heterogeneous in
terms of platform. For instance, the example 3.3 illustrates that use case : the sensors application
part is deployed both on OSGi gateways and real-time CCM runtimes while
the sensor warehouse part is deployed on J2EE servers.
2.3 Model-based
GDF is inspired by deployment approaches based on models
like ORYA or SoftwareDock.
3 Use cases
3.1 The OSGi gateway use cases
GDF OSGi personality deploys OSGi units (ie bundle) on gateways (hundreds, thousands even millions in the context of interactive television).
3.2 The J2EE distributed application use case
GDF J2EE personality deploys J2EE units (ie EAR, EJBJAR, WAR) on a cluster of J2EE servers (JOnAS). The server on the right is a backup server used when one of the lef servers fails.
3.3 The Weather Station use case: OSGi, J2EE and CCM application
GDF must support the deployment of heterogenous units (ie CCM, OSGi, J2EE) of an application on heterogenous platforms.
A typical application is the collection of measurements from embedded sensors.
In this application, embedded gateways get measurements from sensors connected to them by field buses (OpenCAN, Profibus, ModBus ...) or adhoc networks (RFID, Bluetooth, ZigBee, ...).
The embedded gateways filter and agregate (sliding average, ...) the measurements and push regulary them to the server (the "SensorWarehouse"). The server can pull also requests to the gateways to get the last measurements.
The server is a cluster of J2EE servers (JOnAS) and the gateways can be either OSGi platforms (Oscar) or real-time embedded CCM platforms (OpenCCM, CARDAMON).
3.4 The platforms deployment use case
The platforms (ie JOnAS, Oscar, ...) or additional tools (Apache HTTPD, MySQL, ...) used be a application must be previously deployed.
3.5 The "cluster" of OSGi gateways use case
A platform (OSGi) can be used to deploy other platform' units (CCM, Fractal).
3.6 Others ????
4 Model
4.1 Deployment Framework
4.2 Attributes
Description
The Attributes interface allows to
associate some properties to others interfaces of this framework. A
property is an unmutable key-Value pair. Properties can be either
platform-specific or application-specific. Development status is an
example of an application-specific property and the bundle version is
an example of platform-specific property.
Operations
- getAttributeNames():String[]
Returns the
names of attributes of the associated class.
- getAttribute(String key): Object
Returns the
attribute identified by its key.
- getAttributes(String key): Object[]
Return the set
of attributes of the associated class.
4.3 Dependant
Description
The interface Dependant represents a site, an application or an unit
that has dependencies.
Operations:
- getDependencies(): Dependency[]
Returns the
dependencies required by the dependant (site, application or unit)
4.4 Dependency
Description:
The interface Dependency represents a
dependency. A dependency can be resolved by an Unit, a Site or anything
else (Organization, User ...). An application, an unit or a site can
contains several types of dependencies. Dependencies can be different
according to the deployment activity (installation dependencies,
activation dependencies, uninstallation dependencies, ...).
Dependencies can be mandatory or optional. Dependencies can be
singleton or collection.
Operations:
Indicates if
the dependency is mandatory or optional. Returns true if the Attributes
object resolves the dependency, false else.
- ResolveBy(Attributes attributes): boolean
Checks if the Attributes object
resolves the dependency. The Attributes object must be a Unit.
Examples:
In this section, we propose some example of dependencies to illustrate
our purpose.
Common dependencies:
- UnitDependency
- FilterDependency
- ConjunctionDependency
- DisjunctionDependency
OSGi-specific dependencies:
- VersionedUnitDependency
- ImportPackageDependency (OBR)
- Eg: the unit requires the package javax.servlet; version=2.3
- ImportServiceDependency
- ServiceBinderImportServiceDependency
- ExportServiceDependency
- Eg: A command requires a Shell
- ConsumerWireAdminDependency
- ProducerWireAdminDependency
4.5 Unit
Description
The Unit interface represents a
deployment unit. An Unit object is characterized by a set of attributes
(interface Attributes). A Unit object have dependencies (interface
Dependant). A Unit object can embed others Units. For instance, in
J2EE, a EAR can included an EJB'JAR, several WAR and several
client'JAR. The WARs can contains Midlet and Applet JAR. In OSGi, a
bundle can contain JARs and native libraries.
Operations:
Returns the identifier of the
Unit. This identifier is globally unique over the unit space.
Return the list of embedded units.
Associations:
Remark:
- The attributes of a Unit object is not necessarily the super-set
of the attributes of its embedded units.
- The dependencies of a Unit object is not necessarily the
super-set of the dependencies of its embedded units.
4.6 DeployedUnit
Description
The DeployedUnit interface represents
a deployment unit deployed on a site. A DeployedUnit has a status,
which represents the state of the unit: installed, stopped, active or
unistalled.
Operations:
Returns the
status of a deployed unit on a site.
4.7 Application
Description
The Application interface represents
the application to deploy and its dependencies (site, unit, ...). When
an application is composed of a set of identified units, the
dependencies should include one instance of UnitDependency for each
unit. UnitDependency is an implementation of the Dependency interface,
it represents a dependency to an other unit.
Operations:
Returns the
identifier of the application. This identifier is globally unique over
the Application space
4.8 DeployedApplication
Description
The DeployedApplication interface
represents the application to deploy on a site or a organization. In
the case of a distributed application, the application is deployed on
several sites (or organizations). A deployed application is composed of
one or more deployed units.
Operations:
Returns the
status of a deployed application on a site
- getDeployedUnits(Site site): DeployedUnit[]
Returns the
deployed units on the site or the organization
4.9 Site
Description
The Site interface represents a site
with the deployed units and the deployed applications . A site could be
a computer, a cluster of computer or an organization. A site can be
described (for instance by hardware and software constraints) thanks to
the dependencies and the attributes.
Operations:
Returns the
identifier of the site
- getDeployedUnits():DeployedUnit[]
Returns the
deployed units on the site
- getDeployedApplications():DeployedApplication[]
Returns the
deployed applications on the site
4.10 Organization
Description
The Organization interface represents the organization and its sites on
which units are deployed.
Operations:
Returns the sites of the
organization (owned/operated by the organization)
4.11 Resolver
Description
The Resolver interface represents a service that defines a deployment
process of a application.
Operations:
- resolves(Application application): Process
Returns a process to execute from
the dependencies associated a application, site, ...
4.12 Process
Description
The Process interface represents a workflow of deployment instructions
to execute. A process can be a atomic deployment instruction (i.e.
install this bundle), a sequential list of instruction, a complex (non
cyclic) of instructions
Operations:
5 Resolution
The units are the root of a
multi-colored graph. Edges are satisfying dependencies. One color per
type of dependency. A deployment is successful if all dependencies are
satisfied (For the application, sites and units).
Several algorithms can coexist.
Basic algorithm proposition (TODO).
6 Issues
6.1 Packages hierarchy
Do we change the packages hierarchy?
6.2 Interface design issues
org.objectweb.deployment is dedicated to the description.
6.2.1 Collection parameters and collection return values
- Several alternatives are available for the parameters and the
return values when they are a collection of objects:
- Type[] (currently used)
- javax.management.AttributeList for Attributes
- Iterator
- Iterator<Type> JDK 1.5 and +
- List/Set
- List/Set<Type> JDK 1.5 and +
6.2.2 Replacement of the Attribute interface
The interface may be replace by the
javax.management.DynamicMBean.
- Potential drawback: javax.management.DynamicMBean is muttable
- Potential drawback: javax.management.DynamicMBean is strongly related to Java
- Advantages: reuse existing JMX agents and clients
The interface may be replaced by the
org.objectweb.fractal.api.control.AttributeController.
- Potential drawback: AttributeController is non functional since Attribute is functional : this may be confusing ???
- Advantages: reuse existing Julia tools
6.2.3 Mutable interfaces
For operational uses it’s necessary
to add, remove or modify the entries in repositories (applications and
units) and in attributes objects. Mutable interfaces provide add,
remove and modify methods:
- add(Type), remove(Type), ...
6.2.4 Observable interfaces
For operational uses it’s necessary
to observe changes on repositories (applications and units) and
attributes objects. Observable interfaces provide a way to observe
their changes. For instance, units observes the version changes for a
particular unit:
- get/set Observer (Observes if the Unit changes its implementation
version)
6.2.5. Filtering on attribute
Filtering is eased when Attributes
value entries implement the java.lang.Comparable.
- Eg: Version, VersionedPackage, ...
6.2.6. Attributes indexing
For operational uses, dependencies
and resolution algorithms may used indexes of attributes collections on
particular entry keys. This improves performance during the resolution.
The interface could have some methods such as find(String filter) for
ApplicationRepository, UnitRepository, Organization, ...
6.2.7. Others ?
6.3. Open issues
- Code/State migration
- Compliance with
- (Deployment and Configuration of Component-based Distributed
Applications)
- (J2EE Server API for 3-tier Deployment Tools)
- SUN JNLP, DVB-MHP, Linux RPM, ...
6.4. Which issues are not addressed by GDF ?
- Packaging
- Platform specific : RPM, Bundle Jarfile, EAR Jarfile
- Metadata Formats
- Java .MF, RPM multi-files, .NET XML manifest, ...
- Protocols between global and local deployer
- rsh, rlogin, ssh, Globus, PBS, LSF, MapRsh, ...
- telnet, http, https, soap, xmlrpc, javagroup ?, ip multicast+carrousel, ...
Should GDF address them ?
The right place (low level GDF)
