Re: [soa-rm] Microservice Use Case from Emergency Management Domain

[rexbroo <rexb@starbourne.com>]

Good thoughts, Ken,

Thanks. I'm modeling a set of microservices in a test case, so noodling/teasing out the most appropriately scoped microservices is on my plate right now. That makes this particular use case a good exercise. The specific set of microservices I think our test case will resolve to, surround the task of building templates for the EDXL-DE (Distribution Element) wrapper/header/envelope that facilitates the message-routing and delivery of the specific EDXL message-type payload. What our micrservices are doing is assessing the data in the message-type payload and using it to craft an proposed basic skeleton of the EDXL-DE wrapper/header for content-based routing.

In the case of the [EDXL] CAP Winter Storm Warming Alert example this might involve taking the data values for various elements, such as <urgency>, <severity> and <certainty> to determine the how high a priority a particular message is given in relation to the geographic areas where the storm is passing through, for the length of time it is a danger. One microservice might key off geospatial info in the <targetArea> element while another keys off whether the <scope> of the [EDXL] CAP message is aimed at the public or restricted, possibly to emergency managers or first responders via the <recipientRole> element of the EDXL-DE wrapper/header.

Ken, you're correct a CAP message with an "Update" value for its <msgType> replaces the previous CAP message it <references> explicitly. Moreover, the EDXL-DE wrapper/header can also reflect that with "DistributionKindType" that takes the enumeration value "Update". The <parameter> element in the CAP message can be used for many purposes and could be hint to downstream delivery systems to indicate how it is intended to be delivered. Depending on the application delivery system, the message can be delivered through weather radio, television scroll text, or smartphone interrupts by using the content of the <instruction> or <headline> elements. The smartphone delivery can engage Wireless Emergency Alerts (WEAs) which require a very high degree of <urgency> <severity> and <certainty> to actually break into existing conversations or ring at 3:00 a.m. local time. In fact the criteria for such intrusive alerting is in the process of a 30-month schedule for implementation. WEAs are particularly important for situations like tornado warnings where they are credited with saving many lives in the recent outbreaks in Mississippi and Alabama.

When a message passes its <expires> datetime it is simply deleted from the servers where it has been residing. Anyway, as you can tell it is on the top of my mind at the moment and there are a lot of factors to be considered.

Rex

On 2/18/2017 2:50 PM, Ken Laskey wrote:

Rex,

Some thoughts:

- Going through the microservices.io deployment options and other sources like Sam Newman’s book, the preference seems to be one microservice per host/VM/container depending on your tradeoffs for directly running on host vs. VM vs. container.  Container often gets the nod but not an unqualified nod.

- A lot of sources also seem to point to event notifications to get the microservice to do the update.

- NOTIONAL SOLUTION: Looking at the problem, I would think the microservices would create a warning from the data (possibly distributed in different sources) available at a given time.  It would update a warning by creating a new one and overwriting the old one.  There would be no explicit delete.  The create would be initiated by an event from one of the sources saying it has been updated.  There would be no expire (unless there was a domain rationale), only an overwrite.  Eventually, the last overwrite would be a passing of the emergency.

Ken

------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S F510          phone: 703-983-7934
7515 Colshire Drive                           fax: 703-983-1379
McLean VA 22102-7508

On Feb 1, 2017, at 6:25 PM, rexbroo <rexb@starbourne.com> wrote:

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></polygon>

<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 

-- 
Rex Brooks
Starbourne Communications Design
Email: rexb@starbourne.com
GeoAddress:
1361 Addison St. Apt. A
Berkeley, CA 94702
Phone: 510-898-0670