FlexiNet
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:
-
Component architectures are increasing in popularity. By building
application from components, not only is the development time reduced,
by there is an increased freedom with the choice and placement of components.
For example alternative components may be used to provide the same function
when deployed in different circumstances.
-
A second trend is in introspection, this is the provision of information
about the running system. This gives an application the ability to examine
its environment and act appropriately. For example, if we can determine
the topology of a network, we can assess the most efficient way to distributed
an application.
-
The third trend is business needs driving application development. Modelling
the need provides us with the information about the business goals and
constraints, and allows us, to determine the best approach to meeting these
constraints in a particular deployment. For example we may adopt different
tactics to validating and auditing communication between parties in the
same organisation and between those in different organisations.
Adoption of technology that follows these trends provides definite advantages:
-
Component based approach leads to cheaper and faster software development.
-
Agreed policies are imposed on application components as required.
-
Applications evolve to support business needs.
-
Applications can be re-deployed dynamically as the environment evolves.
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.