OASIS Emergency Management TC

  • 1.  Fwd: CAPv1.2 Web-Service Implementation Challenges

    Posted 02-05-2010 21:15
    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
    703-899-6241





  • 2.  Re: [emergency] Fwd: CAPv1.2 Web-Service Implementation Challenges

    Posted 02-05-2010 21:54
    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" 


  • 3.  Re: [emergency] Fwd: CAPv1.2 Web-Service Implementation Challenges

    Posted 02-06-2010 01:32
    > 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 


  • 4.  Re: [emergency] Fwd: CAPv1.2 Web-Service Implementation Challenges

    Posted 02-06-2010 20:28
    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 


  • 5.  Re: [emergency] Fwd: CAPv1.2 Web-Service Implementation Challenges

    Posted 02-06-2010 20:46
    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 


  • 6.  Re: [emergency] Fwd: CAPv1.2 Web-Service Implementation Challenges

    Posted 02-06-2010 23:02
    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.


  • 7.  Re: [emergency] Fwd: CAPv1.2 Web-Service Implementation Challenges

    Posted 02-07-2010 01:00
    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 
    > 


  • 8.  Re: [emergency] Fwd: CAPv1.2 Web-Service Implementation Challenges

    Posted 02-07-2010 16:41
    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


  • 9.  Re: [emergency] Fwd: CAPv1.2 Web-Service Implementation Challenges

    Posted 02-07-2010 20:12
    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 


  • 10.  Re: [emergency] Fwd: CAPv1.2 Web-Service Implementation Challenges

    Posted 02-08-2010 22:25
    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 
    >