[dmis-bof] FW: BOUNCE dmis-bof at ggf.org: Non-member submission from [Ian Foster <foster at mcs.anl.gov>]
William E. Allcock
allcock at mcs.anl.gov
Thu Dec 22 10:09:05 CST 2005
A mail from Ian Foster bounced...
-----Original Message-----
Date: Thu, 22 Dec 2005 01:42:31 -0600
To: "Peter Kunszt" <Peter.Kunszt at cern.ch>, <allcock at mcs.anl.gov>,
"Hiro Kishimoto" <hiro.kishimoto at jp.fujitsu.com>
From: Ian Foster <foster at mcs.anl.gov>
Subject: RE: [dmis-bof] Comments on the charter?
Cc: <dmis-bof at ggf.org>
Peter:
(I'm online very briefly in Australia, not back until January 3rd ...)
I am always trying to understand the concerns that motivate the "WS-I vs.
WSRF" debate, so I'd be very grateful if you could help elucidate the
concerns that underlie your email below.
In DMI, we want to be able to request the creation of transfers, monitor
the status of those transfers, and control their progress (e.g., cancel
them). Thus, we need (as is often the case) constructs in our interface for
"naming" transfers, for requesting information about their state, and for
performing control operations.
WSRF standardizes some operations for doing these things: WS-Addressing
EPRs for naming transfers, WS-ResourceProperties operations for accessing
state, and WS-ResourceLifetime operations for control. We also have the
option of using WS-Notification mechanisms for notification of state
changes, if desired.
Modulo the use of EPRs, these operations are all WS-I compliant.
Thus, two questions:
* When you say you want a "WS-I" interface, do you mean that you don't want
to use EPRs to name things? If so, can you explain the reasons why?
* If you are ok with EPRs, but don't want to use WSRF interfaces for state
access and control operations, can you explain the reason for this? It
seems to me that you're just saying that you want to use different
operation names than those defined in the WSRF specifications. I don't
understand the advantages of substituting different names for what will be
essentially the same operations.
Regards -- Ian.
At 03:30 PM 12/14/2005 +0100, Peter Kunszt wrote:
>hi bill
>
>here it comes - my dreaded comments ;-)
>
> > - I changed the name to OGSA-DMI
>
>i don't like that. having my EGEE hat on, please consider that we cannot
>adapt and use OGSA in any of the near future (next year) as everything
>is set up for production pretty much now. there is no time for us to
migrate
>to OGSA quickly and to deploy and use it. there are lots of question marks
>concerning especially the security infrastructure and how that will
>interoperate
>with classical transport-level security.
>
>so to recap: we would very much appreciate a pure WS-I interface
>standardization
>first, where we can talk cleanly about interfaces and semantics and we
>would not
>clog our discussions about which semantics of WSRF should be applied to
>what. we
>could focus on the transfer specs. then someone can take the spec and
>'ogsafy' it.
>so please consider to keep this just as DMIS-WG. (sorry hiro - i have to
>be pragmatic here)
>
> > - we need to address naming. What will we accept as source
> > and destination names? URLs? URIs? any string? EPRs?
>
>URL seems like a good choice, this would probably suit all use cases.
>this is what we use in the GSM-WG. we have storage URLs.
>an EPR is nothing more than a decorated URL so a simple URL would
>suit that too.
>
> > - There is a general issue which will affect a lot of this
> > and that is just extensible WSDL. How do we allow parameters
> > to change when options in the WSDL change.
>
>the pragmatic approach is to increase the minor version number
>for compatible changes and the major one for incompatible changes.
>however, there are alternatives that we have investigated also in
>the GSM-WG: it is possible to leave an extensibility hook in the WSDL,
>so that new functionality can be tried on existing services, before
>it is migrated into the mainstream WSDL. this is a good idea also
>for interoperating between versions.
>
> > - I think we all agree that this needs to be transport
> > agnostic, but we need to figure out how best to implement
> > that (related to the WSDL question)
>
>unless i'm mistaken, doc/literal should just do the trick..?
>
> > - what statement do we want to make (and does the OGSA data
> > architecture
> > need) about delivery semantics
>
>i think we need to make as detailed statements as possible/reasonable!
>we need to define what states the transfer service exposes to the client
>and what failure modes the client has to expect.
>
> > - what about scheduling / planning aspects? Do we want to
> > include elements in this WSDL that specify rate (bandwidth),
> > quantity (file size), and timing (START BY, FINISH BY, etc)
>
>our experience: individually for each transfer job: no. that is very
>complicated and of questionable use.
>on the scale of the service itself as a service parameter/configuration:
yes.
>
> > - everybody's favorite: security. I hope we can basically
> > punt on this and say we will do whatever OGSA does
>
>well.. please see
>http://www.globus.org/toolkit/docs/4.0/security/GT4-GSI-Overview.pdf
>
>and the discussion here on transport and message-level security.
>GT4 currently supports both in parallel.
>
>together with my comment on top, i think for this essential service
>we need to at least task the OGSA security group to give us a clear
>path of how both can interoperate and what are the migration paths.
>this is highly nontrivial and until it is not given, it will not be
>practical for us to talk about message-level security at all. we don't
>have the effort available to do what GT4 did and to run both everywhere.
>
> > - A sort of pet project of mine is monitoring /
> > troubleshooting. I would like to potentially include
> > elements in the WSDL or state that is exposed that would
> > enable better/easier monitoring and troubleshooting. For
> > instance, some sort of unique job identifier that can be
> > passed down to children, so that you can trace the chain back
> > when you have a failure.
>
>yes, statistics gathering is another one. very important to have -
>i already sent the wsdl's we have today to this list..
>
> > - groups that we need to be aware of to one extent or
> > another include OGSA, OGSA-D, info-d, gsm, byte-io, naming,
> > grid file systems, authz (other security groups),
> > ws-agreement (GRAAP?). are there others? how should we
> > liaise with those groups? some will require more work than others.
>
>:-) the best thing to have is if there are individuals participating
>in both who can act as liaisons. i am happy to take gsm and parts of
>ogsa-d, together with you of course.
>
> >
> > Let me know what you think.
>
>keep'em coming ;-)
>
>cheers
>peter
_______________________________________________________________
Ian Foster www.mcs.anl.gov/~foster
Math & Computer Science Div. Dept of Computer Science
Argonne National Laboratory The University of Chicago
Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A.
Tel: 630 252 4619 Fax: 630 252 1997
Globus Alliance, www.globus.org
--=====================_7827395==.ALT
Content-Type: text/html; charset="us-ascii"
<html>
<body>
Peter:<br><br>
(I'm online very briefly in Australia, not back until January 3rd
...)<br><br>
I am always trying to understand the concerns that motivate the
"WS-I vs. WSRF" debate, so I'd be very grateful if you could
help elucidate the concerns that underlie your email below.<br><br>
In DMI, we want to be able to request the creation of transfers, monitor
the status of those transfers, and control their progress (e.g., cancel
them). Thus, we need (as is often the case) constructs in our interface
for "naming" transfers, for requesting information about their
state, and for performing control operations.<br><br>
WSRF standardizes some operations for doing these things: WS-Addressing
EPRs for naming transfers, WS-ResourceProperties operations for accessing
state, and WS-ResourceLifetime operations for control. We also have the
option of using WS-Notification mechanisms for notification of state
changes, if desired.<br><br>
Modulo the use of EPRs, these operations are all WS-I
compliant.<br><br>
Thus, two questions:<br><br>
* When you say you want a "WS-I" interface, do you mean that
you don't want to use EPRs to name things? If so, can you explain the
reasons why?<br><br>
* If you are ok with EPRs, but don't want to use WSRF interfaces for
state access and control operations, can you explain the reason for this?
It seems to me that you're just saying that you want to use different
operation names than those defined in the WSRF specifications. I don't
understand the advantages of substituting different names for what will
be essentially the same operations.<br><br>
Regards -- Ian.<br><br>
At 03:30 PM 12/14/2005 +0100, Peter Kunszt wrote:<br>
<blockquote type=cite class=cite cite>hi bill<br><br>
here it comes - my dreaded comments ;-) <br><br>
> - I changed the name to OGSA-DMI<br><br>
i don't like that. having my EGEE hat on, please consider that we
cannot<br>
adapt and use OGSA in any of the near future (next year) as
everything<br>
is set up for production pretty much now. there is no time for us to
migrate<br>
to OGSA quickly and to deploy and use it. there are lots of question
marks<br>
concerning especially the security infrastructure and how that will
interoperate<br>
with classical transport-level security.<br><br>
so to recap: we would very much appreciate a pure WS-I interface
standardization<br>
first, where we can talk cleanly about interfaces and semantics and we
would not<br>
clog our discussions about which semantics of WSRF should be applied to
what. we<br>
could focus on the transfer specs. then someone can take the spec and
'ogsafy' it.<br>
so please consider to keep this just as DMIS-WG. (sorry hiro - i have to
be pragmatic here)<br><br>
> - we need to address naming. What will we accept as
source <br>
> and destination names? URLs? URIs? any string? EPRs?<br><br>
URL seems like a good choice, this would probably suit all use
cases.<br>
this is what we use in the GSM-WG. we have storage URLs.<br>
an EPR is nothing more than a decorated URL so a simple URL would<br>
suit that too.<br><br>
> - There is a general issue which will affect a lot of this
<br>
> and that is just extensible WSDL. How do we allow parameters
<br>
> to change when options in the WSDL change.<br><br>
the pragmatic approach is to increase the minor version number<br>
for compatible changes and the major one for incompatible changes.<br>
however, there are alternatives that we have investigated also in<br>
the GSM-WG: it is possible to leave an extensibility hook in the
WSDL,<br>
so that new functionality can be tried on existing services, before<br>
it is migrated into the mainstream WSDL. this is a good idea also<br>
for interoperating between versions.<br><br>
> - I think we all agree that this needs to be transport <br>
> agnostic, but we need to figure out how best to implement <br>
> that (related to the WSDL question)<br><br>
unless i'm mistaken, doc/literal should just do the trick..?<br><br>
> - what statement do we want to make (and does the OGSA data
<br>
> architecture<br>
> need) about delivery semantics<br><br>
i think we need to make as detailed statements as
possible/reasonable!<br>
we need to define what states the transfer service exposes to the
client<br>
and what failure modes the client has to expect.<br><br>
> - what about scheduling / planning aspects? Do we want
to <br>
> include elements in this WSDL that specify rate (bandwidth), <br>
> quantity (file size), and timing (START BY, FINISH BY,
etc)<br><br>
our experience: individually for each transfer job: no. that is very
complicated and of questionable use.<br>
on the scale of the service itself as a service parameter/configuration:
yes.<br><br>
> - everybody's favorite: security. I hope we can
basically <br>
> punt on this and say we will do whatever OGSA does<br><br>
well.. please see <br>
<a
href="http://www.globus.org/toolkit/docs/4.0/security/GT4-GSI-Overview.pdf"
eudora="autourl">http://www.globus.org/toolkit/docs/4.0/security/GT4-GSI-Ove
rview.pdf</a><br><br>
and the discussion here on transport and message-level security.<br>
GT4 currently supports both in parallel.<br>
<br>
together with my comment on top, i think for this essential service<br>
we need to at least task the OGSA security group to give us a clear<br>
path of how both can interoperate and what are the migration paths.<br>
this is highly nontrivial and until it is not given, it will not be<br>
practical for us to talk about message-level security at all. we
don't<br>
have the effort available to do what GT4 did and to run both
everywhere.<br><br>
> - A sort of pet project of mine is monitoring / <br>
> troubleshooting. I would like to potentially include <br>
> elements in the WSDL or state that is exposed that would <br>
> enable better/easier monitoring and troubleshooting. For
<br>
> instance, some sort of unique job identifier that can be <br>
> passed down to children, so that you can trace the chain back <br>
> when you have a failure.<br><br>
yes, statistics gathering is another one. very important to have -<br>
i already sent the wsdl's we have today to this list..<br><br>
> - groups that we need to be aware of to one extent or <br>
> another include OGSA, OGSA-D, info-d, gsm, byte-io, naming, <br>
> grid file systems, authz (other security groups), <br>
> ws-agreement (GRAAP?). are there others? how should we <br>
> liaise with those groups? some will require more work than
others.<br><br>
:-) the best thing to have is if there are individuals
participating<br>
in both who can act as liaisons. i am happy to take gsm and parts
of<br>
ogsa-d, together with you of course.<br><br>
> <br>
> Let me know what you think.<br><br>
keep'em coming ;-)<br><br>
cheers<br>
peter<br>
</blockquote>
<x-sigsep><p></x-sigsep>
_______________________________________________________________<br>
<tt>Ian
Foster &nbs
p;
<a href="http://www.mcs.anl.gov/~foster"
eudora="autourl">www.mcs.anl.gov/~foster</a><br>
Math & Computer Science Div. Dept of Computer Science<br>
Argonne National Laboratory The University of
Chicago <br>
Argonne, IL 60439, U.S.A. Chicago, IL 60637,
U.S.A.<br>
Tel: 630 252
4619
Fax: 630 252 1997<br>
Globus Alliance,
<a href="http://www.globus.org/" eudora="autourl">www.globus.org</a><br>
</body>
</html>
--=====================_7827395==.ALT--
More information about the dmis-bof
mailing list