- From: Assaf Arkin <arkin@intalio.com>
- Date: Mon, 05 May 2003 13:13:46 -0700
- To: jdart@tibco.com
- CC: Champion Mike <Mike.Champion@SoftwareAG-USA.com>, public-ws-chor@w3.org
Jon Dart wrote: > Assaf Arkin wrote: > > >> The rule I stand by is "what you don't need to expose should not be >> exposed. period". > > > This is a good general design principle, but there are cases where you > need to limit information and cases where you don't. If the > choreography involves only internal, non-sensitive systems, then each > can have complete information about the other, at least complete at > the level of what interfaces are used and how they interact (not > message contents, necessarily). I think the implementation should work in support of the choreography so the implementation can include any number of steps you need there, and the choregoraphy could include only those steps that are necessary to be exposed. So if you have to expose one or two steps you would do that as part of writing the choreography, but that does not include the implementation from having any number of steps that, not being part of the choreography, are simply not exposed even though they get executed. > >> I would not be interested in supporting a language that forces me to >> expose to any party how I happen to do things when I service their >> requests. Except in those case where I do need to expose that >> information for the benefit of these parties as agreed upon by all >> parties involves (in this case customer, rental agency, credit >> agency). My question is therefore how do I deal with those cases that >> do require some specific steps to be exposed in a controlled manner >> as dictated by the business scenario? > > > > > arkin > > This is related to the "central" vs. "participant-focused" modelling > issue that has periodically been discussed in this group (and which > has recently re-surfaced in ws-arch). > > If I have to employ a centralized model that includes all > participants, then IMO it becomes more difficult to "hide" > interactions from some subset of those participants. (I say more > difficult rather than impossible, because you could imagine a > technology that combined a central modelling facility with views into > the model). In my opinion there would be three different choreographies here. Choreography #1 would model the fact that some agent is issuing a credit request on behalf of the customer with some credit report agency and all future interactions possible between the customer and credit report agency. It would just include all those steps that are important for all three parties together (i.e. obtaining the credit rating by the agency is not modeled here). Choreography #2 would model the fact that some agent is issuing a credit request on behalf of the customer and how it obtains a credit report. It will contain a reusable subset from #1 but not encapsulate #1 in its entirety, and also include additional steps required to actually get the credit report and other relevant information (e.g. how many long a report remains effective). Choreogaphy #3 would cover the interaction between the customer and the agent and would also reference #1 as a reusable component that could be incorporate into any number of other choreographies. This would make it easier to agree on some reusable choreographies not particular to any specific industry and then incorporate them into choreographies specific to the industries. An implementation may have to participate in two different choreographies (#2 and #3 for the agent) but can easily determine what parts are overlapping if we have the proper referencing/inclusion mechanism. arkin > > --Jon >
Received on Monday, 5 May 2003 16:15:51 UTC