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

["Chiusano Joseph" <chiusano_joseph@bah.com>]

Here's an article from May 2005: (I think you will recognize the
author;)

http://bpmfocus.com/2005/06/01/story.html?xrap=y&story=Get_Ready_WS-BPEL
.xml&title=Articles%20:%20Get%20Ready%20for%20WS-BPEL

Please note that the schedule for BPEL has since changed - the first
paragraph of this article reflects the schedule as conveyed by the BPEL
TC chairs at the time of the article. 

Joe

Joseph Chiusano
Associate
Booz Allen Hamilton
 
700 13th St. NW, Suite 1100
Washington, DC 20005
O: 202-508-6514  
C: 202-251-0731
Visit us online@ http://www.boozallen.com

-----Original Message-----
From: Ken Laskey [mailto:klaskey@mitre.org] 
Sent: Wednesday, March 15, 2006 2:06 PM
To: Francis McCabe
Cc: soa-rm-ra@lists.oasis-open.org
Subject: Re: [soa-rm-ra] [soa-ra] why or why not composition needs to
addressed

Frank,

I haven't gone through any details of BPEL in a long time but my
uninformed instinct is that BPEL is a small and insufficient subset of
what is needed.

Is there a good BPEL reference (or a stable spec) to look at to confirm
or disprove my assumptions?  I'd like to look at some BPEL info and then
try to further flesh out the traffic cop in an RA context.

Ken

At 01:51 PM 3/15/2006, 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
/
 
------------------------------------------------------------------------
----------