See also: IRC log
Present:
Chair: MikeC & DaveH
Scribe: JeffM
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?
<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 [email protected], 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 3.3.3.2.5
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
([email protected])
<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...
MikeC: Yes, fair amount of discomfort on 2nd bullet.
DaveBu: presenting factorization of features.
<hao> Which second bullet?
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.
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.
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.
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.
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
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.
<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