+1
Steve Graham wrote:
Here is my take on "refactoring
the Whitepaper". I would see parts of the Whitepaper going to:
Primer, BaseN, Topics, BrokeredN or /dev/null.
Section 1. Introduction ->
/dev/null. Much of the material already exists in the introductions
of the existing specs.
Section 1.1 Goals and Requirements
->
/dev/null. The goals and requirements are already in each spec.
Section 2. Overview of the
WS-Notificaiton
specifications -> Primer. This is good context setting material
to explain how the various individual specs compose to produce an
interesting
definition for a Web services pub/sub system.
Section 3. Terminology and Concepts
-> various specs
- Situation, NotificationMessage,
Notification,
NotificationProducer, NotificationConsumer, Subscription,
SubscriptionManager,
Subscriber -> WS-BaseN
- Topic, TopicSpace, TopicTree ->
WS-Topics
- NotificationBroker, Publisher,
PublisherRegistration,
PublisherRegistrationManager, Demand-BasedPublisher -> WS-BrokeredN
Section 4. Example -> Primer
Section 5. Security Considerations
->
WS-BaseN and WS-BrokeredN (with a little wordsmithing to tailor to each
spec).
Net result, no whitepaper.
sgg
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, IBM Software Group, Web services and SOA
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++
Most of the white paper actually looks OK. There
is some mention of the
IRP, which will need updating. The relationship between WSN and WSRF
may or may not need cleaning up.
I would recommend putting some mention of the produce/deliver
distinction in the whitepaper, along with a more detailed description
in
BaseN.
I would recommend switching the security considerations sections in
BaseN and the white paper. That is, the actual specs, particularly
BaseN, should have the definitive discussion and the white paper should
very briefly summarize and point to them.
|