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.
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
On Oct 24, 2012, at 19:21 , Roger Bass wrote:
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?
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.
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
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
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
Sent: Wednesday, October 24, 2012 9:20
To: firstname.lastname@example.org; 'Sander Fieten'; 'Dale
Connect protocol questions
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