OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [soa-rm-ra] Policy Types

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.


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.


-------- Original Message --------
Subject: Re: [soa-rm-ra] Policy Types
From: Don Flinn <flinn@alum.mit.edu>
Date: Tue, June 03, 2008 6:51 am
To: Francis McCabe <frankmccabe@mac.com>
Cc: Ken Laskey <klaskey@mitre.org>, Duane Nickull <dnickull@adobe.com>,

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

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 

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 Flinn
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.

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 -

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, "michael.poulin@uk.fid-intl.com 

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.
Community Music - http://www.mix2r.com
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
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 

Don Flinn
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

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

Ken Laskey
MITRE Corporation, M/S H305      phone: 703-983-7934
7515 Colshire Drive                         fax:       703-983-1379
McLean VA 22102-7508

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]