Grandpa Ham – Grandpa Can do IT!

I will be explaining the contents of the new IPAWS-OPEN Developer’s Guide tomorrow. It will soon be added to downloads from the FEMA IPAWS-OPEN web site.
details are per the following:

Integrated Public Alert and Warning System (IPAWS) Developer Webinar
Open Platform for Emergency Networks (OPEN)
Introduction to the New IPAWS-OPEN Developer’s Guide
Wednesday January 18, 2012 12:00 Noon Eastern

IPAWS-OPEN enables the interoperable sharing of emergency alerts and incident-related data between systems that comply with non-proprietary information standards, and serves as the alert aggregator for the Integrated Public Alert and Warning System.

During our next Webinar, System Architect Gary Ham will provide an introduction and overview of the new IPAWS-OPEN Developer’s Guide. The purpose of the guide is to help developers successfully write IPAWS-OPEN interoperable code.

This program is intended primarily for third party IPAWS-OPEN developers and testers. Please make plans to join us via Live Meeting. As always, your questions and comments are welcome.

IMPORTANT: The audio portion of the program will be delivered via your computer speakers. The Live Meeting client must be used in order to receive the audio. Please review the instructions available from: http://www.fema.gov/pdf/emergency/ipaws/livemtginstruct.pdf prior to the program.

Login to MS Live Meeting for visuals: The following login link can only be used 30 minutes prior to the scheduled meeting time: https://www.livemeeting.com/cc/eiip/join?id=DMprogram&role=attend

If you are unable to attend this month’s program due to other commitments, a recording will be accessible from the FEMA Library.

FEMA has announced its new course for Alerting Authorities. Alert Origination Software developers/vendors may also find the course useful to understand the context of alerting via IPAWS-OPEN to EAS, CMAS, and NOAA Radio. The course is required for alerting authorities as a pre-requisite for getting Alerting Authority for IPAWS push dissemination, but it also provides info for developers as they define requirements for the software they build. Here is the notification that I received:

The FEMA Integrated Public Alert and Warning System (IPAWS) program office has worked with FEMA’s Emergency Management Institute (EMI) and subject matter experts to create a course that provides alert and warning training. This course (IS-247) is now available at no cost on-line. See http://training.fema.gov/EMIWeb/IS/is247.asp

IS-247 provides basic information on the Integrated Public Alert and Warning System (IPAWS). The goal of this course is to provide public safety officials with: increased awareness of the benefits of using IPAWS for effective public warnings; skills to draft more appropriate, effective, and accessible warning messages; and best practices in the effective use of Common Alerting Protocol (CAP) to reach all members of their communities. The course is expected to take 2 hours to complete and includes a final exam.

Regional, State and Local alerting authorities must successfully complete this course prior to being authorized to use IPAWS OPEN to send alerts via EAS, mobile devices, and other communications pathways. Although the course is designed primarily for emergency management, law enforcement, fire services, dispatch, and other public safety personnel, anyone wishing to learn more about IPAWS may take the course.

IPAWS announced its CAP 1.2 Interface last Friday (30 September 2011).

The CAP 1.2 schema from OASIS imposes a pattern on date formats that forces the pattern to be exactly YYYY-MM-DDThh:mm:ss-hh:mm as specified in the CAP 1.2 schema. The last six could also be +hh:mm and represents the offset of the local time in the time string from GMT.

WSDL generated code from the IPAWS-OPEN WSDL may use a standard utility for converting a Java Calendar (or its equivalent in .Net) to a String for its XML writer that is in the form YYYY-MM-DDThh:mm:ss.nnn-hh:mm where the “.nnn” is in milliseconds. This will break the schema. In fact, it resulted in runtime errors in some code I generated from the CAP 1.2 WSDL for IPAWS-OPEN using Java axis2. My solution (credit to Prafash Kumar from Alerting Solutions who gave me his example) was to edit the stub code wherever there was a Calendar to string conversion to substring out the milliseconds from the conversion. There may be a better way, but my solution was successful. Here is a snippet I used in one of those conversion situations:

Original: xmlWriter.writeCharacters(org.apache.axis2.databinding.utils.ConverterUtil.convertToString(localEffective_type0));
Replacement: xmlWriter.writeCharacters(org.apache.axis2.databinding.utils.ConverterUtil.convertToString(localEffective_type0).replaceFirst(“.000″, “”));

I can get away with the “.000″ string match because an incoming message to IPAWS-OPEN is also validated for a structure that contains no milliseconds, so the outgoing conversion will be a .000 if it is there at all.

There is a lot of talk lately about CAP compliance (and/or conformance) in alerting products.  At it is there.  It is, in fact, happening but there is compliance and then there is compliance with a wink. For example, IPAWS-OPEN 2.0 itself is only CAP 1.1 compliant and not IPAWS Profile compliant (yet). March is the goal at this point for CAP 1.2 and IPAWS Profile. Typical of any Government Program, we are trying to catch up with ourselves. But at least we are succeeding. (Note: we also have to be completely compliant. Compliance with a wink does not work very well in middleware.)

Also CAP 1.2 Compliance can be defined at many levels. (How many vendor products can actually digitally sign CAP 1.2 messages in accordance with the spec? I know it is optional, but compliance at one level means doing all the mandatory. At another level, it is also being able to do all of the optional.)

How about CAP IPAWS Profile compliance? The profile specifies Message Conformance, Message Producer Conformance and Message Consumer conformance. The rules for each are in the spec. Again is it all or just what is mandatory? (Hint: vendors will need to be able to do a LOT of the optional to be functional for their user base.)

Finally, there is the ability to send and/or receive messages from FEMA’s IPAWS aggregator. You will need to be able to do that. Particularly for CMAS which is scheduled to be operational in 2012 (Testing with the carriers begins very soon.) I can help with the last one. Many companies have signed up to begin development and test. Some have not. Give me a call or send e-mail. I can help.

How can testing begin even without 1.2 in place at IPAWS-OPEN? It can. The functional interface will be virtually unchanged for CAP 1.2 and most CAP 1.2 messages will also validate as CAP 1.1. The only difference is a couple of responseType values and the way the optional digital signature is configured on the message. (So those will not work with us until March. )