- From: bhaugen <linkage@interaccess.com>
- Date: Sun, 10 Nov 2002 06:51:09 -0600
- To: www-ws-arch@w3.org
Mike Champion wrote: >> As the ISO Open-EDI group discovered (and called Rule One), >> you're not just exchanging data, you're making legal commitments. >> For example, Purchase Orders are legal contracts. > >> I expect choreographies (or whatever rules of engagement evolve >> for electronic business collaborations) to become legal contracts. > I hope I'm not being naive to think that the business/legal/semantic > aspects of web services transactions/choreography can be decoupled from the > technological aspects of describing sequences of web services and > coordinating their state. The business/legal aspects inform the requirements, if you're trying to coordinate business deals. Otherwise it doesn't matter. It's sort of like in eXtreme programming, the business people define the stories and decide the priorities, the technical people devise the solutions (but only to the stories that were presented, according to business priority.) For example, if you define a hypothetical use case of unnecessary complexity and then create a technological solution to fit, you may have an over-engineered "solution", plus you may miss some critical aspects of the problem. One of which is that complexity hurts in this domain even more than some others. And that some dimensions of complexity hurt more than others. E.g. the number of parties who must agree to follow a particular scripted behavior hurts more than the number of activities. Or for another example, you may devise a solution for a stunningly complex set of business interactions without considering the exceptions, only to find that a different solution may be much simpler when the exceptions come into the picture And many of the exceptions will be business-level, not technical. (E.g. unfulfilled commitments.) I think this will end up being the case with explicit sequencing vs preconditions. Explicit sequencing will seem simpler until you get tangled in a spaghetti bowl of exception paths. (But I'll wait and see.) > We discussed this somewhat during the > requirements phase under "non-repudiation." That has a business/legal > meaning that the web services architecture probably won't say much about, > but some infrastructure is needed to collect the data about who did what > when, and how we know that reliably, in order to allow business-level > non-repudiation. I think we can aspire to something like that in the area > of choreography: The non-repudiation discussion flailed about similarly for a while until people who understood the business/legal aspects of the problem persuaded everybody that no technical solution exists, all you can do is collect good evidence. In other words, the business/legal understanding helped to simplify the technical issues. When somebody gets down to collecting the good evidence, they may want to go back to the business/legal understanding to help determine what evidence to collect, and in what form. -Bob Haugen
Received on Sunday, 10 November 2002 08:01:12 UTC