Abstract Model Subgroup摘模型组.pptVIP

Abstract Model Subgroup Stuart Williams skw@ Overview of Model Status Plans Issues Questions 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. 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 Top-Level Diagram 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) Operations Summary Operation through Intermediaries Event Parameters Applications, Modules and Handlers 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. 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 suppor