OGSA Evolution Policy Statement

			GGF "Drawer Statement"

		    Approved by GFSG on April 19th

			    David Snelling


Part of GGF's mission is to "define grid specifications that lead to
broadly adopted standards and interoperable implementations." In the
standards life cycle from new concept through to ubiquitously adopted
standard, there is a tension between innovation and interoperability.
For example, a partial solution standardized too early can fail to
become widely adopted; a plethora of designs can delay
standardization, and hence adoption. The GGF accepts the existence of
this dichotomy and aims to deal with it proactively, particularly in
the development of the Open Grid Services Architecture (OGSA).


Background:

In the strategy adopted by the GGF, three distinct levels of
interoperability provide a framework that allows both innovation and
standardization to proceed in parallel. The result we believe is an
architecture the can be quickly adapted to changes in the standards
landscape, while at the same time promoting the development of stable
reference standards on which interoperable implementations can be
built.

Interoperability at the lowest level, coined here the "Infrastructure
Level", is defined by OGSA to be the well-defined Web service
infrastructure as defined by the WS-I organisation, including SOAP,
WSDL, WS-Security, etc. We expect that in the short term W3C's WS-
Addressing will become part of this infrastructure level. At this time
the GGF has no plans to define interoperability profiles or perform
conformance testing at this level. All work on OGSA must comply with
these infrastructure requirements. Note that the GGF is open to
individuals wishing to define specifications and even architectures
that are not based on this infrastructure, however this work would
fall outside the sphere of OGSA.

Interoperability at the highest level, coined here the "Architectural
Level", is defined by OGSA in a GGF Informational Document (GFD.30).
This description is abstract in nature and therefore provides no
message exchanges, wire protocols, or detailed interface
specifications. As a result, only an abstract kind of interoperability
makes sense, and testing for compliance is not really possible.
However, two implementations that follow the design patterns set out
in GFD.30 and adhere to the requirements of the infrastructure level
could, with the development of "wrappers" or "adaptors", be made to
interoperate.

Interoperability at the middle level, described here as "Profiles for
OGSA", is defined by a set of "Profiles" refining collections of
detailed interface specifications (WSDL and Schemas) that are built on
the infrastructure requirements and conform (in an abstract sense) to
the architecture as defined at the Architecture Level. Two
implementations, conforming to the same set of Profiles are expected
to interoperate without modification. Profiles can capture domain
specific functions or common design patterns. A Profile describing job
submission and management, using JSDL and the Basic Execution Service,
is an example of the former; a Profile describing widely used grid
patterns, using WSRF and WS-BaseNotification, is an example of the
latter.


Policy:

To meet its aim of broad adoption, the GGF actively promotes the
development of specifications targeted at the grid community's needs
without restriction or limitation.  

However, in order to promote greater interoperability, the Open Grid
Services Architecture (OGSA) restricts the content and structure of
Profiles for OGSA (and hence the specifications they reference). These
restrictions are described as follows:

- Profiles must build on the Infrastructure Level as described above.

- Profiles must be consistent with the Architecture as defined by
GFD.30 (and its successor documents).


Notes:

These restrictions allow for the development of grid specifications
(including architectures) that are not based on Web services, but this
work is considered outside of the OGSA activity.  Although the
Profiles must remain consistent with the Architecture, there is no
requirement that all Profiles be consistent with each other. An
undesirable consequence of this is that implementations adhering to
different Profiles may not interoperate without modification or
adaptors, but this is offset by the advantage of a greater degree of
flexibility and innovation within OGSA and the GGF.

As the abstract architectural description of OGSA evolves (e.g.
successors of GFD.30), there is a risk that the Profiles and the
Architecture may become inconsistent. Although this inconsistency must
be rectified over time, the Profiles, the Architecture, or both may
need to be modified. In other words, both the Architecture and the
Profiles are informed by the each other, and neither dictates to the
other.