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

For me, the metaphor is not ice cream, it's two sides of the same coin.  I
commonly switch back and forth between Interaction diagrams (choreography)
and activity diagrams using swimlanes (orchestration).  At the end of the
day, it's just a flow of processes with some indication of role/organization
playing.  The representation is up to the individual how they want to
represent a process flow.  You can map one representation into another.
My 1.8 cents.


On 4/13/09 12:44 PM, "Francis McCabe" indited:

> 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]