Jan Algermissen wrote:
>> Specs are worthless unless you are in control of the implementation of those
>> specs if we are talking about security and QOS and service
>> guarantees. You are just trusting that the remote end is doing the right
>> thing.
>
> The lack of control you describe is exactly the reason why the messages
> MUST be self descriptive
> in order to protect the client from change on the server side affecting
> what it is effectively saying.
There are multiple ways to express that "self descriptive" ness. The more
specific you are about it, the less ambiguity there is in a legal arena.
Using "POST /pizza/order" with some content such as
<order type="pizza">
<crust type="thin"/>
<toppings>
<cheese type="mozzerella" quantity="extra"/>
<meat type="pepperoni"/>
<meat type="sausage"/>
<pepper type="green"/>
<onion type="red"/>
</toppings>
</order>
makes it pretty clear what you want. Legally and mechanically, that's no
different than
if( pizzaService.placeOrder( new ThinPizza( new Toppings[]{
new Mozzerella( true ),
new Pepperoni(),
new Sausage(),
new GreenPepper(),
new RedOnion() } ) ) ) {
... tell user order is placed ...
}
> From a legal/business transaction POV it is totally irrelevant what the
> other side actually *does* with
> my request. It is important that the transition the client made
> (here from "wantingToOrderPizza" to
> "havingPlacedPizzaOrder" ) is uttered in a way that is independent from
> serevr side issues.
It has to be something that the user can demonstrate to have executed. That's
the other side of the "internet". If you don't record what you've done, and
you
don't authenticate who you did it with, there isn't a lot of "evidence" that is
provable. A DNS spoof could have redirected you to another place in the
network, and the intended service never used.
This is one of the things that Jini provides at the service level. A client
can
assert constraints in their proxy preparer to demand that a service
authenticate
as a particular entity (X.500 or Kerberos are supported directly today). The
client can then have a better indication of what is on the other end, if the
Cert Auth/KDC are trustable as well.
There's not a definative, proven way to guarantee anything on the network
though. At some level, a certain degree of trust has to be accepted, or noone
would ever use it for exchanging legal obligations.
Gregg Wonderly
