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
Date: Tue, June 03, 2008 6:51 am
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
Tel: 781-856-7230
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?
;-)
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.
Adobe MAX 2008 -�
**********************************************************************
-----------------------------------------------------------------------------�
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
Tel: 781-856-7230
---------------------------------------------------------------------
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:
--�
Don Flinn
President
Mansurus LLC
Tel: 781-856-7230
---------------------------------------------------------------------
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:
---------------------------------------------------------------------
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: