OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebcore message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [emergency-if] Federating OASIS EDXL-DE routing capability with goal ofsupporting SOIS


David,

Catching up here on my email.

One thing that strikes me is the overlap between EDXL-DE and ebXML ebMS - and obviously there are reasons for this that I am aware of - and with 20:20 hindsight perhaps DE could have been implemented as a profile of ebMS - but there you go.

However - notice that the ebMS v3.0 is now progressing to OASIS standard vote.  So what is different in V3 compared to V2?

Specifically the distributed message routing handling has evolved based on field experience over the past three years with industry and government use particularly in the EU and Asia.

To your point that Sandia has been trying to solve this for 10 years now - there is some very sophisticated thought processes gone into ebMS v3 - way beyond what most folks normally encounter.  

These capabilities seem tailor made for the use case of emergency management and reliable information distribution across a grid.  Bear in mind EU has same need for its power grid to mention just one application.  And of course security and all that it entails too.

So what does this mean for DE?  First - I'd recommend an in-depth look at what ebMS v3 is doing.  There are many documents, examples, and of course the spec' itself.

One possibility would be to create a ebMS v3 profile for DE - which is indeed improved in V3 also.

If we look at the solution and deployment architecture here this may not be what at first you would imagine.

Let's walk this through for now to get a sense of what the landscape looks like.

Scenario A - todays DE world + add V3 style distributed delivery feature set.

- Network nodes that support DE distributed delivery would need to be deployed.
- Old point-to-point DE systems would talk to those nodes

Result you have a 2-tier infrastructure

Scenario B - todays DE world + ebMS v3 layer for distributed delivery + DE profile

- Deploy ebMS V3 network nodes
- Old point-to-point DE systems talk to ebMS via profile
- ebMS V3 provides distributed delivery

Result you have a 2-tier infrastructure

So what are the differences?  Well less specification work and the fact that ebMS v3 is available already in both OSS and COTS.  Second - I suspect that ebMS V3 already has built-in capability to bridge between DE systems and mitigate the capability profiles - because its already doing that with WSDL SOAP point-to-point systems.

The nice thing is that in B - you get to retain your existing DE based infrastructure - but provide a new distributed layer seamlessly under that - to provide the added functionality you desire.

I've CC:d the ebCORE team for the gurus there to provide feedback - and sanity check what I'm seeing as the possibilities.  Perhaps what would make sense - assuming there is agreement - to have a joint technical discussion on a call - to walk through the possibilities?

I hate to see us re-invent the wheel - especially when it is an OASIS wheel!

Thanks, DW

-------- Original Message --------
Subject: [emergency-if] Federating OASIS EDXL-DE routing capability
with goal of supporting SOIS
From: "David E. Ellis" <dellis@sandia.gov>
Date: Wed, June 30, 2010 3:29 pm
To: jeff.waters@navy.mil, "'Hans Jespersen'"
<Hans.Jespersen@SolaceSystems.com>, emergency-if@lists.oasis-open.org
Cc: "'Rondeau, Daniel M'" <dmronde@sandia.gov>, "'Sanzero, George'"
<gsanzer@sandia.gov>, "'Oien, Chuck'" <ctoien@sandia.gov>

Jeff, Hans, EM TC Infrastructure subcommittee;
I am trying to position the OASIS EDXL-DE standard as one of the capabilities for supporting the Strategic Operations Information Sharing (Google for current public info).  This will support federal agencies sharing all types of information sharing use to support Commanders Critical Information Requirements (CCIRs) and Essential Elements of Information (EEIs) in times of emergencies.  Since most of the Federal planning scenarios began locally, the discussions of how to federate various information collection and sharing capabilities is becoming more critical.
I represent USNORTHCOM as a Subject Matter Expert supporting creating SOIS planning and capability development.  This requires me to examine the trends of emerging Standards development and attempt to create understanding within these bodies about SOIS requirements to federate federal, state, local and tribal information sharing resources.  This is why I have such an interest in federating capability from all OASIS EDXL-DE distribution capabilities and strive to ensure OASIS EDXL-DE messages met sensitivity and repudiation requirements for consolidation and up channel reporting to federal agencies.
Sandia National Laboratories has been working on this for over ten years.  This began for DTRA before 9/11 and DHS/USNORTHCOM were formed.  We have been using a commercial product for over seven years to prototype TSG and SPOR technology which use the OASIS EDXL-DE.  This was used in developing the First OASIS EDXL-DE specification.  During this time we have interfaced with DMIS, DTRA HPAC/Ensco, and all of the CWID 2005 participants.  Later we supported IPAWS development and interfaced MyStateUSA, Warning Systems, and many other information injection and subscriber capability.  Currently we are supporting operation deployment of DNDO AIR and other DoD programs.  The current Sandia deployments of OASIS EDXL-DE routing capabilities do not have requirements to share information with many capabilities like IPAWS Open, EAS and CMAS systems, HPAC etc.  Therefore; in our systems, if we would receive an OASIS EDXL-DE message with an IPAWS profile or IPAWS OPEN COGS, our system would check for EDXL-DE schema compliance using CAM and ignore attempting to process elements.
The bottom line is even if you receive a valid OASIS EDXL-DE message there should be no immediate requirement to execute deliver specified by these elements for this message to some EDXL-DE routing capability which can process it.  That said, ultimately it would be ideal to have a federation of EDXL-DE routing systems which could support an ever increasing set of capabilities.  The Internet took years to build and continues to evolve (e.g. IP V6, secure DNS).  Therefore, we need to focus on the practices and/or methods of building capability which will migrate to ubiquitous information sharing interoperability.
Every constituency should be encouraged to choose the type of OASIS EDXL-DE capability which meets their operational needs.
David E. Ellis
(505) 844-6697


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]