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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

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


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


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.
>
>
>
>
>
>
>
>
>
>



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