OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Talking about favoring orchestration over choreography, or vice versa,  
is like mandating vanilla over chocolate ice cream. Surely it is up to  
each scenario/application provider to make best choices for this?
On Apr 13, 2009, at 9:35 AM, Rex Brooks wrote:

> Thanks Michael,
> I don't especially favor either Orchestration or Chorerography. We  
> must make allowance to accommodate both, in my opinon. I was just  
> pointing out where I thought our collective focus has been and why  
> that perspective colors our use of Policy as integral with Contracts.
> Cheers,
> Rex
> At 6:11 PM -0500 4/12/09, 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" , 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
>> --
>> 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
> ---------------------------------------------------------------------
> 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]