OASIS Emergency Management TC

Folks,

Here is the basic issue we have been having in building a CAP 1.2 implementation.  Your help is appreciated.  Neil recommends a change to CAP 1.2.  I am not sure we want to do that, but we sure do need to find a way to use the "Standard FEMA SOA platform" without having to hand code everything behind the WSDL.  So, suggestions are appreciated.

R/s

Gary Ham


Begin forwarded message:

From: "Bourgeois, Neil" <NBourgeois@constellationinc.us>
Date: February 3, 2010 5:41:02 PM EST
To: Lee Tincher <ltincher@evotecinc.com>, Gary Ham <gary.ham@eyestreet.com>
Subject: CAPv1.2 Web-Service Implementation Challenges

Gary and Lee
We are experiencing Web-service implementation issues with the CAPv1.2 schema. DM-OPEN is currently using Oracle 10g application server and Oracle 10g assembler to generate Web-Services.  DM-OPEN is also leveraging JAXB2 and its capabilities in binding XML to Java classes.
Here are the following issues:
1) With the two <any.../> tags the Oracle Assembler generates a single Alert object as a SOAP Element. This will require a significant amount of rework to upgrade the current CAPv1.1 Web-Service to CAPv1.2.
2) JAXB will not compile. Get response that "Any element has already been defined".
Recommendation to resolve these issue is to place <any.../> elements within their own element. I do not believe that this recommended change will take away any of the flexibility intended in the original CAPv1.2 schema.
Have similar Web-Service implementation issues been experienced by other developers?
Thanks
Neil Bourgeois
Cell: 703-732-6331
 
 
Original Schema:
        </element>
                <any minOccurs = "0" maxOccurs = "unbounded" namespace = "http://www.w3.org/2000/09/xmldsig#" processContents = "lax"/>
                <any minOccurs = "0" namespace = "http://www.w3.org/2000/09/xmlenc#" processContents = "lax"/>
      </sequence>
    </complexType>
  </element>
  <element name = "valueName" type = "xs:string"/>
  <element name = "value" type = "xs:string"/>
</schema>
Recommended Change:
        </element>
        <element ref="cap:Signature"/>
        <element ref="cap:Encoding"/>
      </sequence>
    </complexType>
  </element>
  <element name="Signature">
  <complexType>
    <sequence>
      <any minOccurs = "0" maxOccurs = "unbounded" namespace = "http://www.w3.org/2000/09/xmldsig#" processContents = "lax"/>
    </sequence>
  </complexType>
  </element>
  <element name="Encoding">
  <complexType>
    <sequence>
      <any minOccurs = "0" namespace = "http://www.w3.org/2000/09/xmlenc#" processContents = "lax"/>
    </sequence>
  </complexType>
  </element>
  <element name = "valueName" type = "xs:string"/>
  <element name = "value" type = "xs:string"/>
</schema>
 


Gary Ham
http://grandpaham.com
703-899-6241

Well, Folks,

It is now firmly etched in my head. Solutions sometimes actually do 
occur to me, but usually when I'm doing something else, like sleeping, 
which I've been doing a lot lately. So, maybe we'll get lucky.

Cheers,
Rex

Gary Ham wrote:
> Folks,
>
> Here is the basic issue we have been having in building a CAP 1.2 
> implementation.  Your help is appreciated.  Neil recommends a change 
> to CAP 1.2.  I am not sure we want to do that, but we sure do need to 
> find a way to use the "Standard FEMA SOA platform" without having to 
> hand code everything behind the WSDL.  So, suggestions are appreciated.
>
> R/s
>
> Gary Ham
>
>
> Begin forwarded message:
>
>> *From: *"Bourgeois, Neil" 

> Here is the basic issue we have been having in building a CAP 1.2 implementation.  Your help is appreciated.  Neil recommends a change to CAP 1.2.  I am not sure we want to do that, but we sure do need to find a way to use the "Standard FEMA SOA platform" without having to hand code everything behind the WSDL.  So, suggestions are appreciated.
> 

Neil's suggestion would entail creating Signature and EncryptedData elements as containers for the DSig and XMLEnc elements.  This of course would change the schema and the specification language, a substantive change, and require a 15 day public review.  I don't think this change, creating new elements, fits in the original scope for 1.2, but I had thought of creating a Security container for CAP 2.0 that could be used to hold not only the DSig and Encryption elements but other security related information for the CAP message.

I have included an alternate schema that does not require these containers but also takes a different approach than the current use of 

Right now I don't understand the problem, so attempting to suggest a 
solution or even an approach to a solution wouldn't make sense for me. 
If smeone could please direct me to the documentation for the Standard 
FEMA SOA platform and the specific part of Oracle 10g that chokes on 
xsd:any, I'll look at it.

This is going to require me to rewind my own head since the last version 
of the Oracle DBMS I worked with is 11i and that was at least two years 
ago.

However, I advise caution with regard to suggesting a solution. The 
reason for caution is that xsd:any is the element we use when we want to 
allow implementers to "extend" a given schema, How that is done and what 
tools, databases or database management systems are used to do that is 
not something we can control or even affect much. I would say offhand 
that this is very much an implementation-specific problem for which, no 
matter how much we would prefer to be able to provide a solution from 
our end, we are necessarily forced to say "we didn't make this problem 
and we can't take responsibility for fixing it."

Having said that, I will still try if I can find the documentation for 
the Standard FEMA SOA platform and a more complete description of the 
specific problem.

Cheers,
Rex


Jacob Westfall wrote:
>> Here is the basic issue we have been having in building a CAP 1.2 implementation.  Your help is appreciated.  Neil recommends a change to CAP 1.2.  I am not sure we want to do that, but we sure do need to find a way to use the "Standard FEMA SOA platform" without having to hand code everything behind the WSDL.  So, suggestions are appreciated.
>>
>>     
>
> Neil's suggestion would entail creating Signature and EncryptedData elements as containers for the DSig and XMLEnc elements.  This of course would change the schema and the specification language, a substantive change, and require a 15 day public review.  I don't think this change, creating new elements, fits in the original scope for 1.2, but I had thought of creating a Security container for CAP 2.0 that could be used to hold not only the DSig and Encryption elements but other security related information for the CAP message.
>
> I have included an alternate schema that does not require these containers but also takes a different approach than the current use of 

To all,

I think that Jacob's solution would work perfectly for creating a CAP message with the needed values.  Not so sure it would work in middleware that needs to validate message with and without signatures.  The key for DM-OPEN is that it must accept and process any valid CAP 1.2 message and reject only invalid messages.  Neil can experiment though. Maybe he can make a solution based on Jacob's suggestion work, or maybe we can find another way.  My point is that there is an issue when we use less straightforward concepts like 

Team OASIS,

Next week Desktop Alert will publish a press release which will commemorate the OASIS Emergency Interoperability Demonstration at the recent TCIP Conference & Expo.

As all of the members are aware our company was tasked with the formidable task of deploying the first ever IP-Based nationwide mass notification system in U.S. Military history.

As a result of a DoD contractual mandate to our company, The U.S. National Guard and The U.S. National Guard are now proceeding with connecting to the Common Alerting Protocol Nationwide.

This is significant.

This means that as a result of the OASIS efforts over 146 National Guard locations and 88 Air National Guard locations across 54 states, territories and locations  (50 states, Guam, Puerto Rico and The Virgin Islands)  over 500,000+ Military End Users will now have access to actionable intelligence directly from CAP.

BLUF (Bottom Line Up Front)

We could not have done this without the support of OASIS.

Repeatedly, based on our intake of RFI and RFQ opportunities the bidder must provide a solution that is CAP Compliant.

As a company, we take heed of the fact that Desktop Alert is a relatively new member to the ORG.

While we all operate as independent vendors, we would like to include company statements from any of the OASIS vendors as well as DHS contributors to this release.

The nationwide integration of CAP by the National Guard and The Air National Guard will significantly bolster the accomplishments by the ORG and to that end, once again....we acknowledge that we are a recent entrant to OASIS and desire to include any statements or collateral from all contributors.

Here is a private link to the event with some of the Press Release Content:

http://www.desktopalert.net/index.php?option=com_content&view=article&id=141

The express intent and purpose of this email is to make sure all OASIS supporters are properly represented in the press release.

All feedback is encouraged prior to this release.

Regards,

Howard Ryan

Desktop Alert Inc.

Thanks Howard,

Sometimes we lose track of the good our work does. Its good to be reminded.

Cheers,
Rex

Howard Ryan wrote:
> Team OASIS,
>
> Next week Desktop Alert will publish a press release which will 
> commemorate the OASIS Emergency Interoperability Demonstration at the 
> recent TCIP Conference & Expo.
>
> As all of the members are aware our company was tasked with the 
> formidable task of deploying the first ever IP-Based nationwide mass 
> notification system in U.S. Military history.
>
> As a result of a DoD contractual mandate to our company, The U.S. 
> National Guard and The U.S. National Guard are now proceeding with 
> connecting to the Common Alerting Protocol Nationwide.
>
> This is significant.
>
> This means that as a result of the OASIS efforts over 146 National 
> Guard locations and 88 Air National Guard locations across 54 states, 
> territories and locations  (50 states, Guam, Puerto Rico and The 
> Virgin Islands)  over 500,000+ Military End Users will now have access 
> to actionable intelligence directly from CAP.
>
> BLUF (Bottom Line Up Front)
>
> We could not have done this without the support of OASIS.
>
> Repeatedly, based on our intake of RFI and RFQ opportunities the 
> bidder must provide a solution that is CAP Compliant.
>
> As a company, we take heed of the fact that Desktop Alert is a 
> relatively new member to the ORG.
>
> While we all operate as independent vendors, we would like to include 
> company statements from any of the OASIS vendors as well as DHS 
> contributors to this release.
>
> The nationwide integration of CAP by the National Guard and The Air 
> National Guard will significantly bolster the accomplishments by the 
> ORG and to that end, once again....we acknowledge that we are a recent 
> entrant to OASIS and desire to include any statements or collateral 
> from all contributors.
>
> Here is a private link to the event with some of the Press Release 
> Content:
>
> http://www.desktopalert.net/index.php?option=com_content&view=article&id=141 
> 

Rex,

Thanks so much and once again, feel free to make a statement contribution to the release.

Howard

On Sat, Feb 6, 2010 at 7:59 PM, Rex Brooks <rexb@starbourne.com> wrote:

Thanks Howard,


Sometimes we lose track of the good our work does. Its good to be reminded.


Cheers,

Rex


Howard Ryan wrote:


Team OASIS,


Next week Desktop Alert will publish a press release which will commemorate the OASIS Emergency Interoperability Demonstration at the recent TCIP Conference & Expo.


As all of the members are aware our company was tasked with the formidable task of deploying the first ever IP-Based nationwide mass notification system in U.S. Military history.


As a result of a DoD contractual mandate to our company, The U.S. National Guard and The U.S. National Guard are now proceeding with connecting to the Common Alerting Protocol Nationwide.


This is significant.


This means that as a result of the OASIS efforts over 146 National Guard locations and 88 Air National Guard locations across 54 states, territories and locations  (50 states, Guam, Puerto Rico and The Virgin Islands)  over 500,000+ Military End Users will now have access to actionable intelligence directly from CAP.


BLUF (Bottom Line Up Front)


We could not have done this without the support of OASIS.


Repeatedly, based on our intake of RFI and RFQ opportunities the bidder must provide a solution that is CAP Compliant.


As a company, we take heed of the fact that Desktop Alert is a relatively new member to the ORG.


While we all operate as independent vendors, we would like to include company statements from any of the OASIS vendors as well as DHS contributors to this release.


The nationwide integration of CAP by the National Guard and The Air National Guard will significantly bolster the accomplishments by the ORG and to that end, once again....we acknowledge that we are a recent entrant to OASIS and desire to include any statements or collateral from all contributors.


Here is a private link to the event with some of the Press Release Content:


http://www.desktopalert.net/index.php?option=com_content&view=article&id=141 <http://www.desktopalert.net/index.php?option=com_content&view=article&id=141>



The express intent and purpose of this email is to make sure all OASIS supporters are properly represented in the press release.


All feedback is encouraged prior to this release.


Regards,


Howard Ryan


Desktop Alert Inc.



--

Rex Brooks

President, CEO

Starbourne Communications Design

GeoAddress: 1361-A Addison

Berkeley, CA 94702

Tel: 510-898-0670





--
Regards,

Howard  Ryan
Founder and CEO
Desktop Alert Inc.
346 Main Street
Chatham, NJ 07928

1-973-727-0066 p
1-866-689-9838 f

www.desktopalert.net

Will do, Howard,

Cheers,
Rex

Howard Ryan wrote:
> Rex,
>
> Thanks so much and once again, feel free to make a statement 
> contribution to the release.
>
> Howard
>
> On Sat, Feb 6, 2010 at 7:59 PM, Rex Brooks 

All,  Thanks to everyone looking into this issue.  We do need to be 
prepared for questions as Gary suggests.  At our next EM-TC meeting, 
we will identify the best approach.  This does not appear to be a 
problem for which we need to hold up the CAP 1.2 process.  If you 
feel we should, please post a note to that affect right 
away.  Otherwise, I have asked OASIS Admin to begin the ballot for 
CS-Spec and OS-Standard.  The ballot will run for 7 days, and your 
vote can change during that period. Elysa

At 02:43 PM 2/6/2010, Gary Ham wrote:

>To all,
>
>I think that Jacob's solution would work perfectly for creating a 
>CAP message with the needed values.  Not so sure it would work in 
>middleware that needs to validate message with and without 
>signatures.  The key for DM-OPEN is that it must accept and process 
>any valid CAP 1.2 message and reject only invalid messages.  Neil 
>can experiment though. Maybe he can make a solution based on Jacob's 
>suggestion work, or maybe we can find another way.  My point is that 
>there is an issue when we use less straightforward concepts like 
>