Just reading through the thread and I think we need to say something about business logic -- likely in the Interacting section and somewhat connected to composition. We also need to connect with policies. I see policy enforcement as applying business logic in response to whether reality aligns policy assertions. So policies and business logic are distinct but the effect of them being around is connected.
Note, you can have business logic without policies but I don't think you can have effective policies without business logic.
Ken
P.S. That said, I think the categories of assertions and commitments still works.
On Jun 3, 2008, at 10:03 AM, Danny Thornton wrote:
Those sound like good suggestions. Let's make sure they are captured in
our next issues list. It will make my job easier when I make the next
pass at the policy section.
Danny
-------- Original Message --------
Subject: Re: [soa-rm-ra] Policy Types
From: Don Flinn <>
Date: Tue, June 03, 2008 6:51 am
To: Francis McCabe <>
Cc: Ken Laskey <>, Duane Nickull <>,
,
I agree with Frank that what I am describing is more along the lines of
business logic. The point is that business has many written or implied
policies that are used and are critical to the running of their
businesses. Thus, in many situations policy drives the business logic.
What I'm talking about is an architecture for automating those policies
and rules and their use in a service.
The way I see the architecture is:
- rules would use pertinent facts from the ecosystem
- the rule outputs would be combined into a policy
- the output of the policy would be an action.
This follows the present policy architecture. The changes to the
section are mostly changes to make the wording in the write-up and
figures more general and less security specific. For example change
grantAccess to useAction; change requestForPermission to
requestForAction; change the output of the policy to an action and so
on.
For my simple example the input from the ecosystem to the rules would be
the load on the various warehouses. The action output from the policy
would be an address or endpoint, which would be an input to, for
example, WS-Addressing. Of course there would be additional inputs to
the rules to handle such things as the topology of the warehouses, the
various cost factors and time to customer. But these are implementation
details.
The model would be applicable other business logic problems such as buy
verses make, work flow, etc. We could extend the taxi example given in
this section to provide the driver with instructions to reroute the taxi
depending on changing weather conditions or other environmental facts
such as road detours. (Yes, I'll consider interfacing with humans - for
now :-)) I'm sure Michael can come up with better examples from
Fidelity and others from the government arena or whatever industry in
which they are working.
Don
--
Don Flinn
President
Mansurus LLC
e-mail:
Tel: 781-856-7230
http://mansurus.com
Francis McCabe wrote:
I have ben thinking about Don's policies.
To me, they are not policies in the same sense that we have talked
about. More like business logic.
However, having said that, there may be as a good reason to articulate
business logic as there is policy. I would note that many people
consider technologies like BPEL to be exactly that: ways of encoding
business logic in a language that is closer to the decision makers.
(Personally, I do not think that BPEL is all that good for that; but
hey its in XML so it must be good)
The kinds of constraint that show up in business logic are not nec.
the same as show up in security or admin policies. In order for us to
architect a 'customer discount policy' for example, or a 'shipping
policy', requires a transparency to capability that we have not
considered before.
I.e., if we wanted to describe and enforce that kind of business
logic, then architecturally, the issue of which shipping policy one
might use would have to be brought out of the service capability in
such a way that we could establish the link.
To do that, we would need to have a stronger idea of what processing
takes place.
I.e., in the mantra of knowing who is doing what to whom; we would
need to be able to decide what in as much detail as whom.
Frank
P.S. apologies if this seems too meandering.
On Jun 2, 2008, at 11:39 AM, Don Flinn wrote:
Beware you carbon-based entities! It won't be too long -
Sincerely,
R2D2 (aka Don)
Ken Laskey wrote:
except T4 will be the good guy
On Jun 2, 2008, at 11:50 AM, Duane Nickull wrote:
Does this mean we'll see "T4 - the rise of SOA" in a theatre soon?
;-)
On 02/06/08 8:28 AM, "
<mailto:>"
<
<mailto:>> wrote:
Don wrote:
One of the purposes of SOA is to facilitate the replacement of
humans by machines.
--
**********************************************************************
"Speaking only for myself"
Senior Technical Evangelist - Adobe Systems, Inc.
Blog - http://technoracle.blogspot.com
Community Music - http://www.mix2r.com
My Band - http://www.myspace.com/22ndcentury
Adobe MAX 2008 -
http://technoracle.blogspot.com/2007/08/adobe-max-2008.html
**********************************************************************
-----------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
--
Don Flinn
President
Mansurus LLC
e-mail:
Tel: 781-856-7230
http://mansurus.com
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
Don Flinn
President
Mansurus LLC
e-mail:
Tel: 781-856-7230
http://mansurus.com
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
-----------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
