Special Features:
GRID INFRASTRUCTURE PROTOCOLS TO BE TESTED FOR INTEROPERABILITY
By Alan J. Weissberger, Contributing Editor
At the Oct. 26-27 meeting of the OASIS WS-RF TC, several important draft
standards were progressed that will have a huge impact on Grid infrastructure.
Orignially part of GGF Open Grid Services Infrastructure (OGSI), the WS-RF
standards will provide the basis for modelling stateful resources behind a Web
Service and also specify their lifetime. Additionally, the Web Services
Distributed Management (WSDM) specs -- a replacement for the GGF Common
Management Model (CMM) -- will make use of both WS RF and WS Notification
standards.
The key specifications from the WS RF Techinical Committee are:
- WS-Resource ( a replacement for the Implied Resource Pattern that has been
renamed WS-Resource Access Pattern or WS-RAP).
- WS-Resource Properties.
- WS-Resource Lifetime.
- WS-Base Faults.
- WS-Service Groups.
- WS-Renewable References (how to renew a WS Address [EPR] that has become
stale, e.g. because an endpoint fails).
At this meeting, emphasis has been placed on the first three draft standards
listed above, with planning for an interoperabilty event using a Printer as
the WS Resource behind the WS interface. The printer properties would be
described in WS-Resource Properties, while the scheduled or immediate
destruction of the resource would be specifed by WS-Resource Lifetime. An
interop event that will result in multi-vendor testing of these specs will be
held in early 2005. Planning is underway for that event, which might occur at
the next WSRM meeting in early February 2005 in Raleigh, N.C.
In addition to the WSRF specs listed above, there will also be an
introduction/tutorial (WS RF Primer) and a Users Guide (WS RF App Note). This
editor is responsible for the latter document and would like to solicit
contributions from OASIS member companies to participate.
The Latest Outline For The WS RF App Note
I. Introduction/ Abstract
The purpose of the WSRF App Note is to produce a non-normative document that
describes how to use the WS-RF family of specs. Building on the WSRF Primer,
it clarifies non normative issues of the WSRF spec, while providing
composability aspects with related specs. The focus of the document is on
three types of "how to use WS-RF specs" with appropriate examples:
- Composing WS-RF specs with each other, e.g. WS-RP, WS-RL, and WS Service
Groups (maybe WS Resource too?).
- How other WS specs might use the WS-RF specs, e.g. WS-Notification
(modeling a subscription as a WS Resource), WSDM, WS-Portlets, WS Security,
others TBD.
- How new WS applications (with stateful resources behind the WS interface)
might use the WS-RF specs, e.g. modeling peripheral (e.g. printers, disk
drives) and network equipment (switches and routers) as WS-Resources, modeling
other types of stateful resources (equipment or services) that exist behind a
WS/WSDL interface.
II. Detailed Outline For The WS-RF App Note document
High-level overview of the WS-RF specs: WS-Resource, WS-Resource
Properties, WS-RL, WS-BF, WS-SG, WS-Renewable References (when published).
(Only one or two paragraphs to describe each spec description) - Reference to Definitions of various terms+: WS Resource, Implied Resource
Pattern, Factory Pattern, Resource Lifetime, Renewable Resource, etc.
- Four normative definitions are in WS Resource spec. The WSRF
Primer should have a complete listing of definitions, and if so, we
can point to it here.
Information from the two white papers (suggest we extract relevant
applications/related information from the two white papers [The WS-Resource
Framework and Modeling Stateful Resources with Web Services]).
What sections parts of the white papers should be extracted? Need
volunteers to work on this!
III. Motivation: WS Applications/ Use Cases for the WS-RF specs
Potential applications for WS-RF specs include: examples of Web Services that
contain stateful resources behind the WS interface, Grid Infrastructure layer
(formerly known as OGSI- see OGSI Primer and OGSA Use Case document), WSDM
specs use of WS-RF capabilities, Modeling remote portlets (WS-RP) as WS
resources, modeling a subscription to a notification pattern as a WS resource
(WS-Notification), other WS specs that might make use of WSRF specs (TBD by
the contributors -- what about WS Security?).
IV. Composability Details
- How the individual WS RF specs compose, i.e. are used together (including
any dependencies and interactions). Which one's are used together (e.g.
WS-Resource, WS-Resource Property and WS-RL) vs WS RF specs which might stand
alone (e.g. WS Base Faults).
- How WS-RF specs could be used with WS-Notification specs (as per Peter
Niblett's presentation to both TCs at f2f meeting).
- How WSDM specs (MUWS and MOWS) make use of WS-RF specs (input from WSDM TC
will be solicited).
- How WS Remote Portlets could be modeled as WS Resources and make use of
WS-RF specs (which ones?). This might be a placeholder till we get volunteers
to work on it.
- Clarification of the issues from the WSRF issues list that we feel are
implementation dependent (and therefore non normative/ not subject to
standardization). This also includes best practices* and recommendations. For
example, possible interpretations of fault messages, potential recovery
options, policy issues effecting any of the WS-RF spec.
** We specifically stated that Issue WSRF48, Specify behavior of nillable
properties, was a candidate for the App Note.**
Here is how the WSDM (WS Distributed Management) specs will use WS-RF:
- Use of WS-ResourceFramework
MUWS (Management Using Web Services) leverages the Web Services Resources
Framework ([WSRF]), in which, the MUWS manageable resources are represented by
Web services as manageable resources, in the WSRF sense of the term. This
implies that references to manageability endpoints in MUWS use the mechanism
defined by WSRF, leveraging endpoint references (EPR) as defined by
WS-Addressing.
If the manageability endpoint corresponds to a variable number (zero or more)
of manageable resources, then the WSRF Implied Resource Pattern MUST be
followed. This means that the element(s) listed in the ReferenceProperties of
a WS-Resource qualified EPR must be included in the header of messages sent to
such manageability endpoints. This specification does not currently define how
to obtain the EPR. There may be an out-of-band agreement between provider and
consumer on how to obtain EPRs or future versions of this specification would
clarify this subject.
In the specific case where a manageability endpoint corresponds to one and
only one manageable resource, then either the WSRF Implied Resource Pattern,
as above, or the singleton WS-Resource implied pattern MUST be used. If the
singleton WS-Resource implied pattern is used, this means that the
manageability endpoint does not expect to receive the elements listed in the
ReferenceProperties section of WS-Resource qualified EPRs in the message
headers to indicate which resource is being managed. A manageability consumer
who does not have an EPR for a manageability endpoint MAY try to invoke
manageability operations without including reference properties information
[WV1] . If such an invocation succeeds, the manageability consumer can infer
it is talking about a manageable resource through a manageability provider.
[WV2] [IS3] Further, management properties defined in MUWS are represented as
"properties," in the WSRF sense of the term, using the mechanisms defined in
WS-ResourceProperties ([WS-ResourceProperties]). This means that each
manageable resource exposes a resource properties document and makes this
document available as specified in WS' ResourceProperties.
Supporting WS-ResourceProperties means that any implementation of an interface
that includes properties MUST include access methods to these properties as
defined by WS' ResourceProperties. Specifically, the interface MUST include
the GetResourceProperty operation defined by WS-ResourceProperties and MAY
include the GetMultipleProperties, SetResourceProperties and
QueryResourceProperties operations. If the QueryResourceProperties operation
is provided, it SHOULD support the XPath 1.0 query expression dialect,
represented by URI www.w3.org/TR/1999/REC-xpath-19991116.
[WV1]Clarify that it should still have the other addressing headers.
[WV2]Do we need to update because of the changes to IRP in WSRF?
[IS3]This may just refer to WS-Resource spec. May be just clarify with a
picture here.
In addition, MUWS refers to WS-ResourceLifetime for use to manageable the
lifetime of relationships. WS-ServiceGroup is listed as one possible way to
advertise manageable resources.
Postscript
Expect the WSRF specifications to be completed by the 2nd Quarter of 2005.
Those, along with WSDM and WS Notification will form the core infrastructure
protcols to be used in Grid computing.
About Alan J. Weissberger
As the founder and Technical Director of Data Communications Technology (DCT),
a technical consulting firm started in March 1983, Alan J. Weissberger
specializes in telecommunications standards and their implementation. His
clients have included network providers (AT&T, NTT, Pacific Bell, US West,
Entel and CTC in Chile, Telkom South Africa, Moroccan PTT, others), equipment
and semiconductor manufacturers, and large end users. In 1995 and 1996 Alan
was the principal architect for the European Commission's multi-service,
multi-country ATM network -- the largest private network in Europe (that
network has now evolved into Gig Ethernet over CWDM). In 2000-01, he was
Ciena's lead ITU-T delegate, contributing to the standardization of the
optical control plane in SG13 and SG15. Alan now represents NEC Corp in
several OASIS TCs dealing with Web Services, while also attending the Global
Grid Forum and the Optical Internetworking Forum (OIF).
Weissberger can be reached via e-mail at
aweissberger@sbcglobal.net or
ajwdct@technologist.com. To read his entire biography, please visit
www.gridtoday.com/04/1011/bio.html.
|
