The Eight Areas of OGSA Are Briefly Introduced Below

1. What is OGSA? (definition)

OGSA is an “open, service-oriented architecture,” based on Web services, for realizing Grid scenarios. “Open” refers to both the process to develop standards and the standards themselves. It is “service-oriented” because it delivers functionality as loosely-coupled interacting services. The “architecture” is the definition of the components, their organizations and interactions, and the design philosophy used.

1. What are the key architectural areas associated with OGSA and how do they fit together? (taxonomy and definitions of each area)

OGSA v1 defines eight broad areas, defined in terms of capabilities that are frequently required in Grid scenarios. These capabilities are provided by functional behaviors of services, often through interaction with other services. It is important to note, though, that while there may be interdependencies between services, not all services need be used at any given time—different use-cases may call for different subsets of services.

The eight areas of OGSA are briefly introduced below.

• Execution Management Services  Concerned with issues such as starting and managing tasks, including placement, provisioning, and lifecycle management. Tasks may range from simple jobs to complex workflows or composite services.
• Data Services  Provide functionality to move data to where it is needed, manage replicated copies, run queries and updates, and transform data into new formats. Data consistency, persistency and integrity are key requirements satisfied by these services.
• Context Services  Supply a context that can be used to associate users, their requests, and a set of resources. Resource sharing is necessarily controlled by the policies set by resource owners, and negotiation is required to establish the context that allows a user to access a resource.
• Information Services  Provide efficient production of, and access to, information about the Grid and its constituent resources. The term information refers to dynamic data or events used for status monitoring; relatively static data used for discovery; and any data that is logged. Troubleshooting is just one of the possible uses for information provided by these services.
• Infrastructure Services  Refer to a set of common functionalities typically required by higher level services. As OGSA builds on Web services technologies, service interfaces are defined by the Web Services Description Languages (WSDL). Infrastructure includes emerging standards such as the Web Services Resource Framework (WSRF), WS-Notification (WSN), Web Services Distributed Management (WSDM), and Naming.
• Self-Management Services  Support service-level attainment for a set of services (or resources) – with as much automation as possible, to reduce the costs and complexity of managing the system. These services are essential in addressing the increasing complexity of owning and operating an IT infrastructure.
• Security Services  Facilitate the enforcement of security-related policy within a (virtual) organization, and support safe resource-sharing. Authentication, authorization and integrity-assurance are essential functionalities provided by these services.
• Resource Management Services  Provide management capabilities for Grid resources: management of the resources themselves, management of the resources as Grid components, and management of the OGSA infrastructure. For example, resources can be monitored, reserved, deployed and configured as needed to meet application quality-of-service requirements.

1. Why is OGSA critical to the pervasive adoption of standards-based distributed computing?

Because there is considerable overlap between the goals of distributed computing and the clear benefits of a service-oriented architecture (SOA) based on Web services. Rapid progress has been made in evolving Web services technology and standards, and there is now a natural evolutionary path from the “stovepipe” architecture of current Grids to the standardized, service-oriented, enterprise-class Grid of the future.

1. Can you describe several customer use cases driving the OGSA architecture and how these use cases are satisfied? (1 research slide, 1 business slide)

<entire table for now; need to narrow down to a few major ones>

Analysis of the use cases and other relevant input led us to identify both important and apparently broadly-relevant characteristics of Grid environments and applications, and functional and non-functional requirements that appear to have relevance to a variety of application scenarios.

Our goal in defining OGSA is to define a coherent and integrated set of components that collectively address the requirements identified, within the context of a service-oriented architecture. For example in the case of the XYZ use case <…>

1. What is the overall process by which the OGSA architecture becomes more concrete specifications and standards - and how does this then get adopted into software products by the open source and software vendor communities?

The process by which we see OGSA being further refined is shown in Figure 1.

A key issue is that the “top down” and “bottom up” worlds are to be coordinated as follows:

• OGSA-WG is concerned with defining requirements and overall architecture: the lighthouse towards which others may steer.
• WGs within GGF or other bodies may (hopefully will!) be formed to develop specifications that speak to requirements identified by OGSA-WG.
• The steps by which a technical specification may become identified as “OGSA compliant” remains to be clearly defined. A key requirement might be identification as a “recommendation” in the sense that there are two or more interoperable implementations.
  

Figure 1. OGSA definition process

1. What is the current status of OGSA? (OGSA v1 Informational Document and what is the definition of Informational Document) (OGSA v2.0 Recommendation Document and what is the definition of a Recommendation Document)

The WG is working on finalizing OGSA v1, a GGF informational document. An informational document does not define any standards but we felt that releasing the first version of OGSA in this form was an appropriate choice in order to provide a snapshot of the work of the group and receive feedback from the community. OGSA v1 has recently completed a 30 day public comment period. We received a lot of good feedback and are now revising the document for final submission to the GGF Editor.

We expect that a later iteration of this document will become a recommendation document. A recommendation document would define OGSA as a standard. In particular it would then be possible to define what OGSA interoperability means. However a lot of work is needed before such a recommendation document can be completed.

1. What are the priorities for OGSA v2.0?

OGSA-WG is now working on this issue and will publish our roadmap document at GGF13. Your input is very welcome.

1. Do you have a roadmap for OGSA?

The OGSA-WG is working on a roadmap document. A first draft of the roadmap was presented at GGF12 (September 2004). We expect to have a more complete, possibly final version, by GGF13 (March 2005). We are actively soliciting input from the community to help set the right priorities. As in any standardization process, we need to be careful not to standardize prematurely, i.e., standardize without adequate experience and/or buy in from its eventual users. These issues are particularly important in the case of OGSA, due to the particularly large gap between our ambition and experience.

1. What is the timeline for completion of OGSA v2.0?

OGSA v2.0 is series of document. There are three “root” specification documents. The OGSA Use Cases document describes the use cases or scenarios that motivate the design of OGSA. The main OGSA document summarises the requirements and capabilities of the architecture. The OGSA Glossary defines the terms used throughout these documents. For OGSA v1.0 and v2.0 these are all GGF Informational documents.

For each topic within the architecture, a design team is responsible for producing two sub-documents. The Service Description document describes the services in the topic in natural language, listing the key interfaces and key operations defined by each service and how they are intended to be used, without going into detailed specifications. The Scenarios document demonstrate how these services can implement the use cases, using a combination of natural language and UML. These are GGF Informational documents.

Finally, each service is specified by an appropriate working group, as are other components such as description languages and schemas. These specifications are GGF Recommendation documents. They specify the services using a mixture of WSDL and natural language.

We hope root documents, the Service Description documents, and the Scenarios documents become available at GGF14. Also a couple of, but not all of, concrete interface specifications are available at that time.

1. What specific specifications within OGSA v2.0 will be finalized and how did you choose these specifications?

It is too early to name specific specifications to be finalized in OGSA v2. We do expect to focus onthe Data and Execution Management capabilities as these are the capabilities most often provided by Grids. Also Naming is an important enabling functionality that is still insufficiently addressed in existing standards work. A more detailed answer to this question depends on further refinement of the Roadmap.

1. What standards are important to the realization of OGSA and why?

Our goal in defining OGSA is to define a coherent and integrated set of components that collectively address the requirements, within the context of a service-oriented architecture. We must necessarily make assumptions about the infrastructure on which we build if we are to make concrete statements about higher-level services.

The primary assumption is that work on OGSA both builds on, and is contributing to the development of, the growing collection of technical specifications that form the emerging Web services (WS) architecture. Indeed, OGSA can be viewed as a particular profile for the application of core WS standards. We made this choice because of a strong belief in the merits of a service-oriented architecture and our belief that the Web services architecture is the most effective route to follow to achieve a broadly-adopted, industry-standard service-oriented rendering of the functionality required for Grid systems.

1. What is the status of these individual standards today and where will we be when OGSA v2.0 is published as a recommendation document?

A number of basic standards we expect to build on, such as WS-RF, WS-N, WS-DM, have entered the standardization process and should be available in time for v2. …

1. Which OGSA-inspired standards will be driven out of GGF and which will be driven out of other standards organization - and why?

As a consequence of the successful completion of the OGSA V1.0 document, it is now clear that the magnitude and scope of the work that still needs to be done is greater than a single working group or even standards body should attempt on its own. In seeking a way to proceed, we can see that a lot of related work is already carried out in other standards organizations and we think that each specification should be created at the most suitable organization.

1. Which open source and packaged software vendors support OGSA and what does support really mean?

OGSA support at the moment means primarily a willingness to be involved in the OGSA definition and standardization process. <list of ogsa-wg participants>

1. Which OGSA specifications are likely to show up in ISV software implementations in 2005, 2006?

Data service specification, for example DAIS.

1. Will ISV's certify software products to be OGSA compliant and what does OGSA compliance mean anyway?

We have already seen a strong desire from a variety of companies and projects to describe their products as OGSA compliant. We think this desire will become stronger as OGSAaddresses in a standard manner the complex challenges presented by Grid scenarios, such as security (authentication, authorization, trust, and data integrity), fault-tolerance (meeting service-level agreements, availability, etc.), scheduling and resource management, and data management.

Unfortunately it is not possible to talk at this moment of OGSA compliance. We realize that this is one area of great importance not just to ISVs but to the community as a whole and intend to provide guidance as soon as possible.

1. Many ISV's have grid-related software offerings today prior to the finalization of OGSA. Will these software vendors have to retrofit there products once OGSA v2.0 is completed?

In order to achieve interoperability of these products, OGSA will be adopted by commercial product gradually. Similar to the Internet technologies more connectivity and interoperability mean more benefit to end users.