WS Architecture WG F2F
14 Nov 2002

See also: IRC log



AT&T Mark Jones
BEA Systems David Orchard
Commerce One David Burdett
Computer Associates Igor Sedukhin
Contivo Dave Hollander
Fujitsu Frank McCabe
Hewlett-Packard Company Yin-Leng Husband
IBM Heather Kreger
IBM Chris Ferris
IONA Eric Newcomer
Macromedia Glen Daniels
Nokia Michael Mahan
Oracle Corporation Jeff Mischkinsky
Oracle Corporation Martin Chapman
Progress Colleen Evans
Software AG Michael Champion
Sun Microsystems, Inc. Doug Bunting
Sun Microsystems, Inc. Geoff Arnold
The Thomson Corporation Hao He
W. W. Grainger, Inc. Tom Carroll
W3C David Booth
W3C Hugo Haas

Chair: MikeC & DaveH

Scribe: JeffM


Brainstorming Session for Extended Architecture

Scribe: I'll just enter the list

<dbooth> Scribes: JeffM, Yin-leng

Group: intermediaries, processing model, packaging, fault tolerance
... availabibility, semantics, feature composition, profiles, ...
... new transport bindings, trading partner agreements, manageability, ...
... security, privacy, transactionality, compensation, localization
... manifest, n-phase commit, negotiation, policy, I18N
... QOS, scheduling, resource planning, Grid, ownership

<hao> how about automated agent?

Group: automated agent, templates, billing-charging, economics, cache
... logging, cash, reconciliation, archiving, mobility, scalability

<hao> did we mention about management?

Group: accessibility, state management, service delivery
... choreography/orchestration, identity management, presentation layer

<hao> relibale messaging

Group: authorization, non-repudiation, external constraints, versioning
... contracts, legal (jurisdiction, enforcement, ...), conformance,
... certification, type libraries, reuse, Intellectual Property (IPR) management

<hao> personalised delivery

Group: copyright, DRM, confidentiality, privacy, personalized delivery

<dougb> Hao, we're mostly talking about things not already on our list of agenda items and that's why reliable messaging and management aren't on the list.

Group: recovery and restart, hot swaps, self healing, configuration,

<hao> self-destory
... self-destory when a service goes bad, just a like cell kill itself

Group: deployment, RDF, diagnostics, self-destroy, interoperability,
... design environment, a2a, b2b, soa

<hao> self-tunning

Group: , self-tuning, registries and repositories, ontologies, help-desk,
... maintenance, TCO (total cost of ownership), lifecycle, references

<hao> dynamic proxy ( a service may mirror itself remotely)

Group: dynamic proxy, REST, SLA (service level agreement), BLS (business level agreement)

<hao> service market ( a client offers a

Group: auditing, security management, risk management, risk model

<hao> price, services try to satisfy)

Group: EOL (can add later if you feel something important has been left off)

DaveH: Anything urgent enough to be promoted to discussion list for today?

dougb: wanted someone to compare with original list

<hao> proxy?

Scribe: no takers, sigh :-(

<hao> where is the original list?

<dbooth> hao, the chair had already closed the list

DaveH: looking for volunteers to refactor/consolidate

<hao> I can do it from the irc log
... if that is what you want?

<hugo> dynamic proxy is listed

<hao> I though we were going to pick up one and discuss?

Scribe: ACTION: martin, davidbu, francis volunteer to refactor/consolidate at lunch today

Colleen: how will this work occur in future

DaveH: 1st step-consolidation, 2nd step - assign people to write paras
... Darwin will decide the rest

<hao> What is some of these stuff can be done without SOAP?

DaveH: asks for champions who want to promote a particular topic -- can't volunteer unless you are willing to write by lunch

Mark_J: how do we compose these features?

<hao> what do we need to write in order to promot a topic?

Mark_J: "these" refers to the basic features that are up on the screen

DaveH: need to write candidate definitive paragraphs (1-4)
... trying to get closure on this section
... Group will do priortization/deletion excercise sometime tomorrow or later this afternoon if there is time
... How many folks have paras ready for topics that are already on agenda?

DaveO: reliability, asynch, correlation

Heather: management

DaveH: schedule time to finish up Heather's discussion from yesterday - before lunch today

Mark_J: has pub/sub para

<DaveH> Asynchronous messaging (including queues, publish/subscribe)

Colleen: from agenda list: what's missing?

<DaveH> Attachment Caching
... Sessions / Coordination / Correlation
... Long running transactions -
... Reliable messaging -
... Message authentication -
... Message confidentiality -
... Message integrity -
... Message routing -

Mark_J: packaging (soap w/ attachments, etc.) is missing

<dougb> For grouping, our effort from first f2f included a bit < http://www.w3.org/2002/ws/arch/2/04/f2f-minutes.html#Grouping:> as a start for that effort. List itself includes a few aspects that aren't quite features (simplicity, useful, consistent, web friendly) and a couple of synonyms for features we covered (aggregation, standardized metadata, interaction diversity).

Scribe: Need owners for next hour

Colleen: message routing

Mark_J: packaging, attachments

Eric: long running transactions

<soliton> REST is missing

DaveO: reliable messaging, asynchrony, coordination

Scribe: For next hour break into small groups. Either work with one of the above 4,

DaveO: or form one of your own; prioritzation group will also meet

<hao> which 4?
... which group is doing reliable messing?

Heather: correlation

Dale: candidate glossary

<igors> hao, we're all doing a 'reliable messing' :)

Scribe: daveo is doing reliable messing (about) :-)
... No Scribing for an hour or so until we reconvene!

<hao> hi, igor, can I join jou guys

<igors> hao, just reliably mess arround :)

<DaveH> plsase - use the hour to work on your definitions and be prepared to post to IRC the completed work

<hao> hi, Dave, just doing a definition at this stage?

Scribe: rssagent, where am i?

Review of Architecture Document

<DaveH> hao, please review the agenda...it is the morning session that we are pursuing
... http://lists.w3.org/Archives/Member/w3c-ws-arch/2002Nov/0034.html

<dbooth> TOm, WSDL Primer draft is at http://dev.w3.org/cvsweb/~checkout~//2002/ws/desc/wsdl12/wsdl12-primer.html?rev=1.3&content-type=text/html#N1018A

<Mark_J> Packaging:
... - Use cases / real world need for the feature
... For some applications, a purely XML-based representation of the
... payload is awkward or inefficient. Examples of such cases include
... payloads which contain binary data, recursively structured envelopes,
... syntactically ill-formed XML fragments, etc.
... - Outline of one or more proposed solutions
... The most common packaging tactic in such cases is to introduce a
... multipart representation which carries the SOAP envelope and its
... related data (commonly referred to as "attachments"). "SOAP Messages
... with Attachments", published as a W3C note
... [http://www.w3.org/TR/SOAP-attachments], is one proposed scheme;
... "Direct Internet Message Encapsulation (DIME)"
... [http://www.ietf.org/internet-drafts/draft-nielsen-dime-02.txt] is
... another. An abstract model for the SOAP 1.2 attachment feature
... [http://www.w3.org/TR/soap12-af/] specifies how SOAP 1.2 bindings use
... attachments and how those attachments are referenced from the
... envelope.
... - Outline of one or more proposed solutions
... - Discussion of the controversies surrounding the feature
... - Discussion of the controversies surrounding the feature
... 1. How does serialization of the SOAP envelope (primary part) interact
... with serialization of the attachments themselves (the secondary parts)
... and the serialization of the packaging glue itself? For example, if
... the SOAP HTTP binding is normally responsible for serialization of
... the SOAP envelope in a non-packaging context, how does a packaging
... feature binding extension modularly interact with the base binding?
... How does the packaging serialization interact with other features
... that involve re-codings for encryption, compression, etc.?
... 2. Concerns have been expressed about the issue of references. SOAP
... 1.2 has taken the position that web resources that get copied into
... attachments are new resources with their own URI schemes. The binding
... (in particular, the packaging feature binding extension) has the
... responsibility for resolving references to these resources. Is this
... the correct model for attachments? Can dereferencing schemes smoothly
... handled cases in which the attachments need to be treated as cached
... representations of web resources?

MikeD: Get more detail into the WSArch Doc so that AC has more info to aid in deciding what to do about choreography

MikeC: Assuming choreography task is handled elsewhere, and assuming we finalize the triangle picture
... WG has about a year of life left. Need to plan out the work.

Mark_J: talks about his para

MikeC: anyone want to push back on including attachments, not wordsmithing

MartinC: why are attachments significant at architectural level? Seems to be "down at protocol level"

Dougb: Are there resources that only exist "on the wire"?

Mark_J: eg. camera that fire and forgets a picture, not a WS???

MikeC: need better intro as to why arch needs to deal with this.
... add issue? is attachement a web resource?

<dougb> Generalize architectural issue above attachments: According to us and the TAG, are there resources that exist on the wire?
... Paraphrasing Martin and DavidO's issue: In addition, what about resource representations that aren't valid XML?

davidbu: how do you send non well formed XML?

MikeC: sense of group is that this IS an arch issue, need to get stronger words written

Scribe: ACTION: Editors to produce stronger words describing the architectural signficance of Mark_J's attachment writeup draft
... To get long write-ups into irc:
... email to www-archive@w3.org, search in the archives for URL, and then paste in URL

<dbooth> Eric's message in archive: http://lists.w3.org/Archives/Public/www-archive/2002Nov/0038.html
... Here is where I found it: http://lists.w3.org/Archives/Public/www-archive/2002Nov/index.html

<dougb> Eric's message superceded at http://lists.w3.org/Archives/Public/www-archive/2002Nov/0039.html (according to index :-)

<hugo> Routing definition:
... In the Web services architecture, one-way messages are sent from
... senders to receivers, potentially via intermediaries. The set of nodes
... that a message goes trough is called the message path.
... Routing definition:

<dbooth> Eric's text reformatted: http://lists.w3.org/Archives/Public/www-archive/2002Nov/0040.html

<hugo> In the Web services architecture, one-way messages are sent from
... senders to receivers, potentially via intermediaries. The set of nodes
... that a message goes trough is called the message path.
... The specification of the message path is called message
... routing. Message routing is a message-level concept. It is independent
... from the packaging format and transfer protocol used for a message,
... and the routing of a message therefore does not rely on underlying
... routing capabilites.

Hugo: describes his write-up

davidbu: add 2 ways to carry messages: static and a dynamic msg path

<hugo> Issues:
... - one-way messages can be combined to form complex MEPs: can message
... routing span the lifetime of one message?
... - choreography describes a sequence of services that are invoked in
... order to accomplish complex tasks; one can imagine several
... interactions happening using intermediaries; how does routing relate
... to choreography?
... - what about transparent proxies?
... - what about error reporting and processing.
... - SOAP specific: abstract actors specification (URIs) vs location
... - security (not investigated)
... Candidate technologies: WS-Routing, ebXML Message Service Handler

<Mark_J> I posted my packaging text from my freemail account to the archive list -- http://lists.w3.org/Archives/Public/www-archive/2002Nov/0041.html

MikeC: consensus that message path needs to be clarified

DaveO: need schema for ???

MartinC: what is architectureal significance of routing?

davidbu: significant because you may want to specify path as part of msg
... specification of intermediaries

colleen: reduces application complexity

DaveO: people are starting to explicitly think about how to specify the path information, both statically and dynamically

MikeC: want to have an abstract way to say "I want to get it to THAT mainframe"

MartinC: isn't that a uri?

Colleen: rathole alert - observes that we have a lot of issues "at this level" in the doc
... maybe we should go back and triage/classify once we're happy (enough?) with their description

Scribe: ACTION: chairs/editors to make sure architectural significance of these topics is explicitly described and justified

Colleen: really should've been in template

DaveO: reliability, oh i repeat myself, again

<dougb> wonders if this action should include possibility feature isn't at correct architectural level -- do we need to discuss intermediaries before getting to routing through them?

Scribe: Heather gets 4 minutes (more) of fame until lunch to do management
... The scribe notes that managing trouts is difficult :-)


Management: 30 minutes - Heather is on

Scribe: ACTION: Heather to post html version of slides which she is now talking about

<hugo> Routing text: http://lists.w3.org/Archives/Public/www-archive/2002Nov/0042.html

Scribe: Heather clarified that she went to the OASIS TC asking them to defer making decisions until they had a chance to see output from the WSArch Manufacturing TF

hugo: not clear: when a service is "up", what is up?, and vice versa for down

dougb: conflating 2 things: management of ws, and using managment svcs to manage SOMETHING (e.g. a WS)
... how is a WS different from a "SOMETHING"

heather: mgmt of ws and mgmt through ws
... latter is being done in OASIS

scribe: lost in meta-mgmt space

heather: not attempting to define over-arching how do you manage web services?

francis: what are interoperability requirements for management of WS?
... is w3c in business of specifying global interface for mgmt of WS?

chrisf: what are properties related to mgmt?
... maybe there is a generaliztion for getting properties (in general)
... and then there is a specialized set of properties related to mgmt
... from arch perspective: generic WS needs to have a property bag

<dougb> profiles of general web service property bag such as the Grid bag?

chrisf: then there's a "bundle" of mgmt properties/attributes

heather: trying to define the specific properties/attributes for mgmt

chrisf: should we consider working on general notion of property bag?

heather: 2 things: define THE ws mgmt properties
... define how to find the properties

glen: defers his actual comment until after our hot lunch which is now warm gets eaten
... nope - he's doing it: It is more appropriate to have domain expert groups write the sepcifics
... e.g. SOAP group focuses on core piece that allows extensibility, not specifics of xxx
... arch - how can we define a basic framework so that these various groups can write their specific (domain) specs
... arch group should focus on the "really" generic: how do people write specs that can work together

MikeC: how does heather's presentation violate this principle

glen: not in scope

Scribe: A groundswell occurs

heather: Information model needs to be put together by a WS crowd, not the DTMF group which has less experience in WS

Scribe: several disagreement voiced

<DaveH> groundswell may be turbalance - not necessarily agreement

MikeC: go 'round table

MartinC: this group should not be discussing what base specs should say, etc.
... this level of detail is out of scope

Eric: we need to have something about mgmt in the arch doc. How can you do it
... w/o assuming some specifics about the execution environment.

<DaveH> heather - is the timeframe allocated at oasis for this project near expiring?

Eric: one of classic problems is it can't be defined until less of the world is defined.
... mgmt is often the last thing to be defined

colleen: +1 (to eric) AC018 is in the requirement document, so why is it out of scope

DaveH: have to watch line between detailed specification and architecture

<MartinC> i think the managament task force has done great work to date and should be folded into the arch document but going any further in this group at this point in time is not the best use of the group's effort

DaveH: early on the group put mgmt as a parallel piece of work, not a layer
... oasis TC willing to work with our subgroup
... do we want to recommend a standing TF in this or other WG to continue this work

davidbu: +1 to what was said before

igors: definition of manageability needs to be in arch

Scribe: mumble, mumble, mumble

chrisf: recommend go over "that"

<igors> http://www.w3.org/2002/ws/arch/2/11/WSA.ManagementInto.2.htm

chrisf: "that" ---> mumble, mumble

Scribe: immediately after lunch we will do "that"
... lunch BREAK
... 30 minutes or so

<DaveO> test

<Heather> test

<frankmcca> I'm logging. I don't understand 'where am i', frankmcca. Try /msg RRSAgent help

Scribe: Heather presenting WS Management roles

<igors> http://www.w3.org/2002/ws/arch/2/11/WSA.ManagementInto.2.htm

DaveH: are components equal to roles, or agents?

Hugo: Strong relationship with discovery presented. How so?

DaveH: Anothr verb for discovery is prferred. Issue to change verb?

Heather: Definition of Manageability, and as a result, a Manager Role is required.

Scribe: Just defintion of Manager role is required, not further discussed beyond its definition.

DaveH: Representation of Manager Role is independent of the triangle, i.e. not aligned with any specific node of the triangle?

Heather: Yes.
... What are the Manageable Components - Service Environment, WS, Discovery Agency.

<igors> for the record: concepts and principles being presented now are the base for what was presented before which was an application (or conceptual use case) for these concepts and principles

DaveH: Discovery should be further qualified, Manageability of discovery should be the phrase used.

MartinC: This is too detail for a architecture doc. Maybe "include" instead of "are".

Mark_J: How much of this is guidance, or normative architecture?

DaveH: This is an architectural description as I read it.

MikeC: This is architectural, does not have MUST, MAYs, etc.

DaveH: Test proposed for

Heather: Introduced text leading up to double triangle.

dougb: Suggest "A Realization in WS Architecture" instead of "Realization ..."

<igors> for the record: we're defining responsibilities of the WSA roles (actors) with regards to management and a manager role that exercises (or makes use) of those responsibilities

MikeC: Capture that this is good work, but not definitive as it is not reviewed by overall WG, and there is fair amount of discomfort on what has been presented.

<igors> +1 to dougb

Hugo: Scenario should go into scenario document.

MartinC: The language needs re-worked wrt to normative feel of the document.

MikeF: The whole document needs to say "no consensus".

MikeC: Editiorial Note needs to be inserted to give context for this Management doc.

<igors> 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

DaveH: Add ed note: see also the LifeCycle doc.

Scribe: sub /MikeF/ChrisF/ just above

DaveH: Has concerns echoing Glens - too much details. Would have difficulty adding Liffecycle in the same level of the other doc.

<soliton> but we need that details to do the management

Dbooth: Because of IPR issue, suggest adding lifecycle as separate document rather than in appendix or in main body.

<dbooth> Because of IPR issue, it should be a separate document -- not in main body or appendix.

<soliton> David, what IPR issue?

DaveH: Add 4th bullet as recommendation to W3C as to next steps.

<dbooth> soliton, one of the members of the Mgmt Task Force is not a WG member, and has not submitted an IPR disclosure.
... soliton, specifically Mark Potts (mark.potts@talkingblocks.com)

<hao> yes, I remember now. I thought he had done it.

dougb: There is no decision yet on whether 2nd bullet is accepted?

<igors> hao, I thought so as well...

<MartinC> http://lists.w3.org/Archives/Public/www-archive/2002Nov/att-0043/01-W3C_Extended_Architecture_features_2.txt

MikeC: Yes, fair amount of discomfort on 2nd bullet.

DaveBu: presenting factorization of features.

<hao> Which second bullet?

Categorizing Results of Extended Arch Brainstorming Session

Scribe: Some amount of discussion on the categorization. Whether to add more categories? Just spend 15 minutes now.

<hao> are we discussing the extended architecture features?

ChrisF: What is the objective of this exercise?

MikeC: To organize the work going forward. Want to have place holders for features of the architecture to work on by the WG next year.

DaveH: This is shopping list of candidates.

DaveO: Customers often assume everything will make it.
... So prefer not to publish this.

Makr_J: What do we mean by in scope? Do we launch WGs?

MikeC: Deserves a mention in glossary.

MartinC: The top categories deserve high level definition.

DaveO: Suggest putting the list in minutes as just list of stuff that the WG may use to look at.

DaveBu: Put into 3 levels of priority.

Glen: There is a core arch doc. now. It may need more features. Suggest 2 things being done now.

Scribe: 1: we know the ocean, and what chunks of things are needed. 2: We know the core, and how everything else works with the core.

MikeC: What is the next layer up above SOAP, WSDL, etc. Another layer may be security, choreography, etc. There is at least a business layer at top level and some other layer in between.

FrankM: More than 75% of the list needs to be taken account of before WS can take of. Rather than cover them at 50000 ft., need to show how these are covered.

Glen: Need to identify what things are that fit into the arch. spec.

DaveH: 2 compelling issues: 1. What should WSDL group draw bounds. Various people are looking at it.

Scribe: 2: Why should choreaography be at high priority when X has been identified. There is no context to answer that question.
... MTF has identified some things that the arch WG did not have understanding of the need previously.

MikeC: What is missing from the overall list presented by DaveBu?

FrankM: Are there any topics that cannot be accounted for by the features in the architecture (3.2.1)?

Mark_J: Note this is incomplete as it does not include things in the agenda already.

ChrisF: Explore how things fit together, but that is not on this list. Where is the glue?

Glen: The section is missing some basic architecture.

MartinC: From customers requirements, see how these requirements relate to the list presented.

DaveDu: Don't we need use case?

ChrisF: Too much to do in 1 year. The problem is how does everything work together. The properties of the architecture that we want in order to achieve these things.

DaveH: Want to know what the properties are, what are the contraints, etc.

Dbooth: Like word glue. Also, what are the invariants.

Mark_J: What is good example of architectural property?

Glen: SOAP extensibility.

<hao> client/server model

Scribe: 15 minutes up.

<dougb> architectural issue: when you decide to extend the web services architecture, how to choose between SOAP and WSDL extensibility or both (similar aspect to Chris' point)

ChrisF: Would like to have the feature's relationship to the triangle.

<ericn> http://lists.w3.org/Archives/Public/www-archive/2002Nov/0040.html

ChrisF: To have the relationship indicated.

Long Running transactions

Eric: Described what we are talking about, and the definition.

Scribe: Definition needs refinement.

DaveH: Record need to have a way to describe a unit of work in specific terms wrt SOAP and WSDL

Scribe: This is an issue.

<DaveH> ISSUE: record need to have a way to describe a unit of work in specific terms wrt SOAP and WSDL

Scribe: The smallest unit of work is a WS.
... WS can join a transaction.

<DaveH> - note - misunderstanding on my part --I want to explore the relationship between wsdl/soap and the smallest unit/atom

Eric: Will use sessions that is being worked by DaveO's group.

<DaveH> ACTION: chairs to schedule discussion relating soap/wsdl to smallest unit of effort in a long running transaction (restatement of issue listed above)

MartinC: Para on compensation would be helpful.

<DaveH> is the use of transaction vs interaction purposeful?

<davidbu> Results of the brainstorm are available at http://lists.w3.org/Archives/Public/www-archive/2002Nov/0044.html

Scribe: Discussion on definition of long running transaction.

ChrisF: gave example of lifecycle of purchase order.

<hao> received-processing-processed

Eric: that example is not the same as what is defined as a long running transaction in Eric's doc.

DaveH: Is interaction synonymous with transaction?

ISSUE: need definition of transactionality
... definition of long-running

<hao> interaction can be safe and non-safe

MikeC: BTP and WS Transaction have notions of transactionality.

<hao> transaction is the non-safe one

ISSUE: to record relationship with BTP, WS Transaction & Co ordination.

Scribe: ACTION: chairs to have Eric submit the text to the editors to add it to 3.2
... ACTION: to add the MTF Management Intro. text into the arch. doc.
... ACTION: The remaining 2 docs from MTF (Lifecycle and Concepts) are not to be added to the arch doc but archived.
... Resumption after break.

Asynch messaging.

Scribe: Starting with 2.21 from Usage Scenario doc
... Will also present Heather's work on Correlation.

<Heather> Message Correlation
... Correlation is an activity that uses a message identifier for matching messages.
... A message identifier is a piece of information that is used to establish a relationship between one or more messages.
... The requirement to support asynchronous request response message patterns creates the need for a correlation of messages. The message identifier is an identifier that allows the response to be correlated with the originating request. The sender may also add an identifier for a service, not necessarily the originating sender, that will be the recipient of the message. The
... recipient of the message. The message identifier can be passed in one of three ways:
... 1. message identifier in message
... 2. message identifier in interface
... 3. message identifier identified by a URI and retrieved from a 3rd party
... Who does Correlation:
... · Protocol - Correlation is done by the underlying protocol
... · Infrastructure - Correlation is done by the infrastructure, the message identifier not available to application/user and
... · Application - Correlation is done by the application. Application uses the message identifier directly and it must be passed thru and available to him. The need for the application to do that depends on how much infrastructure he can depend upon.
... We need it to support:
... · Session -
... o Application - application may need to correlate messages over a session
... o User - SessionID might be used as a message identifier for sessions or conversations
... · Pub Sub - Message is a result of a particular subscription
... · Reliable Messaging - storing and resending a message
... · Asynchronous Request Response - Need a correlator to know that a message is the response to a request

Scribe: DaveO pointed out example showing correlation in async messaging.
... The call back address can be dynamic (in a message), static (in an interface), or specified by 3rd party.

DaveO's Proposed text to section 3.2

Jeffm: need to define or explain diff"

Scribe: difference between Infrastructure and Application in section under "Who does Correlation?"

ISSUE: do we need correlation in pub/sub?

<dougb> My suggested words to replace 3rd and 4th sentences: Various requirements and higher level features identified in this architecture lead to the need for message correlation. For example, asynchronous interactions often require higher level correlation between otherwise distinct messages. One implementation of this concept makes use of identifiers for the correlation itself, allowing a response to be correlated with the original request.

Resolution: these are examples of types of correlation.

Reliable messaging.

Scribe: Example from Usage Scenario 2.7

<dbooth> chrisf, http://lists.w3.org/Archives/Public/www-archive/2002Nov/0047.html

Scribe: Proposal to use this text to add to arch doc.

dougb: to put reliable messaging before correlation to lead up to need for correlation.

<mchampion> http://lists.w3.org/Archives/Public/www-archive/2002Nov/0045.html

Pub/sub from Ugo.

MikeC: Do we need a separate section at 3.2, or is pub sub covered by asynchrony?

Scribe: ACTION: MartinC to write up the various architectural topics that he proposed.
... ACTION: for tomorrow to understand how asynchr messaging, pub/sub, reliable messaging might related to choreagraphy.
... ACTION: editors to take text from url and incorporate into 3.2 as appropriate.


MikeC: Is there any other draft text, such as from harvesting work?

<Mark_J> Chris -- the packaging text is in http://lists.w3.org/Archives/Public/www-archive/2002Nov/0041.html

<hugo> chrisf, the routing text is at: http://lists.w3.org/Archives/Public/www-archive/2002Nov/0042.html

MikeC: Remaining sections requiring text are around security.

Scribe: Specifically authentication, and integrity
... and confidentiality.

<dougb> WSS @ http://www.oasis-open.org/committees/wss/

Scribe: ACTION: Hugo will do a few paragraphs on the 3 sections (authen)tication, integrity, and confidentiality

<DaveO> there be trouts eating rats

Scribe: ACTION: Hugo will do authorization words also.

Rat Hole Discussions

<Heather> rathole 0 - what is a web service
... rathole 1 - what is an architecture
... troutpond 2 - what are properties of the system we want to see
... troutpond 3 - what is role

<DaveO> troutpond 4 - go for beer

<Heather> troutpond 2 is now open for fishing - What are the properties of the system we want to see

<DaveH2> trout pond 2 - what are architectural properties of the system being described (ie web services)

<dbooth> Fielding thesis is at http://www.ics.uci.edu/~fielding/pubs/dissertation/software_arch.htm

<daveh> please post the url
... thanks

<dougb> Use case for our architecture group: I (a specification writer) want to bind the web services infrastructure to SNA. Where do I start? Should I do everything using a SOAP binding and use a 'pure' WSDL binding to SOAP? Should I completely ignore the existance of SOAP and bind directlly from WSDL? Or some approach in between? This seems to be a question our group should help to answer.
... sorry daveO, was that a usage scenario?

<daveh> Business Processing Modeling Language (BPML) 1.0 was released as a final draft by the Business Process Management Initiative.

<dougb> ? Summary: simplicity and extensibility are the principles we as a group wanted to discuss the most. Some recognition they may be at odds.

<hugo> hopefully, somebody watches the queue

<DaveO> heh

<hugo> www-archive

<dbooth> @w3.org

<hugo> http://lists.w3.org/Archives/Public/www-archive/

<chrisf> momentus occasion!

<dougb> ACTION: make the core web services architecture simple (usable) -- words from our friends at Oracle

<daveh> humor in the formal minutes are not appreciated...it is hard enough to track this group

<MartinC> a summary of pub sub is at http://lists.w3.org/Archives/Public/www-archive/2002Nov/0048.html

<TomCarrol> I prefer compact architecture to simple

<daveh> chairs should consider a task force focused on detailing the base architecture
... would someone ask zakim for the actions?
... of course not...I am not at your level of abstraction

Summary of Action Items

ACTION: Editors to produce stronger words describing the architectural signficance of Mark_J's attachment writeup draft
ACTION: Heather to post html version of slides which she is now talking about
ACTION: Hugo will do a few paragraphs on the 3 sections (authen)tication, integrity, and confidentiality
ACTION: Hugo will do authorization words also.
ACTION: MartinC to write up the various architectural topics that he proposed.
ACTION: The remaining 2 docs from MTF (Lifecycle and Concepts) are not to be added to the arch doc but archived.
ACTION: chairs to have Eric submit the text to the editors to add it to 3.2
ACTION: chairs to schedule discussion relating soap/wsdl to smallest unit of effort in a long running transaction (restatement of issue listed above)
ACTION: chairs/editors to make sure architectural significance of these topics is explicitly described and justified
ACTION: editors to take text from url and incorporate into 3.2 as appropriate.
ACTION: for tomorrow to understand how asynchr messaging, pub/sub, reliable messaging might related to choreagraphy.
ACTION: make the core web services architecture simple (usable) -- words from our friends at Oracle
ACTION: martin, davidbu, francis volunteer to refactor/consolidate at lunch today
ACTION: to add the MTF Management Intro. text into the arch. doc.

David Booth
$Date: 2003/04/04 12:59:46 $