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

rough sketch for design team discussion
by Hiro Kishimoto 16 Feb '05

16 Feb '05

Hi Fred, Frank, Takuya, Abdeslem, Attached is my rough sketchy proposal for design team architecture discussion tomorrow. Feel free to bash this :-) ---- Hiro Kishimoto

1 0

What's in a webservice-resource name...?
by Frank Siebenlist 15 Feb '05

15 Feb '05

I would like to re-start a discussion about the naming of resources now that the resource reference properties have been ousted. (this ousting may be a blessing as it could simplify our naming as I will argue) The following is a snippet from the latest ws-addressing draft: ------<snippet>-------- 2.3 Endpoint Reference Comparison During the course of Web services interactions applications may receive multiple endpoint references describing the endpoints it needs to interact with. Different copies of an endpoint reference may also be received over time. The following rule clarifies the relation between the behaviors of the endpoints represented by two endpoint references with the same [address]; • The two endpoints accept the same sets of messages, and follow and require the same set of policies. That is, the XML Schema, WSDL, and policy and other metadata applicable to the two references are the same. However, the metadata embedded in each of the EPRs MAY differ, as the metadata carried by an EPR is not necessarily a complete statement of the metadata pertaining to the endpoint. Moreover, while embedded metadata is necessarily valid at the time the EPR is initially created it may become stale at a later point in time. To deal with conflicts between the embedded metadata of two EPRs, or between embedded metadata and metadata obtained from a different source, or to ascertain the current validity of embedded metadata, mechanisms that are outside of the scope of this specification, such as EPR life cycle information [see 2.4 Endpoint Reference Lifecycle] or retrieval of metadata from an authoritative source, SHOULD be used. The [address] properties of two endpoint references are compared according to Section 6 of [RFC 2396bis]. Therefore, a consuming application should assume that different XML Schemas, WSDL definitions and policies apply to endpoint references whose addresses differ. 2.4 Endpoint Reference Lifecycle This specification does not define a lifecycle model for endpoint references and does not address the question of time-to-live for endpoint references. Other specifications that build on or use WS-Addressing may define a lifecycle model for endpoint references created according to that specification. --------</snippet>------ It is almost as if lawyers wrote the statements above... or maybe it is an ill description of a Turing test that we can use to determine if two EPRs refer to the same webservice-resource... :-( My layman and naive interpretation is that if the EPR's addresses of two EPRs are the same, then they refer to the same resource. We essentially now have a "name" for our resource, which is the address' URI value, and if EPR-names are equal, then those names refer to the same webservice-resource. I remember that we challenged the "uniqueness" property of the address before. (e.g. the use of ip-addresses inside an EPR-address, like 127.0.0.1 or 10.*.*.* would not make the EPR-address globally unique addresses). However, in practice we must have a uniqueness property for the address within the "context of usage", otherwise we would be in real trouble. So, we could live within *our* 10.*.*.* domain happily and be guaranteed about the uniqueness of those ip-addresses. In other words, the real global uniqueness may not be a big deal in practice, and there are simple remedies like adding a uuid to the uri if needed. If we have in addition a resolver-EPR that we can associate with an EPR through embedding (or through other means), then we essentially have introduced a mechanism that we could use for an additional naming-level scheme. The Resolver-EPR is also an EPR, and will also have a name: its address' URI. The Resolver-EPR's name will also uniquely refer to the same webservice-resource as the EPR it is associated with. In other words, the Resolver-EPR's name can be used as an alternative name for the webservice-resource. We can use this to derive statements like: if two EPR have different names, but their associated resolver-EPRs have the same name, then those EPRs refer to the same webservice-resource. It would allow a client to find out that different EPRs that use different mechanisms, like soap/http and soap/reliable-messaging, describe alternative ways to talk to the same webservice-resource As the EPR's address can be "logical", we could use any naming scheme we want for a Resolver-EPR's address (as long as it's an URI), and could use human readable names, or application-domain specific names, or UUIDs. In other words, by standardizing the usage convention of a resolver/stable/resilient/renewable-EPR, we have introduced a flexible naming mechanism for our webservice-resources. It would also leave the use of different naming schemes open ... which could be considered a good thing. Regards, Frank. PS. I feel obliged to point out that there are serious trust issues associated with the binding of different names to the same webservice-resource...but that is orthogonal to the "naming" itself. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

[ogsa-wg | Basic Profile - 1231] ENDPOINTREFERENCE resilientReference element definition
by Sourceforge Tracker Monitor 15 Feb '05

15 Feb '05

Tom Maguire changed 1231 on 2005-02-14 12:43:21 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1231&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1231&group_id…) Summary: ENDPOINTREFERENCE resilientReference element definition Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1231 Category: <None> Group: <None> Status: Open Priority: 2 Last Modified By: Tom Maguire Last Modified: 2005-02-14 12:43:21 Submitted By: Tom Maguire Submit Date: 2005-01-28 14:01:04 Assigned To: &lt;None&gt; File(s): <None> Description: section 3.1.5. Need to define the schema for normative description of resilientReference. ---------------------------------------------------------------------- Comment By: Tom Maguire (2005-02-14 12:43:21) reliable endpoints are a basic necessity and that they are of such a key importance, that their placement in as low a level "profile" as possible is good. Ideally, we'd like to see it in WS-Addressing itself. The logical choice (and the one we all came up with individually) was to start placing information into the extensibility elements of the WS-Addressing Endpoint Reference. The specifics aren't important in general, but the idea was to have another EPR sitting inside one of these extensibility elements which could then be used (in the case of failure to communicate with a given endpoint) to re-bind to the endpoint. In othrwords, if I try to communicate with EPR alpha, and I fail for some reason to reach him/her, then I can look for this extensibility element inside of EPR alpha's EPR which will in turn be another EPR that I should be able to go to and ask for a "new" binding to EPR alpha. The parts that we disucussed which weren't quite so identical were: a) That this extensibility element could have 0..unbounded EPR's inside of it b) That the abstract name would be part of it. A) I think is fine either way as long as you can have 0 or 1. Andrew and I would tend to think that 0..unbounded gives you the most flexibility while not complicating a client's code unnecessarily. If the service provider doesn't want to use more then 1 EPR for re-binds, then he doesn't have to. 0 is important to "bottom" out the chain of binding agents. B) Is perhaps the more interesting thing to discuss. The naming group has come up with a number of requirements for abstract names that include: * Globally Unique in time and space * Easy (and cheap) to compare one abstract name against another for equality. * Persistent for the entire lifetime of the endpoint to which it refers. Based on this, Andrew and I want to make it a first class entity as much as possible. Making sure that the thing is easily comparable is very important. To be more concrete, ignoring XML syntax errors and my use of random and incorrect qnames, here is more or less what we were thinking an example EPR should look like.... <EPR> <Address>http://some-machine.org/some-path</Address> <ReferenceProperties>Whatever you want here</ReferenceProperties> <ExtensibilityPolicyWhatHaveYou> <OGSA-Bind-Info> <AbstractName>509733A3-7850-4cb9-AB54-F1B83078F1B4</AbstractName> <RebindAgent> // some other EPR </RebindAgent> </OGSA-Bind-Info> </ExtensibilityPolicyWhatHaveYou> </EPR> ---------------------------------------------------------------------- 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=…)

2 2

Proposed agenda for Jan. 24th call
by Hiro Kishimoto 15 Feb '05

15 Feb '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on January 24th Monday from 5pm to 7pm (CST). 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: 0124 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 Telecon minutes approval - Andreas will send out before the call. Agenda bashing 2) Feb F2F meeting and GGF13 update (10 min) Hiro will send out revised F2F meeting agenda before the call. Andrew will send out F2F logistics if available. Identify which documents we will publish for GGF13 - Basic Profile 1.0 (first draft) - OGSA roadmap document (final draft?) - Any other? 3) OGSA roadmap document discussion (30 min) At GGF12, we explained our final draft plan for the OGSA roadmap document by the GGF13. Based on our recent progress, should we change the contents of the roadmap document? Profile should be in the roadmap? - roadmap document early draft: https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-roadma… 2 - GGF12 roadmap doc status slide: https://forge.gridforum.org/projects/ogsa-wg/document/GGF12-outreach.ppt/en… - Defining OGSA draft: https://forge.gridforum.org/projects/ogsa-wg/document/defining-ogsa/en/1 4) OGSA v1 doc and its glossary final call (30 min) Andreas and Jem will post the revised 'really final' versions of these documents by Friday 1/21. The documents will be submitted to the GGF Editor one week after that: Friday 1/28. This is your last chance to comment on them before submission. 5) Wrap up (10 min) AOB Jan. 26 (10am-noon CDT) Data design team Jan. 26 (5pm-7pm CDT) Basic profile discussion and basic EM profile discussion Jan. 31 (5pm-7pm CDT) OGSA roadmap discussion Feb. 2 (10am-noon CDT) Data design team Feb. 2 (5pm-7pm CDT) <TBD> ---- Hiro Kishimoto

2 8

node-set serialization
by Hiro Kishimoto 15 Feb '05

15 Feb '05

Takuya's email bounced. ---- Hiro Kishimoto Date: Mon, 14 Feb 2005 16:24:04 -0600 (CST) To: ogsa-wg(a)gridforum.org Subject: node-set serialization From: Takuya Mori <moritaku(a)mwc.biglobe.ne.jp> Folks, Just for your information. The XML-Signature spec. defines its node-set serialization as follows: (it just referes to Canonical XML specification. <http://www.w3.org/TR/2001/REC-xml-c14n-20010315>) ---------------------------- 4.3.3.2 The Reference Processing Model <http://www.w3.org/TR/xmldsig-core/#sec-ReferenceProcessingModel> The data-type of the result of URI dereferencing or subsequent Transforms is either an octet stream or an XPath node-set. The Transforms specified in this document are defined with respect to the input they require. The following is the default signature application behavior: * If the data object is an octet stream and the next transform requires a node-set, the signature application MUST attempt to parse the octets yielding the required node-set via [XML] well-formed processing. * If the data object is a node-set and the next transform requires octets, the signature application MUST attempt to convert the node-set to an octet stream using Canonical XML [XML-C14N]. ---------------------------- Hope it helps, Takuya

1 0

[ogsa-wg | Basic Profile - 1298] resilient EPR usage when endpoint is still reachable
by Sourceforge Tracker Monitor 14 Feb '05

14 Feb '05

A new artifact has been added: 1298 Submitted by: A Djaoui Submitted date: 2005-02-14 22:07:00 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1298&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1298&group_id…) Summary: resilient EPR usage when endpoint is still reachable Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1298 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Last Modified: 2005-02-14 22:07:00 Submitted By: A Djaoui Submit Date: 2005-02-14 22:07:00 Assigned To: &lt;None&gt; File(s): <None> Description: If a resource is moved to another endpoint and the initial endpoint is still reachable, then it is efficient for it to act as the primary resolver. When a client sends a stale EPR,the service should repond with the new EPR rather than re-directing the client to make another unecessary call to a resolver. The above is in addition to either the old endpoint or the new endpoint making a registration in one or more resolvers. The resolver is used when the endpoint is no longuer reachable. 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

[ogsa-wg | Basic Profile - 1243] WS Resource Metadata Descriptor
by Sourceforge Tracker Monitor 14 Feb '05

14 Feb '05

Tom Maguire changed 1243 on 2005-02-14 13:28:06 Status has changed: - New: 'Pending' Old: 'Open' Assigned To has changed: - New: 'Tom Maguire' Old: '&lt;None&gt;' Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1243&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1243&group_id…) Summary: WS Resource Metadata Descriptor Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1243 Category: <None> Group: <None> Status: Pending Priority: 3 Last Modified By: Tom Maguire Last Modified: 2005-02-14 13:28:06 Submitted By: Tom Maguire Submit Date: 2005-01-31 12:01:52 Assigned To: Tom Maguire File(s): <None> Description: Section 5 (referenced spec) Should we be referencing WS-RMD? ---------------------------------------------------------------------- Comment By: Tom Maguire (2005-02-14 13:28:06) Premature spec. Lots of ways of handling this leave and extensibility item. AI: remove references to WSRMD ---------------------------------------------------------------------- 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

[ogsa-wg | Basic Profile - 1294] Agreement on specifications included and versions
by Sourceforge Tracker Monitor 14 Feb '05

14 Feb '05

Tom Maguire changed 1294 on 2005-02-14 13:23:06 Status has changed: - New: 'Pending' Old: 'Open' Assigned To has changed: - New: 'Tom Maguire' Old: '&lt;None&gt;' Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1294&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1294&group_id…) Summary: Agreement on specifications included and versions Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1294 Category: <None> Group: <None> Status: Pending Priority: 1 Last Modified By: Tom Maguire Last Modified: 2005-02-14 13:23:06 Submitted By: Tom Maguire Submit Date: 2005-02-14 11:04:08 Assigned To: Tom Maguire File(s): <None> Description: Need agreement on specifications that are included in the basic profile and versions of the same. ---------------------------------------------------------------------- Comment By: Tom Maguire (2005-02-14 13:23:06) Keep versions at level they are at currently. Create timeline for doc recommendation and sync with WSRF, WSN, WSA. ---------------------------------------------------------------------- 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

[ogsa-wg | Basic Profile - 1249] Resource Property Definitions - Creation Time
by Sourceforge Tracker Monitor 14 Feb '05

14 Feb '05

Michael Behrens changed 1249 on 2005-02-14 12:14:32 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1249&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1249&group_id…) Summary: Resource Property Definitions - Creation Time Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1249 Category: <None> Group: <None> Status: Open Priority: 3 Last Modified By: Michael Behrens Last Modified: 2005-02-14 12:14:32 Submitted By: Tom Maguire Submit Date: 2005-01-31 12:19:54 Assigned To: &lt;None&gt; File(s): <None> Description: Section 5.1. Should the profile contain a resource property for the creation timestamp for the resource? ---------------------------------------------------------------------- Comment By: Michael Behrens (2005-02-14 12:14:32) I believe the profile should contain all the proporities needed for minimal interoperability. So, in general, all proporties needed to manage the life cycle of the resource should be available. Side question: Who defines the namespace? ---------------------------------------------------------------------- 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

[ogsa-wg | Basic Profile - 1249] Resource Property Definitions - Creation Time
by Sourceforge Tracker Monitor 14 Feb '05

14 Feb '05

Tom Maguire changed 1249 on 2005-02-14 11:23:48 Priority has changed: - New: '3' Old: '-' Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1249&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1249&group_id…) Summary: Resource Property Definitions - Creation Time Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1249 Category: <None> Group: <None> Status: Open Priority: 3 Last Modified By: Tom Maguire Last Modified: 2005-02-14 11:23:48 Submitted By: Tom Maguire Submit Date: 2005-01-31 12:19:54 Assigned To: &lt;None&gt; File(s): <None> Description: Section 5.1. Should the profile contain a resource property for the creation timestamp for the resource? 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