June 2005 - ogsa-wg - lists.ogf.org

OGSA-D status report
by Dave Berry 15 Jun '05

15 Jun '05

Here is a report of OGSA-D activity for the last month, as input for tonight's OGSA call. ---- Our f2f meeting in London produced very useful technical discussion. It was especially valuable to have representatives of several major activities present. We have a working draft of the architecture document for discussion at GGF. Work on this document has made significant progress but it still contains many holes. Recently we have begun work on a companion scenarios document; this is needed to show how the elements of the architecture fit together. We have begun work on a memo about security concerns for data services. Our aim is to initiate a dialogue with security teams to make sure that their work addresses our needs. We note that other groups (such as the LSG-RG) also have activity in this area. We have three sessions scheduled for GGF14. One is an outreach session at which we will present our work. The other two are technical sessions, on data transfer and transactions. Telcon minutes are available on the OGSA-D WG GridForge site. ---- Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

Proposed agenda for June 15th call
by Hiro Kishimoto 15 Jun '05

15 Jun '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on June 15th Wednesday from 5pm to 7pm (CDT). 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: 0615 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Inauguration of a new co-chair (congratulations Tom!) Telecon minutes approval (if available) Document submission status GGF14 session schedule Agenda bashing 2) OGSA fellow WG status report (20 min) OGSA-ByteIO WG OGSA-BES WG OGSA-data WG OGSA-naming WG 3) OGSA next step discussion (60 min) Since we will complete key deliverables at GGF14, it is time to list up, prioritize, and choose next work item(s) of OGSA-WG for '05H2 and '06. Hiro will send out first-cut laundry list as starting point. 4) Wrap up (10 min) AOB June 20th (Mon) CDDLM cross-WG session, EMS architecture, document review June 22th (Wed) GGF14 preparation, document review ---- Hiro Kishimoto

2 2

RE: [ogsa-wg] RM teleconference reminder -- container properties
by Andrea Westerinen (andreaw) 14 Jun '05

14 Jun '05

Sorry for the resend, but I updated the spreadsheet based on our conversation on the RM call today. Andrea > -----Original Message----- > From: Andrea Westerinen (andreaw) > Sent: Tuesday, June 14, 2005 10:59 AM > To: 'Fred Maciel'; GGF - ogsa-wg ml; ogsa-bes-wg(a)ggf.org > Subject: RE: [ogsa-wg] RM teleconference reminder -- > container properties > > Here are my updates for the call today ... > > Andrea > > > -----Original Message----- > > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] > On Behalf > > Of Fred Maciel > > Sent: Monday, June 13, 2005 5:50 PM > > To: GGF - ogsa-wg ml; ogsa-bes-wg(a)ggf.org > > Subject: [ogsa-wg] RM teleconference reminder -- container > properties > > > > Hi, > > > > On the next teleconference we will continue discussing the > > container's properties, as we did last week. I and Andrea > are working > > on a strawman mapping JSDL and CIM (the attached file is > what we have > > as of now). Examples of things to discuss: > > > > - Review the mapping > > - What in JSIM and CIM apply to the container? For > instance, there are > > more properties in a container than just JSIM (e.g. > > properties for monitoring). > > - How do Individual* and Total* JSIM properties apply to the > > container? > > Total* is across containers? > > - etc. > > > > My intention is to take the results of this teleconference > and present > > on the OGSA-BES teleconference on Thursday. > > > > Date: Tuesday, June 14th, at the following times: > > - 11:00-12:00 US Pacific (GMT - 7) > > - 12:00-13:00 US Mountain (GMT - 6) > > - 13:00-14:00 US Central (GMT - 5) > > - 14:00-15:00 US Eastern (GMT - 4) > > - 18:00-19:00 GMT > > - 19:00-20:00 UK (GMT + 1) > > - 20:00-21:00 Central Europe (GMT + 2) > > - 03:00-04:00 Japan (GMT + 9, following day) -- sorry. > > > > Dial-in: > > Toll Free: (888) 422-7120 > > Int'l Access: (608) 250-0194 > > Participant code: 693305 > > > > If screen sharing is needed, let's use Glance: > > URL: http://ogsa.glance.net > > Session key: 0614 > > Explanation: > > > > http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg > > 00077.html > > > > See you there, > > > > Fred Maciel > > Hitachi America R&D > > > >

1 0

RE: [ogsa-wg] RM teleconference reminder -- container properties
by Andrea Westerinen (andreaw) 14 Jun '05

14 Jun '05

Here are my updates for the call today ... Andrea > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of Fred Maciel > Sent: Monday, June 13, 2005 5:50 PM > To: GGF - ogsa-wg ml; ogsa-bes-wg(a)ggf.org > Subject: [ogsa-wg] RM teleconference reminder -- container properties > > Hi, > > On the next teleconference we will continue discussing > the container's properties, as we did last week. I and Andrea > are working on a strawman mapping JSDL and CIM (the attached > file is what we have as of now). Examples of things to discuss: > > - Review the mapping > - What in JSIM and CIM apply to the container? For instance, > there are more properties in a container than just JSIM (e.g. > properties for monitoring). > - How do Individual* and Total* JSIM properties apply to the > container? > Total* is across containers? > - etc. > > My intention is to take the results of this teleconference > and present on the OGSA-BES teleconference on Thursday. > > Date: Tuesday, June 14th, at the following times: > - 11:00-12:00 US Pacific (GMT - 7) > - 12:00-13:00 US Mountain (GMT - 6) > - 13:00-14:00 US Central (GMT - 5) > - 14:00-15:00 US Eastern (GMT - 4) > - 18:00-19:00 GMT > - 19:00-20:00 UK (GMT + 1) > - 20:00-21:00 Central Europe (GMT + 2) > - 03:00-04:00 Japan (GMT + 9, following day) -- sorry. > > Dial-in: > Toll Free: (888) 422-7120 > Int'l Access: (608) 250-0194 > Participant code: 693305 > > If screen sharing is needed, let's use Glance: > URL: http://ogsa.glance.net > Session key: 0614 > Explanation: > > http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg > 00077.html > > See you there, > > Fred Maciel > Hitachi America R&D > >

1 0

I have the pen on the standards xls <EOM>
by Tom Maguire 14 Jun '05

14 Jun '05

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupery T o m M a g u i r e STSM, On Demand Architecture Poughkeepsie, NY 12601

1 0

RM teleconference reminder -- container properties
by Fred Maciel 14 Jun '05

14 Jun '05

Hi, On the next teleconference we will continue discussing the container's properties, as we did last week. I and Andrea are working on a strawman mapping JSDL and CIM (the attached file is what we have as of now). Examples of things to discuss: - Review the mapping - What in JSIM and CIM apply to the container? For instance, there are more properties in a container than just JSIM (e.g. properties for monitoring). - How do Individual* and Total* JSIM properties apply to the container? Total* is across containers? - etc. My intention is to take the results of this teleconference and present on the OGSA-BES teleconference on Thursday. Date: Tuesday, June 14th, at the following times: - 11:00-12:00 US Pacific (GMT - 7) - 12:00-13:00 US Mountain (GMT - 6) - 13:00-14:00 US Central (GMT - 5) - 14:00-15:00 US Eastern (GMT - 4) - 18:00-19:00 GMT - 19:00-20:00 UK (GMT + 1) - 20:00-21:00 Central Europe (GMT + 2) - 03:00-04:00 Japan (GMT + 9, following day) -- sorry. Dial-in: Toll Free: (888) 422-7120 Int'l Access: (608) 250-0194 Participant code: 693305 If screen sharing is needed, let's use Glance: URL: http://ogsa.glance.net Session key: 0614 Explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html See you there, Fred Maciel Hitachi America R&D

1 0

Teleconference minutes - 8 June 2005
by Andreas Savva 13 Jun '05

13 Jun '05

Minutes attached. Outline: * Document review process * WSRF Basic Profile (BP) review * Roadmap review Gridforge: http://tinyurl.com/5fxfd/minutes-20050608/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 8 June 2005 ================================= * Participants Mike Behrens (R2AD, LLC) Hiro Kishimoto (Fujitsu) Fred Maciel (Hitachi) Tom Maguire (IBM) Mark Morgan (UVa) Takuya Mori (NEC, ANL) Andreas Savva (Fujitsu) Jem Treadwell (HP) Jay Unger (IBM) Apologies: Andrew Grimshaw Minutes: Andreas Savva * OGSA co-chair nomination Tom has received approval from management. * Document review process With three documents nearing completion the group discussed how best to complete the review process. 1. Put a clean copy with all changes accepted on gridforge (today or as soon as possible). Turn on line numbers (by 5 lines by page) for these versions to make it easier for people to refer to specific places in the text. 2. Assign people to go through entire document and do an overall check for consistency, with a special view on the flow of the text, completeness, etc. (Everyone is welcome to contribute to this effort.) 3. Assign people to verify (specific) trackers that are currently in the fixed state (One person per tracker; and maybe more than one tracker per person) The group also discussed how to do comments. There were two proposals: 1. Comments in the document and send document to the list 2. Send text email to the list pointing to the location in the document that needs revision. The overall preference was for the second option (text emails) rather than sending documents around. Partly for bandwidth reasons and partly due to issues of serialization and merging multiple document versions. But if a reviewers decide that a lot of editing is required then they should ask for, or take the pen (by sending an email to the list) and make the changes in the document. The deadline for completing the review is Monday, June 13. ** Basic Profile review volunteers - Proofreading (overall) - Dave Snelling (Tom to ask) - Jay Unger - Mike Behrens - Hiro Kishimoto - (And other people that Tom has asked already) - Tracker verification - Andreas Savva ** Profile definition review volunteers - Proofreading (overall) - Tom Maguire - Andreas Savva - Mike Behrens - Tracker verification - Not needed. All artifacts are closed. ** Roadmap review volunteers - Proofreading - Hiro Kishimoto - Takuya Mori - Tracker verification - Tom Maguire * WSRF Basic Profile (BP) review ** Should the referenced specs be updated? The WSRF BP is referring to an old (2004), somewhat inconsistent, set of specs for WS-Addressing, WSRF and WS-N. (Ref. WS-Addressing discussion). A number of recent developments might offer an opportunity to fix this: - WS-Addressing specs (last call) - The OASIS WSRF TC has a ballot closing at the end of this week (Sat., June 11 (1pm Eastern)) to send out the WSRF set of committee draft documents for public review - The WS-N group is planning to release committee drafts of the Base Notification specification (perhaps July 1) and also of Topics (and maybe also brokered notification). So it looks like there will be an updated, consistent set of documents to refer to. The problem is whether, and how, to keep the deadline for submitting the document to the GGF Editor (next week) and also make sure that the WSRF Basic Profile can be updated to use these specs when they come out. At the very least the changes required to the BP would be to the References, Namespaces and links to imported schemas. - For the WSRF and WS-Addressing specification these are (almost) known. - But the WS-N ones are not completely fixed yet. A number of scenarios were discussed: 1. Wait for the new versions to come out, update the BP and submit 2. Submit the document as-is and then put a public comment that it should be updated with the new WSRF+ set of specifications when they come out. 3. Put a comment in the document that it will be updated with the new WSRF+ set of specs and submit it as-is. - Scenario (3) was rejected since it clearly bends the rules too much. - Scenario (1) is the safest one but it keeps the BP queued and waiting for the updated specifications. - Scenario (2) follows the GGF process---the editors/authors are also encouraged to submit comments. But if there is a delay in the release of the referenced specs then the BP goes through as-is; or if there is a need for more changes than anticipated then a second round of public comment would be required. The remaining issue about scenario (2) was whether we are relaxing the submission rule as defined by "Profile Definition". The key point is whether the current draft of the BP, referencing old WS-Addressing, WSRF and WS-N drafts, qualifies for submission to the GGF Editor. In other words are the references used 'stable' and could the BP proceed to R-P status, potentially without any of the above changes. It was argued that the definition of 'stable' is that specifications must be at least 'committee drafts'. And that the existing referenced specs, even if they are not called 'committee drafts' have been through a similar process and are therefore of an equivalent level. In particular, it was proposed that the new OASIS type of "working draft" is equivalent to a "committee draft" since there is a vote by the TC to make such documents public. There was no consensus, however. The preference on the call was for scenario (2) and (1) in that order. The 'stable' reference rule needs more clarification, however. Action: Hiro to follow up on the definition of 'stable' and whether the specifications in question satisfy that rule. Also, if the group decides to go with (2) then the group has to discuss and agree on what the public comment should say. ** Section 4.1.1: ResourcePropertiesNames Defines syntax of resource properties, but there is no explanation of the meanings of most of these, what their values may be and why. Action: Tom will add an appendix with pseudo schema (mini spec) and additional text for each property. (A definition along the lines of R0415 and R0416.) ** Appendic C: Basic profile schema - There is a duplicate definition. - The definitions are incomplete (see above) Action: Tom will add cardinalities; perhaps add these in the mini-spec. ** Section 4.3: Serialization of XPath 1.0 response The mini-schema was defined to avoid the ambiguity in the XPath spec. But why did not other people try to solve it, already? The WSRF TC, for example, is aware of this problem but decided that it did not have the authority to fix this. (Out of scope.) The W3C, which has the authority to address this problem, also has not done anything. But the W3C does not mandate XPath 1.0. In the WSRF BP 1.0 XPath 1.0 is mandated so a solution had to be provided. Action: Tom will add explanation to the BP on the necessity of defining the XPath 1.0 response serialization. ** Numbering of R & E statements Numbering is inconsistent. Some numbers are based on section numbers; some on subsection. Action: Tom will make them consistent; suggestions welcome. ** Appendix A There are three references to UDDI specs. Agreed that the list needs cleanup. Action: Tom to clean up list and in particular remove the UDDI binding template reference. ** Appendix B Also needs cleanup. * Roadmap review Jem has done some work on how to keep tables consistent. Tom has also independently done some work on this. They seem to have arrived to the same solution. - Use an excel spreadsheet for the master table and produce separate smaller tables in separate sheets for each specific spec. These smaller tables refer to row/column in the master sheet. Considered linking the spreadsheets directly to the Roadmap using OLE but rejected this during the call since it is not a platform-neutral method. (People using Macs could not use the Word document.) Therefore it was agreed that the master table and sub-tables should be done in Excel. And a 'view' or 'image' of the sub-tables should be provided for use in the Word document.

2 1

OGSA-D telcon agenda for June 15th - Use cases,
by Dave Berry 13 Jun '05

13 Jun '05

Dear all, This week's telcon will be on Wednesday (15th June), at the usual time of 8:00am PDT / 11:00am EDT / 4:00pm BST / 5:00pm CEST. PIN for this call: 632 065 UK Dial In: 0845 245 0224 US Dial In: 1866 838 0046 International Dial In: +44 1452 542309 Here is a provisional agenda for this week. 1) Early discussion (5 min) Note taker assignment Roll call Minutes approval Agenda bashing 2) Action report (5 min) - Dave to reconfigure tracker mail [Done] - Dave to reply to Torsten of the TM-RG, inviting him to our session [Done] - Ann will organise the security notes we've taken so far into a coherent memo that we can take to the security working groups. - Dave will discuss security with the NeSC security people. - Dave will approach the OGSA WG security design team about a joint meeting. - Allen will approach the OGSA-AuthZ WG about a joint meeting. - Stephen to iterate on the replication use case. [Done] - Dave to revamp section 3 of the architecture document. 3) WG status (5 min) - Trackers - GGF working drafts - GGF session plan 4) Use cases (20 min) 5) Security requirements for data grids (20 min) 6) Wrap up (5 min) AOB DONM Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

Proposed agenda for June 13th call
by Hiro Kishimoto 13 Jun '05

13 Jun '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on June 13th Monday from 5pm to 7pm (CDT). Since our plate is full on Monday, I propose to postpone OGSA fellow WG status report to Wednesday. The dial-in number for Monday; Free: +1-866-639-4741 Toll: +1-574-935-6703 PIN: 8980700 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0613 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval http://tinyurl.com/5fxfd/minutes-20050608/en/1 http://tinyurl.com/5fxfd/minutes-20050606/en/1 http://tinyurl.com/5fxfd/minutes-20050601/en/2 http://tinyurl.com/5fxfd/minutes-20050518/en/1 http://tinyurl.com/5fxfd/minutes-20050516/en/1 http://tinyurl.com/5fxfd/minutes-20050511/en/1 http://tinyurl.com/5fxfd/minutes-20050509/en/1 Agenda bashing 2) OGSA roadmap review (30 min) Jem has uploaded the revised version to the GridForge. - http://tinyurl.com/aez86 Look forward to proofread and tracker verification. 3) OGSA WSRF BP 1.0 review (30 min) Discuss and decide when we submit BP 1.0. >From June 8th minutes > 1. Wait for the new versions to come out, update the BP and submit > 2. Submit the document as-is and then put a public comment that it > should be updated with the new WSRF+ set of specifications when > they come out. > Action: Hiro to follow up on the definition of 'stable' and whether > the specifications in question satisfy that rule Tom has uploaded the revised version to the GridForge. - http://tinyurl.com/5fxfd/draft-ggf-ogsa-wsrf-basic-profile Look forward to proofread and tracker verification. 4) OGSA profile definition review (30 min) Tom has uploaded the revised version to the GridForge. - http://tinyurl.com/5fxfd/draft-ggf-ogsa-profile-definition Look forward to proofread and tracker verification. 5) Wrap up (10 min) AOB June 15th (Wed) fellow WG status report & OGSA-WG next step discussion June 20th (Mon) CDDLM cross-WG session, EMS architecture June 22th (Wed) GGF14 preparation ---- Hiro Kishimoto

2 3

RE: Resilient References? (Re: [ogsa-wg] ogsa London f2f minutes uploaded)
by Savas Parastatidis 13 Jun '05

13 Jun '05

Mark (that's Mark McKeown), You are assuming HTTP here while most (if not all) of WS-* specs do not make that assumption. While what you are describing with HTTP headers may work indeed, they are all tied to HTTP. We are now seeing SOAP processors supporting other transport protocols as well (e.g. Indigo and Axis 2 support SOAP over TCP/IP). (note that I am treating HTTP as a transport protocol here and now as an application protocol :-) Regards, -- Savas Parastatidis http://savas.parastatidis.name > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of > Mark McKeown > Sent: Friday, June 10, 2005 4:32 PM > To: Mark Morgan > Cc: ogsa-wg(a)ggf.org > Subject: RE: Resilient References? (Re: [ogsa-wg] ogsa London f2f minutes > uploaded) > > > Hi folks, > I have read the WS-Naming strawman and been trying to follow > the discussion on resilient references on the list. Putting EPRs inside > EPRs seems a bit strange to me - the following seems simpler (the > obvious inspiration is tinyurl) ... > > <wsa:EndpointReference> > <wsa:Address>mailto:mark.mckeown@manchester.ac.uk</wsa:Address> > <ws-name:Handle>http://www.thegrid.com/a4dfg</ws-name:Handle> > </wsa:EndpointReference> > > Where "Handle" is used as an identifier/name and is mandated to be > a HTTP/S URI. To resolve the Handle a client does a HTTP GET on the > URI to get a new EPR, (client gets 404 if resolution is not supported, > 410 if the service/resource is gone/terminated). > > I can see a number of advantages to this: > > *) It is simple and easy to implement. > > *) The Cache-Control headers in HTTP can be used to pass on information > to the client to indicate how long it can cache an EPR for - this > is an optional optimization. > > *) If-Modified-Since HTTP header could be supported so a client will only > retieve a new EPR if the one it has is stale - again an optional > optimization. > > *) The "Handle" is easy to pass around between users - it can be pasted > into a mail message and the reciever can use HTTP GET to retrieve the > EPR. > > *) HTTPS can be used when trust is important. > > *) The service developer can make his EPRs "resilient" whenever he wants, > ie he creates an EPR with a "Handle" but only later makes the "Handle" > URI live. > > Effectively the low level HTTP protocol could be used to bootstrap the > higher level SOAP protocol. Perhaps there are strong reasons why this > approach was not considered? > > cheers > Mark > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Mark Mc Keown RSS > Mark.McKeown(a)man.ac.uk Manchester Computing > +44 161 275 0601 University of Manchester > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > On Fri, 10 Jun 2005, Mark Morgan wrote: > > > > when Mark writes: "...the general idea we have is to in fact > > > possibly have a method who's signature is EPR resolve( [EPR] > > > ) Where the parameter EPR is optional..." > > > > > > Does this "optional" mean that the schema for the input > > > message parameter of the resolve operation will have an > > > optional "EPR"; it should either be empty or consist of a single EPR? > > > > Borrowing the pseudo syntax used in the "Web Services Base Notification > 1.2 > > Working Draft 03, 21 June 2004" and replacing the given template for the > > NotificationMessage syntax with appropriate naming elements, what I mean > is > > this: > > > > > > <ogsa-naming:Resolve> > > <ogsa-naming:ResolutionMessage> > > <ogsa-naming:TargetEPRHint>? > > wsa:EndpointReference > > </ogsa-naming:TargetEPRHint> > > </ogsa-naming:ResolutionMessage> > > </ogsa-naming:Resolve> > > > > > If so, what does the "optional" mean for the implementors of > > > that porttype/operation "EPR resolve( [EPR] )"? > > > Does the service implementation have to cater for both options? > > > > No, it doesn'. It can implement the empty parameter one, or both the > empty > > parameter one and the one that takes an EPR as a parameter. See below > for > > explanation. > > > > > Or can it just return an error for the one it doesn't implement? > > > > No, this would not be correct I don't believe. > > > > > And then what does the "optional" mean for the client's processing? > > > If the schema indicates that the client could either call the > > > resolve operation with or without the original EPR, how does > > > it know which option to choose? Should it just try the one it likes? > > > > The important points to recall here are: > > 1) There are two EPRs involved in this communication conversation. > > One is the obvious one listed as an optional parameter. For clarity, > let's > > call that parameter the "Hint EPR". The other EPR is the implicit one > which > > would be indicated in the SOAP headers to which the communication is > taking > > place. Let's call that EPR the "Resolver EPR". > > 2) The Resolver EPR is created with whatever information the > > implementor of the resolution services feels is appropriate. It's up to > > that service to generate an EPR with enough information to do the > > resolution. > > 3) The Hint EPR is just that -- a hint. It should not be considered > > the end all source of information for resolution. > > > > What we imply by all of this is that a resolution service should be able > to > > deal with a resolution message that does not include any EPR as a > parameter > > by virtue of the fact that the Resolution EPR to which the resolution > > messages are addressed is created by that service with enough > information to > > completely carry out the resolution. If an EPR is given as a parameter > to > > that resolution service, the service MAY choose to use that hint to more > > efficiently resolve the endpoint in question, but is not required to do > so. > > In otherwords, a resolution service implementor may choose to implement > code > > that uses the optional EPR parameter if available, but MAY also choose > to > > ignore it. > > > > >From the client perspective, it should be the case that the client may > > equally choose to send either an empty message (since this is guaranteed > to > > work), or one with an EPR (since a service may choose to ignore this > > parameter). In this way the client is free to pick either one -- the > > parameterless one if it feels inclined to go with no hints, or the > message > > with an EPR if the client feels like this extra hint may be useful. > > > > So, in what cases would the EPR parameter be useful should the client > decide > > to send it and should the service decide to use it? Well, in the > general > > case, we have found that it is tremendously useful (bordering on > necessary) > > sometimes for a client to indicate to a resolution service that that > client > > has already tried to communicate with a given binding (EPR) and that the > > resolution service might want to go to extra efforts (i.e., instead of > just > > looking the binding up in a cache or table) to determine whether or not > a > > more suitable EPR exists. > > > > -Mark > > > > > Thanks, Frank. > > > >

2 1