Web Services Architecture Working Group Call -- 6 Oct 2003

Present: Abbie Barbir, David Booth, David Orchard, Doug Bunting, Frank McCabe, Geoff Arnold, Gerald Edgar, Hao He, Mario Jeckle, Mike Mahan, Paul Denning, Roger Cutler, Shishir Garg, Sinisa Zimek, Yin-leng Husband

Regrets: Dave Hollander, Katia Sycara, Ugo Corda, Zulah Eckert

Chair: MikeC

Scribe: Gerald W Edgar

Approve 2 October telcon minutes

Review of Action Items

<Scribe> ACTION: (See also pending actions listed in the agenda) [PENDING]

<Scribe> High level action items - needed to declare victory
Discovery needed David proposed text Paul Denning proposed ideas.

<David> - posted an updated section1.5.6 overall process for engaging a service. the overall framework where discovery fits in a follow up from the face to face. he took an action item with work with others, martin, zula, Katia for a consensus. It is not committed into CVS yet. there is a proposed replacement. It is not discovery per-se but a larger umbrella.
<Mike C> - how to discover a service
<David B> - Discovery is step one.
<Mike C> - Paul proposed text on discovery

<Paul> - discovery based on thoughts stemming from UDDI, and another view where search engines find WSDL files. Perhaps an "index" semantic web based perhaps? Search engines find things and index them. In our architecture there is no index. Perhaps to tell the index what you want to find. To harvest what is exposed on the web., Use a query language to express what you are interested in.

<Mike> - a Google like index, not a registry. related to an automated reasoning agent not a registry or index, a knowledge base. UDDI is one example of discovery mechanism Goggle is another.

<Paul> - For web services a spider does not apply in that there are no links.

<Mike C> do we really need a network of web services separate from the rest of the web? Links in the general web might link to WSDL documents. These links would lead to other web services.

<Paul> observations from paul about how to discover services.
it is higher level, but there is no distinction between the UDDI or Google approach.

<Mike C> - To use various examples of discovery mechanisms. to query the discovery service and get a description of the service. in the architecture we would not distinguish between uddi, Google or reasoning agent.

<Mike M> - distinguish between manual and machine discovery. for a human, there are different needs. There is also an issue of trust involved, with a human doing the discovery, people make judgments. They trust their own judgments.

<David Booth>. do we need to distinguish between machine and human discovery?

<David B>. the reason to distinguish is that machines can not do all the things that people can do

<Mike M and David B - discussion about trust of mechanized interactions versus trusted human interactions.

<Mike C >- to We need to be aligned with Semantic web.
we do not want to get too far into the details.

<Mike M > - to query a registry and receive results is in scope, to bind to those processes perhaps is not in scope. criticisms as written - it is not given enough emphasis on the autonomous discovery.

<Paul.> notion of Proxy - a discovery proxy. various UDDI servers - an issue of federated servers. an agent that knows how to find the services. This would be needed in this environment.

<scribe> Intermediaries and the soap/WSDL mismatch issue.
<scribe> Hugo is working this. the addressing part of the issue. SOAP does not have the final receiver. there is no description of the intermediaries. He has had no time to get this done. he asked for a back-up.

<Mike C> - he would like to be volunteer for the back-up but he would need some jump starting.

<scribe> Mike C to Mike M - thoughts on intermediaries.
<Mike M> - thoughts on this. proxies or gateways for SOAP / WS messaging. he will revisit the intermediary text.
<Mike C> - to focus on soap intermediaries.
<Mike M> - not to emphasize web intermediaries.
<Mike C> to relate the two kinds of intermediaries [scribe: web services and the web].
<Mike M> components that are restricted devices.
<Mike C> - to give context.

<scribe>Security Model Abbie, Frank, Katia. to work this.
<Frank> - This is still pending.

Reliable Messaging
<Scribe> The larger issue of reliable messaging comes up in all sorts of conversations. Is there anything we can do or is it too political;? beyond the formalisms of a reliable message.

<Mike C> - back 2 years ago - Part of our understood duties were to tell the W3C what needs to be standardized.

<Roger> - we need to define the architectural requirements for reliable messaging.

<Hao> yes, but after f2f he was to work with Frank - but he had not heard anything from frank.

<Mike C> - How wrote useful text with a better understanding what is needed is to harvest minutes form that meeting

<Frank> - we could do something, no problem with how to have a "first go at that" reliability needs to be addressed before we can declare victory service and message reliability needs to be addressed.

<Hao> - basically a guaranteed delivery of a message from one place to another. if we look at TCP/IP - has various aspects of reliability. that is the difference between TCP/IP and Message level reliability. TCP/IP does not address different hops.

<Mike C> - How to draft text. if some transport even handles reliability, the message has to go from ultimate sender to ultimate receiver. we can not rely on the transport layer. In putting this in the larger context of reliability. reliability in transactions, reliability in resource or policy model. we do need to tie in the larger issues of reliability. the other thing is the concept that reliable messaging is not magically getting the message there with complete certainty, but also the state of that message. this was discussed in the face to face.

Policy oriented Model
<Mike> - Hugo - the policy oriented model - is it ready as it stands?

<Hugo> - let's talk by - not just a review of the policy policy how can the policies and requirements fit in our document. from Martin, how to existing specs from the real world fit here? WS-Policy requirements for services. out concept is different, Hugo examined to find how they are related. some changes are suggested.

Who do we want to talk about capabilities and requirements in our documents - the three paragraphs would fit in our document. to support some features and not others. Service and agent requesters. to determine the use of some of the web service features. the description of the descrtiption of the requirements are imporatant

The behavior of agents capabilities and requirements will constrain the behavior of agents. permissions and obligations.
Permissions the allowed actions of agents against a resource. there was a mix or how the current documents is uneven. permission should be renamed capability. hugo said he hopes this is what Frank had in mind. for an obligation - this could be a requirements.

<Frank> - capabilities and requirements are not the same as permissions and obligations. i.e. capability for encryption - a requirement for encryption these are separate.

<Mike C> - If a message exchange pattern is published, don't the parties agree to that pattern?

<Scribe > A discussion about obligations and requirements. for a choreographed pattern

<Frank> - capability - not a permission.
<Hugo> - a sequence of permissions. to remove the portion for choreography.

<Roger> - requirement and obligations - have a similar relation as delegation and proxy.

<Frank> - you are obliged to do something.
<Mike C> - a distinction - cap and reqquirements do not depend on an agreement - nothing is an obligation until the parties agree.
<Frank> - permissions are two sides of a coin. need to capture cap and requirements
<Hugo> - is this belongs in the policy section,
<Frank> - to capture a common threat, to constrain behavior. subject, object target. we need to sharpen the policy if we can do this - it would be useful to capture requirements and obligations.
<Mike C> - how to continue.
<Frank> - suggest to elucidate the capabilities and re and see how that fits into the rest.
<scribe> Frank will take the action to go forward and write it.
<frank> - hugo and frank to write this.
-------------
<Mike C> - workshop on WS - Policy
<Hugo> - related to the topic above. W3C has been thinking about WS-Policy - wrote to WS-Policy specs to participate in a workshop to create a wg on capabilities and requirements. Sent the e-mail yesterday. position papers will be invited, the workshop has not been announced.

<Roger> - WSPolicy - a competing set of standards?
<Mike C> - not to our knowledge.

------------------
Wraping up the Document
Mike C> issue on how to wrap up this document.
two high points. no sentiment for simply extending this group. this raised the issue of the normative form for the document we produce. we could make it a note. It will take more effort to make this a W3C recommendation.

<Frank> - use this as a clarifying moment to get this thing finished. it would be help full to know what plans other W3c groups have for our effort.

<Hugo> - do some architectural work in the spirit of the TAG. As of today we have not decided what the best thing to do next would be. By january we will have a clear view of what to do.

<Frank> - it would be useful to encourage people to state what should be the next steps.

ACTION: MikeC to ping Mike Mahan on the status of the privacy work he did. [DONE]

ACTION: Zulah and Heather to have proposed Management Note draft ready by F2F[PENDING]

ACTION: dbooth to reference current semantics work (DAML-S, OWL-S) in discovery section [PENDING]

ACTION: Katia to email Abbie about pasting Abbie's whole text into the document as a starting point and to force people to comment on it [DONE]

Web Services Architecture Working Group Call
16 Oct 2003

Attendees

Contents

Approve 2 October telcon minutes

Review of Action Items

Web Services Architecture Working Group Call 16 Oct 2003

Attendees

Contents

Approve 2 October telcon minutes

Review of Action Items

Web Services Architecture Working Group Call
16 Oct 2003