ANSA Principles
ANSA PrinciplesOne of the fruits of the age of technology, is the proliferation of diverse business structures, operational processes and information systems. The increasing need for enterprises to inter-operate, often globally, places immense challenges upon organisations and their information systems in managing this diversity. It is only recently that enterprises have been discovering that standardisation of procedures and systems is only a temporary and incomplete solution to change, the growth of diversity and the need to inter-operate. Increasingly, enterprises are turning to forms of federation, in order to maintain control, when forced into distributing management, processes, businesses and systems.
The ANSA Architecture is founded upon a set of simple principles for building software which can both interoperate across and be managed within federated business structures. This briefing note outlines those principles and their use.
Trading and Controlled InteroperabilityANSA emphasises a view of systems as being made up of autonomous domains. Within a domain, technology and administrative policies are taken to reflect the needs of the users served by that domain. Thus different domains may comprise different technologies and be managed in different ways. Within a domain ANSA sees applications, data, machines and networks all as "objects" providing "services". A service is a high level statement of what an object does. For example a database of customer accounts might underpin a "banking" service which provides credit, debit and balance query functions. An object is simply a software component which can be installed, upgraded, replaced or relocated independently of any other object - i.e. it is encapsulated.
Taking the service view decouples what the system does from the details of the implementation (which database, the exact schema used and so forth), bringing the system model closer to the business model and allowing scope for independent change and evolution of system components.
To accomodate change and evolution, each domain has a special service called a "trader" which contains an up-to-date view of which services are available in the domain, where thay are located and how to access them. A server can advertize itself in a trader, indicating what service(s) it provides; a client can browse the trader to find a suitable service it needs. The trader is the foundation of configuration management and system flexibility. When services move from one object to another, updating the trader is sufficient - clients do not have to be reprogrammed. A trader can embody procedures for creating services "on demand" - i.e. when a client seeks them, thereby economising IT resources.
The trader stores "references" to services. References appear to the applications programmers as "network pointers" giving access to the object supporting the service, wherever it may be. To the infrastructure the reference is a source of the addressing and other information needed to locate the object and establish communications with it. References can be passed from program to program so that one service can grant access both to the services it defines and, where appropriate to the services to which it has access. This uniformity of referencing across services is a key element towards simplification of the programmer's burden.
When two domains are interconnected (for example a branch office domain is linked to a head office domain) the two traders involved provide for controlled interoperability. They can be informed of any requirements for protocol conversion necessary between the domains and what policies apply to use of services between the domain (e.g. security, resource usage, billing and so forth). Before allowing use of a service across a domain boundary the traders cooperatively set up a "bridge" or "interceptor" to manage the interworking between the domains. This "federation" model of interoperability is therefore one which provides both management control and accomodation of heterogeneity within an automatic framework. Obviously when the inter-operating domains are similar in both technology and management policy the interceptors are null and no overhead need be incurred. Thus the system manager has the flexibility to either exert control or enable freedom service by service, domain by domain.
Customized InfrastructureDistributed computing is more demanding than single machine computing, be it mainframe, midrange or PC. As soon as more than one computer is involved more things can go wrong and without care, the system can become more fragile. On the other hand, with careful selection of suitable technology and appropriate systems design distribution can bring benefits of decentralization and "right-sizing", fault tolerance and enhanced availability through replication, load balancing and data migration. A key design choice is "transparency": does the programmer assume the operating system provides a "single system image" (e.g. by using transactions to maintain integrity), or does the programmer have to design the application to be intrinsically robust. ANSA takes the position that transparency should be selective: the transparent "single system image" case is often easiest for the programmer, but may impose a penalty in terms of performance and cost. Moreover complete transparency is a fool's paradise; no amount of software can defend against all disasters...... Thus ANSA suggests that transparency should be selected service by service and each object given an appropriately customized interface to the supporting communications and systems management infrastructure. It is almost as if each object had its own operating system and middleware, and is managed in those terms. Moreover ANSA explains how to have a systems interface for applications programmers to use that is neutral to the particular selection of transparencies that apply. This allows transparency requirements to be changed, or for alternative transparency implementations to be substituted without having to rebuild applications from scratch.
Abstract and AutomateThis aspect of ANSA naturally leads into the third ANSA principle "abstract and automate". The point here is that by looking at systems in terms of enterprise-oriented services rather than technical components one gets a more direct understanding of what the system is for, and if systems are programmed at this level, the software becomes less committed to the underlying technology than in traditional approaches. Essentially this is a stylized use of object orientation. Every object has one or more well-defined interfaces at which it provides services. Since objects are fully defined by their interfaces it is possible to provide tools that automatically grow interfaces to add the extra code needed to drive communications, transactions and all the other machinery of distribution. Hence automation.
The benefits of abstraction and automation can be applied to existing code. ANSA has a number of techniques for wrapping up non-object, non-distributed applications and bringing them into the ANSA framework. Usually wrapping consists of providing some code that maps from message passing across the network to some form of local I/O by which the legacy application can be driven. Once the legacy application has been captured in a "wrapper" it is a first class citizen of the ANSA world and can be used, traded and managed just as any other object. For new applications we can exploit abstraction and automation further by allowing distribution to be added into the application itself, e.g. to exploit parallelism when searching multiple databases, or to add value to other services accessed across the network (for example compiling a folder of references by which some entity is known).
Modular EngineeringDistribution assumes some sort of infrastructure or middleware which provides the baseline communications and management for distributed objects. ANSA proposes that the infrastructure be modular in three respects:
These architectural requirements are being met by industrial standards: CORBA and DCE both have defined portability interfaces; CORBA has recently had an interoperability interface defined, and there is a move towards defining the network interface too. The advantage of ANSA is that we have worked on these three interfaces simultaneously and have a good understanding of how they interact, and thus we can predict how the standards will evolve to meet the architecture. Moreover it explains why products based on ANSA explicitly (e.g. ICL's DAIS) are as flexible and effective as their vendor's claim.
There are many case studies of systems based on ANSA, some built by APM, others by other companies; they follow a common template for using the architecture.
At the core lies some mission-critical data being maintained dependably in real-time by a distributed application styled as a "value adding service". This service manages the mission-critical data and its flow into and out of other systems, be they backend databases or frontend PCs. The flows pass through wrappers that bring these external systems into the objects and services framework so that from the perspective of the value adding service they are all at the same level of abstraction so that they can be accessed and managed uniformly. The complexity is hidden in the tools (e.g. stub generators) that build the wrappers. The value adding service is built as a set of distributed objects supported by components enabling the required forms of transparency (e.g transaction managers to enable atomicity) which is in turn supported by the modular engineering infrastructure.