wsn message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsn] Initial review of INFOD specification
- From: Susan Malaika <malaika@us.ibm.com>
- To: Matthew I Roberts <matt.roberts@uk.ibm.com>
- Date: Tue, 25 Jul 2006 17:26:41 -0400
Thank you. I've posted this item to
the INFOD mailing list - we'll discuss your feedback on this Thursday's
INFOD call.
Currently we plan to attend the WSN
call on Monday 31st July
Susan Malaika.
Matthew I Roberts <matt.roberts@uk.ibm.com>
07/25/2006 12:40 PM
|
To
| wsn@lists.oasis-open.org
|
cc
|
|
Subject
| [wsn] Initial review of INFOD specification |
|
All,
Please find attached a copy of the INFOD specification that I volunteered
to take a look at on last week's WSN call. I have included some comments
in the document that highlight my thoughts/concerns etc.
I must qualify my review with two caveats - firstly I was pressed for time
(so I apologize if I have missed things I would normally have picked up)
and secondly I'm not sure I was able to give my efforts sufficient time
to get a full and detailed view of what the specification is trying to
achieve. This may mean that I have misinterpretted things and lead my comments
down a blind alley.
As far as I can tell, INFOD is a specification which is aimed at providing
a mechanism for creating the association between a producer of events,
and a consumer in some way which can be more advanced than the standard
WSN pattern. In particular there is a INFO Registry service to which all
producers and consumers register, and in which an INFOD subscription is
created (different to a WSN subscription) which indicates that types of
messages that consumers wish to receive. The INFOD Registry is then responsible
for matching subscriptions to the available publishers, and then invoking
an operation on the publisher to indicate the set of consumers to which
it should send notifications. (The Registry is a bit like a NotificationBroker,
but notifications flow directly from producer to consumer rather than through
the broker).
The only item from WSN that seems to be used in the Notify operation (mainly
covered in section 3 of the INFO doc attached). My primary concern is whether
the INFOD folks are intending to take a copy of the Notify operation, or
use the one we define in WSN. There are several areas in the document (notably
the Schema document in 5.10 and parts of 3.1.1) where they seem to copy
the Notify operation into an INFOD namespace, which strikes me as a pretty
weak form of reuse (ie regular WSN apps wouldn't be able to invoke this
new variant of Notify because of the different namespace). They also define
a new WSA Action URI to be used when invoking this Notify operation, which
is a violation of the WSN spec (if they are trying to reuse rather than
copy).
I have attached comments in the document below that highlight the specific
areas that I have identified - I think is would still be very useful for
someone from INFOD to present to the WSN committee to give some more background
on how this will be used and clear up any misconceptions I may have stumbled
into!
Cheers,
Matt
Matt Roberts
IBM WebSphere Messaging Design and Development
Hursley Park, England. +44 1962 815444
matt.roberts@uk.ibm.com
MP 211 / DE3H22
[attachment "INFOD-Base Specification.doc" deleted by Susan Malaika/Santa
Teresa/IBM]
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]