XML Abstract Model Subgroup telcon, Jan 30, 2001
Attendees
- Jean-Jacques Moreau (Canon)
- Lynn Thomson (Unisys)
- Mark Baker (Sun Microsystems)
- Nick Smilonich (Unisys)
- Yves Lafon (W3C) - scribe
- Oisin Hurley (IONA Techologies)
- Stuart Williams (HP)
Look at the major elements in the current drafts. Major parts missing, or new
contribution. How do we manage the document.
then more technical discussions.
Why do we need an abstract model?
SW: In summary, the XML Protocol abstract model establishes a
set of useful concepts for developing. The abstract model contributes to
the XP design work. The subgroup agrees with the objectives and role of
the abstract model.
SW: iterations of the document for the f2f meeting
plan is to have somthing by feb 9. Meeting: weekly? more?
OH: it is better to do this too often, then changed according to this.
SW: weekly ok? -> taking that offline. tentative plan for one week.
Document check:
* start is a diagramatic overview
* largest part is then abstract processing model, major part of the draft.
* how module processing is done in the layers
* operation through intermediaries.
* bindings, pretty small as of now. (interesting stuff here should be donw wrt
payload/attachements)
SW: The diagrams and terms in this document need to be aligned with
the glossary of terms in the XML Protocol Requirements. Are the major
elements in the current draft? Are there parts that are missing or
need to be added?
LT: The XML Protocol Abstract Model document is well formatted.
The subgroup discussions may lead to adding or changing some items in
the document. Overall, the document looks pretty good.
MB: sec 2 maybe too details (strawman definition for XP).
JJM: detail in the section is about right, thinking about parameters and
their meaning is useful.
AMG Process
Current plan is to distribute a revised draft of the XML Protocol Abstract
Model document before the F2F meeting (2/9). Should the subgroup have one
or more weekly teleconferences? If so, when would be a convenient day and
time?
OH: It would be better to schedule the telecon often. It would be
easier to cancel a scheduled telecon than to set-up a new one.
SW: The discussion on telecon scheduling will be taken offline (in
consideration of a full 90-minute agenda). Based on the e-mail
responses, there are 5 people would be available for a 2/1 telecon.
Tentative telecon plan is a week from today.
SW: I can continue editing, but other contribution are welcomed. The subgroup
members could be noted as editors to the document.
MB: It is not clear whether they should be called editors or not.
people should contribute, but calling editor or not is not clear.
MB: we can have contributor/editor at the end
-> SW continues to be the editor.
NS: is it a standalone document? Where does this document fit in the family of
XML Protocol documents?
SW: it could be a roadmap for the documentation, an introduction for a bigger
document.
NS: it is then quite standalone then.
LT: Will the document be published internally (i.e., W3C and XP WG)
and/or be made available publicly?
SW: XP WG has not decided what to do with this document, we will sort this out
at the f2f when we will have something more robust
LT: looks good.
6:
Described: 2 best-effort services, datagram (one way) and req/rep.
Path is pulling intermediaries into a kind of layer.
Inclusion of the notion of path pulls thinking of intermediaries down into the XP layer.
May be better to think of intermediaries as being above the core XP layer.
Might (usefully) lead to separate working on a message routing/path module
above the core rather than integral to.
initiating client -> responding client through intermediaries.
message routing and/or processing?
OH: agree, not end to end directly (hope I got that ok).
(SW got caught up in some local administrative difficulties over the room he
was using!)
SW: partial pb through intermediaries, should we dig into that?
is best effort good enough? or should we have mechanism in the XP layer to
select reliability. reliability, order-delivery and such.
MB: just the word reliability is overused.
JJM: it would be good if we have something that could be extended for QoS, it
should not be in the core system.
JJM: about intermediaries and doing hop by hop instead of end to end, do you
have SMTP in mind or not? (error messages).
SW: from the XP point of view, you address only the next hop in the chain, so
thinking about PATH is separated from the core. Mark was using the word
"terminate", the hop may interact with another node, but we don't have the
notion of PATH.
SW: for reliability of in-order, if we have to say simgle hop or along a path,
things can get pretty complicated.
NS: According to the diagram on page 1 (Abstract Architecture), the abstract
model suggests that there is a routing intermediaries and then a connection
is maintained as point-to-point
SW: the notion is XP is a layer to something that uses it, it is client not in
client/server but for the program.
MB: I would just add hook for transport intermediaries
NS: The Abstract Architecture diagram shows a single request-response client
dialogue. It should show multiple response clients such as for multi-cast.
SW: ACTION, introduce transport intermediaries into the diagram
SW: Can't think of a good example for request/response pattern multicast... how
do you know when you've had all the responses you want/need.
JJM: example for multicast, you schedule a meeting, you send a request to
multiple people and you do the chenges only if all the responses are
reused.
SW: we have to take care of failure pb.
sec 3, message processing and module processing.
XP module has both syntactic elements and behavioural elements.
SW: tried to descibe the Apache SOAP 3.0 Axis architecture that appears
builds chains of inbound and outbound handlers to process extension
elements (cf. XP_Blocks). The processing chains being part of the local
configuration rather than being influenced by the 'shape' of a message.
MB: trying to integrate source routing might be better suited
SW: only few comments about XP blocks processing, distinction btw a module
processor and an XP processor.
OH: sounds like a reasonable start.
NS: Stuart, at what point do you see the message encryption occurring in your
abstract model?
SW: at the moment, it is somthing the application is doing before giving it
to the application layer -> application semantic.
SW: if you have an HTTP binding, if you have http basic auth how you get the
credential? -> binding context is a 'bucket' for carrying useful context
info that lower layers may need to operate, userid/password, certificates
for SSL etc, and (not discussed) inbound context such as authenticated
userinfo that could effect the response.
NS: There needs to be an end-to-end secure XML protocol message flow and then
determine what is handled by XP. I looked at SSL as an example protocol
external to this message flow.
SW: the the protection of the encryption is removed to talk to the actual
processor (http server ex).
MB: want to reuse part of intermediary model of HTTP as it is well understood
and well defined.
NS: Section 4 & 5, Message Processing shows only request-response flows.
Should this effort be expanded to cover the conversational flow/sessions?
SW: session/conversation is not handled yet should we do it?
SW: SOAP is intrinsicly req/resp especially with the HTTP binding.
OH: right
OH: we can say atomic interaction is one way
SW: I want to keep for now both one way and req/resp to clarify things.
LT: this document is independant of what SOAP does.
YL: connection and conversation would fit nicely in a module and demostrate
the fact that extensions are orthogonal.
SW: is packaging (binary attachements) related to binding. Would like to
position the encapuslation of multiple payloads/attachments, binary or
otherwise as a binding issue. Would like the basic XP service definition
to intrinsically support attachments/multiple payloads.
OH: we should send binary date, without encoding in b64, we have mime multipart
mime is an envelopping protocol. It provides a way to separate the XML from
the payload and being able to process only the small xml (ex).
OH: from the modelling point of view it is independant.
LT: in our work, we should see mapping to other underlying protocol, as we have
to be generic.
SW: the goal is to use some references for SOAP but not doing an abstract model
for SOAP, but for XP.
SW: aim to do more editing and get back to the group by the week end.