W3C home > Mailing lists > Public > public-ws-chor@w3.org > May 2003

Re: What is Abstraction ... and why

From: Francis McCabe <fgm@fla.fujitsu.com>
Date: Fri, 16 May 2003 09:23:09 -0700
Cc: "WS Choreography (E-mail)" <public-ws-chor@w3.org>
To: "Burdett, David" <david.burdett@commerceone.com>
Message-Id: <AE8A8BA0-87BA-11D7-801B-000393A3327C@fla.fujitsu.com>

While not commenting on the requirements etc., this does not come 
across as a particularly clear definition of abstraction.

Paraphrasing from the book "Cognitive Existentialism", an explanatory 
system is self-consistent if an underlying realization can be replaced 
without affecting the predicted behavior of the system. (The technical 
term is `supervening' here.)

For example, in order to model the relationship between buyers and 
sellers I have to introduced concepts such as agents, goods, transfer, 
money, exchange, etc. In the real world, all of this can be realized in 
terms of people, cockle shells etc. However, cockle shells or dollars 
are concepts at a different `supervened' level than commerce itself: we 
can replace people, cockle shells with computers, email/SOAP messages, 
without significantly affecting the predictive power of the commerce 

Achieving the right abstractions; and hence the right explanatory 
model, is the hardest part of design. Done right, and you get many of 
David's benefits below; done wrong and you get a mess.:-(


On Tuesday, May 13, 2003, at 03:35  PM, Burdett, David wrote:

> In the call today, I was asked to define what is meant by abstraction 
> and why it is useful in choreography definitions ... so here goes ...
> Abstraction is one of the solutions to the problem of reuse and 
> variability.
> Reuse is required because:
> 1. The organizations taking part in a choreography all need to use the 
> same choreography if they are to interoperate successfully
> 2. Each choreography will need an implementation that is aware of and 
> can behave according to the rules of the choreography
> 3. Reducing the number of choreographies an implementation has to 
> support by enabling choreography reuse will therefore reduce the costs 
> of implementation.
> Variability is a "fact of life" becausemessage content will vary 
> because of:
> 1. Different contexts. For example, you only need VAT on orders in 
> Europe, you only need to specify shoe size for orders in the shoe 
> industry
> 2. Different implementations. An organization is free to specify their 
> own service interface in terms of the format of the messages they 
> accept, for example: Does the Order go in the SOAP body or in an 
> attachment? Are attachments packaged using MIME or DIME? Is the 
> message sent using HTTP or SMTP? Is the message digitally signed or 
> encrypted using XMLDsig/Encryption, PKCS#7? or not at all? etc
> 3. Different methods of communication. For example, big business can 
> use SOAP and Web Services but maybe the only way to send an order to 
> an SME (Small to Medium size Enterprise) is by fax or phone. (An 
> aside, IMHO, big businesses will want to be able to use the same 
> choreography with *everyone* no matter how big or small, so support 
> for this last type of "variability" is important).
> ... yet in spite of all the variability, the basic sequence of 
> exchanging messages (i.e. the choreography) is the same.
> Abstraction helps as:
> 1. You define the messages in a way which is independent of their 
> "variability", i.e. they are "abstract messages"
> 2. You define the services the messages are sent to/from in a way 
> which is independent of the service implementation, i.e. they are 
> "abstract services"
> 3. A choreography definition that is based on abstract messages and 
> services is therefore reusable and directly shareable as it is 
> independent of the "variability".
> 4. ... and finally ... shareable, reusable choreographies reduce the 
> cost of implementation.
> Hope this helps.
> David
> PS I think it quite possible that "templates" based on WSDL 1.2 are 
> capable of being the way of defining abstract services and messages.
> Director, Product Management, Web Services
> Commerce One
> 4440 Rosewood Drive, Pleasanton, CA 94588, USA
> Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704
> mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com
Received on Friday, 16 May 2003 12:24:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:04 UTC