1. Abstract Model Subgroup Stuart Williams skw@hplb.hpl.hp.com Mark Baker, Sun Microsystems, (mark.baker@canada.sun.com)mark.baker@canada.sun.com Martin Gudgin, DevelopMentor, (marting@develop.com)marting@develop.com Oisin Hurley, Iona, (ohurley@iona.com)ohurley@iona.com Marc Hadley, Sun, (marc.hadley@uk.sun.com)marc.hadley@uk.sun.com John Ibbotson, IBM Corporation, (john_ibbotson@uk.ibm.com)ohn_ibbotson@uk.ibm.com Scott Isaacson, Novell Inc. (SISAACSON@novell.com)SISAACSON@novell.com Yves Lafon, W3C, (ylafon@w3.org)ylafon@w3.org Jean-Jacques Moreau, Canon, (moreau@crf.canon.fr)moreau@crf.canon.fr Henrik Frystk Nielsen, Microsoft Corporation, (frystyk@microsoft.com)frystyk@microsoft.com Krishna Sankar, Cisco Systems, (ksankar@cisco.com)ksankar@cisco.com Nick Smilonich, Unisys, (nick.smilonich@unisys.com)nick.smilonich@unisys.com Lynne Thompson, Unisys, (Lynne.Thompson@unisys.com)Lynne.Thompson@unisys.com Stuart Williams, Hewlett-Packard Company, (skw@hplb.hpl.hp.com)skw@hplb.hpl.hp.com

2. Overview of Model Status Plans Issues Questions

3. Overview of Model Descriptive Tool Focus on WHAT, not HOW A means to develop clarity over the WHAT XMLP is and what (functionally) it does. A potential means to partition the design task. A potential means to structure a document collection.

4. Model Outline Top Level Overview Service Abstraction –One-way, Two-way request/response and Intermediary operation. Modules and Applications –Path, Targetting Binding –BindingContext and Arbitrary Attachments Security –Mostly a placeholder defers to Bindings and Modules

5. Top-Level Diagram Sending XMLP Application Handler(b) Sending XMLP Processor Receiving XMLP Processor Intermediary XMLP Application Receiving XMLP Application Intermediary XMLP Processor Handler(a) Handler(d) Handler(c) Handler(g) Handler(f) Handler(e) XMLP Layer Underlying Protocol Layers XMLP Block 1 XMLP Block 2 XMLP Block 3 XMLP Block 4 XMLP Message ‘Transport’ Intermediary eg. HTTP Proxy SMTP Message Router XMLP_DATA XMLP_UNITDATA … XMLP_INTERMEDIARY Node INode IINode IIINode IV Node V

6. Service Abstraction It’s ‘hard’ to abstract the functionality of arbitrary modules! XMLP Handlers ‘positioned’ above the XMLP Layer into XMLP Applications The core abstraction is then around XMLP message exchange (through processing intermediaries). Service Abstraction describes protocol operations as event patterns seen from ‘above’. Layer Entity (XMLP Processor) implements the procedural rules of the protocol (which have yet to be designed). Layer Supports 3 operations for the exchange of XMLP messages –XMLP_Data (Two-way req/resp.) (4 events) –XMLP_UnitData (one-way) (3 events) –XMLP_Intermediary (2 events) Layer Entity Upper Layer Boundary Events between Layer Entity and Layer Clients Events between Layer Entity and Underlyling Protocol(s)

7. Operations Summary XMLP_Data.request Initiating XMLP Application Responding XMLP Application XMLP_Data.indication XMLP_Data.response XMLP_Data.confirm XML Protocol Layer, Underlying Protocols and Medium Time Sending XMLP Application Receiving XMLP Application XMLP_UnitData.send XMLP_UnitData.receive XML Protocol Layer Intervening Protocols and Medium XMLP_UnitData.status Time Intermediary XMLP Application XMLP_Intermediary.indication XMLP_Intermediary.resend XML Protocol Layer, Underlying Protocols and Medium Time

8. Operation through Intermediaries Layer Primitives Key 1.XMLP_Data.request 2.XMLP_Intermediary.indication 3.XMLP_Intermediary.resend 4.XMLP_Data.indication 5.XMLP_Data.response 6.XMLP_Data.confirm Numerical ordering indicates time sequence Initiating XMLP Application Intermediary XMLP Application Responding XMLP Application XMLP Layer 123456 Initiating XMLP ApplicationIntermediary XMLP Application Responding XMLP Application 1 2 3 4 5 6 Layer Primitives Key 1.XMLP_Data.request 2.XMLP_Intermediary.indication 3.XMLP_Intermediary.resend 4.XMLP_Data.indication 5.XMLP_Data.response 6.XMLP_Data.confirm Time NB. Response could also be processed by an Intermediary

9. Event Parameters To From ImmediateDestination OrigPath ActualPath Faults Headers Bodies Attachments BindingContext Status OperationType NextHop and Path Modelling Intrinsic support for Attachments ‘Catchall’ for underlying protocol capabilities, properties etc. eg. UserID/password, certificates/keys say HTTP, SSL, HTTPS. Message Components

10. Applications, Modules and Handlers XMLP_Data.indication XMLP_UnitData.receive XMLP_Intermediary.indication XMLP_Data.confirm Or XMLP_UnitData.status XMLP_Data.request XMLP_UnitData.send XMLP_Intermediary.resend Or XMLP_Data.response Initiating, Responding, Sending, Receiving or Intermediary XML Protocol Application XML Protocol Handler XML Protocol Handler XML Protocol Handler … XMLP Layer An XML Protocol Module encapsulates the definition of one or more related XML Protocol Blocks and their associated processing rules. These processing rules are realised in one or more XML Protocol Handlers. An XML protocol application is responsible for identifying and dispatching targeted XML protocol handlers

11. Message Path and Targeting This is a topic of active debate – how/whether to support message path as 1 st class notion in XMLP ImmediateDestination, OrigPath and ActualPath make current draft neutral to the resolution of this discussion. Need for terminology around types of targeting: Directed, Functional, Group… Issues of handler processing order semantics. ab d c f e g Node I Node III Node V Node numbering from figure 2.1

12. Binding and Attachments Service Abstraction provides intrinsic support for Arbitrary Attachments –Implications: 1.An intrinsic mechanism for carrying and referencing arbitrary attachments carried (somewhere) within the outermost XML construct (for bindings to protocols that don’t have intrinsic support for arbitrary attachments). 2.Binding specific mechanisms to carry attachments in more ‘efficient’ ways. ebXML/SOAP with Attachments discussion. Topic of active discussion BindingContext – mentioned earlier. –Container for parameters/properties of underlying protocols –Eg. UserID/Passwd, Key(Refs)/Certificates, QoS… –Means to deliver binding specific context information to XMLP Application and Handlers.

13. Security Refers to BindingContext to exploit any underlying security features. Refers to XMLP Modules (extensions) for Application layer security.

14. AMG Document Status Work of a subgroup of the XMLP-WG –4 Phone Conferences – One major rewrite. Good handle on basic message exchanges and model of XMLP processing intermediaries. Section 3. (Service Abstraction) is problematic for some. Treatment of Fault Handling, Paths, Targeting and Attachments is still open (require work).

15. AMG Plans Solicit Feedback from WG –Need to know whether WG regarded this as a useful contribution. Participate in and synthesis from Path/Targeting and Arbitrary Attachment discussions Seed further discussion of Fault handling. ‘Road-test’ Model against DS’s, S’s, SOAP 1.1 and SOAP with Attachments.

16. AMG Issues Requirements Glossary and AM Definition of Terms – These are closely related and in most cases aligned. Need to converge to a single reference. Section 3. Stuart regards it as a crucial part of abstraction of XMLP - the WHAT of XMLP. Henrik regards it as being too close to an API definition (larger note in Issues section). Intrinsic support for BOTH two-way request/response and one- way operations… do we need both? Questions…