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:]
>Sent: Monday, April 13, 2009 12:19 PM
>To: Ken Laskey
>Cc: Rex Brooks; James Odell;
>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" , ""
>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:>"
>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:>
>>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
>
>
>
>
>
>
>--
>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
