[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] Policy Types
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: flinn@alum.mit.edu 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, "michael.poulin@uk.fid-intl.com >>>> <mailto:michael.poulin@uk.fid-intl.com>" >>>> <michael.poulin@uk.fid-intl.com >>>> <mailto:michael.poulin@uk.fid-intl.com>> 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: flinn@alum.mit.edu >> 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: flinn@alum.mit.edu Tel: 781-856-7230 http://mansurus.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]