RE: [ebxml-cppa] Agenda August 11 2006 OASIS ebXML CPPA 8 AM PDT Teleconference

["David RR Webber \(XML\)" <david@drrw.info>]

Sacha,

 

Actually these are good questions - and the answers relate to the typical government installation and operational rules (also applies to any large company / institution).

 

1) The government wants to adopt a standard for CPA information - not create its own database layout (they have slews of those already!)

 

2) Operationally its a challenge to update the database content - requiring approvals and sign-offs that can take days.  Just ftp'ing files to a sub-directory is much less intrusive.

 

3) Forget sending the government your CPA - they are going to dictate to you what the CPA is and the transactions to use and issue it for you!

 

4) Even if you store the CPA's XML in the database you still have all the same issues.  I'd rather trust the operational staff to update just singleton files and CPA-lets - then have them run global updates against a database - where one fat fingered letter or additional space character can bring my whole system down - and I have no idea why!

 

So what I'm trying to do here is marry the operational needs to the ability to use CPA's in a simple and intuitive way.

 

I don't think these issues are unique to big sites and government though.  The easier you can make using CPAs - the more people can build their communications around them.  Fact is manually editing / verifying a CPA today is almost impossible.

 

In the ebXML model where you share CPAs its critical that this be easy to do.

 

In my case - we've packaged the ebMS toolkit - so its quick and easy to install.  Then people fill out a form with their setup details, URL, company - and we generate a CPA for them - and then they copy that to their setup and begin communicating with us.

 

I really want that CPA we send them to be a CPA-let - very simple if they open it - to understand - and also to be the exact same CPA-let that we use to config their access on our system.  Clean, clear, simple.

 

Notice - I cannot send them my database, eh? ; -)

 

DW

-------- Original Message --------
Subject: RE: [ebxml-cppa] Agenda August 11 2006 OASIS ebXML CPPA 8 AM
PDT Teleconference
From: Sacha Schlegel <sacha@schlegel.li>
Date: Fri, August 11, 2006 9:16 am
To: "David RR Webber (XML)" <david@drrw.info>
Cc: Dale Moberg <dmoberg@us.axway.com>, OASIS ebXML CPPA TC
<ebxml-cppa@lists.oasis-open.org>

Hi David

At one point in time I came across the following CPA management mantra:

"Don't manage the CPA's but manage the information in the CPA to always
be able to generate a CPA (or a new version of the CPA for that
matter).".

Would this make sense to you?

Also what I found out was that I was thinking to much that I provide the
CPA to my trading partner .... but we also have to deal with the
situation where I get a CPA from a trading partner.

Once you accept that someone can give you the CPA ... you kind of have
to do a reverse setup of your CPA configuration (if you follow the
approach not manage CPA's but the information inside them). Eg you have
this sophisticated trading partner management system (supports CPA's)
but a trading partner insists to use the CPA's SHE/HE generates then
your system has to be able to cope with that.

An alternative I keep thinking of is:

Have your CPA's stored in a XML database where you can run XML work,
such as XQueries ... this would still be possible if an ebXML registry
supports an underlying XML database (eg something along the lines of
Raining Data's freebxml Registry plugin).

Even if you have your CPA's stored in a XML database ... you are still
in no position to update/change CPA's ... you still need that logic
somewhere outside of the database ... this leads back to the mantra
above.

Somehow all these questions are rather implementation questions, aren't
they?

Sacha


On Fri, 2006-08-11 at 05:11 -0700, David RR Webber (XML) wrote:
> Dale,
>  
> I've been working on ideas for templating CPA to permit easier
> management of wide community of partners and multiple backend delivery
> systems thru a common frontend secure gateway.
>  
> What I'm focusing on right now is having a single "master" template
> CPA - and then cut-down sparse CPA-lets that just have the core
> elements needed for partner control - but rest of parameters assumed
> to default to the master template settings.
>  
> This means the CPA-let can have just a few lines in it - and also use
> <include "..."/> to pull in things like the message types - so I can
> just edit that in one place - not for every instance of the CPA-lets I
> have out there "somewhere".
>  
> Some of the challenges I'm looking to address this way:
>  
> 1) If I have couple of hundred partners - and I add a new message type
> - how do I avoid having to edit every single one of those CPAs?
>  
> 2) I want to have production and stage routing through my front end
> delivery gateway - based on message type - again how do I simplify
> switching a partner from stage to production?  How does the message
> gateway know to route in-bound message to stage or production - just
> based on CPA-id in envelope?
>  
> 3) I basically want very simply operational configuration - where the
> incoming CPA-ID from the ebMS envelope is used to look for a file -
> CPA-[cpa-id value].xml - that is written as a CPA-let in sparse syntax
> - opens that up - verifies the interchange details, end point URLs.
> For the main operational parameters the ebMS uses the CPA master
> template for all the comm's settings, etc, and the CPA-let can
> reference that master template CPA.
>  
> 4) Masking the internal delivery details from the CPA-let - so I can
> share the CPA-let widely - its still completely secure and tamper
> resistant for each partner - and the one format works both internally
> and externally - simplifies support and means the help-desk staff can
> issue and control the CPA-let directly.
>  
> 5) Create groups of message sets by process - and hence create one of
> those templates per process - and just have the CPA-lets include that
> one definition -by role and context - so for example I could have a
> "shipper" process group - with messages for handling shipping and
> delivery.
>  
> I'm hoping this is not too radical a departure - and that the CPA-let
> XSD is just a sub-set of the main CPA XSD - so it can be derived
> without having to re-invent anything.
>  
> Thoughts?
>  
> Thanks, DW
>
>  
>
>
>         -------- Original Message --------
>         Subject: [ebxml-cppa] Agenda August 11 2006 OASIS ebXML CPPA 8
>         AM PDT
>         Teleconference
>         From: "Dale Moberg" <dmoberg@us.axway.com>
>         Date: Thu, August 10, 2006 4:43 pm
>         To: "OASIS ebXML CPPA TC" <ebxml-cppa@lists.oasis-open.org>
>        
>         Remember that there are NEW numbers!!!
>        
>          
>        
>         866 383 5205
>        
>         732 694 1566 (for international callers)
>        
>          
>        
>         144286# is the conference participant pin
>        
>          
>        
>          
>        
>         Agenda
>        
>          
>        
>         1 Still awaiting ebMS 3.0
>        
>          
>        
>             P-Mode - table / adjunct
>        
>             MEP Mappings
>        
>          
>        
>         2. Updates on CPA template, NDD, and WS for “negotiation” if
>         Pim is present.
>        
>          
>        
>         3. Proposals for new substitution choices for DocExchange.
>         Should DocExchange allow _any_ substitution particles?
>        
>          
>        
>         4. Any other items from TC.
>        
>          
>        
>          
>        
>          
>        
>          
>        
>