Bryan,

This really extends the work done on the S2Sclient at NIH (you can download that ZIP and the documentation here: [1]http://era.nih.gov/ElectronicReceipt/system.htm ). Currently I'm investigating using OrionMSG to extend that - here's the list of features from S2Sclient appliance right now - plus extra list that OrionMSG brings.

S2Sclient feature set: 1) Desktop integration - send / receive folders - works on both Windows and *nix. 2) Self-install package 3) Data handlers that are configurable to pre-set payload types 4) CPA support - allows management of partners, CPAid and endpoint URLs 5) Digital Certificate use 6) SSL configuration 7) Pre-configured Tomcat and DerbyDB 8) Documentation for installation and developer guide.

with OrionMSG - this list extends to include

9) jCAM built-in for easy scripting and validation configuration 10) xslt for form generation for desktop use - jCAM provides easy integration 11) Better platform support including OS X 12) Python installation scripting 13) Extended api for data handler configuration 14) Open license SQL DB for persistence 15) Better message dashboarding for management / control

My experience is that xsd just gets in the way mostly. People prefer some sample XML transactions for their application area + CAM templates that allow them to run and inspect the rules and validations locally as they develop their message sets. The cross-field dependencies are especially important during testing.

At NIH we obviously setup the data handlers and XML samples for the S2Sclient - to work with the eReceipts system for service providers. So it works out-the-box for common functions.

I think using the OrionMSG approach we'll be more easily able to create domain packs that plug-in to the base installation. The domain pack will include:

1) Documentation for domain use cases 2) CAM templates and sample XML transactions 3) xslt for form transformations of inbound content 4) data handlers for message integration 5) Sample CPA for testing / basic setup 6) Form to request official CPA and submit optional certificate 7) Self-certificate build toolkit

The S2Sclient already includes 4 thru 7 while 1 thru 3 can be easily done using existing jCAM tools.

As I noted - we've got a tremendous way forward already in the NIH S2Sclient implementation - I'm hoping to extend and expand on this in 2007.

Thanks, DW

"The way to be is to do" - Confucius (551-472 B.C.)

-------- Original Message -------- Subject: [ebxml-dev] ebxml virtual appliance From: "Bryan Rasmussen" <BR...@itst.dk> Date: Thu, March 15, 2007 7:12 am To: "Ebxml-dev" <ebxm...@lists.ebxml.org>

Hi, I just sent off a question to XML-dev asking for wishes for XML virtual appliances

to-whit "What requirements should one have for an XML virtual appliance http://www.vmware.com/vmtn/appliances/directory/cat/44

What OS should it run (thinking Ubuntu) What tools should be configured and set up. What presets should there be. What protocols and presets might be useful.

what tools not yet built should there be integrated (these probably prerolled scripts, for example a script for checking directory of instances against range of Schema processors etc.)

I figure:

XSV, Schema Quality Checker, Sun's multi schema checker Saxon Exist

A repository of schemas? "

Thinking of that repository of schemas made me think, what about an Ebxml virtual appliance.

Cheers, Bryan Rasmussen

References

Visible links 1. http://era.nih.gov/ElectronicReceipt/system.htm