[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm-ra] SOA-RA(F) reorganization
Rex: The bases for the discussion of contracts is inter-organizational or crossing ownership boundaries, which is, to me, fundamentally, where ecosystem SOA differs from enterprise SOA. Therefore, I can't. At least that is my take. Am I missing something? Bob -----Original Message----- From: Rex Brooks [mailto:rexb@starbourne.com] Sent: Tuesday, April 14, 2009 9:25 AM To: Ellinger, Robert S (IS); Mike Poulin; Ken Laskey Cc: Rex Brooks; James Odell; soa-rm-ra@lists.oasis-open.org Subject: RE: [soa-rm-ra] SOA-RA(F) reorganization 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.ph >>p>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.p >>hp >> > >-- >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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]