Re: [emergency-msg] CAP Channels

[Allen Wyke <emtc@nc.rr.com>]

Great email Art - you certainly raise some very good thoughts and
approaches to unifying "how" CAP messages are moved around. I can
actually add some Blue292 comments to an approach we are using, to help
further an investigation into this topic.

What we have done is created a Web Service that has 3 methods, which we
*think* will cover all the variations of the push and pull scenarios.
The methods are as follows:

getCAPAlerts(): basically, this is passed a time/date stamp, and the
function returns a list of alerts with their corresponding IDs.

getCAPAlert(): this function takes a CAP alert ID and returns the full
alert message.

pushCAPAlert(): this function allows you to push a CAP alert into the
system.

Using these three, partners would be able to poll the system and see
what new alerts have been entered, and then pull the ones they are
interested in. At the same time, it allows them to push alerts into our
system. We, of course, can do the reverse with a system that has the
same interface - you just give us the URI to the Web Service and specify
the authentication method (HTTP Basic right now) that needs to be used.

Anyway, its a stab at accomplishing a similar thing, but in the world of Web Services.

>From a standards perspective, and probably the best way to approach this
question of "how", we should take these two examples and any other ideas
the group has and lay out how we want to deal with them. For instance,
should we standardize on this too - as in actually put in the CAP
standard document? Or, should we just create an implementor's note (I think Eliot
suggested this at one point) to help avoid confusion for implementors -
something like a "CAP for Web Services" or "CAP for RSS"? Or, is there another, better idea? Rex, maybe you can chime in and comment on things you have seen within other OASIS TCs.

I agree with your comment that we should not preclude or limit
implementations, so we need to keep an open mind about the various
methods - I am sure there is more than one. At the same time, it would probably be to our advantage to pick
2 or 3 approaches as a starting place to facilitate a
conversation on how we should handle. We definitely want to not limit
adoption, and having some guidance out there for implementations will
help achieve that goal....as long as we do not try to force it on
people.

Thoughts?

On Mon, 2003-08-11 at 16:58, Art Botterell wrote:
> Friends -
> 
> Until now most of our work has focused on the CAP alert message 
> format itself.  But building a demonstration CAP 0.9 source has led 
> me to experiment with an idea developed by Robert Bunge and Eliot 
> Christian about one way to move CAP messages around.
> 
> Many CAP transmissions will occur in "push" mode, of course... 
> possibly using SOAP messaging over the Internet, or perhaps some sort 
> of data broadcast.  But sometimes a provider of CAP traffic may want 
> simply to post all its current messages on a web server... to enable 
> catch-up by a client that's just been turned on, for example... or to 
> support polling clients behind firewalls and/or with dynamic network 
> addresses (both of which make push more difficult)... or just to 
> avoid the costs of creating and maintaining  explicit subscription 
> records for a push service.
> 
> In such arrangements a list of current messages must be visible to 
> the clients.  In early prototypes we posted a simple text list of 
> filenames... basically just a directory listing.  Later experimenters 
> used an RSS file as an index to the current messages... but RSS was 
> designed with HTML content in mind and doesn't strike me as an 
> entirely comfortable fit here (although my mind remains open about 
> that).
> 
> So what I'm testing now (see 
> <http://www.edis.ca.gov/cap_0.9/index.xml>) is an RSS-like index file 
> customized for indexing operational XML messages.  A client can 
> retrieve this "channel" index and determine which messages, if any, 
> are a) new to that client, and b) not yet expired.  Then it can 
> retrieve those messages for further evaluation and use.
> 
> A few random notes about this arrangement:
> 
> * An unlimited number of sources and devices could expose some or all 
> of their current state in the form of channels, either to the general 
> public or (perhaps using HTTPS with authentication) to a restricted 
> community of viewers.
> 
> * For security and to reduce local network traffic some sources might 
> choose to publish their channels via off-site servers (as California 
> does for EDIS.)
> 
> * The channel index can reference messages from other servers and 
> sources, so a specialized channel could link to selected messages 
> from one or several sources... e.g., as a channel of messages 
> targeted to a particular region, or of a particular type.  (RSS is 
> used that way frequently to aggregate Web content according to some 
> particular editorial principal.)
> 
> * The <item> element includes the source and identifier of the 
> message, which together  form a unique ID for that message (at least 
> in the case of CAP)... so a client looking at multiple channels could 
> resolve any duplications it encountered.
> 
> * The <item> includes a <format> element populated with the default 
> namespace for the target document... so a channel could expose 
> multiple types of XML messages, not just CAP alerts.  (Of course, a 
> specialized channel client could filter out all but a particular 
> format.)
> 
> * An <item> can refer to another <channel>, so a "channel of 
> channels" might provide a basic means of discovering data sources. 
> (Of course, "recursive" channel clients would want to implement loop 
> detection, just in case.)
> 
> Again, I want to stress that the channel concept doesn't preclude any 
> other dissemination options or architectures... but for simple 
> implementations it may be a convenient and flexible approach.
> 
> Your thoughts?
> 
> - Art
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: emergency-msg-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: emergency-msg-help@lists.oasis-open.org
-- 
R. Allen Wyke
Chair, Emergency Management TC
emtc@nc.rr.com
http://www.oasis-open.org/committees/emergency