What is Abstraction ... and why

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" because message 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>
mailto:david.burdett@commerceone.com; Web:  <http://www.commerceone.com/>
http://www.commerceone.com