AW: [dmis-bof] Comments on the charter?

Thu Dec 22 15:18:55 CST 2005

hi ian,

i fully agree with the aims for DMI. of course you need a unique ID for the transfers
by which you can refer to them from the client side. and all the rest. but for defining how to do all this,
i questioned the relevance of WSRF or WS-I. i said that we should try to
define the interface without going into the rendering.

to this bill replied that we have to fix that 'detail' already before we start otherwise interoperability
is not guaranteed. and he may be right. at least this is what i understood, 
so please correct me if i missed the point.

to answer your question: what my concern is that at least 
to someone like myself who only follows the development of WSRF
sporadically, it is not clear to what extent we'll have to delve into detailed modifications 
of our current services if we are to do it using WSRF. to be honest, we didn't have the time to
gather the necessary experience. so it's your basic 'fear of all that is new'.  it's hard
for us to estimate the amount of work involved, and resources are scarce (getting
worse not better) while the timelines given for completion of the services are over-ambitious. so
if you want interoperability with EGEE within say the next 6-12 months, there are not many
options... it's really not the lack of willingness but simply the lack of means and of time.

so that's all there is to it, no political or religious reasons whatsoever. anyway, i will hand over the
'defense of the EGEE viewpoint' to others in the new year as i'll move to a new position
at the swiss supercomputing center near Lugano (see cscs.ch). i'll be responsible for the swiss national
grid programme. so i'll certainly be still quite involved, but you may hear very different 
concerns from me in the near future :-)

best regards to sunny australia,
have a great holiday and i wish you a happy new year

peter 

(i'll be out of email contact until jan.9th)

--
CERN IT-Grid Middleware

________________________________

Von: Ian Foster [mailto:foster at mcs.anl.gov]
Gesendet: Do 22.12.2005 08:42
An: Peter Kunszt; allcock at mcs.anl.gov; Hiro Kishimoto
Cc: dmis-bof at ggf.org
Betreff: RE: [dmis-bof] Comments on the charter?

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 <http://www.globus.org/> 