See also: IRC log
Present: Mike, Roger, Zulah, Frank, David, Hugo, Jeff, Bijan_(observing), Jacek Kopecky
Regrets:
Chair: MikeC
Scribe: Paul_Downey
dbooth: it's meta-comment rather than text for the document
mchampion: we long ago decided not to use the word component
Scribe: discussion about the paragraph "First of all .." regarding cardinality and constraint
Roger: method of constraints should be cardinality or governance
dbooth: has suggested rewording ..
mchampion: do we need to say "what architecture is"
fgm: abstract has some description ..
mchampion: we considered this and don't think it adds anything.
dbooth: an agent realises a service
Roger: service is conceptual
mchampion: a service is an abstraction and may exist without an an
implementation
... a service may exist even if we switch implementations
<dbooth> EricN proposed:
... [[
... Can we be clear on the definition a service, that a service only exists
if and when if it's
... deployed within an agent?
... ]]
fgm: the word entity with two different meanings
dbooth: for person or organisation
fgm: and for "object" but not an object!
hugo: how about person or organisation : POO
Roger: an agent is a programme
dbooth: how about piece of software
mchampion: entity should only be used for person or organisation
<dbooth> The group didn't understand what EricN meant by:
... [[
... Do we need a standard notation for a (Web services) contract with
annotation? So that it
... is presented consistently throughout the document?
... ]]
Scribe: ACTION: mchampion to follow up with eric what does he mean
by "standard notation for Web Services contract"
... Action: fgm to check collation order of concepts
... ACTION: fgm to check collation order of concepts
fgm: we don't have a processing model in the architecture - do we need one ?
Roger: isn't specifying the order things happen difficult
fgm: we may want to be more abstract than SOAP, but we don't say "how things work"
dbooth: processing model of what ?
... message exchange is only one part of the picture
mchampion: we discussed a state-event diagram and dismissed it
hugo: the larger picture includes choreography and so addresses processing
mchampion: we don't want to recapitulate SOAP
Eric: the document is inconsistant, i'm trying to scope within what we need to be consistant within. we have a collection of specifications is greater than just SOAP.
Roger: concerned about focus on one given MEP
dbooth: clarification is the order the concepts in the document to based on importance or within processing model
Eric: order should be the as they are introduced in the processing model
dbooth: we had already decided to order alphabetically
mchampion: what is meant by "standard notation of contract" ?
Eric: standard notation system across diagrams
dbooth: consitancy of iconic symbols (eric) of term definitions (roger) across diagrams
Scribe: group brings Eric upto speed on suggestions the group has accpeted
Eric: i have a list of specific inconsistencies which i'll continue
to work on ..
... stack diagram and concepts section should be consistent
fgm: distinction between definition and runtime is bogus
<mchampion> Eric: a processing model view ("execution
environment") view of the concepts/relationships should somehow align with
the definition time view
... ACTION: Chair will schedule time to follow up on the question of whether
we should do more run-time / processing model work
... DavidBooth: Eric's "processing model" may be simillar to his "procedure
for invoking a Web service"
dbooth: expand description of stack diagram, and processing model (as we have it) ?
mchampion: we're out of time on this.
fgm: our understanding of intermediary is incorrect: it's below our horizon, and role based
dbooth: transport level detail or specific use of the web service
<mchampion> dbooth: SOAP intermediaries are a way of structuring services
Scribe: WRT to section "Message Oriented Model"
fgm: routing is below our horizon
<mchampion> ACTION: Frank will remove
intermediary from MOM
... ACTION: Frank will discuss with others how to refactor SOM to incorporate
intermediaries properly
fgm: core of SOA focus is on message and agents are outside our scope, but middleware is about structuring a service.
dbooth: not convinced intermediaries need to be in here at all
zulah: intermediaries are important and should be in our architecture
fgm: pen in hand explains intermediaries may be shells of processing
dbooth: if a message is modified in transit, what is the difference between sending a different message ?
<mchampion> Paul: example of HTTP to MQ bridge as one type of
intermediary -- lots of other transport-level issues
... Roger: how about "proxy" that does end to end encryption?
Roger: intermediaries are an important part of an architecture
Paul: cites examples of proxies which route and transport and others that add value, e.g. logging and encryption. likes fgm's shell diagram
<mchampion> Paul: Proxies for routing as well; transport-independent correlation is hard!
Roger: questions separation of messaging from service
fgm: our focus is not on routing and low-level concerns
mchampion: transport may provide routing or may be in a higher level ..
Scribe: fgm, Roger: discuss having intermediaries in both models
dbooth: questions how services may be combined, an intermediary be considered as a separate service or part of a pipeline
fgm: intermediaries could be viewed as simple choreography
mchampion: result of discussion is to continue to include intermediaries
RSSAgent: what actions ?
<mchampion> ACTION: Frank will complete action from last F2F to add body/content to mind map and text for MOM
mchampion: anything else on MOM ?
<mchampion> mchampion: suggests we consider the usual diagram showing the architectural differences between SSL encryption between nodes and SOAP-aware end to end encryption
Roger: doesn't like the explanation of "action"
dbooth: deletes the philosophical definition
Roger: likes the word "program"!
hugo: service description is not linked with message description concept
fgm: choregoraphy identifies messages, WSDL describes their content
dbooth: WSDL does describe MEPs
... deletes message description language section
fgm: Message identifier has been commented out ?
hugo: we have an identifier concept, so we don't need a message-identifier concept as well
fgm: what is the cardniality of message and message-identifier ?
hugo: not every message has an identifier, you could argue they all should have one.
Roger: concerned about REST model terms in resource model, in particular the PUT action
Zulah: i have issues between the connection with resource and service models
dbooth: editorial question re term usage of "service requestor" and "service provider"
<mchampion> ACTION: chairs will determine what we decided on refactoring the SOM at the North Carolina F2F, contact the owner of the action item to see if it will be completed quickly, and reassign it if not
dbooth: ambiguity between agent and organisation
<mitrepauld> i'm online now
dbooth: suggests remove term "service provider"
zulah: service provider is a commonly used term and should appear
<mitrepauld> +1 to zulah
dbooth: wants to be precise
<mitrepauld> Roger ... provider entity, provider agent, service provider need to be clarified
Roger: "provider entity" and "provider agent" and use "service provider" in glossary
Scribe: ACTION: dbooth to clarify term "service provider" and
"service requestor" and expand glossary
... lunch - sushi!
... ACTION: dbooth to look at security notes put on public list by Roger
<mitrepauld> Will you be resuming after your sushi?
<hugo> ACTION: Hugo to set up a poll about length of f2f in January
<mchampion> paul, there are only a couple of people left. If
you have any comments/suggestions, we can talk.
... I have to leave in about 1/2 hour (12:30 PST)
... ACTION: Hugo to talk to Janet about possible promotion of our Note
<mitrepauld> Mike, I'll look through IRC log. I'll stay
connected for a while longer, and chime in if I have something to ask.
... URL above is forbidden. Can Hugo open it up?
... bye