[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Microservice Use Case from Emergency Management Domain
|
Hi Again guys, In the course of replying to Ken's comments on the questions we have developed about Microservices, I discovered an error when I pasted the xml below into the Google CAP Validator, so I have added in some dummied-up WGS84 coordinates so that it validates and works with Google's mapping functionality - which places it on the map a few miles southwest of Lake Tahoe which is still in the general area for which the actual Winter Storm Warning was issued. You can now copy and paste it into the validator to see how it works. Rex I propose to use the following example as a use-case to explore
the operational mechanics of Microservices. It is a NOAA NWS
Winter Storm Warning that uses the Common Alerting Protocol
XML-based standard. It has plenty of data and includes an
<expires> element about which we can inquire as to how a
Microservice manages data freshness, i.e. how often does it "pull"
messages from an external source to see if there has been an
update to a given alert message? Or is it better to have a
Microservice "subscribe" to other services that "push" changes out
as opposed to having the Microservice initiate the message
exchange on its own? Would a Microservice typically have its own mechanism for
deleting the alert message after its expiration? Would it
typically have a mechanism for checking to see if there is an
update before it deletes an alert? Likewise we can ask how such management pertains to other likely
changes in an alert like the movement of a storm over different
counties by adding and/or deleting <geocode> elements in
updates? There are other data management issues that can be
explored like changes in values for <urgency>,
<severity> and <certainty>. I may find other use cases for other kinds of emergency messages,
but this one is part of a current effort looking into what is
going to be involved in developing alternative JSON
representations of XML-based Emergency Data Exchange Language
(EDXL) specifications.
Microservice Use Case: Weather
Website Microservice implements OASIS Standard Common
Alerting Protocol v1.1 (CAP) CAP-v1.1 Alert Message in XML format for Winter
Storm Warning received from NOAA National Weather Service to be
ingested and displayed on weather website on click from end user.
<alert
xmlns = 'urn:oasis:names:tc:emergency:cap:1.1'> <!--
http-date = Sun, 22 Jan 2017 06:31:00 GMT --> <identifier>NOAA-NWS-ALERTS-CA125838F5ECFC.WinterStormWarning.125838F803C0CA.EKAWSWEKA.d2e18d2b81b08f7bcd9e6fadde0ff6db</identifier> <sender>w-nws.webmaster@noaa.gov</sender> <sent>2017-01-21T22:31:00-08:00</sent> <status>Actual</status> <msgType>Alert</msgType> <scope>Public</scope> <note>Alert
for CAZ107; CAZ108 (California) Issued by the National Weather
Service</note> <info> <category>Met</category> <event>Winter
Storm Warning</event> <urgency>Expected</urgency> <severity>Moderate</severity> <certainty>Likely</certainty> <eventCode> <valueName>SAME</valueName> <value>WSW</value> </eventCode> <effective>2017-01-21T22:31:00-08:00</effective> <expires>2017-01-22T12:00:00-08:00</expires> <senderName>NWS
Eureka (Northwest California Coast)</senderName> <headline>Winter
Storm Warning issued January 21 at 10:31PM PST until January 22
at 12:00PM PST by NWS Eureka</headline> <description>.SHOWER
COVERAGE WILL CONTINUE DIMINISH THROUGH THE REMAINDER OF THE
AFTERNOON...BUT BURSTS OF LIGHT SNOW CAN BE EXPECTED AT ELEVATIONS
AT OR ABOVE 3500 FEET WITH LIGHT ACCUMULATIONS POSSIBLE. HEAVY
SNOW WILL RETURN TO ELEVATIONS OF 3000 FEET OR HIGHER OVERNIGHT
SATURDAY THROUGH SUNDAY MORNING. SNOW SHOWERS WILL CONTINUE
PERIODICALLY THROUGH MONDAY... ...WINTER
STORM WARNING REMAINS IN EFFECT UNTIL NOON PST SUNDAY ABOVE
2500 FEET... SNOW
ACCUMULATIONS...1 TO 4 INCHES BETWEEN 2500 AND 3000 FEET... 4
TO 8 INCHES BETWEEN 3000 AND 4000 FEET. 8 TO 12 INCHES ABOVE 4000
FEET...WITH LOCALLY HIGHER AMOUNTS POSSIBLE. LOCATIONS
IMPACTED...TRINITY CENTER...PEANUT...HETTENSHAW... RUTH...AND
ELEVATED AREAS SURROUNDING WEAVERVILLE AND...HAYFORK. HIGHWAYS
IMPACTED...HIGHWAYS 36 AND 3 WITH HIGH CERTAINTY. LIGHTER
ACCUMULATIONS POSSIBLE AT BUCKHORN AND OREGON MOUNTAIN SUMMITS
OF HIGHWAY 299. FOR
A DETAILED VIEW OF THE HAZARD AREA...VISIT HTTP://WWW.WEATHER.GOV/EUREKA/HAZARDS</description> <instruction>A
WINTER STORM WARNING MEANS THERE IS HIGH CONFIDENCE THAT SIGNIFICANT
SNOW...SLEET...OR ICE ACCUMULATIONS WILL IMPACT TRAVEL.
CONTINUE TO MONITOR THE LATEST FORECASTS.</instruction> <parameter> <valueName>WMOHEADER</valueName> <value></value> </parameter> <parameter> <valueName>UGC</valueName> <value>CAZ107-108</value> </parameter> <parameter> <valueName>VTEC</valueName> <value>/O.CON.KEKA.WS.W.0005.000000T0000Z-170122T2000Z/</value> </parameter> <parameter> <valueName>TIME...MOT...LOC</valueName> <value></value> </parameter> <area> <areaDesc>CAZ107;
CAZ108</areaDesc> <polygon><alert
xmlns = 'urn:oasis:names:tc:emergency:cap:1.1'> <geocode> <valueName>FIPS6</valueName> <value></value> </geocode> <geocode> <valueName>UGC</valueName> <value>CAZ107</value> </geocode> <geocode> <valueName>UGC</valueName> <value>CAZ108</value> </geocode> </area> </info> </alert> -- Rex Brooks Starbourne Communications Design Email: rexb@starbourne.com GeoAddress: 1361 Addison St. Apt. A Berkeley, CA 94702 Phone: 510-898-0670 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]