RE: [soa-rm-ra] SOA-RA(F) reorganization

[Rex Brooks <rexb@starbourne.com>]

And DON't limit SOA to intra-enterprise 
solutions. Our work is primarily and up to 80% in 
the territory crossing enterprise boundaries. 
Note please that enterprise largely means 
business, but is not limited to business.

Cheers,
Rex

At 11:37 AM -0500 4/13/09, Ellinger, Robert S (IS) wrote:
>Michael, Ken:
>
>There is a major missing point in this 
>discussion.  Michael is always talking about 
>transactional/programmed activities of the 
>organization.  Additionally, SOA works for 
>unprogrammed/authoring/design and 
>development/research activities; witness Google, 
>Yahoo, and other search engines.  I submit that 
>the purpose of these nascent SOA concierge 
>services/repositories is to dynamically link 
>(perform Choreography) functions--though the 
>choreography is performed by a person, rather 
>than through a set of business rules (rules that 
>include knowledge rules, event rules, and value 
>rules).  I discussed this concept in a paper I 
>published in the Journal of Enterprise 
>Architecture in 2006/2007.  Still much of the 
>most value laden work is performed by 
>unprogrammed activities (that's what e-mail, 
>word processing, etc. is all about).
>
>Please don't limit SOA to transactions only.
>
>Bob
>
>
>From: Mike Poulin [mailto:mpoulin@usa.com]
>Sent: Monday, April 13, 2009 12:19 PM
>To: Ken Laskey
>Cc: Rex Brooks; James Odell; soa-rm-ra@lists.oasis-open.org
>Subject: Re: [soa-rm-ra] SOA-RA(F) reorganization
>
>Ken,
>
>if two organisations decide exchange messages, 
>i.e. interact, there is a common/shared reason 
>for this. Such reason IS the orchestration 
>entity, it may be deployed anywhere. Plus, as I 
>mentioned, orchestration may be very dynamic 
>based on required business logic and service 
>descriptions.
>
>Nonetheless, I agree with you that combination 
>of orchestration and choreography is better than 
>they taken separately; it is better if each part 
>minds its own business, i.e. orchestration 
>defines order of functionality invocation and 
>choreography - dynamically assigned message 
>exchange and end-points.
>
>- Michael
>
>----- Original Message -----
>From: "Ken Laskey"
>To: "Mike Poulin"
>Cc: "Rex Brooks" , "James Odell" , "soa-rm-ra@lists.oasis-open.org"
>Subject: Re: [soa-rm-ra] SOA-RA(F) reorganization
>Date: Mon, 13 Apr 2009 11:49:24 -0400
>
>Michael,
>
>It's been a while since I looked at the WS-CDL 
>draft so I can't comment on specifics.  However, 
>I think the problem is not in choreography, per 
>se, but in the way you see WS-CDL implementing 
>it.
>
>In my mind, I can set up a choreography for an 
>emergency scenario that has a series of 
>agreements on how one should respond to a 
>understandable piece of information, and I can 
>see a very flexible response as the situation 
>unfolds.
>
>Part of the problem with orchestration is it 
>requires *all* participants to work under a 
>single orchestration engine.  This is fine under 
>the notional "enterprise" but what about peer 
>resources that can exchange messages but are 
>otherwise independent?
>
>What happens when a variation of the scenario is 
>not covered by the specifics of pre-programmed 
>orchestration logic?
>
>I am not arguing for one over the other but I 
>see the combination as being more powerful than 
>either alone.  However, this requires SO 
>composition rather than a traditional 
>integration mindset.
>
>Ken
>
>
>On Apr 13, 2009, at 10:38 AM, Mike Poulin wrote:
>
>>Unfortunately, Ken, this is the principle point 
>>because Choreography constantly screws SO model.
>Choreography is classical application 
>integration centric model where each change in 
>the integration requires change in each 
>participant of this integration, code 
>modification, re-compilation and re-deployment. 
>This relates as to the change in the invocation 
>order as to the change in the participants of 
>particular Choreography.
>The WS-CDL standard under W3C makes the life 
>even worth - it defines so-called Global 
>Contract, which freezes all participants. If you 
>need to modify any participant due to new 
>business requirements, you have to re-construct 
>the Global Contract and affect all (innocent) 
>participants.
>The Š standard is so bad that Mr. Ashley 
>McNeile  with his university colleagues tried to 
>construct a mathematical model which 
>externalises choreography scenario from the 
>participants and build it around centralized 
>dispatcher (very similar to Orchestration).
>Orchestration is real antipode to Choreography.
>As of "Dave Ellis will tell you related to 
>emergency response, where the choreography 
>pattern is vital because you do not know in 
>advance the location and extent of the emergency 
>and thus do not know the resources you will need 
>to orchestrate", I can say that you do not know 
>where your resources (participants) for 
>choreography will be as well. Emergency is NOT 
>the argument. If you construct a set of 
>choreographies they are solid, monolithic and 
>incapable to be quickly changed in the case of 
>emergency. You have to pre-build all 
>choreographies up-front wasting resources 
>(because you do not know the location, right?)
>Orchestration, in the contrast , is absolutely 
>dynamic, if you approach it with a 
>service-oriented mind. As IBM Dynamic Process 
>Edition has proved, Orchestration does not need 
>to know Who and How/Where performs the 
>orchestrated functions. It needs only to know 
>What functions are and Why/Which order of 
>invocation has to be applied. Whatever service 
>meets requirements to the business functionality 
>declared by the Orchestration, it may be used. 
>It also may be reused in absolutely different 
>Orchestration at the same time (due to the match 
>of offered business functionality) because the 
>service does not know where it participates in.
>Choreography, as it is defined in 
>the WS-CDL standard under W3C, is an 
>application-oriented, not service-oriented 
>mechanism.
>If you need more information on this topic, 
>please, look at 'Does SOA need a choreography or 
>it can dance by itself?' 
>(<http://it.toolbox.com/blogs/so-enterprise-blog/does-soa-need-a-choreography-or-it-can-dance-by-itself-27775>http://it.toolbox.com/blogs/so-enterprise-blog/does-soa-need-a-choreography-or-it-can-dance-by-itself-27775).
>
>- Micahel
>
>----- Original Message -----
>From: "Ken Laskey"
>To: "Mike Poulin"
>Cc: "Rex Brooks" , "James Odell" , 
>"<mailto:soa-rm-ra@lists.oasis-open.org>soa-rm-ra@lists.oasis-open.org"
>Subject: Re: [soa-rm-ra] SOA-RA(F) reorganization
>Date: Sun, 12 Apr 2009 20:44:01 -0400
>
>Michael,
>
>There are problem, such as Dave Ellis will tell 
>you related to emergency response, where the 
>choreography pattern is vital because you do not 
>know in advance the location and extent of the 
>emergency and thus do not know the resources you 
>will need to orchestrate.
>
>I also don't see the need to change the service 
>with a change in the choreography.  I expect the 
>choreographies are externally maintained 
>patterns.
>
>Ken
>
>On Apr 12, 2009, at 7:11 PM, Mike Poulin wrote:
>
>>I am in favour of Orchestration for SOA 10 
>>times more than for Choreography because the 
>>latter requires services modification for each 
>>new choreography it participates in and this 
>>decreases SOA flexibility in adopting business 
>>changes. Everything Rex said about events and 
>>policies is applicable to Orchestration as well 
>>but Orchestration is much cleaner from SO 
>>perspectives and much more dynamic. In Yahoo! 
>>SOA User group, we have discussed this topic a 
>>few times and always concluded the advantage of 
>>Orchestration over Choreography for 
>>service-oriented environment.
>>
>>- Michael
>>
>>----- Original Message -----
>>From: "Rex Brooks"
>>To: "James 
>>Odell" , <mailto:soa-rm-ra@lists.oasis-open.org>soa-rm-ra@lists.oasis-open.org
>>Subject: Re: [soa-rm-ra] SOA-RA(F) reorganization
>>Date: Sat, 11 Apr 2009 16:47:14 -0700
>>
>>
>>If we had spent more time on Choreography, where events trigger
>>policy-based rules for transactions and/or communications, it would
>>be somewhat easier to pull together a stand alone Policy
>>subsection. Of course, Orchestration also employs policy-based
>>rules, but resorting to a Conroller Application removes the
>>requirement for either human intervention based on judgment
>>required by rules and assessing state, or some heuristic algorithm.
>>
>>I'd still just add the standalone policy subsection rather than
>>eliminating the Policies and Contracts which I think we need for
>>more reasons than just continuity from the RM.
>>
>>Cheers,
>>Rex
>>
>>At 7:03 PM -0400 4/11/09, James Odell wrote:
>>>  Hi Frank,
>>>
>>>  Hmmm. While the two "the enforcement of the two is fairly
>>>  closely aligned" -- contracts are not necessary for Policies,
>>>  only the other way around. Policies, IMO should stand alone on
>>>  their own. The CEP folks argue that policies and events are
>>>  "fairly closely aligned". I can name a half dozen other areas
>>>  that could say the same. The bottom line is that: Policy is a
>>>  concept that may be necessary, but not sufficient for other
>>>  areas. Therefore, I strongly support its own sub-section.
>>>
>>>  -Jim
>>>
>>>
>>>
>>>  On 4/11/09 6:11 PM, "Francis McCabe" indited:
>>>
>>>  Hi Jim
>>>  Thank you for taking a look.
>>>  As far as policies go, we have havered a little (to use a
>>>  Scottish-ism) on how to organize it. In the RM work we closely
>>>  identified the two -- with the distinction being that contracts
>>>  are agreed to and policies are asserted. Once you have either
>>>  one, the enforcement of the two is fairly closely aligned.
>>>  Frank
>>>  On Apr 11, 2009, at 2:46 PM, James Odell wrote:
>>>
>>>  Hi all,
>>>
>>>  After yet another reading of the SOA-RA (Foundation?) and having
>>>  sat through the recent spate of meetings, I have the following
>>>  say about the reorganization of the SOA-RA:
>>>
>>>  Overall, I think that the chapters and topics are sequenced in a
>>>  coherent and logical manner. Perhaps, it is because I read it
>>>  too many times now. But, I don't think so.
>>>  Also, I understand the need to minimize the amount of work
>>>  needed on the SOA-RA at this point in its development. We need
>>>  to get it released for public comment - without compromising
>>>  quality and understandability, of course.
>>>  Having said this, the only thing that bothers me enough to
>>>  suggest a reorganizational change is the area of Policies:
>>>
>>>  1) Policies, in general, are depicted in document far earlier
>>>  than they are finally addressed (by 40-50 pages). Since policies
>>>  - IMO - are an important ingredient in the SOA-RA, I would like
>>>  to see them addressed earlier. (My personal opinion is that
>>>  policies are not mentioned anywhere near the amount that they
>>>  should. For example, they are used in events, composition of
>>>  services, roles, and organizations. However, since this would
>>>  involve additions to the current document, I will not push this)
>>>
>>>  2) I strongly dislike grouping the entire topic with contracts.
>>>  While policies are used for contracts, Policy is a standalone
>>>  concept - which neither depends on nor is used solely with
>>>  Contract. (Even the OMG and W3C treat policies as a separate
>>>  notion.) Why is this reasonable? Because policies are used in a
>>>  variety of situations - only one of which is contracts. By
>>>  placing Policies in lock step with (and almost subordinate to)
>>>  with Contracts is not appropriate, IMO. 3) My suggestion:
>>>  separate Policies and Contracts into two distinct subsections
>>>  (e.g., 4.4 and 4.5). In short, this would provide clarity for
>>>  the notion of Policy and not require much change to the current
>>>  document.
>>>
>>>
>>>  All the best,
>>>
>>>  Jim
>>>
>>
>>
>>-- Rex Brooks
>>President, CEO
>>Starbourne Communications Design
>>GeoAddress: 1361-A Addison
>>Berkeley, CA 94702
>>Tel: 510-898-0670
>>
>>---------------------------------------------------------------------
>>To unsubscribe from this mail list, you must leave the OASIS TC that
>>generates this mail. Follow this link to all your TCs in OASIS at:
>><https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>
>--
>Be Yourself @ mail.com!
>Choose From 200+ Email Addresses
>Get a Free Account at <http://www.mail.com/Product.aspx>www.mail.com!
>
>
>-----------------------------------------------------------------------------
>Ken Laskey
>MITRE Corporation, M/S H305      phone: 703-983-7934
>7515 Colshire Drive                         fax:       703-983-1379
>McLean VA 22102-7508
>
>
>
>
>
>
>--
>Be Yourself @ mail.com!
>Choose From 200+ Email Addresses
>Get a Free Account at <http://www.mail.com/Product.aspx>www.mail.com!
>
>
>
>------------------------------------------------------------------------------------------
>
>Ken Laskey
>
>MITRE Corporation, M/S H305     phone:  703-983-7934
>
>7515 Colshire Drive                        fax:        703-983-1379
>
>McLean VA 22102-7508
>
>
>
>--
>Be Yourself @ mail.com!
>Choose From 200+ Email Addresses
>Get a Free Account at <http://www.mail.com/Product.aspx>www.mail.com!


--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670