WSA Minutes - Tuesday July 29, 2003 - Morning Session -- 29 Jul 2003

Present: Bryan Thompson, Chris Ferris, Daniel Austin, David Booth, Doug Bunting, Eric Newcomer, Frank McCabe, Hao He, Hugo Haas, Katia Sycara, Martin Chapman, Paul Denning, Roger Cutler, Shishir Garg, Tom Carroll, Zulah Eckert

Regrets: Daniel Austin, Steven Lind / Mark Jones (AT&T), Yin-leng Husband

Chair: Mike Champion

Scribe: David Booth, Shishir Garg

Scribe: Date: 29 Jul 2003
... Present today: (MikeC has the list; same as yesterday except EricN is not here today)

John Kemp suggestion for adding Web Service Consumer to glossary

Scribe: General agreement to add it to the glossary saying "See WS Requester".
... Katia voiced concerns that we might get other requests for additions to the glossary, but wouldn't stand in the way.
... ACTION: MikeC to draft response to John Kemp of Liberty project

Explanation of MEP in Arch Document

Scribe: A WSA MEP TF met last night and reported their suggested wording today.
... Consensus: First paragraph accepted. (See text below.)
... Consensus: Use for definition: "A Message Exchanage Pattern (MEP) is a template, devoid of application semantices, that describes a generic pattern for the exchange of messages between agents."
... Consensus: "In order to promote interoperability, it is useful to define common MEPs that are broadly adopted and unambiguously defined. When an MEP is described for the purpose of interoperability, it should be associated with a URI that will identify that MEP."
... ACTION: Bryan to provide revised MEP text to DBooth for inclusion in minutes. -- DONE
... Revised text:
... [[
... Distributed applications in a Web services architecture communicate via
... message exchanges. A Message Exchange Pattern (MEP) is a template,
... devoid of application semantics, that establishes describes a generic a pattern
... for the exchange of (one-way) messages between agents. These message
... exchanges are logically factored into patterns that may compose at different
... levels. These patterns can be described by state machines that indicate define
... the flow of the messages, the including the handling of faults that may arise,
... and the correlation of messsages.
... In order to promote interoperability, it is useful to define common MEPs that
... are broadly adopted and unambiguously identified. When a MEP is
... described for the purpose of interoperability, it should be associated with a
... URI that will identify that MEP.
... <contentious>The exchanges may be synchronous or asynchronous. An
... asynchronous exchange involves some form of rendezvous to associate the
... message and its responses, typically due to separate invocations of the
... underlying transport or to long response time intervals.</contentious>
... At the SOAP messaging level, an MEP refers to an exchange of messages in
... various invoking-response patterns. Each message at this level may travel
... across multiple transports en route to its destination. A message and its
... response(s) are correlated, either implicitly in the underlying protocol (e.g.,
... request-response in HTTP) or by other correlation techniques implemented
... at the binding level. The exchanges may be synchronous or asynchronous.
... An asynchronous exchange involves some form of rendezvous to associate
... the message and its responses, typically due to separate invocations of the
... underlying transport or to long response time intervals.
... <draft>MEPs are abstract and must be mapped to a protocol. Some
... protocols may implicitly support certain MEPs, e.g., HTTP supports request-
... response. In other cases there is a need for additional glue to map MEPs
... onto a protocol.</draft>
... Web service description languages at the level of WSDL view MEPs from
... the perspective of a particular service actor. A simple request-reponse MEP,
... for example, appears as an incoming message which invokes an operation
... and an associated outgoing message with a reply. Extremely simple
... applications based on single message exchanges may be adequately
... characterized at the operation level. More complex applications require
... multiple, related message exchanges.
... <contingent on input from ws-chor>C; choreography describes patterns
... where the units of communication are themselves instances of MEPs and
... adds application semantics (choreography = MEPs + application semantics).
... Especially at this higher level of abstraction, the communicating actors are
... seen as peers which play various roles in more complex applications. These
... choreographic patterns form the communication structure of the
... application.</ contingent on input from ws-chor>
... ]]

Service Oriented Model

Scribe: Issues collected:
... [[
... Discovery
... Service identifier = ?
... SOA Trout - contract?
... Why no "service description language"?
... Rogers proposed text for "action"
... Semantics, actions, task, goals all needed?
... Cardinality, qualifiers?
... "Service Execution Model"
... ]]

What to do with Discovery?

Scribe: Hugo made a suggestion to remove the discovery concept from the SOM section, while leaving the Discovery section in the stakeholders section.
... AGREED: Discovery discussion is deferred to the ROM discussion.

What is a "Service Identifier"?

Scribe: Katia ask what it identifies.
... Can i have two identifiers, one identifying the service, the other identifying the service description?
... Several people answer: yes.
... (Discussion of service types, instances and what the "service identifier" identifies)
... AGREED: Editors need to be clearer about distinguishing between service types and service instances.
... (Discussion about service types, instances and what is identified)
... Task force for clarifying the distinction between service types, instances and what is identified by the service identifier: Paul Denning, Katia, DBooth, Frank
... ACTION: Paul, Katia, DBooth and Frank to recommend clarifications of service types, instances and what is identified by the service identifier

SOA

Scribe: AGREED: Informal action item to all to ensure that the term SOA is used consistently with industry.
... ACTION: Editors to clarify distinction between SOA and SOM
... AGREED: Anyone who wants more on SOA should propose it.

Daniel: Section 1.6.2 needs some rewriting. Too many references that average reader may not know.

Paul: The term "contract" I associate with SOA. We need more words on contracts.

Why no "Service Description Language"?

Roger: We have "Chor desc language" but not "service desc lang" in the concepts.

Scribe: ACTION: Editors to make the concepts more consistent re: We have "Chor desc language" but not "service desc lang" in the concepts.

Roger's proposed text for "action"

Scribe: ACTION: Editors to include Roger's proposed text for "action" or push back on the mailing list

Are Semantics, Actions, Acts, Tasks, Goals all needed?

Scribe: ACTION: Martin to kick off discuss on mailing list re: Are Semantics, Actions, Acts, Tasks, Goals all needed?

Governance Qualifiers

Doug: Regarding the "has-a" relationships, in the SOM section and elsewhere, there are a lot of identifiers that are required (according to these descriptions) and most are optional. These need to be more carefully examined.

Service Execution Model

Zulah: In section 2.3.2.5.2 the term "Service execution model" appears but is not defined.

Scribe: ACTION: Frank to address the fact that in section 2.3.2.5.2 the term "Service execution model" appears but is not defined.
... (Lunch break)

<Frank> History was to do REST on top of SOM. Importance of PUT and GET to get increased interop. Was written before the TAG discussion of resource within the Web architecture. There is the notion of a resource, which has an identifier and there are things you can do to resources eg GET or PUT. Resource owned by a legal entitity.

<Frank> Ontology 101 is about things that exist, and discovery is about things that exist. Also flows underneath the service model.Resource at this level is much more general than a service.

<Katia> We need to have some kind of relationship between the concept of a service and resource,

<Frank> Diagram: Explains what a resource is by linking to a representation.

<Frank> Yes. Confusion in TAG about what a resource is in a Web architecture. Some think resource is a computational that produces a representation. Some think it could be anything. These 2 notions have been confused.

<Frank> Tim Bray is wrong on that as we're here to define systems that represent the real world. Bank example used: Your bank account is a representation of the money in your account.

<Mike> You can have a URI for the printer itself rather than specific software that interfaces the printer with the web.

<DBooth> RFC 2396 defines a URI as anything. RFC 2396 also defines what a resource is. It says clearly that a resource can be anything. TAG's issue is not for URIs in general, but specifically HTTP URIs.

<Zulah> Can't we choose a subset of resources that we restrict ourselves to.

<Frank> The section was there to capture REST. We can take it in a different direction.

<Katia> A resource can be anything that has identity. Not all resources can be network retrievable.

<Roger> This section has only REST related discussion and is disjointed from the rest of the document. There should have been a relationship to all WS in general.

<Hao> Resources are abstract concepts. They need to be associated to the service.

<Frank> This section was meant to model REST. It may be too restrictive. Standard service model related to resources in the architecture, and one relationship is that a service is a resource.

<Hao> Why is POST not there? Draw a graph to identify resources. When you follow the paths, the representational state is modified and this behavior needs to be considered.

<Frank> Because WS represents real things for real people. This is a real requirement for WS architectures.

<DBooth> Remove ROM and merge with SOM. Remove GET and PUT, Representation from it and make a separate REST section.

<Mike> REST is an extremely constrained SOA model with hardwired operations. SOM is REST + Non-REST. For the document, don't mind calling everything a Service (rather than Resource).

<Martin> We should keep the ROM, it's the top level for everything we're trying to do.

<Doug> True, which is a problem with the current text because it describes ROM exclusively in terms of REST restrictions. Text goes even further because it restricts REST to instances that implement all of the actions available in the generic interface.

<Frank> Because ROM has PUT, does not mean PUT needs to be implemented for all resources.

<Frank> Both layer on ROM but in a different way. There may be other kinds of WS that we have not defined yet. They will introduce other new ideas that should be layered on top of ROM and SOM. So, not sure if that union or subset relationship exists.
... Being W3C, and having an existing resource model, why don't we have a standard model for manipulating resources. This will be important for the management model also.

Scribe: ACTION: Frank, Hao, Brian, DBooth to propose an orientation of REST against the other concepts. Refactor REST and ROM, and propose a relationship between the two.

<Brian> Regarding REST, do we consider REST as a set of constraints on the SOM model. OR. to show REST apart from HTTP as a way to achieve a RESTful architecture over HTTP. OR. ?

<DBooth> What is the value considering that very few of these things are specific to WS.

<Chair> This issue is tabled for the WG until another proposal is received from the Task Force.

Scribe: ACTION: all-members to get editors their succint comments.
... Resource VS. Service

<Doug> About us describing generic models: That applies to a lot of topics, and as long as we describe it well enough to tie it back and reference existing locations, that will be good enough. However, we need to talk about these things.

<Hugo> Long discussion on stateful (and related to choreography) produced some text. It is on editors To-do list. Hugo already did harvesting but got no responses.

Scribe: ACTION: Hugo to put harvested stateful discussion text into the document.
... Discussion on Policy Oriented Model (POM):

<Frank> Policy is based on constraints on the behavior of agents. We are only interested in machine readable policies. We are only interested in enforcable and enactable policies.

<Martin> EJBs define a number of policies and the container selects the ones it enforces. Those are the ones we're interested in.

<Frank> Two kinds of policies: permission - right to perform some action or be in some state. obligation - requirement to perform some action or be in some state. There's a link between the two. What we're looking to capture is the notion of policies and how it relates to WS, and how it relates to security, privacy, etc.They could both be two sides of the same contract, but the distinction is useful and necessary. Permissions can be proactively denied, but obligations can not be proactively enforced. This leads to different policy types. Common to use additional concepts like domains. Policies can belong to domains. Policy can be applied to different agents. Relationship to security, privacy, Security has types of threats: like confidentiality - encryption is a policy

Scribe: Issues discussion --Features as concepts - authentication does not have a place in the concepts..

<Roger> Two negative comments:- Wht is a Controlled resource?- Legal entity is important and need to understand what their bounds are

<Paul> XACML, SAML use PDPs and PEPs. Don't see those here. Better to align with them and map to existing terminology.Roles associated with services may be useful in dealing with the Legal Entity issue.

<DBooth> If the minor is operating such systems, it should be with the consent of their guradian
... Legal Entity is used but not in the legal sense. Else use a term such as a "real-world" entity.

<Chris> When you have a policy you can advertise what it is but that does not affect the WS in any way directly.On the other hand, the policy can say that you need to provide a number of things. Descriptions don't describe policies.Policies scope to a domain.Action to target a controlled resource? Guarded resource.Domain not defined well enough to have a position in this?Policies have scope and they are usually within a domain, but another word is needed. Maybe context, scope?

<Katia> Intelligence agencies, DARPA, etc. comprise a large community that use Domain. So we can use Domain. However, it could be vague and therefore the use of the word Domain could imply many things and each entity/agent could be a part of multiple domains.

Scribe: ACTION: Katia, Daniel to harvest from WS-Policy, WS-Security and other real world specifications. Make sure abstract terminology in WSArch maps to those specifications.
... ACTION: to Editors to make sure consistency between concepts in text and diagram.

<Katia> A policy holder can transfer policies. Granting and revoking permissions are commonly accepted behaviors for policies.

<Frank> Presented Conversation, contract, relationships a year ago. Need to have a detailed understanding of the relational level.

<Katia> Suggests to add the text "Permission may be granted, revoked and transferred" to 2.3.4.6.1.

<Brian> Will Choreography talk about bindings without getting into referencing Legal entity?

<Frank> Can't describe the notion of Privacy without mentioning "Legal entities".

<Katia> Depends on the future of this work, if we want to incorporate contracts and business relations as a part of the architecture, the text should keep sight of such directions.

<Chris> None of this text is a part of a contract. There's no legal binding to this and we are getting beyond our scope here.

<Chris> Why are we taking an arbitrarily different phrase as against the TAG?

<DaveO> WS Arch fits very well on top of agents talking to agents, and the web architecture in general. Therefore, the term used seems OK.

<Mike> whether it's a human, child, adult or bot, it doesn't matter to the architecture. It may matter to the users who get misguided etc.

<Brian> Doug mentioned that WS-Arch can be defined without legal entity related text. Can we have a strawpoll to removing the concept of owners of these things and putting it out of scope.

<DaveO> Will it be possible to publish a v1.0 without this and publish this in a future document. We should start thinking of what we won't do in v1.0.

<Frank> We need to meet security related requirements in v1.0. (lie in road for this).

<Chris> Disagrees. We need to put both these things in there with an editor's note. Lay out what the references are to the TAG document, etc. and also add it to the issues list. Get feedback and take it from there.

<RESOLUTION> Publish possible approaches to the document and mark as an issue and solicit feedback into the first document draft.

WSA Minutes - Tuesday July 29, 2003

Attendees

Contents