CrossGrid architecture diagram (click the picture to enlarge it)

The CrossGrid architecture consists of a set of self-contained subsystems, which can be divided into layers that contain applications, software development tools and Grid services. The components and layers are shown above. The application subsystem represents all the applications developed in CrossGrid namely Medical, the Flood Protection system, High Energy Physics and Air Pollution Modeling Applications.

Since the development of interactive applications requires also new developer tools, the second layer contains many useful ones: Using PPC the user can get knowledge about predicted preformance of the application, GridBench allows benchmarking Grid sites and systems consisting of many Grid sites, G-PM using OCM-G monitoring system allows on-line performance measurements of funning application and MARMOT helps writing correct MPI programs and displays logs with potentaila errors and warnings.  There are also the Migrating Desktop and the Portal that are the user friendly interfaces to CrossGrid.

The Grid services layer consists of the following subsystems: Roaming Access Server (RAS), Scheduler, OCM-G application monitoring, SANTA-G and JIMS infrastructure monitoring systems, postprocessing of monitored data, Opimisation of Data Access subsystem and GVK (Grid Visualization Kernel). In addition to the CrossGrid components, we also distinguish the most important external subsystems used, namely Globus Toolkit , EU DataGrid and MPI libraries.

All the subsystems of CrossGrid are developed as independent software pieces to facilitate the distribution of work between partners, to allow code reusability and exploitation of produced software in the future. However, there are many connections between these subsystems that make CrossGrid an integrated software environment for Grid application developers and users. These connections are depicted above using an UML dependencies diagram.  Arrows run from subsystems that use other CrossGrid modules to the ones being directly used by them.

The picture also includes types of interfaces.  The lines correspond to interfaces that are developed and running.  We have distinguished the Web service interfaces (SOAP), APIs, Protocols, Plugins and direct library link as interface types.

Job sumbission example ( the 5MB AVI movie with an audio explanation - click the picture to preview)