Automating Application Deployment and Evolution

Position Paper for Workshop on Compositional Software Architecture

Richard Hayton, APM Ltd., UK (Richard.Hayton@ansa.co.uk)
Matthew Faupel, APM Ltd., UK (Matthew.Faupel@ansa.co.uk)

The FlexiNet Project

FlexiNet is a research project being carried out by APM Ltd. as part of the ANSA Research Programme. It is investigating solutions for dynamically deploying distributed applications according to user-specified policy.

Problem Area

Distributed programming is now a mature area of computer science. CORBA, RMI and other distributed object systems can mask distribution issues allowing a straightforward, computational, view of application execution. However, this high level of abstraction can impose other burdens. In particular the placement of components within a distributed system is not modelled, and it is up to the programmer to create application objects within capsules that are themselves located at appropriate locations in the network.

The network environment is changing. For security and management reasons, companies are dividing their organisation into a number of intra-nets, and are defining policies about information flow between these networks. With this division, there is an increasing need for applications to span organisational boundaries, either internal or external, for example in order to undertake electronic commerce. The Internet itself is also expanding, computing resources are becoming ubiquitous and applications are being developed to support large number of distributed clients, spanning many organisations.

Applications can no longer be developed in isolation from their environment. Instead, the programmer must be aware of how the application is to be deployed, in order to ensure that it will respect the organisation's polices. Such development of distributed applications is a highly skilled task, and is prone to error. If, as is usually the case, the environment is itself evolving, then a manual approach to application development is all but impossible.

FlexiNet Architecture

FlexiNet separates application development from application deployment. By providing a specification of the requirements of an application and a description of the environment in which it is to be deployed, the FlexiNet framework will mask deployment issues ensuring that all parts of the application respect the agreed policies, at all times, in all circumstances. The four key elements of the FlexiNet architecture are: software components; transparent component binding; policy definition, and automated deployment.

Component Based Software Development

There has been an increasing trend towards component based software development as an aid to code management. Component based program development has a number of advantages over traditional development techniques in achieving shorter development times, more efficient use of resources, and provision of uniformity of use combined with a variety of functionality. In the context of code deployment, components have a further use, namely a component may be considered as the distribution unit for management purposes. This is a logical division, as components embody a degree of functional and management encapsulation. We may consider the role of distribution management as the deployment of application and middleware components in a distributed environment.

Interactions Between Components

In order to program with components, there must be a model of binding between components, so that a programmer may locate one from another. The FlexiNet programming API will mask potentially complex object trading, as straightforward component binding. This will simplify the task of the programmer, and keep a clear separation between design and deployment. For example, in an ATM module, a programmer may write x = getBank(), and the FlexiNet system will be able to infer from the modelling information and policy statements which particular bank instance is being referred to, and how to locate and authenticate it as required.

Components may pass references to other components between each other in a transparent way, just as method calls may pass references to objects. In these circumstances FlexiNet will again be able to associate the implicit binding request with the relevant policies and ensure that the constructed binding respects the policies. This allows the programmer to construct a component based application, free from concerns about deployment

Policy Definition

By modelling the interaction between components, potential communication paths and opportunities for distribution can be identified. This model can be annotated, either manually or automatically to describe how the application interacts with organisational policy. For example an annotation may indicate that a particular component must be replicated within different parts of the organisation. In addition to policy relating to the application, there will be policy relating to the environment. For example, an organisation may have a multilevel view of security, and only allow programs executing on particular hosts to obtain particular access privileges.

This policy definition is closely linked to modelling techniques to describe the computational function of an application and the information flow between parts of an organisation or application. We envisage that ODP modelling techniques will provide the flexibility and functionality required.

Automated Deployment

Deployment of an application may be viewed as an optimisation problem. Given a model of component interaction, and a description of available resources, it is possible to find the optimal deployment strategy. This is a complex problem, given that communication tactics vary depending on deployment and that the environment is very dynamic - for example the population of clients using a service may not be known at the time the service is deployed. We envisage a number of different tactics for solving these problems in different environments; ranging from manual deployment, to pre-computed and heavily optimised deployment to rapid near-optimal strategies for dynamic groups. Importantly, the deployment strategy is not linked to application development, allowing organisations to fine tune deployment in different environments.

Justification of Approach

There are three trends in system design which strongly support the approach that FlexiNet has adopted: Adoption of technology that follows these trends provides definite advantages:

Current Status

The FlexiNet project has been running now for 8 months. In the initial phase we have concentrated on two areas. First, we have designed and built a modular middleware platform in Java, to allow flexible binding approaches to be investigated. Secondly, we have undertaken initial investigation and design of a high level specification language to be used to map between application requirements and engineering solutions to binding problems.

The FlexiNet engineering framework provides an open implementation of an object request broker that can provide transparent bindings to interfaces on local or remote machines. The binding architecture is extremely open, and allows reflexive techniques to be used at many levels, for example to provide protocol negotiation, location of mobile objects and secure session establishment. We provide automatic 'on the fly' stub generation that simplifies the use of FlexiNet, as no special compilers or knowledge of toolkits is required by the programmer.

Bindings are created by the assembly of a number of components. In addition to naming, serialization, and transmission components, other components have been built to provide 'late binding', where resource usage is minimized until the first invocation, 'secure binding' with key exchange and encryption, and 'negotiated binding' where a third party services is consulted to determine the most appropriate mechanism for a particular binding. These mechanisms can be composed, for example to delay negotiation until the first invocation on a binding takes place.

The next phase of the project will involve the integration of the specification language with the engineering framework for negotiation. This should allow an application to be specified in terms of the interaction between clients and services, and for a particular client and service to negotiate, within the bounds of this specification, to find the most appropriate mechanism for interaction.