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

[Ken Laskey <klaskey@mitre.org>]

I've been chewing on this and had some better words but those now  
escape me so I will limp along with the following.

I think calling BPEL the traffic cop is like saying WSDL is the service  
description.  It addresses a necessary piece but a small one.  What  
needs to be managed is the full interaction through the execution  
context.  In fact, the traffic cop to a certain extent is the  
enforcement point for the EC and also the place that evolves the EC  
depending on other events and needs.

I'll try to develop further but this suffices as a beginning.

Ken

P.S. Does it make sense to talk about composition without talking about  
the process through which the pieces work together.  Even if I bolt two  
pieces of metal together, the bolted assembly notionally serves some  
purpose that the separate pieces did not, and beyond saying I've got a  
bolt, a washer, and a nut, I need to say how these are used together.   
Composition starts looking like a small piece of a larger thing we need  
to tackle.


On Mar 15, 2006, at 1:51 PM, Francis McCabe wrote:

> Ken:
>  What you are talking about is orchestration. The traffic cop is (of  
> course) the key driver for BPEL.
>  At the moment I am not I would want to mandate that all SOAs have  
> this kind of organization. At the same time we should be able to  
> clearly identify where in the RA such a cop would sit (stand)  
> directing the traffic.
>  There are some echoes here with intermediary processing too..
> Frank
>
> On Mar 15, 2006, at 7:49 AM, Ken Laskey wrote:
>
>> 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
>>
>
>

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