Bob,
existence of service description, which may be not fully automated, leads to "unprogrammed/authoring/design
and development/research activities;" first of all and only then to "transactional/programmed". That is, Bob, I am rather with you than on transitional automation side.
This means that dynamic linking cannot happen as an initial step. In my example with Dynamic Process Edition, all service that might be used dynamically by the process/orchestration are listed in the repository AFTER related CONTRACTS are set (may be manually or off-transaction).
Moreover, I do not think that transaction-based dynamic invocation of arbitrary service is inconsistent with the notion of business trust. That is, business services may not pick-up non-trusted services from UDDI, the contracts have t be set up first (probably, manually, by person).
- Michael
----- Original Message -----
From: "Ellinger, Robert S (IS)"
To: "Mike Poulin" , "Ken Laskey"
Cc: "Rex Brooks" , "James Odell" ,
Subject: RE: [soa-rm-ra] SOA-RA(F) reorganization
Date: Mon, 13 Apr 2009 11:37:05 -0500
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).
-
Micahel
-----
Original Message -----
From: "Ken Laskey"
To: "Mike
Poulin"
Cc: "Rex
Brooks" , "James
Odell" , ""
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" ,
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 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 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 www.mail.com!
--
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com!
