WS Architecture Teleconference
15 January 2004
See also: IRC log
Present:
Regrets:
Chair: MikeC
Scribe: Gerald Edgar
Contents
- Approval
of Minutes
- Review
of Action Items
- Management
model
- Abbie's
combined policy and security
draft
- Usage
scenarios document
- Architecture
Loose Ends
- Report
from Hugo on last call criteria
- Summary
of Action Items
Approval of Minutes
Scribe: Minutes for were
approved.
[Links to minutes]
Review
of Action Items
<To be
added>
Action items
Management model
Mike C: Dave have you had
time to go over this [management model]with others:
DavidB: no I have not
Mike C: this is addressing
part of the simplification proposal
DavidB: the idea is that this
model is unnecessary because of his understanding of the way management
it done, it is using other aspects of w/s architecture it does not
require anything special. The idea of a management interface - that is
yet another interface. There is noting special needed in the
architecture to accommodate this.
Frank: a management
calls out a number of items. The diagrams are wrong because it is
not consistent with WSDL the concepts are older, remove this from the
concepts section but not the stake holders section if you correct it is
not needed.
Yin-Leng: the correct section
does not have the updated section
Mike C: it has been
updated since then the diagram discussed with Zulah is not the new one.
Frank: no new concepts are
introduced in management
Rodger: management does
not effect the architecture
Yin-Leng: there is nothing new
introduced in the management section.
Rodger: if we feel it is
the best interface to provide we should not leave it out.
Frank: there are political
implications to this.
DavidB:if WSDL 2.0 there is
only one interface per service.
Mike C: the real reason
is that WSDL is less generous. Manageability and the meta
relationship to that service
are separate in the management. You may
have a video steaming service, you may allow people to change the bit
rate of the service Management of the service as opposed to using
the service. If we think we know what is needed for manageability of
the services then we should keep it
Katia: management of the
service can be URLS be part of the same service - there may be several
services, the service and the management of that service,
Frank: there is a meta
relationship.
DavidB: [In WSDL there is]one
interface per service. There is not complete agreement for this, but it
is unlikely to be reopened.
Rodger: can one interface have
one entry to one server and another for an entry to another server?
Mike C: this is not
clear - we should address this as one of the unresolved issues.
Frank: the current model
for management is not defensible. David's is defensible. It is not
defensible for a number of reasons. There is not time in 2 weeks
to complete it.
DavidB: since we know it
is obsolete - we should remove the management model, and to the
stakeholders section add Zulah's diagram.
Yin-Leng: is it available
Mike C: it is there, but not
in the document
Yin-Leng: that is the
same diagram that I put in my proposal for the management interface.
This diagram has been edited. 2.3.5 management model text. You can drop
the model text and retain the stakeholders section, that is fine
Rodger: management is still
going to be discussed in the stake holders section.
Yin-Leng: her text
on management interface the stake holders section describes when a web
service becomes manageable.
We should not talk about an additional management interface.
Mike C: a management
interface is real, but it is just another interface.
Action Item - remove management model make sure that the actual
stakeholders text encompasses what Yin-Leng proposed.
Action to Yin-Leng to make sure what is checked in is what she thinks
should be there.
Hugo: if management is
removed from section 2 - should we keep them in the glossary?
Rodger: I did not think
we were removing this section
Frank: in this case we
are.
Rodger: we are removing
content people care about -
Mike C: Only the
management concepts are being removed.
Rodger: hopefully
the management is still covered
Mike
C: choice between moving or removing is slanted to
removal given the time frame. The WSDL folks could not swallow the
management model
Yin-Leng: the concepts
section - it is not her text.
Mike C: it is obsolete.
Yin-Leng: I have text to
replace this. Consistent with Zulah's model and consistent with the
stake holders section.
Frank: I believe that the
elaboration of Zulah's model is essentially empty. There is nothing
added
Yin-Leng: the issue of the
glossary there are terms that are not used in the text.
Mike C: To remove
obsolete terms. That is something that needs to be done. To move
definitions to the glossary.
Mike C: to Hugo - to make
sure Yin-Leng - concepts to the glossary.
Hugo: I think I added them all,
I would rather have
Yin-Leng -check to make
sure that all the concepts are there.
Mike C: Other issues for
simplification?
to use the diagrams he sent in in order to use the proposed
diagrams as a roadmap.
Frank: [We could]
use the simplified diagrams as a precursor, as a drill-down starting
point. What is done is to start each model with These diagrams. As an
roadmap. Leave this up to the editors to do this
Katia: to have a diagram
and then lead into the subsection to fill in
the bubbles
Frank: if there is
a higher level description that would be good.
Mike C: leave this
to the editors.
Architecture Loose Ends
Mike C: [We need to
] ID the issues that are still hanging over the Web Services
architecture that no single group can resolve - such as what we talked
about in management - intermediaries, WSDL definition of a web service
- interface vrs service. What are the things people should be thinking
about?
Frank: that is uncountable
Mike C: the first 5 of that
infinite list - this is from a bit
of discussion on the mailing list.
Katia: security is on that
list?
Mike C: security is an
issue on everyone's list it is not so much an architectural issue
Frank: a model in trust for
security - he did a simple trust model diagram we do need to deal with
that. Trust is a "version 2" kind of think
Mike C: think of the top
items or issues have we shed light on on relation of services and
messages. SOA and web services Bring these items to the attention to
the editors. We need to wrap up with what we think we have don and what
a future incarnation should address in this area, what should people
should address, reliability and security is yet to be covered.
Suresh: reliability is
a very important issues security may not figure in right away. Some
will -= authorization - features within each layer for authorization,
building in authorization for each layer, not thinking about security,
or something between.
Mike C: we should think
about this in the context of what Abbie has sent out.
Mike C: Identity
management - do we have a handle on that.
Frank: identity is more than
one Ph.D..
Mike C: We can
identify promising Ph.D. topics.
Eric N: - there is a
difficulty - it is possible to have resources that have ho
authorization. Is it possible to include it everywhere? give security
analysis of the whole architecture. To use security thorough - or to
ignore it.
Suresh: if we say
resources are accessible based on the premise that resources enforce
security
Mike C: these are
the kinds of things we need to make sure are in Abbies Text. To make
sure we identify the topics
Mike C:
Moving along -
Mike C: there is a
reasonable convergence of the SOA text is there anyone who is not
comfortable with the bits and pieces? there was no decent
Mike C: the service
model - some is covered by frank's 50,000 foot section . If
there are other issues that people want
Katia: Choreography
Mike C: as a term,
or as a description of the ways messages can be composed.?
Katia: service role and
choreography - as neighboring concepts. Message are part of
choreography, choreoagraphy is about task -
Frank: this is s what we
have
Katia: that is fine.
Frank: interface as defining a
choreography - WSDL objections, but that is a limited view.
DavidB: message exchange
sequence or pattern vrs choreography do they have the same
meaning?
Frank: there is a shaded
meaning of atomacity
DavidB: Message Exchange
Pattern - Message Exchange Sequence a pattern may match a
specific sequence
Katia: a sequence - an
interaction of two
a choreography -
multiples perhaps in parallel.
DavidB: Message Exhange
Sequence is a particular sequence - a pattern is a hypothetical.
Suresh: - there is a danger in
making the patterns more complex in a sequence there is no standard
order many times. Message exchange pattern particular exchange of a
message exchange sequence.
Combined policy and security draft
Abbie dropped
off this discussion is deferred.
Action to Mike C to put this on next weeks meeting.
Usage scenarios document
Hao:
Yin-Leng has made some
suggestions there is some clean up to be done. We just need
to identify the scenarios
Hao: a new version to be
available this weekend. It must be done by Friday.
Report from Hugo on last call criteria
Hugo: there are three things in
order to meet the last call criteria - no issues and satisfying
dependencies and other groups to agree on this. He have no read
the issues. We need to document any issues. Last call - it is on a path
to recommendation - we are not ready yet. We also need to
be here to accept the results of that last call
Katia: to continue in an
informal way
Rodger: objection to that the
activity proposal for web services - loosing one and scaling back on t
he other.
There was a discussion of the
disappointment on the scaling back of web services activities and the
potential of companies leaving as a result.
Frank - this is not really a
question of persuading the big players to participant. It is still
important.
David - what we have seen
recently is that these small groups are
taking specs elsewhere.
Hugo: description of the three
ways to initiate an activity.
Work with your AC rep to get things out there. What we in this group
think is different from the membership as a whole: he did not see a lot
of support for web services activities.
Summary of Action Items
[NEW]
Minutes
formatted by Gerald Edgar
$Date: 2004/01/29 21:07:29 $