Systems Development in a GRIDs Environment

Abstract

Over the past 30 years or more information systems engineers have attempted to improve the cost effectiveness of systems development by improving requirements capture and analysis, by structured design, by utilising design languages that can be verified for consistency more or less formally and in some cases matched formally to requirements. While data design methods improved significantly with relational and extended relational paradigms, program design was not so successful. Jackson input-process-output and hierarchic design methods gave way to functional. Object-orientation soon came up against the inability of hierarchic/inheritance mechanisms to represent the real world requirements which has more complexity. Aspect-oriented programming was intended to resolve this problem but appears to have caused even more confusion. Meantime, a bringing together of functional and object-oriented process design as service-oriented architecture, together with relational data design principles, has given some hope for progress. Early system design achieved device independence of programs and then (with relational technology) true data independence. However, general virtualisation of computing, data storage and communications resources has hitherto not been possible. The GRIDs paradigm achieves this latest step forward. Starting with metacomputing (linked supercomputers) in the USA, the European vision of GRIDs is a general IT ‘surface’ with which the end-user interacts intelligently to determine her requirement and the system behind the surface offers a ‘deal’ to fulfil the request. Beneath the ‘surface’ various architectures have been attempted. The GLOBUS architecture provides computational scheduling, but does not virtualise generally computation, data or network resources. The bringing together of WS (web services) with the GRIDs environment led to OGSA (Open Grids Services Architecture). Work with OGSA has exposed two major problems: the operating system facilities provided today are inadequate in various areas including security and resilience and the multiple layers in the service-oriented architecture expose too much complexity. The latest thinking revolves around SOKU (Service Oriented Knowledge Utilities) which are composed of self-managing, self-assembling, self-organising and self-destroying processes with exposed parametric and data input/output interfaces as well as its service description including non-functional aspects. The key is metadata (describing the SOKU processes and the data resources) and its use.