Presentation is loading. Please wait.

Presentation is loading. Please wait.

Peter Niblett William Vambenepe WS-Notification Face-to-Face 18-20 May 2005.

Similar presentations


Presentation on theme: "Peter Niblett William Vambenepe WS-Notification Face-to-Face 18-20 May 2005."— Presentation transcript:

1 Peter Niblett William Vambenepe WS-Notification Face-to-Face May 2005

2 2 Agenda - 18 th May (times in PDT) 1:00 Roll Call Scribes (4 half days) Decision on group dinner Approval of minutes from May 9 th Time and Location for next F2F Proposal 12 Sep (or 19 Fujitsu UK 1:30 Action items review 1:45 Possible new issues Qualified elementFormDefault on inline schemas? 2:00Review status and plans for committee drafts 2:30 Editors for WS-Topics and the primer 2:45WS-Topics issue 4.2 3:30 WS-BaseNotification issues 2.6, 2.25, 2.40, 2.42, :30 Adjourn Group dinner?

3 3 Agenda - 19 th May (times in PDT) 08:30Pull Notification issue :00 WS-BrokeredNotification issues 12:00 Lunch 12:45 WS-BrokeredNotification issues 3:00 Policy Specify policy Work through a specific example - useRaw 5:00 Decision on what we do on Friday 5:30 Adjourn

4 4 Agenda - 20 th May (times in PDT) 08:30Continue with Policy Pull Notification Boxcarring Durability Managing Message Rates 12:00 End of Meeting - Lunch

5 5 Action Items  AI 56 - Igor: Fix typos in WS-Topics as described in [3]  AI 74 - BaseN editors to correct problems in implementation of issue 2.34  AI 76 - BaseN editors to update spec to tighten semantics of send/deliver (issue 2.39)  AI 79 - Lily to propose new issue and solution outside BaseN to replace 2.26  AI 81 - Chairs to recruit editors for the primer  AI 82 - Spec editors to incorporate content from the white paper as described in [6]  AI 85 - WS-Topics editors to respond to questions raised in Kato-san's [7] regarding use of terms TopicPath, TopicExpression, TopicPathExpression, and the names of the related Faults.  AI 90 - Lily to verify the approach proposed for WSN3.8. See [4]  AI 91 – Matt Roberts to verify whether [9]#5 is an issue  AI 92 - BaseN editors: address [9]#1-4  AI 93 – WS-Topics editors: Edits/improvements to WS-Topics raised by Ian Springer.  AI 94 – Sanjay to mark WSN 2.23 as Approach Agreed, see open.org/apps/org/workgroup/wsn/download.php/11939/issue% proposal.2.dochttp://www.oasis- open.org/apps/org/workgroup/wsn/download.php/11939/issue% proposal.2.doc  AI 95 – Sanjay to mark WSN 2.36 as Approach Agreed

6 6 Reference [9]  Brokered Notification’s Subscribe Operation is different from BaseNotification’s. It has some extra Topic related Faults. Shouldn’t they be consistent?  Many of the operations in the NotificationBroker portType refer to messages using the wsnt prefix when they should be using the wsntw prefix. Similarly references to messages using the wsrl prefix that need to be changed since wsrl is the prefix for the WS-ResourceLifetime schema namespace not the wsdl one.  NotificationBroker’s ResourceProperties should include TopicExpression not Topics (issue 2.38 applied to BrokeredNotification)  The namespace for ws-addressing needs to be consistent across WSBrokeredNotification and WSBaseNotification  The BrokeredNotification wsdl defines a ResourceUnkownFaultType and ResourceUnkownFault. These duplicate what is defined in the WS- Resource xsd. Some places in the WSDL refer to the type defined BrokeredNotification version but the BrokeredNotification also refers to messages in WS-Resource which can in turn refer to the WS-Resource version of the type. WS-Notification should use the WS-Resource version to avoid problems.

7 7 OASIS TC process  Committee draft an interim document approved by a TC –full majority vote of the TC required no notification to OASIS required we used to call these stable working drafts  Public Review Draft a Committee Draft that has been approved by the TC to go to public review –full majority vote of the TC required TC Administrator announces on the OASIS members list TC Administrator issues a Call For IPR Disclosure. Public comments addressed to public wsrf-comment list If changes are required the specification must be withdrawn from review then resubmitted. –The TC may conduct any number of review cycles (i.e. approval to send a Committee Draft to Public Review, collecting comments, making edits to the specification, etc.). 1 st public review of a specification must take place for a minimum of 60 days; any subsequent reviews must be held for a minimum of 15 days.  Committee specification a Public Review Draft that has completed public review and achieved final approval by a Technical Committee The TC Administrator conducts a ballot to approve the Committee Specification.  OASIS standard a Committee Specification that has been submitted by a Technical Committee and reviewed and approved by OASIS membership

8 8 Planning  WS-BaseNotificationPublic Review July 1st Resolve open issues –1.4 Pull-type notification –5 others –Any new ones Execute on Approach Agreed issues Merge in the Whitepaper material Issue verification / proof reading Change WS-Addressing version  WS-TopicsPublic Review July 1st One open issue (4.2) Execute on Approach Agreed issues Several typographical issues (AI 85, AI 93)  WS-BrokeredNotification Committee draft target was May 2005  Policy specification Committee draft target was July 2005 Use cases and selection Getting started Embodiment dependency (not in July 2005 version)  Primer/Best Practices documentAugust 2005  Interop?

9 9 BaseNotification issues  Open - Proposal available 1.4 Support for Pull-type notification –http://www.oasis- open.org/apps/org/workgroup/wsn/download.php/11249/pull%20proposal.1.pdfhttp://www.oasis- open.org/apps/org/workgroup/wsn/download.php/1  Open 2.6 Third party subscriber can be a security concern 2.25 Indirection via WSRP and WSRL 2.40 Use of wsa:RelatesTo 2.42 Security section to include more specific advice 2.44 Filters based on headers

10 10 BaseNotification issues  Approach agreed 1.5* Term “Event” is not clearly defined 2.1* Topics are not optional in WS-BaseNotification 2.23 Is subscription a WS-Resource? 2.32* Dialect of TopicExpression in Subscribe MUST be specified 2.33 Message ordering/interleaving 2.34 Additional Fault definitions 2.36 Specify baseline Policy behaviour 2.39* Tighten up semantics of send/deliver 2.41 Use of wsrp:Dialect 2.43* Message generation and accumulation styles 2.45* Typing of Notification payload – xs:any vs xs:anyType 2.46* Should UseNotify be a policy utterance? 2.47 Open content on messages * = In draft 01f

11 11 BaseNotification issues  Resolved 1.7 Indirect Notification pattern 2.3: Duration for the initial termination time is not allowed 2.7 Updating resource properties 2.11 Consumer can not identify the subscription causing notifications 2.13 Bindings for sending messages to Consumer 2.14 Is EPR the right construct? 2.15 Reliance on WS-Addressing 2.17 Common set of Faults related to TopicExpressions 2.18 WS-BaseNotification should allow any garbage collection mechanism 2.19 Soften the wording for the Subscribe operation 2.20 QOS regarding change of subscription properties 2.21 NotificationProducer resource property declarations 2.22 Pause/Resume message types 2.24 Use of term “implied resource pattern” 2.29 SubscribeResponse to specify effective termination time 2.35 XML schema separated from the WSDL file 2.37 TopicExpression RP to have attribute extensibility 2.38 Topics RP to be renamed TopicExpression

12 12 WS-Topics Open –4.2: source document for FullTopicPathExpressions (the topic set is different from a topic space and not fully specified) Approach Agreed –4.3: XPath 1.0 as an additional dialect for FullTopicPathExpression –4.4: domain-specific extension to topic spaces (how can you extend if you don't have access to the domain name used by the initial topic space). –4.9: Specifying the Ad-hoc topic space is cumbersome –4.16: When are wildcards and aliases resolved? –4.20: SimpleTopicExpression type as xsd:token –4.21: TopicSpace location attribute –4.22: Finality of TopicSpace –4.23: Resolving XML Names in the TopicExpression content –4.24: Namespace prefix change may result into unbound QNames

13 13 WS-Brokered Notification  Open Issues 3.4: Demand-Based Publisher is a light-weight NotificationProducer 3.5: Need additional Fault definitions 3.7 Specify baseline policy behaviour 3.9: Separate endpoints for Producer, Consumer, etc.  Approach Agreed 3.1: Dependency of WS-BrokeredNotification on WS- Topics 3.6 Need XSD separated from WSDL 3.8 SubscriptionManager interface in BrokeredNotification 3.10 Open content on Publisher Registration


Download ppt "Peter Niblett William Vambenepe WS-Notification Face-to-Face 18-20 May 2005."

Similar presentations


Ads by Google