RE: Combining Policies (was RE: Partial executability/ determinis m of a Chor description language

Assaf

See comments in line.

David

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Friday, May 30, 2003 3:26 PM
To: Burdett, David
Cc: Ricky Ho; Yaron Y. Goland; public-ws-chor@w3.org
Subject: 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.
<DB>It's only a done deal because: a) there are dominant networks like Visa
and Mastercard that can make it work, and b) they have been working on it
for decades. The issue is that for Web Services, right now, there is no
"done deal" and it will be some time before it gets there. This means, that
we should start thiking about what it takes to help the "deal get done
faster".</DB>

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.
<DB>People can always make the decision on which service (e.g. a bank
account) to use because they can read. Computers find it much harder as they
don't understand the semantics.</DB>

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?
<DB>You could expose it as part of your WSDL definition. However before it
could be used, someone else would have to write software that could
interpret the semantics of the definition so that it could make an
appropriate decision. Although this is possible, I don't see it happening
unless and until there is some standardization of the semantics around how
you describe the rules and regulations as the cost of developing the
software for all the different ways of describing the semantics would be
prohibitive.</DB>

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
>