[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm-ra] SOA-RA(F) reorganization -choreography-orchestration
Hi Michael, I just got the tons of material for the Emergency Data Exchange Language Situation Reporting submission to the EM TC vetted by a Practitioners Steering Group and Standards Working Group involving the Dept. of Homeland Security (DHS) and the Emergency Interoperability Consortium (EIC) and even though it is only a coincidence, it illustrates the point: this (ER Service Orchestration) just isn't feasible in Emergency Management. I am simultaneously working on an Integrated Emergency Response Services SOA Pattern for the net-Centric Operations Industry Consortium (NCOIC), where the best chance exists to attempt to automate the most simple responses in an orchestration, and all indications are that even that will be beyond our capabilities for the foreseeable future. Despite more examples than I'd care to count, people still attempt to build master lists for such things as event/incident types and run into the same problem: no one is willing to give up their control over their own terminologies. If you can't get that, you can't even start building an orchestration engine. Cheers, Rex At 11:02 AM -0500 4/13/09, Mike Poulin wrote: >Exactly, Ken, "if...different sequences of actions are required, >these can be modified without modifying the services themselves". >This is possible ONLY if services do not know who, where, why and >when use them. That is, they DO NOT operate under current >Choreography standard which requires all this knowledge to be in the >service itself. > >If paramedics, Walmarts and alike operate with available services >being service orchestration services/engines/components by >themselves, they will know up-front (before engaging a helper >service) what messages to expect and in which order because the >engagement is made based on Service Description and >implicit/explicit service contract that define interaction >interfaces. > >- Michael > >----- Original Message ----- >From: "Ken Laskey" >To: "Ellinger, Robert S (IS)" >Cc: "Mike Poulin" , "Rex Brooks" , "James Odell" , >"soa-rm-ra@lists.oasis-open.org" >Subject: Re: [soa-rm-ra] SOA-RA(F) reorganization >Date: Sun, 12 Apr 2009 22:00:47 -0400 > >Think of the scenario this way: > >FEMA comes up with a generic coordination of assets for an >emergency. So the police are prepared to receive certain messages >and perform certain actions (including the use of and reporting >through SOA services). The paramedics are prepared to receive other >messages and respond. The Walmarts are prepared to receive messages >that certain supplies (such as bottled water) are needed from >certain stores. The public transportation is prepared to receive >messages that would indicate putting predetermined evacuation >patterns in effect, and their responses trigger other messages. > >Note, we have lots of folks who are prepared to receive messages, >possibly initiating service interactions, and respond as agreed. > >If a review of the predetermined coordination decides different >sequences of actions are required, these can be modified without >modifying the services themselves. > >Ken > > >On Apr 12, 2009, at 9:49 PM, Ellinger, Robert S (IS) wrote: > >>I suspect that if there was more than one, say two or three, >>services offered that performed the same function, that a service >>could ameliorate the condition of SLA build-up, which is similar to >>tolerance build up, by dynamically choosing various fallback >>services and could, with a concierge service, discover a reasonable >>set of services to perform the function of some service that is >>unavailable to due a backhoe outage or an operator fatfinger or... > >Choreography would then be "in play" even though the service might >be orchestrated under normal conditions. > >Bob > > >From: Ken Laskey [<mailto:klaskey@mitre.org>mailto:klaskey@mitre.org] >Sent: Sunday, April 12, 2009 8:44 PM >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 > >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 > > > > > > >----------------------------------------------------------------------------- >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]