RE: What is Abstraction ... and why

Francis:

It is very clear to me that choreography specifications will be used in
environment that involved hundreds, thousands, ... maybe in a few cases
millions of users. If we create a model by which a "choreography
definition" cannot be used as is and maintained by this type of size of
business communities, we will definitely create a huge mess (e.g. a bid
A&D company has almost 30000 suppliers, Ricky, how many CISCO has?, the
number of car dealers in north America is roughly 22000).

If we spend a $1000 per node to update a choreography definition, we
spend $1 million per thousand node. How fast can you spend $1000 in an
IT shop?

IMHO, it is not whether or not we need some abstraction, but it is
rather how much of abstraction do we need to keep these kind of cost
(deployment/maintenance) at a reasonable level. It is one thing to
orchestrate a few services and compose them into a higher level service
that could be used by a lot of people, it is a very different thing to
establish loosely coupled large trading peer-to-peer (e.g. trading)
communities doing all kinds of activities (not just one activity like
swapping files).

Jean-Jacques Dubray____________________
Chief Architect
Eigner  Precision Lifecycle Management
200 Fifth Avenue
Waltham, MA 02451
781-472-6317
jjd@eigner.com
www.eigner.com 
 
 

>>-----Original Message-----
>>From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org]
>>On Behalf Of Francis McCabe
>>Sent: Freitag, 16. Mai 2003 12:23
>>To: Burdett, David
>>Cc: WS Choreography (E-mail)
>>Subject: Re: What is Abstraction ... and why
>>
>>
>>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
>>model.
>>
>>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.:-(
>>
>>Frank
>>
>>
>>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 14:09:37 UTC