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


Help: OASIS Mailing Lists Help | MarkMail Help

bdxr message

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

Subject: RE: [bdxr] Re: Connect protocol questions

I had not yet replied to Roger's question on my #4.   It relates to a distinction between connecting and exchanging business documents, both of which may rely on service providers,  not necessarily the same service providers (e.g. one service provider may offer connecting services, and another may offer e-invoice exchange services).
Suppose trading partners X and Y have become "connected" (exact mechanism to be specified).   
Suppose Y's partner profile has a delegation to service provider Z.  I.e. Y is sending messages from Z,  and receiving messages at Z.
If the connection is established in a way that does not involve Z (e.g. if there is a bilateral exchange between X and Y,  or via some service provider other than Z),  then Z may need to be informed that X may send messages to it that are addressed to Y.    E.g. if Z a white list of trading partners for each of its customers,  then if a customer wants to receive messages from new partners not yet on the white list, then the white list needs to be updated.  The point #4 is making is that this could be done by Y sharing information on the "connection" with Z.    How that is done could be proprietary to the service provider,  but if the connection is expressed as an XML document (e.g. X's CPP or SMP,  or an X-Y CPA), then Y could submit that XML document with Z. 



On Oct 24, 2012, at 19:21 , Roger Bass wrote:

Pim et al,
Thanks for your comments.  I’ve cc’d Kenneth here too… and wonder if emails like this shouldn’t even go to the full BDXR list, despite the fact that it’s just a few of us who would be paying close attention?
Thinking about the ‘Connect Service’ as just another service does seem clearer.  And as you say, it’s important that we show how the two models (with and without ‘Connect’) can coexist.
As we refine our picture of the architecture and system components, it seems to me some care is required in focusing on the “what” of various architectural components, or service roles, and not confusing them with the “who” of their deployment across different entities.  To that point, our use of the term “Provider” at all seems to me somewhat problematic, falling more into the “who” category.  More specifically Pim, in your #4, if “Service Providers can also have a service that customers can push partner CPPs or CPAs to…“, regardless of who operates it, is that not perhaps just a simpler case of the Connect Service, just one that doesn’t implement the full handshake and authentication/authorization process?
I’m still struggling with a lack of clarity and precision in some terms we’re using here.  I’ll send some more thoughts/proposals once I have this a little clearer in my own mind.
From: Pim van der Eijk [mailto:pvde@sonnenglanz.net] 
Sent: Wednesday, October 24, 2012 9:20 AM
To: roger@traxian.com; 'Sander Fieten'; 'Dale Moberg'
Subject: RE: Connect protocol questions
 4)  Once X and Y are connected for some service S (e.g. Invoicing), they need to inform any service providers they use for S about the established connection.  This is not necessary when the Connect Service and the "S" Service are the same (as in the diagram),  and we don't need to specify it as it does not have to be a standard mechanism.  But Service Providers can also have a service that customers can push partner CPPs or CPAs to, to have them added to their trading partner configuration.

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