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

I understand what you say, I don't understand how it relates to what I 
have said.

Here's a case in point. On-line banking. All messages digitially signed, 
sent over RM, for all message formats ever used. Mandated by banks, 
FDIC, the Global Domination ATM Network, or whoever. Doesn't matter. 
There is no complexity in reach agreement it's a done deal.

The bank also have policies that apply to specific accounts which may be 
FDIC, bank-specific, IRS, BBB whatever. I don't care how expensive it is 
to define these rules because the rules would be defined regardless of 
which technology we use. In fact, they are already defined. And I don't 
care how expensive it is to reach agreement with a million customers 
because the bank simply publishes it's rules - take it or leave it - and 
does not try to reach agreement. And I don't care if UDDI is trusted or 
not, because the bank already has mechanisms to make it available 
securely from a trusted source.

But, I know that some rules are different from bank to bank (e.g. the 
cost of a returned check) and some rules are different from account to 
account within the same bank (e.g. the cost of an overdraft withdrawl). 
And given that the rules are already there, I can select which account 
to use when/where, if I only know which rules apply to which operation I 
am about to perform.

So yes, there is complexity in the world and we haven't solved it. And 
it applies in a lot of cases that like it or not will not be able to use 
the capbilities we are discussing right now because they already have 
too many problems reaching agreement. And any solution to that problem 
is outside of this working group.

But there are too many use cases where it's simply not-a-problem. It's 
not a problem to reach agreement, and it's not a problem to have an 
unreadable 32-page booklet listing all these rules and policies. So now 
the question is - since as you said the technology is already there - 
can we capitalize on that? If my bank already has a 32-page booklet with 
rules and regulations, can I just expose some of them as part of it's 
Web service definition?

arkin


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
>

Received on Friday, 30 May 2003 18:29:49 UTC