1 / 16

Abstract Model Subgroup

Abstract Model Subgroup. Mark Baker, Sun Microsystems, ( mark.baker@canada.sun.com ) Martin Gudgin, DevelopMentor, ( marting@develop.com ) Oisin Hurley, Iona, ( ohurley@iona.com ) Marc Hadley, Sun, ( marc.hadley@uk.sun.com ) John Ibbotson, IBM Corporation, (j ohn_ibbotson@uk.ibm.com )

judson
Download Presentation

Abstract Model Subgroup

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Abstract Model Subgroup • Mark Baker, Sun Microsystems, (mark.baker@canada.sun.com) • Martin Gudgin, DevelopMentor, (marting@develop.com) • Oisin Hurley, Iona, (ohurley@iona.com) • Marc Hadley, Sun, (marc.hadley@uk.sun.com) • John Ibbotson, IBM Corporation, (john_ibbotson@uk.ibm.com) • Scott Isaacson, Novell Inc.  (SISAACSON@novell.com) • Yves Lafon, W3C, (ylafon@w3.org) • Jean-Jacques Moreau, Canon, (moreau@crf.canon.fr) • Henrik Frystk Nielsen, Microsoft Corporation, (frystyk@microsoft.com) • Krishna Sankar, Cisco Systems, (ksankar@cisco.com) • Nick Smilonich, Unisys,  (nick.smilonich@unisys.com) • Lynne Thompson, Unisys,  (Lynne.Thompson@unisys.com) • Stuart Williams, Hewlett-Packard Company, (skw@hplb.hpl.hp.com) Stuart Williams 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. Sending XMLP Application Intermediary XMLP Application Receiving XMLP Application XMLP Block 1 Handler(a) Handler(e) XMLP Block 3 XMLP Block 2 Handler(b) Handler(c) Handler(f) Handler(d) Handler(g) XMLP Block 4 XMLP_DATAXMLP_UNITDATA …XMLP_INTERMEDIARY XMLP_DATAXMLP_UNITDATA XMLPLayer Intermediary XMLP Processor XMLP Message Sending XMLP Processor XMLP Message Receiving XMLP Processor Underlying Protocol Layers ‘Transport’Intermediaryeg. HTTP ProxySMTP Message Router Node I Node II Node III Node IV Node V Top-Level Diagram

  6. 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) Service Abstraction Events between Layer Entity and Layer Clients Upper Layer Boundary Layer Entity Events between Layer Entity and Underlyling Protocol(s)

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

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

  9. Event Parameters NextHop and Path Modelling Message Components Intrinsic support for Attachments ‘Catchall’ for underlying protocol capabilities, properties etc. eg. UserID/password, certificates/keys say HTTP, SSL, HTTPS.

  10. Initiating, Responding, Sending, Receiving or Intermediary XML Protocol Application XML Protocol Handler XML Protocol Handler XML Protocol Handler … XMLP Layer 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 Applications, Modules and Handlers 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. e c f a b d g Node I Node III Node V Node numbering from figure 2.1 Message Path and Targeting • This is a topic of active debate – how/whether to support message path as 1st 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.

  12. Binding and Attachments • Service Abstraction provides intrinsic support for Arbitrary Attachments • Implications: • 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). • 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…

More Related