RE: [ebxml-cppa] ebMS 3.0 draft configuration examples.

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

Dale,

 

I concur with this.  We've implemented this approach - CPAid from messaging envelope - direct lookup and checking in the S2Sclient for NIH.  And as you note - for super high volume realtime systems only - caching in memory as needed of immediate first level checks - "is CPAid valid, is transaction permitted?"  Then downstream processes can check more as needed.  For typical usage though - database approach plenty fast enough.

 

BTW - in the context of SOA deployments - I'm seeing a huge potential role here for CPA beyond ebMS - as an abstraction layer definition contract of the service interchanges - whether those are ebMS, WSDL, WS-I or REST based...or even AS/2?!

 

If we believe we can meet this - or even get close with some initial default scenarios and templates - would be HUGE selling point for adoption into SOA.  Does not need to be perfect obviously - 80:20 rule more than adequate for the first cut at this.  The idea would be the CPA provides a consistent way to define the SOA interchange - even if more components - WSDL, WADL, SAML, etc offer discreet syntax specific customizations at the deployment layer - the CPA could point to those...

 

DW

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

-------- Original Message --------
Subject: RE: [ebxml-cppa] ebMS 3.0 draft configuration examples.
From: "Dale Moberg" <dmoberg@us.axway.com>
Date: Fri, July 13, 2007 11:33 am
To: "Pim van der Eijk" <pim.vandereijk@oasis-open.org>,  "OASIS ebXML
CPPA TC" <ebxml-cppa@lists.oasis-open.org>
Cc: <ebxml-msg@lists.oasis-open.org>

In case I don't make it tonight, some feedback on this:

 

1) In "docExchangeA1", the MEPBinding values should be "pull" instead of "push", right?

 

Yes, and the docExchangeB1 or B2 should match. Too much cut and paste apparently. I will correct today. Thanks Pim.

 

2) In ebMS3, access to messages by pulling is done only by MPC name, not by values for From and To PartyId. The example in ebMS3 CD-07, section 5.3.2 makes this clear as a pull signal does not contain a PartyInfo element, so it does not provide information about "who" is attempting to pull messages from "whom". Section 7.10 of ebMS3 defines a way to define authorization mechanisms for MPCs. 

 

- If an organization wants to use CPA to configure MPC channels to be polled by partners, do we need a restriction that a specific channel can only be pulled by one organization, or more precisely, can only be defined by one (active) CPA?   Otherwise the server from which messages are polled would need to inspect all active CPAs for the MPCs they define, to build an access list (e.g. usernames and passwords ) for each of the MPCs.

 

Dale>> I recall that the ability for several parties to pull from a given MPC queue, er, channel was requested and was justified by end user requirements having been given.

 

I think that authorization is the main gatekeeper to access on a MPC. Looking up CPAs would probably have to be keyed off of the authorization credentials. So I think that the use cases actually would mean that multiple CPAs may be associated with a given MPC. I understand your concern about checking CPAs but normally CPAs are stored in a RDB and various indices over the information support rapid access as needed (often with a runtime cache!)

 

- More an ebMS3 question perhaps: Thinking about this further, shouldn't the default ebMS3 MPC a partner pulls from be something like

"http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/PartyType/PartyId" rather than "http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/defaultMPC"?  

 

The specification currently has the value in the samples as the default MPC value. I will copy this response to the ebMS TC list to let them be aware of this comment. Certainly a community can organize itself around the convention you suggest.