Ad-hoc Meeting of XP Abstract Model Sub-Group participants 17th January 2001

Participants:

Background

The meeting arose out of responses to Stuart's original posting of an strawman Abstract Model to the XML Prototocol WG members list [1]. The meeting was planned and scheduled ahead of the formation of the abstract modelling sub-group and it seemed reasonable to make use of the fact the three participant all live in the SW corner of the UK and can conveniently meet f2f.

What follows is an attempt summarise the salient points of our discussion. 

Discussion

There was general consensus that an Abstract Model is a powerful tool for aiding the process of defining and describing (specifying) the XML Protocol; that its primary focus is on the WHAT of XP rather than the HOW; and that it may also be a useful tool to structure a document collection and divide up the task of generating our specification.

Martin remarked that he'd found the discussion text (red, italicised in the PDF, or yellow highlight in the HTML [2]) in the strawman very helpful. It presents more of a range of options whereas the 'black' text has made a strawman choice to pick a particular furough.

Areas that are open to a number of viewpoints are XP Modules, Intermediaries and to some extent bindings. These are the key extensibility points for XP. It is possible to take the

Intermediaries

Intermediaries operating within the XP layer:

This would imply that the concept of intermediaries and path models would need to be an explicit part of the  XP layer service definition. The semantics of the transformation performed by an arbitrary chain of intermediaries, the targeting of XP Blocks (the syntactic elements of XP modules) at XP handlers (the behavioural part of XP modules) the order in which modules are processed by the chain of handlers is hard to hard to abstract.

Basically, pushing intermediaries into the lowest parts of the XP layer makes for a complex abstraction of what the layer does. The combination of intermediaries and XP modules makes for a more imperative (do this, then that, then the other...) style encapsulated in any expression of path XP ordering and 'actor' style targeting of XP blocks at instances of XP handlers. A more functional view would require that the semantics of the message were more evident from the message itself and from a functional model of the message transformations performed by processing intermediaries.

Intermediaries as XP layer clients:

This view move intermediaries up and out of the core of XP specification. The core of XP then becomes about 'single-hop' (at the XP layer) message exchanges. This separates message routing and message path models into the domain of a separate XP Module. This would enable a separate sub-group (or WG under the activity) to work-on intermediaries, they could independently experiment with several intermediary module definitions. In the long run, regarding intermediaries as application entities allows for much more creativity around what can be done in an intermediary than trying to contain it with the a core XP layer. It also makes for much more clarity about the core as being concerned with messaging over a 'single' hop.

XP Modules

Several questions arise with respect to the processing of XP modules:

XP Module processing within the XP layer

This leads to a 'comb' like view of the interface at the top of the XP layer. New modules 'plug-in' to the layer and bring with them their own abstract module of the element of service that they provide to an XP client. There is now single compact definition of a XP service interface definition. A message is processed through a 'chain' of handlers and delivered, the XP client then reaches back into the XP layer through module specific extensions to the XP service interface. Likewise, on outbound messages, the XP client interacts through module specific interfaces to set up the outbound chain of handlers for a given XP message and then kicks it off activity in a message synchronous fashion by sending the outbound message into the layer.

[I'd like to draw some more diagrams here but I don't have the time  right now]

XP Module process in XP layer clients

Abstract Layer Interface

We discussed and liked (I think) the service primitive oriented model for describing UNITDATA (datagram) and DATA (request/response) services. This model of description is 'borrow' from the style adopted in the work of the IEEE 802 committees that developed LAN standards.

We felt that it would be interesting to model all the all the message oriented parameters using XML as an abstract syntax for describing (what I shall call for now) an interface unit [could do with a more appealing term] as a container for the XP message being exchanged and all the associated parameters that the XP layer requires (or provides) for transmission and delivery of an XP message. In a practical implementation there would be no need to materialise this interface unit in XML, indeed there would be no need to materialise it at all. In that sense it is an abstract interface unit (we could call it an XP message but... I think we'd get ourselves and others confused). A 'concrete' XML for this abstract interface unit would then help aid in the description of XP bindings which (in the abstract) derive the content of the 'concrete' message serialisation from the abstract interface unit and the state of the local XP layer entity

.Xp module process in Xp layer client - schema

[One thought is that at least for outbound messages such transformations, from an abstract interface unit to a concrete serialisation, could be described using XSLT... being careful again that this is a formalism to describe the required transformation and not a stipulation that an XSLT engine must be used to perform the transformation. In bound is different, unless it can merely be regarded as the inverse of an outbound transformation - a MIME wrapped serialisation is not suitable input to an XSLT transform]

The diagram below, in imperfect XML tries to capture this idea of an abstract interface unit , the use of XML as an abstract syntax to represent an instance of an AIU (and one could anticipate a schema for an AIU as part of the abstract model - help please Martin!) and the derivation of both XML and MIME wrapped concrete serialisations of the XP message being transferred. 

abstract interface unit schema

HTTP Binding

We discussed a little the issues people have been raising on dist-app regarding starting a response early, head of a complete XP messaging having been received. A streaming response. It seems clear that we need to be able to allow a response to start being made at any time convenient to the responder. Hence, the early release of a 200 response from at the HTTP layer. This would then require that we be able to signal subsequent failure through some sort of abort mechanism (cf HDLC framing which has an abort delimiter or LAN MAC bridges which typically invalidate a CRC in order to loose a damaged packet).

We didn't spend alot of time thinking about mechanisms here. But we felt that there needed to be slightly more sophistication in the handling of HTTP response codes and the premature termination of response.

Conclusions

We felt that we should aim for the simplest useful abstract model we could achieve, namely:

Layer services:

A direct consequence of this view would be to push intermediary processing out of the core of XP to be considered specified as a separate XP module (if there is an explicit path model). Likewise, the bestEffort focus pushes work on reliable variants of the datagram and request/response services out into an XP module. Depending on timing the latter could slip back inside the XP core, indeed a mature description of both paths/intermediaries and reliable messaging services could be integrated back into the XP infrastructure in the long term.

To elaborate further on the use of XML as an abstract syntax to provide a concrete representation of an abstract interface unit and to illustrate how different (binding specific - Stuart's view) serialisations of an XP message (with multiple attachment) could arise depending to meet the intrinsic capabilities of the unterlying protocols. eg. the two concrete representation in the previous diagram are different representations of the same message and the inbound process would re-construct, indistinguishably the same AIU. There was some excitement that this concept might help clarify the discussions of XP and attachments and its binary carrying capability.