[soa-ra] why or why not composition needs to addressed

[Ken Laskey <klaskey@mitre.org>]

My apologies for falling back to email rather than the wiki but I am  
trying to get some percolating ideas down quickly in a familiar format.

Composition needs to be looked at in the context of not just how you  
would specify the combination of more atomic services into a higher  
level one, but also the behavior models and the  
orchestration/choreography that results in generating real world  
effects.  An implemented SOA needs a "traffic cop" process/service to
- accept requests,
- decide what needs to be done with the request,
- rout the request or derived requests to other services,
- collect the results of other services,
- decide on next actions based on behavior model and responses to  
routed requests,
- continue this until the initial request is satisfied or terminated,
- package and send results to receiver designated by original requester  
(where receiver possibly *not* the requester).

The traffic cop will make use of known compositions to make sure  
routing is done properly and for error recovery.  Whatever the traffic  
cop decides, it will probably be captured internally as a service  
composition and corresponding behavior model.  This is likely a useful  
format for logging and future audits.  It also gives a basis for  
evaluating levels of service and identifying bottlenecks.

So in summary, I think composition is a fundamental part of the  
reference architecture but in the context of how the composition  
description is used rather than the description itself.

Ken


------------------------------------------------------------------------ 
------------------
Ken Laskey
MITRE Corporation, M/S H305     phone:  703-983-7934
7515 Colshire Drive                        fax:        703-983-1379
McLean VA 22102-7508