Forge Deployment Methods

Forge Deployment Architecture

Managers, hence system administrators, want closer control over their enterprise-critical applications. A commonly neglected aspect of this control is managing deployment. Many manual and semi-automatic deployment schemes that are acceptable for stand-alone, and even networked PCs are not usually sufficient for medium to large scale distributed software systems. These schemes are usually comprised of special-purpose tools either crafted at time of deployment or added later by frustrated administrators.

When budgets are tight it is important to know where your applications are deployed and the state of the hosts on which they are deployed without having to resort to hand-made tools. Forge has developed an architecture for deploying and monitoring its distributed systems that leads to robust and manageable applications. The major features of our deployment architecture are:

Based on Open Standards (TINA, RM-ODP) with standard naming conventions

The Forge distributed architecture combines proven industry standards with modern Java technology. Rather than invent new terms to describe those devices already well documented in the standards, Forge has taken the approach of keeping its nomenclature clear. Thus: a Cluster is the unit of deployment; a Capsule is a run-time environment for Clusters (normally a system process); and a Node is a software platform that provides system resources to Capsules. These names come directly from TINA and RM-ODP and the behaviour of the named entities is consistent with the standards.

Deployable components (Clusters) can be written - and should be written - so that they are independent of their deployment. The Forge deployment architecture is designed to promote this independence. The deployment of a Cluster is thus a matter of providing a descriptor that indicates the Cluster's setup and needs, to the infrastructure. The descriptor will be specific to the application and results in a physical instance of a Cluster while the Cluster code can be deployed and used by many different applications.

Flexibility in component distribution

The Forge deployment architecture allows an application designer to deploy components together with any run-time support code to any Node that will support it. This means that there is no need to "pre-configure" the Node.

Deployment can be changed on the fly

There is nothing to stop an application shutting down and re-deploying components if those components support it. The Forge deployment architecture performs all the actions to make this possible. Administrators or heuristics in the application itself may take the decision but neither of these entities need to concern themselves with the mechanics.

In most applications, even distributed ones, the deployable components are synonymous with operating system processes. The Forge deployment architecture decouples the components from the system processes thereby allowing more efficient use of system resources. Components (Clusters) can also be more logically grouped as common processes (Capsules) in terms of their co-dependency rather than being forced into separate processes unless specifically written to live together.

Offers tight administrative control

Nodes, Capsules and Clusters all share the common traits of high manageability. They expose interfaces that allow lifecycle operations and the extraction of metrics. They also emit notifications as appropriate so that an application manager gets immediate feedback of its constituents' status. The consequence is that any administrative tool has tight control over the behaviour of the deployed application no matter how the components are distributed.

This is where the application developer must do some work! Each application is different in how it is distributed, in the composition of its components and in its configuration so it will need at least some special-purpose management software. There is usually no side-stepping this but the Forge deployment architecture makes it relatively easy because the application developer has a set of clear, standard deployment interfaces (as described above).

It is still a difficult job starting from scratch, so Forge provides an example of an administrative tool that resides above and makes use of the Node, Capsule and Cluster interfaces to help "kick start" development of application managers.

Highly configurable reporting and resource management

When a system is deployed it must be monitored and the resources it uses must be managed. With the Forge deployment architecture this is relatively easy because the metrics that the components publish are directly related to their state and their underlying resources.

The reporting and resource management we are talking about here is the information relating to deployment only. Applications will also publish information about themselves. The luxury that application designers have with the Forge deployment architecture is that they don't need to worry about providing the fundamental management interfaces and statistics.

	More cost-effective application development by providing a standard method of deploying cross-application components, hence not requiring developers to invent their own each time;
	Better control over application deployment to make better use of valuable resources when the application is being installed; and
	Closer monitoring of application components and their performance so that more timely decisions can be taken concerning valuable resources when the application is running.