Minutes from the face-to-face meeting in Cupertino

[Tim Banks <tim_banks@uk.ibm.com>]

The minutes from the face-to-face meeting held on 26/27th October are
stored on the TC website here:
http://www.oasis-open.org/committees/download.php/9880 and attached to this
note as html.

I think it's worth pointing out that there's one action which has a nearby
deadline:  (Editors) Rework drafts to incorporate resolutions of WSR49
(format of pseudo schema), WSRF 53 (Stop using ‘wsrp’ etc), and WSRF56:
(Specification drafts refer to non-public urls.) by 11th Nov.  Sorry about
that, but it's what we agreed.

(See attached file: WSRF TC [26Oct04] notes[1].htm)

Regards, Tim Banks

Title: WSRF TC notes

Notes from the OASIS WSRF TC Face-to-Face on
26^th & 27^th October 2004

 

Roll call

 

The roll call is kept on the TC web site under the meeting record.

See http://www.oasis-open.org/apps/org/workgroup/wsrf/event.php?event_id=5688

Approval of minutes from previous telecon (18^th October)

 

See: http://www.oasis-open.org/committees/download.php/9879

 

(IanR) Details of actions on issue 4 and 25 need to be added.

There were other comments.

Proposed (Ian) seconded (Dave) to approve the minutes

No Objections.

Other Action Review

(Glen) Propose wording to resolve issue 20 (Notification message format) to mailing list. (Carried fwd from 23^rd August) Action: Drop from action list, but keep on the issue list.

(All/DavidL) Review requirements Doc: (4^th October). David appealed for use cases to support the requirements. Done

(Chairs) Add to the face-to-face agenda a discussion of:  Issue 1: portType aggregation and associated issue 71: Rules for Property composition. See below.

(Bryan):  Move issues 4 and 27 to ‘resolved’. Done

(Igor): Open SetResourcePropertiesDocument issue. Done

(Ian): Write a proposal for issue WSRF 25: More informative fault messages. (Carry fwd)

(Bryan):  Move issue 26 to ‘closed’ Done

(Text editors): Decide which proposal is best to resolve issue WSRF49 (Pseudo-schema language in the specs) and apply it consistently. See below.

WS Resource Spec – Steve Graham

 

See presentation at: http://www.oasis-open.org/committees/download.php/9878

 

 

(SteveG   agenda:

è      Purpose

è      Results

è      Points for further clarification

è      Implication for other specs

è      Dicusssion.

 

Purpose:

è      Clarify “implied Resource pattern”

è      Separate concept from embodiment

è      Publish a Normative specification

·        Define terms and embodiments.

 

 

Result: some definitions

è      Resource

è      Resource Identifier

è      WS-Resource

è      WS-resource Reference

 

SteveG)

(MartinC) Why do we say that the identifier is used by the WS Resource?

(IanR) It’s because this is less prescriptive about where the disambiguation happens.

(Umit) A WS Resource is implicitly a reference to the resource behind, isn’t it?

(SteveG) Well, the WS-Resource Reference is the reference – and we should be careful about the words.

(TomR) If a box has two interfaces, is the resource the box or the interfaces?

(SteveG) Like blades, for example. The resource is the blade.

(TomR) and the resource does not need to know its own identifier?

(SteveG) No.

(Fred) About equality: if references are equal, they might still be resolved dynamically into different Web service addresses by different networks.

(SteveG) Yes, the address needs to be considered in its context.

(MartinC) If we have a resource which is the blob of state, and different WSDLs…

(SteveG) The intent of this spec is not to describe types.

(DaveS) Even if I have no resource Propoerties, I must support the access mechanism?(even if I only want to use WS-transfer)

(SteveG) Yes.

(DaveS) So we are distinguishing this from normal Wsb services.

(TimB) The ‘properties’ language is not a complete generic description of stateful services, it’s possible that useful stateful services will be created that don’t or can’t use ‘propoerties’.

(SteveG) But what would it mean to destroy the resource? There would be no

(Sam)  If we use WS-Resource Lifetime, does that require WS-RP?

(DavsS) This is an interesting issue for WS-RL.

(SteveG

Results - Embodiments

Points for clarification.

è      Resource must/may have properties
(TimB) ‘Must’ restricts the scope of application. Our charter says deal with generic stateful resources.
Proposed to keep as ‘must’. Only one objection.

è      WS-Resource

·        Describe in terms of “WS-endpoint”

·        Must/should on properties and lifetime

è      WS-Adressing embodiment

·        Collapse 3.1 and 3.2 in a single embodiment

è      WSDL embodiment

·        Clarify 3.4

 

SteveG)

(IanR) BPEL want to do their own thing with terminating resource lifetimes.

(DaveS) We need to treat the ‘must/should’ on Lifetime as an issue.

Action: (see below) Raise must/should as an issue.

(SteveG) Embodiment 3.4 needs further clarification.

 

(SteveG

The  Implications for other specs are:

è      Remove Normative refs to state paper

è      Prune definitions sections to remove “implied resource pattern” “WS-Resource” etc.

è      Search and replace “implied resource pattern” with “WS-Resource Access Pattern”

è      Appropriate normative attribution to the WS-Resource spec for first uses of the terms:

·        WS-Resource, Resource, Resource Identifier, WS-Resource Reference, WS-ResourceAccess Pattern

è      Further work on app notes

 

 

WSRF Primer  - Tim Banks

 

See presentation at: http://www.oasis-open.org/committees/download.php/9848

 

The Printer use case based on IPP is a good scenario for the Primer.

(Igor) It would be good also to illustrate business application a use cases to widen the scope beyond device management.

(TimB) There is more to the use case than device management, but yes. Wider scope is better.

Action: (Igor) Construct a ‘Purchase Order’ example.

(TimB) We also need FAQs for the TC Web site.

Action: (TimB) Propose FAQs.

No objections

Metadata for WS-Resources – Tom Maguire

 

See presentation at: http://www.oasis-open.org/committees/download.php/9822

Proposal document: http://www.oasis-open.org/committees/download.php/9758

 

(TomM

Motivation:

è      Support a broad and evolving range of WS-Resource types

·        Discover descriptions of resources

·        Interfaces

·        Additional Descriptors

è      The broader the range of WS-Resources, the more descriptive info is required.

 

What is it:

è      A Mechanism for additional interface and implementation description

 

TomM)

(Igor) It would be useful to apply Metadata to a property description independently of its use in an interface, so that multiple interfaces and benefit from it.

(TomM) Yes, we should revisit this when we have talked about derivation of portTypes.

(WilliamV) There are more metadata description tht are needed – for example describing that a property value sis only available when the resource is in a particular state.

(TomM) The metadata describes additional contractual information.

(DaveS) But the WS-resource behaves in exactly the same way whether or not the document has been read

(DaveS) Shouldn’t xml schema have done all this stuff?

(SteveG) Yes, but we would need to wait a long time to get into schema.

(DaveS) Does everyone still agree that this ‘separate document’ approach is the right one?

(TimB) Have we considered how tools cope with two documents?

(TomM) It makes no difference, and there are other considerations (authorship, cardinality) that are important.

(MartinC) This is all optional stuff, yes?

(TomM) Yes, but we’ll point to it from the RP document.

 

Tom will continue as editor to move towards a specification. Others are invited to co-edit.

(See below for formalization of this)

WS-RP on Blackberry Demo – Steve Graham

 

 

(WilliamV) How much memory is required?

(SteveG) WSRF takes 19K, Soap takes 40K on top of the built-in JVM

 

Issue Resolution

 

(MartinC) What is the status if the WS Resource document?

(IanR) It’s an editors’ draft. We need to make it consistent, make it a working draft and post it with the other four specs.

(MartinC) Can we start work on the working draft today? What shall we do with the ‘WS-Resource’ issues raised this morning?

Proposed (IanR) Seconded(MartinC) That the WS Resource document be adopted.

There were no objections.

The three issues will be put on the issues list (see below).

The order of business is editorial issues, WS-Resource and then WSRP.

 

WSRF 49: Format of Pseudo schema

Proposed:  to use the text from the new WS-Resource document

No Objections.

Action: (Editors) Rework drafts by 11^th Nov

 

WSRF 53 Stop using ‘wsrp’ etc.

Use WSRF-RP instead and make all other namespace prefixes consistent.

Proposed to resolve to do this.  No objections.

Action: (Editors) Rework drafts by 11^th Nov

 

 

WSRF56: Specification drafts refer to some non-public urls.

We need to replace the urls with publicly – accessible ones.

Proposed to resolve to do this.  No objections

Action: (Editors) Rework drafts by 11^th Nov

 

 

WSRF 7: WS-Addressing is not a standard

(IanR) We should drop this issue since we have factored it out in the WS Resource spec.

No Objections.

Action: (Bryan) Close the issue

WSRF13: Should WS-Addressing elements ‘service’ and ‘port’ be required for WS-RF?

 

(IanR) We should say service name and PortType SHOULD (not MUST) be used, because it might not be necessary for some clients.

(WilliamV) It’s ok not to use the type information if it’s not needed, but if it’s an error of omission, that’s bad.

A straw poll (who thinks it is important to have an architectural statement that discovering type information should be possible.) revealed most people were not desperate for an architectural statement.

Action: (Bryan) Close with no change

 

We need a new issue:

Examine use of ERPs in service group – in the operational signatures for add - and base faults specs

 

WSRF43: Consider moving to the WS-Addressing namespace used in the W3C submission

 

Proposed to do as the title suggests. No objections

Action: (Bryan) Move to resolved.

 

WSRF30: Not clear what the SOAPAction (and wsa:Action) field should be set to

(Sam) .net dispatches based on the Soap;Action. Is this for the operation in the most derived portType or the extended portType.

 

Proposed: (Steve) Seconded (Ian) that in each message exchange defined within any WSRF specification, there must be a Soap:action URI defined. Any message which implements the exchange must specify the URI. 

 

For WS Addressing, (therefore specified in the embodiments document) if a wsa:action appears, it must match the Soap:action URI, even if the Soap:action is not specified in the message.

 

No Objections

Action: (Editors) Update specs accordingly. (SteveG) Update embodiments section. (Bryan) move to ‘resolved.’

 

 

WSRF40: Is an EPR the right construct to use to reference a WS-Resource?

 

This can be closed based on the new WS-Resource document.

Proposed to close with No Action. No Objections.

 

 

WSRF41: Is there a way to separate addressing a WS-Resource from the rest of the WSRF specification?

This can be closed based on the new WS-Resource document

Proposed to close with No Action.

No Objections

WSRF46: Finding WSDL given an EPR

 

(WilliamV) This is a refinement of WSRF13, and can be closed with no action.

No Objections.

 

WSRF47: EPR Discovery

 

This was a placeholder, but can be closed.

 

New Issue (PS: WSRF74): Web service vs Web service Endpoint

 

(Fred) Web service is an informal term, it can mean something that responds to messages, or a collection of these things, or a ‘type’.  When we refer to a WS resource, is it a combination of an Endpoint and a resource, or a type and a resource.

(DaveS) We can be more precise by saying ‘embodiment’, which eliminates the ‘type’ idea.  We can’t be any precise than that because multiple endpoints might be the same WS Resource (and resource) or different ones, depending on the implementation.

(MartinC) The use of ‘endpoint’ isn’t meaningful in the context of a WSDM addressing scheme.

Action: (Bryan) Close without change.

 

Meeting recessed 18:30 pdt and resumed 9:00am 27^th October.

Requirements Document - Dave Levine

 

Comments on the document:

è      RQT8, 10 overlap: Properties exposed vs gettable
(DaveL) Exposed means there is some visibility, such as a notification, but not necessarily get.

è      RQT3,13 Need for scalability of notification
(DaveL) Most of this is WS-N business.
(SteveG) ) I think there are two use cases. We need a bare bones solution for WS-RF and leave the rest to WS-N
(MatinC) We shouldn’t say anything in WS-RF; we should depend on composability with WS-N.

è      RQT27 Design time description of what to expect from xsd:any. Good use case would help.
(DaveL) We need use cases to clarify the requirement: how type information is discovered, and why

Anti Requirements

è      No security

è      No transactional behaviour

è      Any more?

(DaveL) Comments?

(MartinC) We need requirements and use cases for ServiceGroups.

 

AppNotes document – Alan Weissberger

(AlanW) The project will be transferred to Katy Warr after this session - we need feedback on the new outline, and volunteers for the sections.

 

This will build on the Primer and be a user’s guide rather than an introduction.

 

Introduction:

è      Interdependency of specs with each other. WS-RP, WS-L etc

è      Exploiters, WSRP etc.

è      Terminology

(SteveG) We need to comment on which applications are suitable for exploitation of WSRF.

(IanR) So where is the distinction between the AppNotes and the Primer?

(Glen) In WSDL, we have one document. Here is what it’s all about, and here’s a use case, and here are the advanced topics.

(SteveG) We should make the Primer a prerequisite to the AppNotes

 

Motivation:

è      WS Applications

è      Use Cases for the WS-RF specs, Potential applications for WS-RF specs

 

(AlanW) Yes. Then we need to take material from the state papers – volunteers?

(IanR) Yes.

 

Issue Clarification

è      Behaviour of nillable

è      Etc.

(AlanW) Comments?

(MartinC) What’s interesting are the architectural choices made be existing applications of WSRF – eg WSDM.

 

Interop Scenario

(IanR) Do we need an interop scenario/event to test the specs

(Glen) A scenario is useful even though we don’t have

(IanR) We need:

è      Scenarios

è      Published endpoints to test

è      An Event

(DaveS) We should scope ourselves to properties and lifetime. We don’t have faults ready yet.

 

(We need a scenario)

(GlenD) We need something that corresponds with the Primer.

(WilliamV) Actually this printing thing is a little sensitive for HP. I need to check it out with my printer people.

(IanR) What about the scenario description? – If Tim and William can produce the Printer scenarios it in 2 weeks time, we can then start a subgroup to work on the Interop scenario. Subgroup volunteers send Emails to Ian, please.

 

(IanR) For the schedule, we should aim to get endpoints available by January, and then think about an interop fest.

Action: (Tim/William) Document printer scenarios for Primer/Interop

 

Renewable References – Ian Robinson

 

See presentation here: http://www.oasis-open.org/committees/download.php/9849

 

(IanR) It is part of our charter to produce a means to cope with references becoming stale – eg because an endpoint fails. We need to be able to renew the reference to regain access to the WS resource.

Using WS Addressing as an embodiment example, we can identify a resolver service in the EPR, and trhe resolver can supply a client with a new reference. This TC is chartered to specify the resolver interaction.

(MartinC) I don’t think WSRF TC should be doing this. It is something that would be done by the implementation under the covers.

(GlenD) This feels close to an addressing issue, perhaps it should be part of the W3C WS Addressing group.

(IanR) Yes, but that may be a long way off: that group does not have this in their charter.

(SteveG) We could consider this a domain-specific policy to solve a quality of service issue concerned with resources.

(MartinC) This is not specific to WSRF. How is interop affected?

(GlenD) If the means to refresh is vendor-specific, the client will be unable to reestablish contact.

(DaveS) This is derived from an OGSI requirement for long-lived handles.

(MartinC) It sounds like naming. There are lots of ways to do this, why standardize one?

(IanR) This is the proposal, if it doesn’t work, we should refine it.

(DaveS) What about the other embodiments?

(MartinC) This should be standardized above the embodiment level.

(IanR) But the solution depends on the embodiment.

(SteveG) But the container approach for addressing is not really the right one.

(Fred) We need to expand this to include selection of quality of service.  Also, the renewal seems to be owned by the creator of an EPR, why do we have a separate renewal service?

(IanR) It’s because creation is domain-specific, but renewal is not.

(GlenD) There are other ways to do this (such as a heartbeat to provide renewal).

(IanR) Yes, but we need to decide on one.

(GlenD) I think I agree with Martin, we shouldn’t do it.

(IanR) In that case we wouldn’t have replaced OGSI.

(DaveS) This is a critical path for the grid space. It should be done above the embodiment layer, because switching the addressing embodiment might be a useful function – something that OGSI could do. I need to consult with Grid people about it.

Action: (IanR) Put the specification on the TC web site.

(MartinC) We need to understand the requirements.

Action: (DaveS) I will coordinate the requirements.

 

Issue Review

 

New Issue (PS. WSRF75): WS-Resources to use WS-RL be relaxed to a SHOULD

(William) There may be other kinds of destruction semantics than the one defined by WS-RL.

(Fred) What does ‘lifetime’ mean?

(IanR) It means having the properties about ‘scheduled termination time’ in the properties document.

(MartinC)  But all resources have a lifetime, though it might not be exposed like this.

(MartinC) We could say that ‘A WS Resource may support WS-RL’; (and whatever happens in that spec is separate.)

(IanR) Seconded. This replaces the text in bullet 3 of section 2.3.

No objections.

Action: (Bryan) move to ‘resolved’.

 

New Issue (PS. WSRF76): Clarification of WS-A Embodiment styles

(TomR) For the purposes of referencing the style of addressing that’s used, can we separate the style of explicit reference parameters vs including it with the address? We need two sections each representing one of the styles.

(SteveG) But these two things are the same – the client does nothing different in the two cases.

(Fred) Can we can put a sentence in to textually identify the style, so that users of a service can know which is being used.

(DaveS) This does make a difference, because a window on the client pops up when the reference properties are used.

Action: (SteveG) Make up sentences to describe the embodiment styles.

 

New Issue (PS. WSRF77): Clarification of WSDL 1.1 embodiment styles

 

(SteveG) We need to improve the description because it’s hard to understand.  Could the reference property be in a security context based on a policy statement? Could it be something the client understands and manipulates into a header. How can a client know what to do?

(GlenD)  The second paragraph is complex, but the client has Web service infrastructure that can follow the WSDL and policy description to construct the message.

(SteveG) But the embodiment says the service can do anything it likes. How can we distinguish regular WSDL from WSDL that satisfies WSRF?

(GlenD) Well, either this is a bad embodiment (too generic), or the embodiment idea is poorly defined. However, this embodiment works. It is a WSDL contextual reference.

(SteveG) Does the text describe this?

(GlenD) We should really only have one WSDL embodiment, which describes that reference data can be included in a message, but not in the body.

(SteveG) The first embodiment is more specific.

(GlenD) Right, so we can include it within the second.

(IanR) The DAIS group is interested in accessing Data-oriented resources where the client knows the identifier of the WS-Resource, and just needs a hint from the WSDL about where in the header to put it.  Is this embodiment described well enough?

(SueM) Yes, this embodiment gets around the ‘opaqueness’ issue, and we could look at it.

(GlenD) I would like to see some simpler text which says we just use WSDL.

(TimB) What mechanism will the DAIS group use to manage the resource identifier?

(SueM) It will be some database-access client software.

Action: (SueM) Work with Igor to decide whether this embodiment can satisfy DAIS usage.

Action: (GlenD) Propose text to improve the description.

 

WSR9: API to list all properties.

 

(IanR) At the July 2004 face-to-face the following proposals were made.

Proposed a) A new resource property – allowedRPQNames, ie those which will not throw ‘unknown resource’ fault.

This properties will return the relevant RP QNames and the schemalocation.

(No objections)

Proposed b) A new resource property – presentRPQNnames, which indicates a property of the relevant name in the instance document.

This property will return the relevant RP QNames and the schemalocation.

(No Objections)

Proposed c) A capability - GetRPDecl (QName) -  to return the current RP document declaration ( minoccurs/maxoccurs/nillable etc) for each QName requested.

(No Objections)

 

(SteveG) We don’t need (b) since we have the getRPDocument resolution.  And, we need support of this optional.

(Igor) This should be separate operations, not Resource Properties so that Resource Propoerties doesn’t exploit its own facilities.

(SteveG) Yes, but the property change notification announcing new properties is useful.

(Igor) We don’t need (c) because WS-MEX can do this.

(Fred) The definition of which values might be allowed is more dynamic than metadata can describe.

(William) We don’t need (a) because it can be metadata can do this, and a notification can be created without hanging it on a property. We don’t need (b), and (c) is also metadata.

(IanR) But dynamic properties (that are created after the schema is written) aren’t described in metadata.

(SteveG) I propose we defer this issue. It’s complicated, and we don’t have a really good reason to do it.

(TimB) Seconded.

No objections.

Action: (Bryan) Create a new list of ‘Deferred’ issues.

 

Follow-On Planning

 

We need to set a date for the next rev of specs and get committee drafts of WS-Resource, WS-RP and WS-RL by the next face-to-face.

(DaveS) We also need base-faults.

Action: Chairs

 

Face-to-face in January: this is proposed to be at IBM in Raleigh on Tuesday/Wednesday 2^nd/3^rd February.

 

Action: (Chairs) to coordinate with WS-N and WSDM groups and set the date.

 

WSRF 1: Interface Aggregation

 

(MartinC) Why is this important?

(WilliamV) It’s because we need to know what semantics are associated with a message, and these come from the portType.

(Igor) If we have the portType information only, we still don’t known which portType provided a particular operation.

() We have the operation collision problem.

(Igor) In WSDM, there are URI’s in properties which can provide the derived information, so we don’t need the ‘derivedFrom’ attribute.

(William) Actually, we shouldn’t be talking about aggregation because it’s not any different in WSRF than it is in WSDL.

(Fred) We could simply use a Service with multiple ports (and portTypes) to aggregate function.

(SteveG) WS-I BP says nothing about the port children of a Service – this isn’t an interoperable solution. Also, what do we do with the aggregation of Properties?

(William) The real issue is the incompleteness of the portType aggregation process. We should deal with that part of the RP spec.

(SteveG) That is a separate issue, we should close issue 1 with no action

Proposed (MartinC), seconded (Igor)

No Objections.

Action: (Bryan) Close the issue.

 

Issue WSRF71: Need normative rules for property composition

(Igor) The issue can be closed with advice in the AppNote that the designer of a portType is responsible for making a sensible choice about the aggregation of two properties which have the same name.

(SteveG) Seconded.

No objections.

 

Action: Move to resolved

 

Metadata proposal

 

(IanR) Proposed: that the Metadata document be formally adopted into the TC.

No Objections.

(IanR) We need volunteers to work on editing the Metadata spec:

Volunteers are: TomM, DaveS, SamM, SteveG, BryanM

 

Meeting closed 17:30 pdt.

Summary of actions

 

(Ian) Write a proposal for issue WSRF 25: More informative fault messages. (Carried fwd from 18^th Oct.)

(Igor) Construct a ‘Purchase Order’ example/use case for the Primer.

(Editors) Rework drafts to incorporate resolutions of WSR49 (format of pseudo schema), WSRF 53 (Stop using ‘wsrp’ etc), and WSRF56: (Specification drafts refer to non-public urls.).  By 11^th Nov

(Bryan) Move issues 7, 13 to ‘closed’ (No action.) Move 30 to ‘resolved’.

(?) Raise new issue: Examine use of ERPs in service group – in the operational signatures for add - and base faults specs – now issue 73.

(Editors) Update specs according to resolution to WSRF 30: Define ‘Soap:action’ url and update embodiments description.

(Bryan) Move issues 40, 41, 46 & 47 to ‘closed’. (No action)

(Tim/William) Document printer scenarios for Primer/Interop

(IanR) Put the RenewableReferences specification on the TC web site.

(DaveS) Collect requirements for renewable references, including from Grid community.

(Bryan) Move New issue 75: use of WS-RL is MAY not MUST to ‘resolved’.

(SteveG) Make up sentences to describe the embodiment styles for Issue 76.

(SueM) Decide whether the WSDL embodiment can satisfy DAIS usage.

(GlenD) Propose text to improve the description of the WSDL embodiment. (Issue 77)

(Bryan) Create a new list of ‘Deferred’ issues and move WSRF9 (API to list properties) onto it.

(Chairs) Confirm if the venue/date for next face-to-face is really IBM in Raleigh NC, on Tuesday/Wednesday 2^nd/3^rd February.  (PS The WS-N meeting advised this should be noon Wednesday 3^rd until noon Friday 5^th Feb).

(Chairs) Decide schedule for next rev of specs

(Bryan) Close WSRF1. No action.  Move WSRF71 to ‘resolved’.