[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency-msg] CAP Channels
Allen - Right, it's mainly the difference between a node-oriented (e.g., API) view and a network-oriented (messaging) view. There's also a question of multiplicity... a pure API-to-API model would work fine in a few-to-few architecture, but in a one-to-thousands application it may make more sense to render the files when they change and serve them up statically the rest of the time. <javaStuff> Using a channel, your getCAPAlerts( Date cutoff ) might be implemented internally in a CapChannel class... initialize it with a URI for the source and on request it returns an array of URIs for individual messages. (My own version also filters for a particular message format and has an option to suppress expired messages.) Your getCAPAlert() might be implemented with something like "new Alert( String uri )"... to retrieve a specified message and parse it into an internal object. And pushCAPAlert()... or you might call it putCAPAlert() just to keep it neutral... might be implemented in a channel with an Alert.marshal( File file ) operation to serialize the Alert as XML, followed by a CapChannel.reindex( String[] messageList ) to rebuild the channel index. (And then maybe some sort of a mirroring method to update a remote server.) </javaStuff> So it seems like there'd be no difficulty in putting a WS wrapper around this sort of exposed channel for folks who preferred it that way. But some simpler (e.g., embedded) applications might not want the overhead of full WS formalities. I'd have no problem, if there were interest, in developing a channel index format as a separate standard document. But I think we'd want to be very careful about trying to mandate architectures. The whole point of XML is to combine interoperability with loose coupling. The more restrictions we try to assert, the greater the risk that our recommendations might be ignored. - Art At 8:42 AM -0400 8/12/03, Allen Wyke wrote: >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 > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: emergency-msg-unsubscribe@lists.oasis-open.org >For additional commands, e-mail: emergency-msg-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]