Service Design Patterns for Computational Grids

Abstract

Component integration has become an important area of research within the last decade ¡ª the intention being to combine a diverse set of custom and offthe-shelf components, from different vendors, to create applications. Components can implement simple functions, such as perform a matrix manipulation or perform a simple database query, or they can be more complex and wrap complete applications. Hence, the granularity of a component can vary from being coarse grained (when wrapping applications), to fine grained (when performing a simple database query). To facilitate the development of applications by combining components, an infrastructure is needed to enable components developed by different vendors to interoperate. The infrastructure must provide specialised services for managing, naming, locating and executing components, with standardisation efforts playing a crucial role in the process. Existing infrastructures such as DCOM from Microsoft, and CORBA/OMA from the Object Management Group (OMG), generally define this infrastructure in terms of (1) a component model, (2) containers which enable components to interact with services provided by the infrastructure, and (3) connectors, which enable components to interact with each other. The CORBA model for instance provides a platform independent language for defining component interfaces using an Interface Definition Language (IDL), and connectivity using an Object Request Broker (ORB). Infrastructure services within the CORBA model include persistence support, lifecycle support, a component naming service, a trading service for identifying services undertaken by components, and others.

Within the context of component based software, another concept has become increasingly important, and referred to as the “Grid”. The “Grid” or the “Computational Grid” (CG) signifies a component infrastructure that is based on the provision of infrastructure services which enable multi-vendor and