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:]
Sent: Sunday, April 12, 2009 8:44 PM
To: Mike
Poulin
Cc: Rex Brooks; James Odell;
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" ,
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
