A new Architecture for OGSA-DAI

Atkinson, M.1, Karasavvas, K.1, Antonioletti, M.2, Baxter, R.2, Borley, A.3, Chue Hong, N.2, Hume, A.2, Jackson, M.2, Krause, A.2, Laws, S.3, Paton, N.4, Schopf, J. M.5, Sudgen, T.2, Tourlas, K.1 and Watson, P.6

1National e-Science Centre, 15 South College Street, Edinburgh EH8 9AA, UK

2EPCC, University of Edinburgh, James Clerk Maxwell Building, Edinburgh EH9 3JZ, UK 3IBM United Kingdom Ltd, Hursley Park, Winchester S021 2JN, UK

4School of Computer Science, University of Manchester, Oxford Road, Manchester M13 9PL, UK 5Mathematics and Computer Science Division, Argonne National Laboratory, Argonne, IL 60439, USA

6School of Computer Science, University of Newcastle upon Tyne, Newcastle upon Tyne NE1 7RU, UK

Abstract

OGSA-DAI is a widely used middleware infrastructure, aligned with the Global Grid Forum’s (GGF) OGSA vision, to facilitate uniform access to data resources using a service-oriented architecture (SOA). It is intended to provide a reference implementation of WS-DAI. Initially OGSA-DAI was based on the OGSI infrastructure but recent releases support WS-I, WS-I+, and WSRF. The change to these new specifications raised new issues and requirements. It has been taken as an opportunity to review all aspects of OGSA-DAI. This paper describes the new architecture for future releases and its rationale.

1 Introduction The Open Grid Services Architecture – Data Access and Integration (OGSA-DAI) project [1] was established to provide a uniform way to access data resources in alignment with OGSA [2]. It enables client applications to submit request documents in order to perform a set of tasks on a remote data resource. The initial versions of OGSA-DAI were built using the OGSI infrastructure [3] provided by GT3 [4]. More recently OGSA-DAI has been released on Axis [5], based on WS-I [6], the OMII_1 infrastructure [7], based on WS-I+ [8] and on GT4 [9] based on WSRF [10]. OGSA-DAI provides activities to access relational, XML databases, and indexed files. It also provides data translation and third-party delivery activities. This activity framework provides extensibility so that application developers can add their own activities. OGSA-DAI will provide a reference implementation of WS-DAI [11]. This paper describes the architectural requirements for future releases, the new architecture’s functionality and components and presents its rationale.

1.1 Experience OGSA-DAI has over 1100 registered users [12] including projects which require continuously available data access and integration services. The architecture of the early versions of OGSA-DAI was based on the assumption that web services were light-weight. For example, it assumed that new web services could be launched to handle each session between a data resource and a client. Similarly, it assumed that a new service could be produced to handle each data transfer to a data consumer. As a result

OGSA-DAI relied on the factory pattern to create independent grid services with a one-to-one relationship with the data they were handling. This meant that grid service handles provided a data naming system, failures were localised to a particular session and that persistence was only required for the accessed and handled data.

1.2 New Requirements The change from OGSI to WS-I+ and WSRF demands a change in the architecture as web services must now be considered long-running. For example, the SIMDAT [13] project believes its requests will run for several hours and requires concurrent requests [14]. This change has been taken as an opportunity to review all aspects of the OGSA-DAI, taking into account performance and operational issues uncovered through extensive use. The following architectural requirements were considered:

• All of the existing activities and facilities should continue to be supported.

• Each data service must support zero or more data resources (DRs) – dynamic configuration may add and remove DRs.

• This exposes complex naming requirements to name DRs and to use name systems provided by DRs.

• Each data service should be resilient to failures within activities and the data resources they access.

• Each data service should be configurable on installation and reconfigurable during operation.

• Each data service should be manageable and persistent, i.e. they should recover after site, platform and internal failures.

• The same architecture should accommodate rapid requests for small tasks (execution of an activity) and tasks involving large volumes of or continuous streams of data.

• The data services should support concurrent sessions and transactions.

• The power of request documents should be extended – to support a broader set of data sources and operations.

• The data services should be able to accommodate standard interfaces such as transaction coordination services.

• The data resources should be an additional OGSA-DAI extensibility point to allow the dynamic exposure of new virtual data resources, e.g. to support an OGSA-DQP [15] federation.

• The extensibility framework based on activities should be stabilised to protect application developer investment –

taking into account the above requirements.

This architecture must be amenable to implementation over a number of platforms (WS-I/Axis, WS-I+/OMII, WSRF/GT4 and other systems of interconnecting services) and must be achieved incrementally without undue disruption of the development process. The further development of data integration activities must also continue.

The new architecture should protect application development investment. A client-side API already hides variations in the web service infrastructure so that investment in client applications is protected from change and the clients can be used unchanged on all new versions of OGSA-DAI. A new context will be defined for activities. In this case, OGSA-DAI provides a container for the activities developed by application programmers. It is intended that the APIs in this context will remain stable and will protect the activities from web service infrastructure variations.

2 Overview of Architecture The primary components of the new architecture are shown in Figure 1.

Figure 1: New OGSA-DAI Architecture

The architecture looks forward to multiple data services administered through a consistent regime. In the figure we can see three data services: one serves OGSA-DAI, one serves the WS-DAI standard [11] perhaps as a configuration of OGSA-DAI and one serves Mobius [16].

2.1 Data Resources

By data resource (DR) we mean any entity that can act as a source and/or sink of data together with its associated management framework. Currently, OGSA-DAI works with six relational DBMS, two native XML DBMS, file systems, and indexed files. Its scope however is more general.

OGSA-DAI provides an extensible framework that allows flexible representation of a data resource. The latter need not be a single physical resource, e.g. RDBMS, but they could also represent complex virtual data resources. For example, a federation of many physical data resources can be represented as a single virtual data resource. This allows for new data resources to be easily added to OGSA-DAI, like streamed data [17], or indeed any kind of entity that can act as a data source and/or sink.

2.2 Data Services

A data service (DS) provides the entry point for clients who want to access data resources. It can be discovered using a registry or from a DRAM (see section 2.10). A data service could expose zero – in case it only provides data translation and/or delivery functionality – to many data resources. A DS can be dynamically configured. For example, new data resources can be added dynamically or the authorisation settings to access the DR(s) could be changed.

As we mentioned in the introduction, OGSA-DAI is built to support many different platforms/specifications. For each one the client would need to make the appropriate (SOAP) requests depending on the DS. However, OGSA-DAI provides a client-side library – the client toolkit (CTK), which offers a programming abstraction and provides a common interface to all these platforms, i.e. the same code can be used whether accessing an OGSA-DAI WS-I or WS-RF data service. Developers need only learn the application programming interface (API) provided by the client toolkit to access any OGSA-DAI data service.

2.3 Activities and Tasks

Because of the large and extending variety of data resources, it is necessary to devise an open-ended scheme for attaching data resources and introducing the languages and operations they support. We do this by providing activities, each of which may address a different resource in an appropriate language. They all fit in a consistent framework.

In OGSA-DAI, an activity represents the basic unit of work. A task is the execution of an activity on some specified data with specified parameters. Activities can provide any kind of functionality but they can roughly be categorised into three main functional groups: (a) statement activities that provide access to DRs (e.g. sqlQueryStatement, xPathStatement), (b) translation activities that perform transformation on the data (e.g. xslTransform, zipArchive), and (c) delivery activities that deliver or collect data to/from third-parties (e.g. deliverToURL, deliverFromGFTP).

We differentiate between three types of activities:

1. Core activities: simple activities that deal with internal OGSA-DAI functionality. These activities cannot be overridden. For example, activities that initiate an OGSA-DAI session or transaction (see later sections).

2. Supplied activities: current activities provided in OGSA-DAI releases – these may be overridden, e.g. when testing a new version.

3. Extension activities: written by community developers for specific purposes, e.g. for a new data resource or an application-dependent data transformation. Potentially, these activities could override the supplied activities.

OGSA-DAI provides an extensible activity framework. Developers can easily add their own (extension) activities according to their needs. This has proved to be a particularly flexible and valuable extension point. In the new architecture, it is enhanced to support additional functionality, for example, permitting extension activities to use session information, engage in transactions and write diagnostic or audit information to logs. The new architecture also requires notifications be produced by activities to permit monitoring, accounting and failure detection.

Request for the execution of a number of activities can be grouped together into a document and sent to a data service into a single message.

2.4 TADD, Requests and Results

A Task And Data Document (TADD) permits a number of tasks to be specified, together with their parameters, inputs, outputs, data flow between them and control flow. This composite format can be used to submit simple requests, to avoid unnecessary round-trip latencies, to report status and results, and to delegate or cascade work. Its ability to contain data (e.g. for a bulk-load activity) further reduces communication that would be needed, for example, to collect the data to bulk-load. A TADD can be used as both a request and a result document, hence the change of name from Request Document in the previous architecture.

Control flow allows a client to specify the order of task execution and which tasks can be run in parallel. Data flow allows the connection between activities to create pipelines for efficient data processing, using streamed interconnections between activities.

Each activity can support one or more languages that define the request. For example, SQL statement activity will accommodate any dialect or version of SQL that the targeted data resource will process. The XSLT transformation activity takes XSLT and so on. This permits clients to exploit any special properties of a data resource or data transforming activity. It has the downside that clients are not protected from the variations that are common among relational databases. In most current use the clients choose data sources and are aware of the dialect used. We are investigating the use of SwisSQL [18] for code which requires independence from target data resource.

It is worth noting that the client developers are not expected to craft TADD documents by hand. Instead, the client toolkit is used, which provides an API to hide the details of a request’s (TADD) format from developers – for example they need not know or write any XML to formulate requests. In addition, the client toolkit shields developers’ code from future changes to the TADD’s format and structure.

2.5 Sessions

A session allows sharing and management of state (context) between several TADDs. Sharing state enables us to:

• to accommodate external decisions, e.g. intermediate results are stored in the session and the client can decide how the process continues,

• retain results awaiting delivery or collection (see later section on DIDs),

• retain transactional information, and • retain security information, localised

identifiers, connection information caches, and similar data.

Sessions are OGSA-DAI internal entities. For a request to join a session the TADD will contain the appropriate information, e.g. the session identifier (SID). SIDs can be one of three types. First, implicit SIDs, when the request contains no information about sessions. This provides backwards compatibility and simplicity for single request sessions. In this case, a session will be created only for this request. A request containing an explicit OGSA-DAI session identifier will join that session and it will be able to access (and store) state to it. Finally, the request can contain information for a new SID (session) to be created. Such a request can also contain session configuration parameters (lifetime, authorisation, etc.). Session functionality will also be managed by the appropriate core activities (e.g. createSession).

2.6 Transactions Transactions are fundamental for many techniques to ensure the integrity of a resource. Two main applications are dealing with potential inconsistencies introduced by concurrent access and recovery from failures in case the system crashes or an error occurs while executing a transaction. A transaction groups a number of activities into one unit of execution (e.g. for atomicity). Moreover, a single activity might contain multiple lower-level operations. These, also have to be transactional. Transactional state is stored in a session.

OGSA-DAI will provide a consistent transactional framework and facilities to allow developers to add transactional behaviour to their activities. This includes:

• a backward-compatible and uniform way to describe transactional metadata and behaviour for each activity and for each exposed data resource that supports transactions,

• the logical rules for combining the behaviour of transactional activities

and activities that access transactional DRs, and

• a set of core activities to manage transactional behaviour (e.g. a commitTransactionActivity).

The progress of a transaction will be recorded to a transactional log that will be later used by the recovery component to restore the DS and its underlying resources to a consistent state.

A transaction coordinator component in the DS will enable distributed transactions within that DS, i.e. when a DS exposes multiple resources and the TADD contains a transactional request involving more than one resource. In addition, we can have a distributed transaction involving multiple DSs. In such a scenario there usually are external coordinators to orchestrate interactions between the participants (DSs). Activities performed as a session or as the result of an individual request document may be part of some distributed transaction coordinated by a standard coordination protocol. It is therefore necessary to support the interfaces, functionality and protocols required by a standard distributed transaction coordinator, such as WS-AtomicTransaction (WS-AT) [19] (also see section 2.9).

2.7 DIDs

Data Identifiers (DIDs) are used to describe the handling of intermediary and externally available results. Data identified by DIDs can contain the data provenance information, the format the data is in, as well as the data itself. DIDs are stored in a session, so that other tasks in a request or subsequent requests that join the session can access them. Although, DIDs lifetime is that of the session, a set of core activities will allow the client to further manage them. For example, the client would be able to discard a DID or make it externally visible by creating a universally unique DID (UUDID) that may outlive the session and be accessed by an incremental data access protocol, such as ByteIO [20] or by other sessions.

2.8 ODE Data Services (DS) have at their core the OGSA-DAI Engine (ODE) that provides a framework for activity and task management. The ODE is being revised to support dynamic configuration, sessions, transactions, recovery and concurrency.

The model of execution can be seen in more detail in Figure 2. The response to a request is

generated by the ODE within a session, which is either created of joined as we assume in the diagram. The ODE analyses incoming TADDs conducts authentication and constructs an internal representation of the request (e.g. a directed acyclic graph (DAG)). The Task Form encapsulates data about authorisation, external relationships, e.g. client identity, and so on, so these may be used abstractly by tasks. The tasks specified in the DAG are then checked for authorisation over the authenticated user’s privileges.

Figure 2: OGSA-DAI Engine Execution

Model

Further analysis and optimisation of the task DAG would create an optimised execution plan that would then be evaluated. Evaluation is overseen by an internal monitoring system to detect excess resource consumption and provide resilience. The following figure illustrates the internals of an execution coordination thread.

Figure 3: Execution Coordination Thread

A request can be part of a transaction, in which case, appropriate measures can be taken. Then, the result TADD (could be more than one) is created so that it can be later populated and potential third-party collections are initiated as soon as possible. The optimised execution plan is then evaluated by spawning activity threads (according to the TADD’s control and data flow description) which use pipes and a Transfer Assembler pattern [21] to handle arbitrary scale

intermediates and results respectively. Third-party deliveries could be started as soon as data are available and on activities completion the result TADD(s) are populated with each activity’s data and execution statuses as appropriate. Finally, cleaning up takes place, discarding state in terminating sessions, informing the monitoring system of completion, etc. and the result TADD is sent back to the requester. Hibernation retains transaction and session state in non-terminating cases. Lifetime management is required over hibernated state to avoid permanent resources loss when clients fail. We are considering pooling mechanisms to reduce initialisation overheads.

2.9 Special Interfaces An important requirement is a DS’s ability to accommodate standard web service interfaces, particularly WS-DAI, or interfaces that require specific message protocols, such as distributed transactions coordination protocols (e.g. WS-AtomicTransaction [19]). These special interfaces will be implemented by binding their ports to code that constructs an equivalent execution graph. The results produced as a TADD by the transfer assembler will be translated to the expected result format. As a matter of principle such functions should also be available through a standard activity in a TADD. Conversely, activities that workflow enactments may require should also appear via “standard” WSDL-defined ports. In this way, functions required by one community via a special interface, e.g. WSRF getResourceProperties, will also be available as a task in a request document.

2.10 DRAM: Configuration and Monitoring

The Data Resource Access Manager (DRAM) is a persistent service that provides administrator and management interfaces for a set of data services. It provides the ability to initiate and configure a DS as well as monitoring and controlling it. For example, a DRAM would know if the DSs that it manages are still running and it will also be able to reconfigure them to support an additional data resource (DR). A DRAM will monitor a DS’s status digest produced by its internal monitor. If this shows potential problems it may reconfigure or restart the DS from its last checkpoint.

A DRAM can be discovered via a registry and it constitutes a gateway to a set of DRs. It could contain explicit DR names or use further

registries to get available resources. A DRAM will have access to processing resources – like single or multi-processor (SMP) machines, processing farms, etc. – and can initiate and configure a DS, on its available computational resources, to access one or more of its supported data resources. Data services supported by a DRAM would be OGSA-DAI, Mobius, other federation and integration services or indeed any other service that exposes data resources.

The initial configuration of a data service is described in the Data Service Description Language (DSDL). Most aspects of a DS will be described by this XML file, which should be built as much as possible from existing standards, such as Management of Web Services (MOWS) [22]. Elements of DSDL will include the type – and potentially configuration – of a data service (e.g. OGSA-DAI), the DS’s longevity, the name or description of a data resource, and quality of service and security requirements.

2.11 Naming A name is used to identify an entity. The OGSA work on naming [23] distinguishes between three layers for names; human names (easily generated and read by humans), which are mapped to abstract names (persistent and globally unique names), which are in turn mapped to addresses (the physical locations of the identified entities). Entities that need to be named in OGSA-DAI include: registries, DSs, DRs, DRAMs, sessions, transactions, result sets (DIDs, UUDIDs), TADDs, activities and tasks.

There are many challenges involved in naming data. Not only is there a large number of data collections, but there are also many individual naming systems - per technology provider (OS and DBMS), per project, organisation or community and those invented by individuals. Moreover, there are many data values, such as data sets awaiting delivery, which maybe needed to be named, e.g. publicly as a UUDID or privately for logs, audit trails and diagnostics, where a UUID may suffice. The relationships between names are complex, for example with synonyms, names of copies and names of a subset of some larger, possibly mutable, data set.

Architecturally, OGSA-DAI must accommodate the naming schemes in use in the context in which it is being applied and must meet standard requirements, as well as application requirements. This is more significant in the new architecture as multiple data resources are accommodated within on data service (for

efficiency and management reasons). This then requires TADDs to contain tasks that operate on a specified DR. This will be achieved by including a name in the task specification. To achieve backwards compatibility and to accommodate standard protocols not equipped with names, it is necessary to set a default DR. This can be done at configuration time or within a session or request using a core activity.

The current evaluation plan is to experiment with handle.net [24] and then to accommodate the OGSA naming standards. We anticipate that the generality of handle.net is sufficient to meet all of these requirements.

The cost of name resolution, possibly through intermediate names could be high. However, the DS can have a local resolver for all of its local DRs and incrementally populate this by interrogating data sources (such as file stores and DBMS) as names are introduced in the sequences of TADD messages. Caching can reduce the mapping costs of external names, for example those used in third-party transfers.

It is sensible to allow clients to reduce name resolution costs by requiring that the language design principle of substitutability is adhered to in the syntax of TADDs. That is, wherever a name is permitted, it should be possible to substitute an address (represented as WS-Address) and in most cases, where the resolution mapper can be reliably inferred, the inverse is also true.

3 Status and Future Work In the upcoming OGSA-DAI release 7, data services are (re)configurable, provide concurrency, and support sessions and transactions (first implementation stage of a well-defined phased implementation plan). In addition, all existing activities and functionality are still supported, while a new extensibility point, that of adding data resources dynamically, has been added. A detailed status report including benchmarks can be found in [12].

The next few releases of OGSA-DAI will complete the engineering of this architecture and exploit it with new data activities and data resources. New activities will include interfaces to other data stores, distributed query, resilient multi-source unions, schema and data integration, standard tools for extracting data from files, and standard computations, such as statistical analyses.

We expect to invest significant effort in engineering good performance. This will

include improving parallelisation of data flow and investigation of improved structured data transfer formats, e.g. based on SOAP Message Transmission Optimization Mechanism (MTOM) [25] and Data Format Description Language (DFDL) [26]. There are difficult trade-offs between translation costs, transfer costs and simple APIs for activity developers. High-performance systems will need to be closely coupled to data management and storage systems. Integration with widely used authorisation systems, e.g. Shibboleth [27], accounting systems, portals, e.g. GridSphere [28] or WebSphere [29], and diagnostic tools is called for. It remains to be seen whether the planned architecture will meet all of those needs as we hope.

The activity framework is a powerful mechanism for extension and for managing complexity. It also provides a framework in which to manage contributed extensions to OGSA-DAI. In the longer-term we anticipate dynamically installing extension activities delivered via requests from clients planning to use them. This will support incremental development of continuously operating data services and performance gains from moving relatively small volumes of code to relatively large volumes of data. However, this will depend on the activity framework providing a robust container and safety net.

4 Conclusions In this paper we presented the OGSA-DAI’s architecture evolution as it progresses to comply with new specifications and service-oriented architecture requirements in an open and highly dynamic environment. First, we discussed the rational for the change and a set of required functionalities. Then, we presented an overview of the architectural components and described each one, the functionality it provides, and its purpose within the overall design. Finally, we concluded with a brief status report and future directions. Acknowledgements: This work is supported by the UK e-Science Core Programme and in part by the Mathematical, Information, and Computational Sciences Division subprogram of the Office of Advanced Scientific Computing Research, Office of Science, U.S. Department of Energy, under Contract W-31-109-ENG-38. We also gratefully acknowledge the input of our past and present partners and contributors to the

OGSA-DAI project including: IBM Corp. and Oracle UK.

IBM and DB2 are trademarks of International Business Machines Corporation in the United States, other countries, or both. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States and other countries. Other company, product, or service names may be trademarks or service marks of others.

© Copyright International Business Machines Corporation, 2005. © Copyright The University of Edinburgh, 2005. © Copyright University of Manchester, 2005. © Copyright University of Newcastle upon Tyne, 2005.

5 References 1. Antonioletti, M., Atkinson, M, Baxter, R.,

Borley, A., Chue Hong, N., Collins, B., Hardman, N., Hume, A., Knox, A., Jackson, M., Krause, A., Laws, S., Magowan, J., Paton, N., Pearson, D., Sugden, T., Watson, P. and Westhead, M., The design and implementation of Grid database services in OGSA-DAI. Concurrency and Computation: Practice and Experience, 2005. 17(2): p. 357-376.

2. Foster, I., Kishimoto, H., Savva, A., Berry, D., Djaoui, A., Grimshaw, A., Horn, B., Maciel, F., Siebenlist, F., Subramaniam, R., Treadwell, J. and Von Reich, J., The Open Grid Services Architecture, Version 1.0. 2005.

3. Tuecke, S., Czajkowski, K., Foster, I., Frey, J., Graham, S., Kesselman, C., Maquire, T., Sandholm, T., Snelling, D. and Vanderpilt, P., Open Grid Services Infrastructure, Version 1.0. 2004.

4. Globus, Globus Toolkit 3.2.1. 2004. 5. Apache, Axis. 2005. 6. WS-I, Web Services Interoperability, Basic

Profile 1.0. 2004. 7. OMII, OMII_1. 2005. 8. Atkinson, M., DeRoure, D., Dunlop, A.,

Fox, G., Henderson, P., Hey, T., Paton, N., Newhouse, S., Parastratidis, S., Trefethen, A., Watson, P. and Webber, J., Web Service Grids: an evolutionary approach. Concurrency and Computation: Practice and Experience, 2005. 17(2): p. 377-390.

9. Globus, Status and Plans for the Globus Toolkit 4.0 (GT4) as of May 1 2005. 2005.

10. OASIS, WS-ResourceFramework. 2005. 11. Antonioletti, M., Atkinson, M., Laws, S.,

Malaika, S., Paton, N., Pearson, D. and Riccardi, G. Web Services Data Access and Integration (WS-DAI). in 13th Global Grid Forum. 2005. Seoul, Korea.

12. Antonioletti, M., Atkinson, M., Baxter, R., Borley, A., Chue Hong, N., Dantressangle,

P., Hume, A., Jackson, M., Karasavvas, K., Krause, A., Laws, S., Parsons, M., Paton, N., Schopf, J., Sugden, T., Tourlas, K., Watson, P. and Vyvyan, D. OGSA-DAI Status and Benchmarks. in UK e-Science All Hands Meeting (to appear). 2005. Nottingham, England.

13. SIMDAT, Consolidated Requirements Report, Roadmap and SIMDAT Infrastructure Design. 2005.

14. Borley, A., Personal Communication (SIMDAT). 2005.

15. Alpdemir, N., Mukherjee, A., Gounaris, A., Paton, N. W., Watson, P., Fernandes, A. A. A. and Fitzgerald, D. J. OGSA-DQP: A Grid Service for Distributed Querying on the Grid. in Ninth International Conference on Extending Database Technology (EDBT). 2004.

16. Hastings, S., Langella, S., Oster, S. and Saltz, J. Distributed Data Management and Integration Framework: The Mobius Project. in GGF11 Semantic Grid Applications Workshop. 2004. Berlin, Germany.

17. Plale, B., Framework for Bringing Data Streams to the Grid. Scientific Programming, 2004. 12(4).

18. AdventNet, SwisSQL. 2005. 19. WS-AT, Web Services Atomic Transaction.

2004. 20. GGF, Byte-IO Working Group. 2005. 21. Gamma, E., Helm, R., Johnson, R. and

Vlissides, J., Design Patterns. 1995: Addison-Wesley Professional.

22. OASIS, Web Services Distributed Management: Management of Web Services (MOWS). 2005.

23. Grimshaw, A., Naming in Distributed Systems (OGSA Naming Design Team working note OGSA-Naming-02). 2004.

24. Sun, S., Lannom, L. and Boesch, B., Handle System Overview, in Request for Comments 3650. 2003, Internet Engineeting Task Force (IETF).

25. W3C, SOAP Message Transmission Optimization Mechanism. 2005.

26. GGF, Data Format Description Language Working Group. 2005.

27. Internet2, Shibboleth Technical Overview. 2005.

28. Novotny, J., Russell, M. and Wehrens, O. GridSphere: A portal framework for building collaborations. in The First International Workshop on Middleware for Grid Computing. 2003.

29. IBM, WebSphere. 2005.