- ogsa-wg - lists.ogf.org

RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Ian Foster 03 Mar '05

03 Mar '05

Andy: One thing that would really help, I think, is for someone on "the other side" to explain what it is that they want to do that GGF/OGSA WG is preventing them from doing. I understand it must be something important, but think that there is genuine lack of understanding within GGF/OGSA WG as to what it is. A set of application scenarios would really help. A second thing that would be helpful would be a crisp characterization of what "the other side" wants to see GGF/OGSA WG do instead. Should we allow for the use of WS-Transfer as an alternative way of interacting with stateful resources? Or that we should allow for EPR + context-id as an alternative way of interacting with state? Or both? Or something else? Again, this hasn't been made clear: the only explicit communication we've received is that "we shouldn't use WSRF," which isn't a very satisfying answer. Clarity on these two issues would really help I think. A couple of other minor points: * I don't see the fact that people build Grid applications and systems in different ways as a reason not to work towards interoperability. Yes, people have built nice Grid-like systems with custom protocols, with JINI, with Web services, with CORBA, with DCOM, etc. But these systems don't interoperate, and interoperability is important in some situations. * I said management applications were "a primary focus" of OGSA, not "THE primary focus." Regards -- Ian. At 04:25 PM 3/3/2005 +0000, Andrew Herbert wrote: >Ian, Tony > > > >This discussion reminds me very much of the early history of CORBA, when >there was a create debate between those who believed dynamic interface >types were central to object request broking and those who thought they >were the spawn of the devil. Both approaches were able to emulate the >other and so any argument about which was the more fundamental was >sterile. There was certainly an element of bias towards different styles >of application, and this was what split the OMG community since each camp >had an legacy to carry forward and an investment in their view of the >future. The OMG architecture was therefore positioned at a level where >both approaches could be accommodated and as CORBA and CORBA Services were >defined a case by case view was taken of the need for a static or dynamic >interface, or both, or some unification of the two. It led to optional >elements and even some duplication of function in the early OMG >specifications, but as the standards process unfolded and users gained >experience with the technology it became easier to make rational choices >and if necessary go back and fix the specifications. Of course vendors >initially implemented just the options they preferred but over time they >converged on common components and interfaces. And of course the users >also demanded interoperability between CORBA and DCOM and got it, even >though for many CORBA vendors DCOM was the enemy. > > > >The academic question of the superiority of one style of object request >broking over another was never actually resolved a workable hybrid evolved >which meet the needs of the users and the OMG moved on. Interestingly >given your comment about the position of names in messages, with hindsight >many of the CORBA debates were ultimately a fight about where names stood >relative to dot, comma, braand ketin object invocation semantics and >fifteen years later I find it hard to remember the passions that made >these things seem so important at the time. > > > >Ian positions the primary purposeof OGSA as being certain classes of >management application. The problem Tony and others appear to be >grappling with is the desire to have OGSA as the architecture for broader >notions of Grid Computingand e-Scienceand this is where the shoe starts to >pinch. Ian asks how to make progress. It seems to me that GGF has two >choices make the scope of OGSA narrow so those interested in certain >classes of management applicationcan develop an architecture for this >unimpeded, or make the scope of OGSA broader and admit to the possibility >of other classes of application of interest to the GGF community. > > > >I observe colleagues I respect building systems that clearly are doing >Grid Computingof the kind envisioned in Ian and Karls book that coined the >concept, and these people seem to manage to build and operate their >systems without invoking WSRF so this makes me wary of any architecture >for Grid computingand/or e-Sciencewhich mandates WSRF in its entirety in >all cases. > > > >Andrew > >---------- >From: Ian Foster [mailto:foster@mcs.anl.gov] >Sent: 03 March 2005 07:04 >To: Tony Hey; Frank Siebenlist >Cc: Dennis Gannon; Samuel Meder; ogsa-wg; paul.watson(a)ncl.ac.uk; >dave.pearson(a)oracle.com; savas.parastatidis(a)ncl.ac.uk; Jim Gray; >humphrey(a)cs.virginia.edu; grimshaw(a)virginia.edu; Andrew Herbert; >gcf(a)indiana.edu; mark.linesch(a)hp.com >Subject: RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times >for GGF & Standards' > > > >Tony: > >I think your message captures nicely (although perhaps inadvertently!) the >way in which people are talking past each other in this discussion. > >I would never say that the "messages to single resources approach" is the >"the foundation for all operations on all services." I understand that >some people in this strange religious debate that we've fallen into have >characterized things that way, but that's far from the truth. > > From my perspective, WSRF was motivated by our experiences building > "service oriented infrastructure", and seeing that the same patterns were > occuring repeatedly in different places as we built systems to manage > Grid systems. The codification of those patterns in standard (and > WS-I+-compliant, I like to emphasize) WSDL has allowed us to simplify > many aspects of both service implementation and client tools. Others > report the same positive experiences. The introduction of WS-Transfer, > which provides similar functionality and seems to be intended for similar > purposes, suggests that there is broad recognition of the importance of > these patterns. However, the fact that these patterns are useful in > building certain classes of management applications (a primary focus of > OGSA, by the way) certainly doesn't mean that they are appropriate everywhere. > >I'd also like to suggest that when considering the assertion that "sending >messages to single resources makes systems fragile", it is useful to >recognize that the messages sent over the wire when using an EPR to a >WS-Resource (the WSRF approach) vs. an EPR plus a context id (e.g., as in >the eCommerce systems that are often mentioned) are close to identical. In >fact, the only difference is really just the location of the "context id": >in the EPR vs. in the body of the message! I don't see how the choice of >one placement vs. the other can render a service "robust and scalable" vs. >"fragile and nonscalable"--especially as the service itself can be >implemented in an essentially identical manner in the two cases. > >My preceding paragraph suggest that there are opportunities for common >ground, and I suspect that is the case. However, to find that common >ground we need to identify clearly just what it is we are trying to do and >then address different issues separately. I believe that there are far too >many different issues being mixed together at present for useful progress >to occur. Unfortunately, I'm not sure how to proceed to separate out the >different issues. > >Ian. > >At 11:37 AM 3/3/2005 +0000, Tony Hey wrote: > >The point is not about how well the WS-RF and WS-Transfer stacks compare >but rather whether it is always appropriate to use the "messages are >directed at single resources" approach? Many people, including people >whose technical judgement I respect such as Tony Storey, Ian Foster, >Dave Snelling and others, apparently believe that the answer to this >question is "everywhere: it is the foundation for all operations on all >services". It is therefore not surprising that this group do not see the >need to worry about the question "is it a good idea to build >architecture around the idea of sending messages to single resources?" > >_______________________________________________________________ >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 _______________________________________________________________ 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

1 0

RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Ian Foster 03 Mar '05

03 Mar '05

Tony: I think your message captures nicely (although perhaps inadvertently!) the way in which people are talking past each other in this discussion. I would never say that the "messages to single resources approach" is the "the foundation for all operations on all services." I understand that some people in this strange religious debate that we've fallen into have characterized things that way, but that's far from the truth. From my perspective, WSRF was motivated by our experiences building "service oriented infrastructure", and seeing that the same patterns were occuring repeatedly in different places as we built systems to manage Grid systems. The codification of those patterns in standard (and WS-I+-compliant, I like to emphasize) WSDL has allowed us to simplify many aspects of both service implementation and client tools. Others report the same positive experiences. The introduction of WS-Transfer, which provides similar functionality and seems to be intended for similar purposes, suggests that there is broad recognition of the importance of these patterns. However, the fact that these patterns are useful in building certain classes of management applications (a primary focus of OGSA, by the way) certainly doesn't mean that they are appropriate everywhere. I'd also like to suggest that when considering the assertion that "sending messages to single resources makes systems fragile", it is useful to recognize that the messages sent over the wire when using an EPR to a WS-Resource (the WSRF approach) vs. an EPR plus a context id (e.g., as in the eCommerce systems that are often mentioned) are close to identical. In fact, the only difference is really just the location of the "context id": in the EPR vs. in the body of the message! I don't see how the choice of one placement vs. the other can render a service "robust and scalable" vs. "fragile and nonscalable"--especially as the service itself can be implemented in an essentially identical manner in the two cases. My preceding paragraph suggest that there are opportunities for common ground, and I suspect that is the case. However, to find that common ground we need to identify clearly just what it is we are trying to do and then address different issues separately. I believe that there are far too many different issues being mixed together at present for useful progress to occur. Unfortunately, I'm not sure how to proceed to separate out the different issues. Ian. At 11:37 AM 3/3/2005 +0000, Tony Hey wrote: >The point is not about how well the WS-RF and WS-Transfer stacks compare >but rather whether it is always appropriate to use the "messages are >directed at single resources" approach? Many people, including people >whose technical judgement I respect such as Tony Storey, Ian Foster, >Dave Snelling and others, apparently believe that the answer to this >question is "everywhere: it is the foundation for all operations on all >services". It is therefore not surprising that this group do not see the >need to worry about the question "is it a good idea to build >architecture around the idea of sending messages to single resources?" _______________________________________________________________ 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

1 0

RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Ian Foster 03 Mar '05

03 Mar '05

Savas: I wondered when you'd join the debate, and as usual your comments are very much to the point. At 06:09 PM 3/1/2005 +0000, Savas Parastatidis wrote: >Please note that I am not suggesting that WS-RF (and WS-Transfer for >that matter) is not useful in certain cases. Indeed, in the systems >management area it may make sense to use them. However, what it is being >proposed in the OGSA working group (if I understand correctly) is that >WS-RF be used as the foundation for all high-level services. I don't think that the OGSA working group would argue for using it as a foundation for "all high-level services," but I understand that some people fear that this is intended. For system management applications (a major focus of OGSA), I do believe that there is value, as you also note. >However, a difference >that I personally see between the WS-RF/WS-Notification and WS-Transfer/ >/WS-Eventing/etc. camps is that the latter is much simpler and "much simpler" is a relative term of course, but I think we should also remember that there isn't a lot to even the "more complex" WSRF/WS-BaseNotification. See Blackberry note below. >lightweight. Most importantly, the MS suite of specifications is not >promoted as the uniform, underlying suite of common messaging behaviours >for all high-level services as WS-RF seems to be. Instead it is some That's not my understanding of WSRF. >patterns that are available to be used where they are appropriate. Also, >WS-Transfer is lightweight so it can be used in very-small-factor >devices. I've seen WSRF implemented on a Blackberry, with the complete SOAP-WSRF-WSN-WSDM stack occupying 102KB. I *think* that the "small factor" issue is a red herring. If you want to run on something with just 64KB memory, you probably shouldn't be using Web services. >So, it would be interesting to understand from the WSRF architects where >they feel the WSRF approach is and is not appropriate. E.g. is it >appropriate for interactions with multiple resources? Should it be used >in the design of all high-level Grid services? What are the semantics of >the 'destroy' messages? Here's my opinions: * WSRF (or indeed any WS-I-compliant specification) should be used when and where it's appropriate. * Semantics of destroy: these are defined fairly clearly in the WS-ResourceLifetime specification. * Interactions with multiple resources: I think that's a red herring. E.g., a job factory can return EPRs to WS-Resources representing jobs, thus allowing individual jobs to be monitored and controlled, if needed. The factory can also maintain a service group representing all jobs, and then support operations that allow a client to "destroy all jobs that match a certain pattern" (for example). It's not an either/or. _______________________________________________________________ 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

1 0

Re: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Hiro Kishimoto 03 Mar '05

03 Mar '05

Kerl's email bounced. I agree with Karl. Actually we have had almost the same discussion at today's OGSA-WG call. We should sort out either (1) message level standards or (2) APIs for the higher level middleware. ---- Hiro Kishimoto Date: Thu, 3 Mar 2005 16:10:31 +0700 From: Karl Czajkowski <karlcz(a)univa.com> To: Steven Newhouse <sjn5(a)doc.ic.ac.uk> Subject: Re: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards' Sorry, but I think this is an example of the confused discussion we are seeing. You are clearly talking about programming environments with terms like "application code interface" and MPI as a rhetorical example. The question "to WSRF or not to WSRF", on the other hand, is really not a programming question at all. (To Globus Toolkit, or to WSRF.NET might be a more reasonable programming question.) MPI is largely a programming methodology, despite its name... it is an API (and build environment) standard that let you port application code from one host to another. MPI did not in any way give interoperability between platforms so that your application could run some tasks here, some tasks there, etc. across multiple vendor platforms. Specific implementations of MPI have tried to address platform heterogeneity over time, but unless I have missed some recent advance, there is still no runtime interop of MPI implementations. Most of the Web services standards are targeted at a completely different area of runtime system interoperation. The WSRF model and Microsoft's comparable proposals talk about basic ways to structure message interchange and more importantly on some protocol-level reflection mechnanisms to help "find" interop at runtime in a heterogeneous environment. The only programming methodology they imply is an accident of current vendor tools and prototypes! I find it an interesting question whether OGSA is trying to standardize a message-passing architecture or whether they are trying to standardize a programming environment. I think it is rather ambitious, and counter to current Internet-inspired strategies, to try to do both at once. If OGSA want to define programming environments, I think it is very appropriate that they define another "abstraction layer", namely a programming language binding to build or access distributed Grid systems. Hopefully you intend to model a message-passing system, or all bets are off as to how well this binding can map to Web service technologies in a globally distributed setting. If OGSA do not want to define programming environments but do have a message-passing architecture that they would like to specify "concretely" using Web service methods, I think they should continue this discussion of how WSRF and the MS proposals relate. But in doing so, they should not get distracted by red herrings about what an API looks like, how portable their code might be, etc. If OGSA is split on this point, I suggest that the people should split their discussions and proceed in parallel. It does seem that there is this recurring dead-end debate where one person is arguing about message protocol mechanisms with someone else who is arguing about application programs and their terminology accidentally collides. karl On Mar 02, Steven Newhouse loaded a tape reading: > >The idea of inventing "yet an other abstraction layer" doesn't sound > >very productive. > > Neither does the idea of re-writing my application code interface when > WS-RF 2.0 comes out, or something else gets adopted by another > community, or... > > Just imagine where the parallel computing world would still be if we > where still exposed to machine specific networking stacks instead of > MPI? Layers of abstraction are (within reason) good. > > Also you are seeing caution in the UK. Remember OGSI...? The UK put in > considerable effort to adopt the 'betamax' of grid web service. Are we > now being offered VHS grid web services? Or will there be another > Betamax type revision? > > I'm finding some of the comments in this thread (not Frank's) are bit > worrying. Should dissenters really be given a 'good talking to' until > they come round to the WS-RF point of view? Wow... roll on GGF! > > Steven > -- > ---------------------------------------------------------------- > Dr Steven Newhouse Tel:+44 (0)2380 598789 > Deputy Director, Open Middleware Infrastructure Institute (OMII) > Suite 6005, Faraday Building (B21), Highfield Campus, > Southampton University, Highfield, Southampton, SO17 1BJ, UK -- Karl Czajkowski karlcz(a)univa.com

1 0

RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Djaoui, A (Abdeslem) 03 Mar '05

03 Mar '05

I agree that defining the perfect layer of abstraction would be a good thing to do. But we have tried before and never got very far in agreeing on what that layer should be in a reasonable time. In order to make quick progress as expected from us, we would be better off discussing what it takes to compose WSRF services with non-WSRF (may be WS-Transfer?) services. some layers of integration (intermediaries, handlers,...) might be needed, but this is a small price to pay, compared to the alternatives of starting again or having a divided community. OGSA being a service oriented architecture will provide a choice of services. Market forces will ensure that the better services survive and the bad ones will be unused for a long time before they die peacefully. This way people can go their preferred way BUT AT THEIR OWN RISK but both approaches will be part of OGSA. Abdeslem. ///////// -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org]On Behalf Of Hiro Kishimoto Sent: 03 March 2005 08:19 To: 'OGSA-WG' Subject: Re: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards' Steven's email bounced. Steven, OGSA-WG is open to any plumbing proposal as our infrastructure service. However, we are under pressure from Grid community at large to publish concrete OGSA basic profile by GGF14. (And please use your registered email address.) Thanks, ---- Hiro Kishimoto Date: Wed, 02 Mar 2005 23:24:14 +0000 From: Steven Newhouse <s.newhouse(a)omii.ac.uk> To: Frank Siebenlist <franks(a)mcs.anl.gov> Subject: Re: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards' > The idea of inventing "yet an other abstraction layer" doesn't sound > very productive. Neither does the idea of re-writing my application code interface when WS-RF 2.0 comes out, or something else gets adopted by another community, or... Just imagine where the parallel computing world would still be if we where still exposed to machine specific networking stacks instead of MPI? Layers of abstraction are (within reason) good. Also you are seeing caution in the UK. Remember OGSI...? The UK put in considerable effort to adopt the 'betamax' of grid web service. Are we now being offered VHS grid web services? Or will there be another Betamax type revision? I'm finding some of the comments in this thread (not Frank's) are bit worrying. Should dissenters really be given a 'good talking to' until they come round to the WS-RF point of view? Wow... roll on GGF! Steven -- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Deputy Director, Open Middleware Infrastructure Institute (OMII) Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK

1 0

Re: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Hiro Kishimoto 03 Mar '05

03 Mar '05

Steven's email bounced. Steven, OGSA-WG is open to any plumbing proposal as our infrastructure service. However, we are under pressure from Grid community at large to publish concrete OGSA basic profile by GGF14. (And please use your registered email address.) Thanks, ---- Hiro Kishimoto Date: Wed, 02 Mar 2005 23:24:14 +0000 From: Steven Newhouse <s.newhouse(a)omii.ac.uk> To: Frank Siebenlist <franks(a)mcs.anl.gov> Subject: Re: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards' > The idea of inventing "yet an other abstraction layer" doesn't sound > very productive. Neither does the idea of re-writing my application code interface when WS-RF 2.0 comes out, or something else gets adopted by another community, or... Just imagine where the parallel computing world would still be if we where still exposed to machine specific networking stacks instead of MPI? Layers of abstraction are (within reason) good. Also you are seeing caution in the UK. Remember OGSI...? The UK put in considerable effort to adopt the 'betamax' of grid web service. Are we now being offered VHS grid web services? Or will there be another Betamax type revision? I'm finding some of the comments in this thread (not Frank's) are bit worrying. Should dissenters really be given a 'good talking to' until they come round to the WS-RF point of view? Wow... roll on GGF! Steven -- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Deputy Director, Open Middleware Infrastructure Institute (OMII) Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK

1 0

[ogsa-wg | Basic Profile - 1314] Relationship to WS-I Basic Security Profile 1.0
by Sourceforge Tracker Monitor 03 Mar '05

03 Mar '05

A new artifact has been added: 1314 Submitted by: Tom Maguire Submitted date: 2005-03-02 20:39:31 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1314&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1314&group_id…) Summary: Relationship to WS-I Basic Security Profile 1.0 Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1314 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Last Modified: 2005-03-02 20:39:31 Submitted By: Tom Maguire Submit Date: 2005-03-02 20:39:31 Assigned To: &lt;None&gt; File(s): <None> Description: Describe the extension model for BSP 1.0 View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

Re: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Samuel Meder 02 Mar '05

02 Mar '05

On Mon, 2005-02-28 at 14:38 -0800, Frank Siebenlist wrote: > Could anyone summarize MS' WS-view, and how it differs from WSRF? So far I have not seen any substantial difference between the two approaches and I definitely believe the onus is on MS to show why people should adopt their proprietary specifications vs. adopting something that is being developed in a open standards body, is getting very close to a 1.0 version and has multiple implementations behind it. /Sam > > Thanks, Frank. > > > > Hiro Kishimoto wrote: > > >Hi all, > > > >Absorbing article by Tony Hey. > > > >http://news.tgc.com/nview.jsp?appid=360&print=1#342708 > >---- > >Hiro Kishimoto > > > > > > > >> GRIDtoday > >> NEWS AND INFORMATION FOR THE GLOBAL GRID COMMUNITY > >> --- February 28, 2005: Vol. 4, No. 8 --- > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >>SPECIAL FEATURES > >>============================================================== > >> > >>[ ] M342708 ) WSRF? WS-*? Where is GGF's OGSA Headed? > >> By Tony Hey, Contributing Editor > >> > >> Tony Hey, director of e-Science for the Engineering and Physical > >>Science Research Council, continues to elaborate the need for open > >>standards in the realm of Web services-based Grid computing. He > >>discusses the great debate of WSRF vs. WS-*, and lays out what the GGF > >>must do with OGSA in order to give e-Science application developers > >>something to rally around. > >> > >> > > > > > > > -- Sam Meder <meder(a)mcs.anl.gov> The Globus Alliance - University of Chicago 630-252-1752

7 8

RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Djaoui, A (Abdeslem) 02 Mar '05

02 Mar '05

Just clarifying a rather small part of the big puzzle! >The argument is about whether support for WS-Addressing is all that is >required in order to interact with services built on top of WS-RF. I >believe this to be an oversimplification. Support for WS-Addressing is >absolutely required. However, it's not enough. It is enough, for a client to interact with a service that implements a WSRF specification. Note: I did not use the term build on top (this term might imply that WSRF implementations have to be provided by the infrastructure). The service simply implements one of the WS-* specifications (ie WSRF)! The client then uses messages exchanges as defined in that services description. >The implementation of the >semantics of the ResourceProperties and Lifetime related messages have >to be provided. If they are not provided, a developer will end up >implementing them. Absolutely, this is true of any web service specification, including WS-Transfer (no offence intended to any WS-* specification!) Abdeslem /////////

1 0

Proposed agenda for March 2nd call
by Hiro Kishimoto 02 Mar '05

02 Mar '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on March 2nd Wednesday from 5pm to 7pm (CST). Dial-in numbers for Wednesday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0302 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 0) Celebration of OGSA v1 documents formal launce GFD.30, "The Open Grid Services Architecture, Version 1.0" GFD.44, "Open Grid Services Architecture Glossary of Terms" GFD.45, "Resource Management in OGSA" 1) Early discussion (10 min) Note taker assignment Roll call Telecon minutes approval (if available) GGF13 update (if any) Agenda bashing 2) Basic profile discussion (60 min) Revised basic profile draft https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… le/en/3 New configuration of Issue tracker https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… 3) Profile template discussion (if available) 4) Roadmap discussion (if available) 5) Wrap up (10 min) AOB Mar. 7 (5-7pm CST) BES BoF preparation Basic profile discussion, basic security profile Mar. 9 (10-11am CST) Data Design team Mar. 9 (5-7pm CST) Roadmap discussion, GGF13 session preparation Mar. 13-16 GGF13 in Soeul See telecon schedule until GGF: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule ---- Hiro Kishimoto

1 0