Re: internal vs external

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