|
|
| |
|
|
|
Frequently Asked Questions |
WS-GAF FAQ
-
Question: What is the goal of the WS-GAF proposal?
(added: 01 October 2003, updated: 01 October 2003)
- The WS-GAF proposal is an attempt to start a technical discussion
about the possible future evolution of the
OGSI
specification beyond its v1.0 release. As we said in the document
conclusions,
-
- "when the OGSI working
group started work on providing solutions for the Grid requirements,
they made the sensible decision to use Web Services technologies
for their infrastructure, and invented solutions that met Grid
requirements. At that time, the number of Web Service specifications
with which they could work was limited, and hence, they had
to devise solutions to problems that the Web Services community
encountered at a later stage."
-
- The result of their work was OGSI v1.0. Now that OGSI v1.0
has been adopted as a GGF recommendation, we think that it is
a good time to start to look at the Web Service technologies
that are now available and consider if and how they could be
utilised in the future evolution of OGSI. Our aim in doing this
is to maximise the synergy between the Grid community and the
wider WS community, to the benefit of both parties.
top
- Question:
What is a service? How do you define a service? (added: 01 October 2003, updated: 01 October 2003)
- In version 1.0 of our document,
a definition of the term "service" is given as follows:
"A service is a well-defined set of actions,
it is self-contained, stateless, and does not depend on the
state of other services." (version 1.0, section 2.1,
page 2).
From an article to be published in the November issue of the
Web Services Journal (by Jim Webber and Savas Parastatidis)
a service can be defined as
"... a logical manifestation of some physical
resources (like databases, programs, devices, or humans) that
an organization exposes to the network."
The literature contains many other definitions of a service,
most of which are consistent with the two above.
top
- Question:
You have used the term "stateless Web Services" in your document.
Do you think that Web Services cannot deal with state? Are Web
Services just "computational entities"? (added: 01 October 2003, updated: 01 October 2003)
- In version 1.0 of our document,
we referred extensively to Web Services as "stateless". After
the initial feedback we have received to date, it has been made
apparent to us that our position has been misunderstood
by some. In Section 2.1 of the document, we say that...
"Here, stateless means that each time
a consumer interacts with a Web Service, an action is performed.
After the results of the service invocation have been returned,
the action is finished. There is no assumption that subsequent
invocations are associated with prior ones."
So, when we refer to "stateless Web Services," we refer to
the lack of their ability to correlate messages without some
additional help. The OGSI Grid Service Instance idea has been
used by the community as a way to implement stateful interactions.
We propose contextualised interactions as an alternative; we believe that
it is the way in which stateful interactions are being handled
in the wider Web Services world (e.g. in the following specifications
use take this approach: WS-Coordination, WS-Transactions, WS-Security,
WS-Context, WS-CoordinationFramework, WS-TransactionManagement).
Therefore, we propose WS-Context (or an equivalent contextualisation
scheme) as a mechanism to correlate messages in stateful interactions
between one or more service and one or more consumer.
We want to make it clear that by "stateless Web Services"
we do not mean that services are not allowed to have internal
state; no useful application would be implemented if that was
the case. Nor we suggest that each message should carry all
the application-specific state.
top
- Question:
How do services deal with internal state? (added: 01 October 2003, updated: 01 October 2003)
- The way in which services deal with internal state is an implementation
detail that should be hidden from the "outside" world. The management
of the internal state and resources should be of no concern
to the consumers of that service neither should any
mechanisms providing direct access to those resources should
be made available. Furthermore, the way a protocol,
like WS-Context, is implemented, and the way any protocol-specific
or application-specific state is maintained should remain an
internal-to-the-service issue.
However, we recognise that there may be exceptional
circumstances where an internal-to-the-service resource
might have to be exposed to consumers (e.g., in a
data-oriented service the result of a query may be so large
that for performance reasons it is kept locally and
consumers are given a way to refer to it). We propose
the Grid Resource Identifier (GRI) as a way to uniquely
identify exposed resources, when that is absolutely
necessary, and the Grid Resource Metadata (GRM) document as
a way to capture metadata about an identified resource. The
Grid Resource
Specification has more details on GRIs and GRMs.
Please, refer to the related question/answer on
"stateless
Web Services" which discusses consumer-service interactions
and the
Grid Resource
Specification which deals with resources.
top
-
Question: Is it fair to base your design on relatively new
specifications that were not available when the OGSI 1 designers
began their work? (added: 01 October 2003, updated: 01 October 2003)
- As we say in the document conclusions,
-
- "when the OGSI working
group started work on providing solutions for the Grid requirements,
they made the sensible decision to use Web Services technologies
for their infrastructure, and invented solutions that met Grid
requirements. At that time, the number of Web Service specifications
with which they could work was limited, and hence, they had
to devise solutions to problems that the Web Services community
encountered at a later stage."
The result of their work was OGSI v1.0. Now that OGSI v1.0 has
been adopted as a GGF recommendatoin, we think that it is a
good time to start to look at the Web Service technologies that
are now available and consider if and how they could be utilised
in the future evolution of OGSI. Our aim in doing this is to
maximise the synergy between the Grid community and the wider
WS community. We are therefore looking forward to the future
of OGSI rather than looking backwards at decisions made in the
past.
top
- Question:
Are the web service specifications referred to in the paper,
such as WS-Context, sufficiently well developed to consider
adopting them for OGSI v2.0? (added: 01 October 2003, updated: 01 October 2003)
- We believe that it is sensible to look at specifications
that could be adopted by a future version of OGSI. Obviously
it is better to adopt standards rather than specifications,
but using existing specifications is better than inventing alternatives,
unless no existing standard or specification meets the requirements.
The high cost in terms of effort and elapsed time of developing
new specifications has been one of the lessons of the early
years of the GGF.
It is also the case that the WS-GAF design is not dependent
on WS-Context. Whilst the WS-Context specification is new, it
is the principle of contextualisation that has become, we believe,
the normal way of dealing with stateful interactions in the
WS world (many other specifications use it, e.g. WS-Coordination,
WS-Transactions, WS-Security, etc.), and so some other scheme
could be adopted/adapted. However, WS-Context has the attraction
that it currently going through the open OASIS standardisation
process as part of the WS-CAF suite (OASIS
Web Services Composite Application Framework TC), and so
should be a candidate for consideration.
top
-
Question: OGSI Grid Service Instances are used to encapsulate
resources and, in some cases, to control their lifetime. How
is this possible with WS-GAF? (added: 01 October 2003, updated: 01 October 2003)
- The initial version of the WS-GAF proposal concentrated
on the identification of data resources through the DataRef
construct. We have now adopted the DataRef concept to provide
a uniform way of referring to all types of resources, and so
renamed it to Grid Resource Identifier (GRI), which is a URN
as defined by the Grid
Resource Specification. Lifetime information related to a
resource, which is exposed to the Grid, is part of the Grid
Resource Metadata (GRM) document.
-
- The Grid Resource
Specification has more details on GRIs and GRMs.
top
- Question: Does
OGSA play a role in the WS-GAF proposal? (added: 01 October 2003, updated: 01 October 2003)
- The WS-GAF proposal suggests that the Grid community should
focus its attention to the
Open
Grid Services Architecture (OGSA) platform rather than on
the underlying infrastructure which can be left to the Web Services
community.
top
- Question: Could
LSIDs be used as Grid Resource Identifiers? (added: 01 October 2003, updated: 01 October 2003)
- There is no reason why the LSID URI scheme could not be
adopted as one of the schemes (or indeed the scheme) supported for naming
resources.
- The Grid Resource
Specification has more details on Grid Resource
Identifiers.
top
-
Question: How is
service re-balancing and dependability supported in WS-GAF? (added: 01 October 2003, updated: 01 October 2003)
- There is a misconception in some parts of the community
that OGSI defines a transparent way to achieve service mobility.
It is believed that through the factory pattern and OGSI portType,
it is possible to arbitrary create Grid Service Instances on
remote hosts. It is believed that any service could be deployed
on a remote machine pending only security and policy related
concerns. Although it is possible to devise and implement mechanisms
where such remote service deployments are possible (in restricted
circumstances), such mechanisms are not part of the OGSI specification.
With Web Services it is possible to achieve re-balancing and
dependability even today. There are various ways to achieve
this:
- Through the provision of additional endpoints to the same
service. The new endpoints could be registered with UDDI, a
light-weight registry or made available through P2P, etc. Registries
could be used to track changes in access policies, availability
constraints, etc.).
- Version 1.0 of our document (section 3.4) suggests a solution
based on WS-Referral and WS-Routing.
- Through the Grid Resource Identifier resolution process it would be possible
obtain metadata so that a consumer could keep track of mobile resources, changes in policies for accessing
resources, caching of resources, replication of resources, etc.).
- The Grid Resource
Specification has more details on GRIs and GRMs.
top
|
|
|
|
|
|
|
