WS Architecture WG F2F
13 Nov 2002

See also: IRC log

Attendees

Contents

• Agenda Items
  1. Meeting Startup
  2. XMLP Resolutions
  3. Representations and resources
  4. Upcoming Agenda
  5. Review of table of contents
  6. Review of section 1 "Introduction" of arch document.
  7. David Booth's Proposed Conventions for Diagrams
  8. Review of section 3.1
  9. Management Task Force
• Summary of Action Items

Meeting Startup

<dbooth> Scribes: Unknown (morning), Mike Mahan (afternoon)

<DaveH> WSA goals for the next 10 days: http://lists.w3.org/Archives/Member/w3c-ws-arch/2002Nov/0009.html
... CALL TO ORDER!
... ACTION: doug to publish mintes from 11/7 asap

XMLP Resolutions

ColleenE: We should be specific in our response

<hugo> Issue is: http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x390

DougB: Forward "XMLP Response to comment 1" and change the the I to We

DaveH: next "Clarifications about how resources on the web are added"

DaveO: need both original URI and the representation is another URI
... treated like it is a cache

DOugB: Proposes Describing the use case and letting XMLP discuss

DaveO: Proposes acknolging the 3 bullet points and say there isn't enough deatail and offer additional detail for XMLP to consider

Resolution: Table pending further work from DaveO, ChrisF and anyone else to bring back specific wording before the end of the meeting

Representations and resources

DaveH: Issue: That our arch doc needs to deal with the issues between Representations and resources.

<DaveH> Add to this the propeor understanding of attachments and other temporal data entities.
... ISSUE: define resource/representation and attachments
... bummer...zakim did not see this

DaveO: When is something a representation and when is something a resource?

<HaoHe> a resource is a concept
... a resouce can have many representations

<dougb> Hao, discussion here is focusing (mostly) on transitory resources or representations. We're also wondering how / whether to ask TAG about general issue (POST request for example).

<DaveH> Chais encourage positioning papers on the resource/prespesentation distinction and how the toppic can be presented in the arch doc

<HaoHe> that sounds interesting, we have quite a few examples in Thomson.

Upcoming Agenda

MikeC: Is there anything missung from the agenda?

DaveH: encourges every one to look at the agenda and if your favorite topic is not there, please bring it forward. Also review the topics in the agenda and create possible wording for each Topic.

Scribe: The WSAWG would like to thank the Admin team for their spam reduction efforts.
... --- BREAK ---

<DaveH> http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch.html

MikeC: Proposal we want to make sure the first part of the arch document is well thought out and useful, so I like to open the floor for word smithing.

DavidB: Would like to get some feed back on some updated diagrams that he and ChrisF worked on.

Review of table of contents

DaveH: any concerns?

<HaoHe> I want my "messaging without SOAP"

Scribe: Remove "Web services reference" from the abstract part of the arch document in sentence 2.
... We are reviewing the state of the abstract statement in the arch document
... http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch.html
... Action: Issue: the second sentence of the abstract requires additional consideration by the WG.

<geoff_a> How about "identifies components, describes properties and constraints of these components, and defines the relationships between them"

Scribe: ACTION: to the chairs add toa future agenda the second sentence of the abstract requires additional consideration by the WG
... We are discussing the name of section 4 of the arch doc
... Is Section 3 of the arch. doc. the primer?

DaveO: what is the intent of section 4?

ColleenE: Section is suffering from multiple author syndrom.

MarkJ: Could be called the "principle of web services architecture"?

DougB: suggests that section 4 is the architecture document the rest is primer

DaveH: there are 2 purposes served by the arch document the web services architecture and the relationship the the web architecture.

MikeC: What is the purpose to section 3 and what is the purpose of section 4 are the questions at hand.

markJ: doesn't see section 3 as the primer.

daveO: retracts the term primer as it is not the correct term.

<dbooth> I suggest we call section 3 "Architectural Overview" a

daveH: our goal is to word smith the document for the AC so it can stand we are not trying to restructure.

Resolution: DavidB proposal accepted.

<dougb> I mentioned a suggestion for future editorial work: Placing the bulk of what's now in section 3 after section 4, describing the components and relationships emerging from the principles and constraints in section 4. DaveH's comment was to clarify my proposal as not appropriate for the current effort. Friendlly amendment accepted.

<geoff_a> Anyone got the URL for the latest Web Architecture draft?

Proposal: add purpose statement to all sections specifically section 4

Scribe: Editor will at his discression add purpose statement and post proposed text to the group

Review of section 1 "Introduction" of arch document.

<HaoHe> http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch.html

Scribe: Option 1 to kill the whole first sentence of the first paragraph.

<HaoHe> Can we go through the doc section by section?

Scribe: option 2 is to delete "is expanding rapidly"

<jeffm> I think this is the url for the latest version of the arch doc DavidO referred to:
... http://www.w3.org/TR/2002/WD-webarch-20020830/
... Please correct if necessary

<dougb> Jeff, newer version (not yet published externally) is much better - http://www.w3.org/2001/tag/2002/WD-webarch-20021107

Resolution: First sentence will be deleted

Scribe: Section 1 second ParaGraph
... DaveH : when are we going to tackle the reference architecture meaning.

DaveH: this document is definitive and describes

Scribe: ACTION: Chairs schedule the discussion on the reference architecture definition

<dbooth> I suggest that we use the term "architecture" instead of "reference architecture" throughout, unless and until we agree on the need for the additional term "reference architecture".

<Heather> Rathole 1: what is a reference architecture

Resolution: We will leave it Section 1 paragrah will be left alone until the reference architecture rathole is completed.

<Heather> Rathole 2: what abstraction away from the implementation do we want this arch to exist: abstract, general, concrete

DaveH: We can't talk about reference architecture until we have a architectual taxonomy.

<DaveH> rathole 2 refinement: what taxonomy of architecture

Scribe: Moving on
... Section 1 Paragraph 3
... Fine

<dougb> resolved: don't bother "fixing" existing mentions of reference architecture (in para 2) until we've had the rat hole discussions.

Scribe: Section 1.1

<dbooth> Someone got the document URL again please?

DougB: For more information on the need of the architeture reference the charter

<hugo> the charter says: "Several proposals have been published by different organizations to address different parts of the required task. The goal of the Web Services Architecture Working Group is to lay out a coherent architecture, by producing architectural documents and advising W3C regarding work in the Web services area."
... we may want to add something stressing interoperability

Scribe: ---- LUNCH BREAK ----

David Booth's Proposed Conventions for Diagrams

<dbooth> My proposed conventions being discussed: http://www.w3.org/2002/ws/arch/2/10/diagram_conventions_clean.htm
... Option 1: Allow the word "component", but never use it to mean "artifact".
... Option 2: Never use the word "component" at all.
... Option 3: Provide multiple definitions of "component" that are context sensitive.
... Option 2a: Use the word "agent" instead of "component".
... Option 3a: Use "component" sparingly, and try to be very clear about what it is supposed to mean.

<Heather> rathole 3: are events covered by actor or artifact or action?

<dougb> ACTION: editors to update diagrams with reinforcements for their biases from David Booth's (new, updated) suggestions document

<dbooth> http://lists.w3.org/Archives/Public/www-ws-arch/2002Oct/0379.html
... DaveH: A role is a set of responsibilities taken on by an actor.
... Proposed definition of role: An abstraction of an actor that has responsibilities or can perform actions.

<dougb> excellent suggestion from Chris: Role is an abstration. (period, dot, exclamation mark)

<dbooth> Proposed def 3 of role: An abstraction of something that has responsitilibies and that is instantiated by an actor.

<chrisf> Role: an abstraction of a (set of) responsibility that is assumed by an actor/agent
... Role: an abstraction of a set of responsibilities that is intended to be fulfilled by an agent

<dbooth> Chrisf, can you put a noun in it? Responsibilities are just verbs.

<dougb> From http://www.m-w.com/cgi-bin/dictionary: responsibility Function: noun
... Inflected Form(s): plural -ties
... From Date: 1786
... 1 : the quality or state of being responsible : as a : moral, legal, or mental accountability b : RELIABILITY, TRUSTWORTHINESS
... 2 : something for which one is responsible : BURDEN

<dbooth> Proposed def 4 of role: An abstraction of an entity that has responsibilities.
... Proposed def 5 of role: An abstract entity that has reponsibilities.

Review of section 3.1

Scribe: 4th paragraph of section 3.1

<geoff_a> 7/msg dougb If a Web Service does not require SOAP, WSDL, or XML messages, is there an unambiguous term for a web service constructed in terms of the HTTP/WSDL/SOAP/XML stack?

<MartinC> a ws-i basic profile web service!

<soliton> What about a Web Services that does not require SOAP, and WSDL?

<dbooth> [[
... "The Service Requester obtains the service description either locally, directly from the Service Provider (if it is already known to the Service Requester), or it uses a find operation to retrieve the service description from a discovery agency (i.e. a registry or respository). The Service Requester then uses the service description to bind with the Service Provider and invoke or interact with the Web Service implementation."
... ]]

<hugo> soliton, this has been recorded as an issue: the definition and its scope

<Hao> hugo, what is the current topic? Is igor giving talk now?

Scribe: currently wordsmithing the arch doc

<dougb> we're on 4th paragraph of section 3.1 (2nd after the bullets)
... who is doing the real time editing?

<DaveH> time for heather

Scribe: finishing up with wordsmithing up to 3.2

<dougb> for the rat hole (I hope not) trailer park: We should probably define "Header: generic term for in-band metadata." in our Glossary to avoid historical "header / summary / items / trailer" orderings and distinctions.

<DaveO> Doug, I tend to agree. We need to differentiate between http headers and soap headers.
... DaveO wrote down the following actions for the editors 1. Write material to explain purpose of each chapter.
... 2. Take text from Charter into ws-arch for rationale for why an architecture group
... 3. Replace component with agent
... 4. Change diagrams to show revised iconography.
... 5. Glossary reference to web arch for software agent.
... 6. Fix initial two diagrams into 1.

Management Task Force

heather: if you are to have a managable web service, the STD models the service execution env
... difficult to define the management aspects without having core state concepts

jeffM: can't we adopt dmtf or other management forums

heather: we need an abstraction above ejb or other service incarnation

<DaveH> Is there a management use case that I have overlooked?

geoff: this seems like a classic case of blessing the dmtf model and moving on - since this is a subset of their definitions

<Heather> The MTF owes a management use case
... will cover in next presentation

ericn: existing management models don't map to WS

geoff: dmtf has created CIM definitions which should apply

martin: we should pick an existing model

<dbooth> The three MTF documents are also available at:
... http://www.w3.org/2002/ws/arch/2/11/WSA.ManagementInto.2.htm
... http://www.w3.org/2002/ws/arch/2/11/W3C.MTF.ServiceLifecycle.20021111.htm
... http://www.w3.org/2002/ws/arch/2/11/W3C.MTF.ConceptsForWSA.20021111.htm

igor: we did look at that, existing models aren't sufficient

<dougb> ?? in what respect(s) are existing service / container models insufficient?

heather: wants inclusion of service lifecycle into WS arch doc

martin: lifecycle is fundamental to the basic architecture

<dougb> for those on call, current presentation is the images contained in the http://www.w3.org/2002/ws/arch/2/11/W3C.MTF.ServiceLifecycle.20021111.htm document

daveo: tcp is fundamental but we don't talk about it

daveh: what happens when a service disappears ... this is why we need lifecycle

daveo: should portions of the lifecycle be in the basic arch?

<DaveH> I belive that it should have the same visabilty for same reasons as discovery
... what are the properties of the basec arch?

dougb: is current WS definition is at odds with lifecycle

geoff: do not confuse the states a services may enter vs. service properties which are manageable

<DaveH> how are they at odds?

igor: basic states, up & down, are managable

<dougb> also: we're dealing with a distributed architecture: from an external viewpoint, can't tell if something is down or unreachable

geoff: can up & down be defined operationally - from a behavioral perspective

heather: up & down is defined as the ability to take requests
... the down state doesn't mean it is not observable

<geoff_a> observably "up" or "down" is linked to the QOS supported by the transport - without reliable messaging, I can't necessarily tell the difference between "down" and "slow"

daveh: we haven't identified constrainable properties
... paragraphs on properties on management and discovery are needed

heather: maybe the extended vs basic distinction is bad

chris: from a basic arch perspective, the triangle is simple to understand and implement
... no need for sec, management, qos, etc
... basic is the essence of the arch
... doesn't see lifecycle in the basic arch

martin: identity is basic and is a property - and so is lifecycle

daveh: you get some sec, management, and lifecycle for free just by creating a service

chris: but that is not arch

heather: exposure of the states, is the management

daveh: all the features are indroducing new managable properties of the arch

<DaveH> not just manageable, but constrainable and therefore of architectural interest

<Heather> Can we make this an issue?

daveo: whether a service is avail is applicable to every WS. But we can make progress without going there

chris: what are the properties we are trying to acheive here

Scribe: [AI] Issue: is management part of the basic or an extended WS architecture

heather: moving to details of what we want to manage
... what to manage is really needs to be discussed with the whole WSA group
... both the service and the service env can collapse

glen: diff between service provider and service env?

<geoff_a> rathole #3 what...?
... We need to think about the principle of "separation of concerns" here

<DaveH> good point

<dougb> service environment makes sense but should be plural and (maybe) layered: for example, SOAP provider | application server | operating system | machine | cluster

jeff: what is the business owner

heather: hosted service/client needs to access the env for information
... what are the implications for management for hosted service concept

<dougb> ? does awareness come up with respect to both client or service and its environment and client being aware of service environment (and visa versa)?

jeff: if a client has responsibilities, then the entitiy is no longer ignorant of the env

<dougb> confused: which of my options are we currently discussing?

igor: diff between implicit and explicit responsibilities

geoff: the boundary of the manageable service and the service logic, where is it?

Scribe: glen" +1

heather: the management data for a service is separate from the app level logic

ericn: what are the benefits of management to the basic arch

Summary of Action Items