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

RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
by Maguire_Tom＠emc.com 21 Oct '05

21 Oct '05

As promised at the F2F in Boston I have started a thread of discussion on the subject line. I have reposted the thread to the this mailing list (ogsa-wg) in the hope that broader distribution will spur debate and discussion. Tom -----Original Message----- From: Maguire, Tom Sent: Sunday, October 09, 2005 4:51 PM To: Maguire, Tom; David.Snelling(a)UK.Fujitsu.com Cc: ogsa-naming-wg(a)ggf.org; tuecke(a)univa.com Subject: RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding Dave you mentioned in one of your question: >>It appears that in the example that either the was:Address and the >>soap:address must be the same or that the wsa:Addess is irrelevant. >> I can't really believe the former so let's assume the later. It's not that the wsa:adddress is irrelevant it is that the wsa:address is logical as opposed to physical. This is precisely why I think we can use it.... Tom -----Original Message----- From: owner-ogsa-naming-wg(a)ggf.org [mailto:owner-ogsa-naming-wg@ggf.org] On Behalf Of Maguire, Tom Sent: Sunday, October 09, 2005 8:35 AM To: David.Snelling(a)UK.Fujitsu.com Cc: ogsa-naming-wg(a)ggf.org; tuecke(a)univa.com Subject: RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding Dave, I'll do my best to answer your questions inline below. Let me caution this thread a bit. The WSDL Binding specification is not complete and is clearly still evolving... >>It appears that in the example that either the was:Address and the soap:address must >>be the same or that the wsa:Addess is irrelevant. I can't really >>believe the >>former so let's assume the later. Yes, I believe that is the intent. As I mentioned in my note it is 'interesting' that they are the same. My guess is that makes implementations that are not <wsa:metadata> aware able to cope. I would expect that would be a 'best practice'. Not sure what the implications would be for us if that were the case... >>With a wsdl11:definitions section present, the wsa:Address field must >>be superseded >>by the soap:address chosen by the client. I assume that the >>soap:address gets copied to the was:To field in the soap header. Ultimately you are correct however I expect that the specification of that linkage would not be quite as explicit as that. >>There is no linkage in the wsdl11:definitions to connect the >>wsa:Address to it. No >>Q1) What happens with more than one wsdl11:definitions section in the >>was:Metadata? I have no idea what that would even mean. I presume they would limit that in the spec. As I said it is still evolving. >>Q2) In this case can we put any old junk in the wsa:Address? >>i.e. leave it out (except that the scheme saus [1..]. <wsa:address> is required and I would assume that at a minimum there would be a statement of 'best practice' where the <wsa:address> is the 'default' address. >>Q3) If we use the wsa:Address as an Abstract Name, how do we know that >>is what >>we are doing? We could subtype the EPR to create a WS-Name as we do >>now, and bind the usage of the was:Address to type of the WS-Name. I would use a wsi conformance claim on both the wsdl and the EPR. The wsdl claim would be that the service is capable of generating WS-Names. The EPR claim would be that this EPR adheres to the additional semantics of a WS-Name. >>Q4) I thought WS-Addressing was NOT about naming or identity. >>How will this use (abuse) of the wsa:Address go down with the W3C folks? I think this is a misread on your part W3C objected to identity being encoded in something OTHER than a URI (IRI); in the WS-Addressing case they objected to ReferenceProperties. Ultimately ReferenceProperties were merged with ReferenceParameters which weakened (removed) the identity semantic. I think they would be extremely happy with the use of a URI as an identifier :-). Tom On 7 Oct 2005, at 12:41, Maguire_Tom(a)emc.com wrote: > This will be a fairly long note to discuss the current incarnation of > WS-Naming Abstract Names. An Abstract Name has the following > properties: > > * The name MUST be globally unique in both space and time. > * The name conforms to URI syntax ("Uniform Resource Identifiers > (IRI): Generic Syntax", RFC 3987). > > Let's leave aside the first point, for the time being, and focus on > the second point. The abstract name is an IRI which is an > internationalized URI. Currently this means that a WS-Name abstract > name would look like > this: > > <wsa:EndpointReference > xmlns:wsa="http://www.w3.org/2005/03/addressing" > xmlns:name="http://ggf.org/name"> > <wsa:Address>http://tempuri.org/example</wsa:Address> > > <name:AbstractName>urn:guid:B94C4186-0923-4dbb-AD9C-39DFB8B54388</ > name:Abstr > actName> > </wsa:EndpointReference> > > There are several built in assumptions in this particular rendering of > an > abstract name. First, there is an assumption that the <wsa:Address> > is the > [destination] MAP of the EPR. Second, the AbstractName does not need > to flow on the wire when 'dereferencing' this EPR. > > It may be ok for the AbstractName to not flow on the wire. I will > leave that discussion to others. Let's focus on the first > assumption... > If you assume that the <wsa:Address> is NOT necessarily a physical > address > (URL) then it is essentially the same as an AbstractName minus the > "MUST be globally unique in both space and time" property described > above. > > This is essentially how 'Web Services Addressing 1.0 - WSDL Binding' > defines > a <wsa:Address>. An example from that specfication: > > <wsa:EndpointReference > xmlns:wsa="http://www.w3.org/2005/03/addressing"> > <wsa:Address>http://example.com/fabrikam/acct</wsa:Address> > <wsa:Metadata> > <wsdl11:definitions targetNamespace="http://example.com/fabrikam" > xmlns:fabrikam="http://example.com/fabrikam" > xmlns:abc="http://www.abccorp.com/" > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" > xmlns:iiop="http://www.iiop.org/" > xmlns:wsdl11="http://schemas.xmlsoap.org/wsdl/"> > <wsdl11:import namespace="http://example.com/fabrikam" > location="http://example.com/fabrikam/fabrikam.wsdl"/> > <wsdl11:import namespace="http://www.abccorp.com/" > location="http://www.abccorp.com/abc.wsdl"/> > <wsdl11:service name="InventoryService"> > <wsdl11:port name="ep1" binding="abc:soap-http-binding"> > <soap:address location="http://example.com/fabrikam/acct"/> > </wsdl11:port> > <wsdl11:port name="ep2" binding="abc:iiop"> > <iiop:address location="..."/> > </wsdl11:port> > </wsdl11:service> > </wsdl11:definitions> > </wsa:Metadata> > </wsd:EndpointReference> > > And also from 'Web Services Addressing 1.0 - WSDL Binding' > > In particular, embedding a WSDL service component description MAY be > used by EPR issuers to indicate the presence of alternative addresses > and protocol bindings to access the referenced endpoint. The > alternatives are provided by the different endpoints of the embedded > service. > > It is interesting to note that in the above example that the > <wsa:address> matches the soap:address location. > So this says to me that the <wsa:address> is essentially equivalent > (or at least could be) to an abstract name. > > Thoughts? > > > Thanks, > Tom > > Senior Technologist, CTO Office > EMC²|SMARTS > 44 South Broadway > 7th Floor > White Plains, NY 10601 > Office: +1-914-508-3477 > Mobile: +1-845-729-4806 > Email: maguire_tom(a)emc.com <mailto:maguire_tom@emc.com> > > If you want to build a ship, don't drum up people to collect wood and > don't assign them tasks and work, but rather teach them to long for > the endless immensity of the sea. > > Antoine de Saint-Exupery > > -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

5 6

Teleconference minutes - 19 October 2005
by Andreas Savva 20 Oct '05

20 Oct '05

Minutes attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051019/en/1 -- Andreas Savva OGSA Teleconference - 19 October 2005 ===================================== * Participants Mike Behrens (R2AD, LLC) Andrew Grimshaw (UVa) Hiro Kishimoto (Fujitsu) Allen Luniewski (IBM) Tom Maguire (EMC) Takuya Mori (NEC) Steven Newhouse (OMII) Andreas Savva (Fujitsu) Ellen Stokes (IBM) Ravi Subramaniam (Intel) Jay Unger (IBM) Pete Ziu (Northrop Grumman) Minutes: Andreas Savva * Minutes approval - Teleconference minutes for Sep 28, Oct 12 and 17 approved with no changes - GGF15 minutes approved with no changes - F2F minutes approved with no changes * Management Developement Conference presentation - Confirmed Ravi as the presenter - There is an existing slide deck. Andrew will upload it to Gridforge and the group will review it next week. - Hiro to add the review of this presentation on next Monday's call. Scheduled time 20 minutes. * EMS discussion - Review of UML sequence diagram previously sent out by Steven N. - Background: - Initially generated during last F2F and partly revised afterwards. - This is scenario 2.3 - Clarified that this is *a* scenario not *the* scenario to address this particular stage of the EMS Roadmap. There may be other sequences. - The JSDL document is initially abstract and becomes more concrete, for example, as a result of the EPS invocation. - The EMS Roadmap should also list the JSDL features that should be supported and make clearer what is becoming more concrete. - Where is ACS? - ACS is part of a later scenario according to this Roadmap. - Why not include CSG in this diagram? - EPS is seen as a black box at this point. It may be calling CSG behind the scenes but this interaction does not need to be shown in this diagram. - Why not rename EPS to RSS then? - RSS is the name of the group not of a service or interface. - The positioning of Agreement - Donal pointed out on the list that the return of EPS may be some form of Agreement. - Details are not clear yet. May have to put together another diagram to show this. Or it may be clearer in later stages of the Roadmap, e.g., when including reservations in the sequences. - Ravi volunteered to refine some of these scenarios. He will provide text for the EMS Roadmap. - Why is the job and its management not shown in the sequence diagram? - Its representation and management are out of scope of this stage of the Roadmap. - Is a sequence diagram of stopping the job also out of scope at this stage? Yes. - The EMS Architecture document should include more detail to describe everything in the sequence diagram, e.g., the ordering policy mentioned in the call to EPS. - It is not the intention for the EMS Architecture document to be normative but it should be more detailed than what's in OGSA Architecture (1.0 or later). The OGSA Architecture document should contain a higher level summary of what will (eventually) be in the EMS Architecture document. - Starting point: - The EMS section from OGSA 1.0 (or 1.5); and - the older EMS draft (pre-OGSA 1.0) (Andreas has sent this to Steven. It is somewhat dated but useful as background information.) - OGSA-WG should agree on a common UML tool so as to share the work of drawing up these sequence diagrams. - Criteria: free for use and reasonable performance - Andreas has a list of (free) tools and will send it out. - JUDE is being used by some people. It comes in various versions with the free versions having some limitations. * Charter - Andrew to take the OGSA-WG charter to the GFSG for approval. * Other business - Postponed the Information model discussion for next week.

2 1

UML Diagram for today's call
by Steven Newhouse 19 Oct '05

19 Oct '05

Following on from the GGF15 F2F and last week's call here is a UML diagram illustrating stage 2.3 of the EMS Composition Roadmap) for the next call. Comments to the list or save it for the call if you will be there! 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

2 1

Proposed agenda for Oct. 19th call
by Hiro Kishimoto 19 Oct '05

19 Oct '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on Oct. 19th Wednesday from 5pm to 7pm (CDT). OGSA WSRF Basic Profile has entered public comment period. Thanks Andrew and Dave. https://forge.gridforum.org/forum/forum.php?forum_id=575 *Advance Notice* From Oct. 31 and onward telecon starts one hour earlier 5pm EST = 4pm CST = 2pm PST = 10pm UK = 7am JST 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: 1019 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (10 min) Note taker assignment Roll call Agenda bashing 2) Minutes approval (20 min) Telecon minutes approval (Sept. 28, Oct. 12, and Oct. 17): https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050928/en/1 https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051012/en/1 https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051017/en/1 GGF15: https://forge.gridforum.org/projects/ogsa-wg/document/ggf15-ogsa-session-1/… https://forge.gridforum.org/projects/ogsa-wg/document/ggf15-ogsa-session-2/… F2F: https://forge.gridforum.org/projects/ogsa-wg/document/ggf15-f2f-minutes-200… https://forge.gridforum.org/projects/ogsa-wg/document/ggf15-f2f-minutes-200… 3) Management Development Conference (10 min) > - Looking for volunteers to give an introductory presentation on > OGSA. > - No known hard deadline for accepting; as-soon-as-possible. > - Both Jay and Tom expressed interest but cannot commit yet. > - Interested parties should contact Hiro. - Ravi has volunteered and committed to present. Discuss and choose presenter. 4) EMS architecture discussion (60 min) > The plan is to merge the Roadmap draft from the F2F and the sequence > diagrams together with the EMS architecture text from OGSA 1.0. The > end result to be the EMS architecture document, one of the > deliverables listed in the new charter. > > - Steven N will do a first draft. > - Weekly EMS calls (allocate half of Wed call) > - Steven volunteered to update the draft scenario (3.2) by next > Wednesday's call https://forge.gridforum.org/docman2/ViewCategory.php?group_id=42&category_i… 5) information model discussion (20 min) BES container profile status update 6) Wrap up (10 min) AOB <NEXT CALL> Oct. 24 (Mon) Basic Security Profile document review, Architecture & Glossary 1.5 (data section review) Oct. 26 (Wed) EMS architecture, information model & CIM profile Oct. 31 (Mon) Basic Security Profile document review, Architecture & Glossary 1.5 (data section review) Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

1 0

Teleconference minutes - 17 October 2005
by Andreas Savva 18 Oct '05

18 Oct '05

Minutes attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051017/en/1 -- Andreas Savva OGSA Teleconference - 17 October 2005 ===================================== * Participants Jay Unger (IBM) Jem Treadwell (HP) Andreas Savva (Fujitsu) Takuya Mori (NEC) Tom Maguire (IBM) Hiro Kishimoto (Fujitsu) Mike Behrens (R2AD, LLC) Minutes: Andreas Savva * The approval of the following minutes was postponed for Wednesday - Sep 28 - GGF15 sessions - GGF15 F2F - Oct 12 * WSRF RMD spec ownership Dan Jemiolo from WSDM TC joined WSRF TC and has taken over the editorial of the RMD spec. No action from OGSA-WG is needed. * Charter update - Hiro incorporated minor edits by Jem. - Andrew as AD to take to the GFSG. * Teleconference schedule - Teleconference schedule as agreed on during the F2F. * Management Developer Conference - Venue: Santa Clara - Looking for volunteers to give an introductory presentation on OGSA. - No known hard deadline for accepting; as-soon-as-possible. - Both Jay and Tom expressed interest but cannot commit yet. - Interested parties should contact Hiro. * Security Profile issues review - Takuya uploaded issues: 7 issues in total for the secure channel profile - 1656: Added the WSRF BP Security Profile URI claim - Takuya to double-check that the correct URI is used - 1657: Takuya checking BSP 1.0 and will add the missing extensibility points, if appropriate - 1658: Focus profile on TLS and review MLS requirements - Main things left are statement to only use TLS (not SSL), mutual authentication, and some of the assertions. - The key exchange is worded for MLS but can also be used for TLS. - Takuya to change the text to 'When exchanging keys...' instead of 'When using MLS...' - 1659: Takuya reviewing - 1660: Agreed on the call that it is ok as is. - 1661: Tom is ok as contributor - 1662: WS-I BSP reference. Takuya checking which version to use (Jan or Aug). But, unless there is a specific reason it is better to refer to the latest one. - Other issues: - Since there may be additional basic profiles the text describing the relation of this security profile and the WSRF BP should be revised. (Tom will propose new text.)

1 0

[ogsa-wg | Secure Channel 1.0 - 1663] normative dependency to OGSA WSRF Profile
by Sourceforge Tracker Monitor 17 Oct '05

17 Oct '05

A new artifact has been added: 1663 Submitted by: Takuya Mori Submitted date: 2005-10-18 08:47:42 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1663&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1663&group_id…) Summary: normative dependency to OGSA WSRF Profile Project: Open Grid Services Architecture Tracker: Secure Channel 1.0 Artifact ID: 1663 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Takuya Mori Last Modified: 2005-10-18 08:47:42 Submitted By: Takuya Mori Submit Date: 2005-10-18 08:47:42 Assigned To: &lt;None&gt; File(s): <None> Description: Not the profile has a normative dependency to the OGSA WSRF Basic Profile. There may be another (or some more?) Basic Profile come up in the future. It's good to remove the normative dependency to the OGSA WSRF Basic Profile to make the profile combinable with other Basic Profles. View the Secure Channel 1.0 : 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

[ogsa-wg | Secure Channel 1.0 - 1662] the latest WS-I BSP
by Sourceforge Tracker Monitor 17 Oct '05

17 Oct '05

A new artifact has been added: 1662 Submitted by: Takuya Mori Submitted date: 2005-10-18 02:43:08 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1662&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1662&group_id…) Summary: the latest WS-I BSP Project: Open Grid Services Architecture Tracker: Secure Channel 1.0 Artifact ID: 1662 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Takuya Mori Last Modified: 2005-10-18 02:43:08 Submitted By: Takuya Mori Submit Date: 2005-10-18 02:43:08 Assigned To: &lt;None&gt; File(s): <None> Description: The Aug. 29 version of the WS-I BSP 1.0 has been released. We need to check the difference between the jan 20th version. (It might be better to refer to the latest one) View the Secure Channel 1.0 : 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

[ogsa-wg | Secure Channel 1.0 - 1661] author information
by Sourceforge Tracker Monitor 17 Oct '05

17 Oct '05

A new artifact has been added: 1661 Submitted by: Takuya Mori Submitted date: 2005-10-18 02:41:32 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1661&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1661&group_id…) Summary: author information Project: Open Grid Services Architecture Tracker: Secure Channel 1.0 Artifact ID: 1661 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Takuya Mori Last Modified: 2005-10-18 02:41:32 Submitted By: Takuya Mori Submit Date: 2005-10-18 02:41:32 Assigned To: &lt;None&gt; File(s): <None> Description: Should we move 'Tom Maguire' from Contributors to Author Information? View the Secure Channel 1.0 : 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

[ogsa-wg | Secure Channel 1.0 - 1660] R0324
by Sourceforge Tracker Monitor 17 Oct '05

17 Oct '05

A new artifact has been added: 1660 Submitted by: Takuya Mori Submitted date: 2005-10-18 02:40:05 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1660&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1660&group_id…) Summary: R0324 Project: Open Grid Services Architecture Tracker: Secure Channel 1.0 Artifact ID: 1660 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Takuya Mori Last Modified: 2005-10-18 02:40:05 Submitted By: Takuya Mori Submit Date: 2005-10-18 02:40:05 Assigned To: &lt;None&gt; File(s): <None> Description: Review WS-I BSP and check what is the requirement for RECEIVER. Perhaps, this should be phrased differently from the description for SENDER role. View the Secure Channel 1.0 : 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

[ogsa-wg | Secure Channel 1.0 - 1659] R0305, 0306 Support for SSL
by Sourceforge Tracker Monitor 17 Oct '05

17 Oct '05

A new artifact has been added: 1659 Submitted by: Takuya Mori Submitted date: 2005-10-18 02:37:12 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1659&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1659&group_id…) Summary: R0305, 0306 Support for SSL Project: Open Grid Services Architecture Tracker: Secure Channel 1.0 Artifact ID: 1659 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Takuya Mori Last Modified: 2005-10-18 02:37:12 Submitted By: Takuya Mori Submit Date: 2005-10-18 02:37:12 Assigned To: &lt;None&gt; File(s): <None> Description: Does the use of SSL violates the conformance statement? Shoud we preclude SSL? Takuya to follow up on distinction between ssl and tls. View the Secure Channel 1.0 : 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