[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. -Jim 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]