Re: Combining Policies (was RE: Partial executability/ determinism of a Chor description language

Dear All,

I have been following all the very interesting discussions and work 
going on in this group for sometime and if time permitted I would have 
joined.

The reason I jump in here is that Im leading a effort within UN/CEFACT 
to look a agreements and contracts in a project called Unified Business 
Agreements and Contracts , UBAC for short. In UBAC we approach 
electronic collaborations from an agreement point of view, i.e. how do 
we make global business level agreements electronically interpretable 
and integrated with varous mechanisms for business collaborations / 
choreographies ?

When reading Davids email I realized that we are touching the same 
problematic areas and It may be if interest to you to know that we 
exists and were working on the border of profiling business realtionships.

I have attached a contribution from EDIFICE / RosettaNet / ESIA/EECA 
that shows a way to legally organize business relations. The UBAC 
project is also going to work with business level artifacts such as 
commitments, fulfillments of for example payment, delivery.

Best Regards
/anders w. tell

Burdett, David wrote:

>>>>But if the policy cannot reference the choreography then it becomes a 
>>>>        
>>>>
>useless policy. In case of doubt, I am not saying that the choreography 
>should reference the policy, but that the policy should reference the 
>choreography.<<<
>
>This type of issue the tip of a HUGE iceberg, specifically how do you
>combine things together. Now this is not, IMO, part of the discussion for
>this group, but to get flexibility in automated systems that is comparable
>to that which humans can provide, there is a lot of work to be done. To
>illustrate lets take a few examples of the combinations that you might need
>to consider in order to make a decision on what to do ...
>1. Choreographies are only allowed if the messages are digitally signed.
>2. Business Partners require that messages are digitally signed.
>3. A partner requires that the messages sent to some, but not all, of the
>services they offer are digitally signed.
>4. Repeat the above with some combination of reliable messaging protocol
>(you can chose your flavor)
>5. Repeat the above with different message formats depending on the location
>in which they are being used, for example you need VAT in europe and sales
>tax in the US.
>
>... and I haven't even started to consider some of the policy decisions you
>mentioned earlier such as whether or not international orders are accepted.
>
>If you think about the number of possible combinations or matches you would
>have to make in order to realize interoperability is effectively infinite.
>This means that:
>1. You can't test them all - there are too many
>2. The SME's won't implement them all - they can't afford to.
>
>The only way out of this is to define profiles of sets of accepted standards
>and policies that apply - unfortunately no one is working on this ... yet.
>
>David
>
>-----Original Message-----
>From: Assaf Arkin [mailto:arkin@intalio.com]
>Sent: Friday, May 30, 2003 2:17 PM
>To: Burdett, David
>Cc: Ricky Ho; Yaron Y. Goland; public-ws-chor@w3.org
>Subject: Re: Partial executability/ determinism of a Chor description
>language
>
>
>Burdett, David wrote:
>
>  
>
>><DB>I think it more likely that the policies will most often apply to 
>>services rather than choreographies. For example the "no international 
>>orders" policy could apply to *all* orders. The actual choreography 
>>used to place the order is irrelevant.</DB>
>>
>>    
>>
>That's precisely my point. I want to find specific services based on the 
>policy. For example, if the policy says "no international order" and 
>some service says "I use this policy" and "My country != US", then I 
>would not bother using that service.
>
>  
>
>><DB>Yes there is. But it is only really relevant to your internal 
>>business process (or orchestration) rather than to the choreography 
>>because ultimately only the sender of the order and nobody but the 
>>sender of the order can decide whether or not to send the order - it's 
>>a private process.</DB>
>>
>>    
>>
>Let's say that I find a service. I find a policy. There is no 
>association between the policy and the choreography. Finding the policy 
>is as useful as knowing that the service definition was created on a 
>Sunday afternoon.
>
>But if there is some way for me to determine that the service would 
>apply the policy as part of the chorography, then MY implementation can 
>do a lot of interesting things, like favoring or avoiding that 
>particular service. Of course it's only relevant to my internal 
>implementation, and if my internal implementation never evaluates the 
>policy it would still be acting based on the choreography. Which is 
>something I don't belive we've refuted so far.
>
>But if the policy cannot reference the choreography then it becomes a 
>useless policy. In case of doubt, I am not saying that the choreography 
>should reference the policy, but that the policy should reference the 
>choreography.
>
>arkin
>
>  
>
>>arkin
>>
>>    
>>
>
>
>  
>