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:]
Sent: Tuesday, April 14, 2009 9:25 AM
To: Ellinger, Robert S (IS); Mike Poulin; Ken Laskey
Cc: Rex Brooks; James Odell;
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:]
>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.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
