To all, I think we indeed need to have a clear understanding of the components that we envision in a four corner architecture. Without such a clear understanding I find it difficult to specify which services should be provided and how that should or can be done. I think this would also answer some questions below on how a Connect Protocol should be seen. I made some Archimate diagrams on what I think could be the components in a four corner architecture, see figure below. This is based on my interpretation of our discussions both on line and off line in Vienna. The blue boxes show which Business Roles there are in the four corner model and the yellow ones show the services they provide. I just showed the basic services needed to establish a message exchange. This is certainly not a complete picture of all service to provide! By talking about Business Roles I do not express anything on the actual party that will act in a certain role. This allows for specifying services based on the requirements we see for each role. When using this model in the real world roles can be mapped to actual parties. In a pure four corner model each role could be executed by a separate entity, like in the figure below. But when trading partner Y will do (part of) its messaging itself it might look like this, which is three corner model: Because the roles and services are the same in both mappings nothing changes for Service Provider W. As said the above figures are just my interpretation, I think we should as a TC define which components/roles we need in a four corner model. Then we can discuss which services these components should provide (the what) and then the options on how to implement these services. Regards, Sander 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. Roger 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 Hello Roger and Sander, A few comments (not addressing all the points you are making): 1) A Trading Partner can use multiple service providers, and can host some services itself (from its own endpoint). So from a MDS document, there could be pointers to various endpoints, or (in the model proposed last week) delegations to other MDS documents. 2) Connect is a service like other services, so I think we could talk about a Connect Service Provider , just as there are service providers for HR, invoicing etc. X and Y can handle Connect messages directly or outsource it. 3) The input to a Connect request could indeed be a CPP, which identifies the Business Process, roles and bindings (possibly by delegation). We could define the protocol so that if the requestor does not provide a CPP in the request, it is interpreted as a request to get a list of all services that the connectee is willing to engage in with the connector. We also need a ConnectException of similar document to report failure or refusal to connect. The response could be Y's CPP or a CPA. 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. 5) If Connect is a service like any service, the SMD can publish a simple CPP for X that just tells people how to send Connect messages to X. The CPP will tell potential partners where to send there requests (to X directly, or to a service provider). The CPP can also (PEPPOL-style) publish other service capabilities for which no Connect is necessary. I think it is important that we show that both models (with or without Connect) can co-exist easily. 6) If the SMD expresses the Connect Send capability, anyone that receives a connect request from a Connect Service Provider claiming to act on behalf of X can look up X's metadata to see if X has indeed outsourced its Connect Service to that provider. That adds an additional safeguard not present in PEPPOL. 7) One of the benefits of a four-corner model is that end entities could leave the authentication to Connect Service Providers, which have Interconnect Agreements that require them to authenticate their customers. Y can process X's connection request trusting that its identity has been validated. Pim From: Roger Bass [ mailto:
roger@traxian.com ] Sent: 24 October 2012 08:58 To: 'Sander Fieten'; Dale Moberg Cc: 'Pim van der Eijk' Subject: RE: Connect protocol questions Sander, (and Dale, Pim, FYI), Thanks for doing this. Your diagram is quite helpful, though it raises some questions for me – see #3 below. Could you perhaps send the source file of the diagram? In answer to your questions, some of my thoughts below. Happy to discuss further via email or phone. I’ve numbered and summarized your questions for easier reference. Dale: I’ve pulled out from the text here and summarized at the bottom a list of the various entities/system components that we might separately identify from this whole process. Talk to you tomorrow morning. Best, Roger 1. Multiple SMD formats? One format in this domain seems simplest; we could address support for others as and when real use cases arise. Two possible use cases for other formats occur to me conceptually (PEPPOL backward-compatibility; and Intercloud convergence, i.e. network level, IEEE P2302), but I doubt they’re worth thinking about at this stage. 2. Default format? Pim’s proposal makes sense to me as well. 3. Profile Exchange Data Flows . How to specify a business process in a Connect request? How and when should that, and the full service binding metadata be exchanged? It seems to me this comes down to questions of: a. What architecture, i.e. what entities/services are actually involved in performing the handshake, and b. How many steps there are in that ‘handshake’? In particular, do we need separate: i. BP and Service Binding messages? ii. ‘Get MD’ and ‘Connect’ messages? (not addressed here, will revisit later) a) Regarding architecture, in this ‘Connect Protocol’ context, I wonder whether the MDS/MDSL architecture should be symmetrical or asymmetrical? In other words: is a Connect Service (i.e. a Connect-protocol-compliant MDS) invoked by a SP? Or does the invoking TP/SP just trigger a handshake between the parties’ respective Connect Services (MDSs)? I’m inclined to think perhaps the latter – which might mean we need to consider and show an MDS for each party, and perhaps even an MDSL each too, even though both parties might use the same services in typical early cases. (We might also need a MDSL ‘Root’, but let’s set that aside for now). I’m also thinking the ‘Connect Services’ (MDSs) might be entirely responsible for the setup of connections between the two SPs, i.e. SPs just communicate with one another for the exchange of transactions, not the setup messages. b) i. Regarding handshakes, Pim (and Dale) have done some preliminary work before re CPPA Negotiation, which can in theory get quite complex. It seems to me, however, best to start out defining the simplest scenario we can initially, with the fewest steps. We can always consider advanced cases later. But the architecture question comes first. If TP X’s SP initiates the handshake directly, then why not just send the technical (i.e. service binding) content as well for the requested BP? Let’s define some terms here: Service Metadata (SMD) = BPMD + Service Binding MD (SBMD). If however, a separate MDS X for TP X is involved, then the message with SBMD would come from MDS X in response to some other message, which might be just a request specifying a BP (i.e. BPMD). In fact, I can see a couple of different use cases here, which was sort of the intent in 41 and 42, but needs spelling out in further detail. Specifically, we have: a. SP X invokes MDS X with BPMD -> MDS X sends a request Get SMD(SMD(X),Y) to MDS Y b. TP X invokes MDS * Y * (e.g. by clicking an email link) -> MDS Y becomes the requester, via a MDSL lookup of X (email address? Other id) b) ii. Your diagram doesn’t seem to say whether the ‘Get Metadata’ message would always need to be there. Seems to me it doesn’t. In many cases, a requester could just send a ‘ConnectToService Message’ directly, including SMD(X) as above, sufficient for Y to respond. 4. Authentication : specifically, how does Y (and their SP/MDS) authenticate X (and their SP/MDS)? You didn’t ask this, but I’ll address it anyway. a) If TP X does indeed have its own MDS, accessible via a MDSL lookup, then that potentially provides an authentication mechanism. Indeed, this seems to me one major potential benefit of having a “symmetrical” handshake between two MDSs / Connect Services. b) If TP X’s MDS does not exist, or is not known, the clicking of an email link (as in 3b above) at least authenticates ownership of that email. 5. Authorization : what processes are required for authorization, as between the MDS Y, SP Y and TP Y? Central to the process here, I think, is a notion of matching to the set of Internal Partner Identities. When you talk about “requesting authorization”, and showing the arrow to the SP, I think you’re really talking about a lookup to this table via some automated process. Or alternatively, there could be a human/email-based process (arrow to TP). I would see this table as being a key component of a Connect Service (MDS). It could be considered internal, but it might make sense to call this out as a separate system component. Not least, I’m thinking it’s just possible that the model for looking up * EXTERNAL * identities in the MDSL might have some relevance for looking up / matching with * INTERNAL * identities as well. Or if not, it could be considered an internal MDS implementation issue, and so out-of-scope here. It’s quite possible that the MDS and SP have some connection or process configured (out-of-band) to populate that internal identity store, either automatically or on some batch basis. (It seems sort of like “Local Service Metadata” as compared with the external “Service Metadata”… but the “Service” notion doesn’t seem quite right here… Local Metadata maybe?). In case of a match after receipt of a ConnectToService request, the user’s (i.e. TP Y’s) account settings on the MDS/SP would determine the behavior, e.g. always email to ask, approve automatically and notify, approve automatically and don’t notify. In the case where there isn’t a match (including cases where no Local Partner Metadata is accessible), then an email would need to be sent to TP Y for approval, much as happens today in the social network ‘friend request’ scenario. SUMMARY OF SYSTEMS/SERVICES For each party, X and Y, we have, potentially: · The Trading Partner or Organization themselves · Service Provider (for exchange of business transactions, but not Connect/Setup/Metadata documents) · Metadata Service (MDS), aka Connect Service · Metadata Service Locator (MDSL) · Local Metadata Service (i.e. Trading Partner Identity / Attribute Store)… still not quite the right term We also potentially have some MDSL Root system, analogous to the DNS Root. From: Sander Fieten [ mailto:
sander@fieten-it.com ] Sent: Monday, October 22, 2012 1:05 PM To:
roger@traxian.com Subject: Connect protocol questions Hi Roger, I did some work on the Connect protocol for BDXR. During the face-to-face in Vienna we drew up a sequence diagram showing what the Connect protocol might look like. The converted blackboard drawing is shown below. The green lines indicate messages part of the Connect protocol. <image001.png> The first step in the Connect protocol is (or should be) the registration of service meta-data (SMD) in the MDS (Meta-data service). Here the first questions comes to mind: Should we support multiple format for describing SMD? When not, what should be the standard format? I think the format Pim described in his post last week would be a good candidate. Next step in the Connect protocol is a trading partner wanting to connect to another trading partner. In Vienna we discussed a very generic principle that the partner should supply some information about the business process (BP) for which he wants to connect. The generality makes the Connect very flexible, but raises the question how this BP information should be supplied. In the UC document it is stated that the partner should or may supply a Partner Collaboration Profile. This however seems to be on a more technical level already than just some BP information. Is that understanding correct? Would simplify the number of information structures to communicate. Last question is on authorization. The figure shows four red lines marked with '?' which represent the request for authorization of connecting trading partner (in this case X). The question here was whether this should be checked on every connect request or if it should be uploaded with the registration of the SMD. I would say it should be asked on every request, otherwise the MDS gets to complex. Whether the SP should ask it the TP each time is up to them as we do not specify anything on that relation. I am looking forward to hear your thoughts on this. Regards Sander ---- Sander Fieten Solutions architect FIETEN IT e:
sander@fieten-it.com t: +31 6 51507886 ---- Sander Fieten Solutions architect FIETEN IT e:
sander@fieten-it.com t: +31 6 51507886