Re: [soa-blueprints] WS-TX

[<marchadr@wellsfargo.com>]

This is a good question how many blueprint variations do we want?

Personally you cannot get fully away from having a bit of policy within a service. The bus could do the greater policy enforcement of the who, what, where. But having policy around identity x will see only a subset of data really needs to reside in a service since this may be different depending on the operation performed within the bus and would be governed by specific business requirements of a certain group.

There are however options to have a filtering approach based on who the client is invoking it, and maybe could lead to pushing some of the business policy up into the bus depending on the technology.

- dan




-----Original Message-----
From: Jones, Steve G <steve.g.jones@capgemini.com>
To: Ken Laskey <klaskey@mitre.org>; Marchant, Dan R. <marchadr@imc.wellsfargo.com>; jharby@gmail.com <jharby@gmail.com>; soa-blueprints@lists.oasis-open.org <soa-blueprints@lists.oasis-open.org>
Sent: Tue Nov 22 03:54:21 2005
Subject: RE: [soa-blueprints] WS-TX


One question on Meta-data from a blueprints perspective, do we feel that
Meta-data resides with the service or with the bus?  This isn't an esoteric
debate, it's about how services are deployed and managed.  One view is that
the service has all of the policy elements and does the all the management
and adherence, this is the full autonomous view of the world.  The other
side is that the service just provides functionality and it is the
enterprise (the bus) that defines and enforces policy.    One other way I've
seen work successfully is where the service has the policy for its minimal
state of operation, while the bus contains the policy related to actual
interactions.  In this last case the ability of the bus is only to
strengthen contracts and add them rather than being able to over-ride.

I've tended to use the later case as it fits with a hierarchy pretty well.
But is it the blueprints going to provide examples of multiple types of
policy management approaches or stick to a single recommended best practice?

Steve


> -----Original Message-----
> From: Ken Laskey [mailto:klaskey@mitre.org]
> Sent: 21 November 2005 19:51
> To: marchadr@wellsfargo.com; jharby@gmail.com; soa-blueprints@lists.oasis-
> open.org
> Subject: RE: [soa-blueprints] WS-TX
>

> Agree.  The descriptive metadata for all entities involved in SOA,
> e.g. content as well as services, should adequately describe that
> entity so a user (both providers and consumers) knows what the entity
> is, when it is applicable, and how to apply it.  Context is obviously
> a big part because the details of what is described may change with
> changing context.
>

> Ken
>

> At 02:19 PM 11/21/2005, marchadr@wellsfargo.com wrote:
> >I would also add that there may be options to include some of the
> >work done in the WS-CAF TC for context.
> >It is not as rich as it should be but feedback to that group might
> >be worthwhile anyway.
> >
> >My 2 cents.
> >
> >- Dan
> >
> >-----Original Message-----
> >From: Ken Laskey [mailto:klaskey@mitre.org]
> >Sent: Monday, November 21, 2005 10:24 AM
> >To: John Harby; soa-blueprints@lists.oasis-open.org
> >Subject: Re: [soa-blueprints] WS-TX
> >
> >
> >John,
> >
> >I would expect the service metadata to include, or more likely
> >prominently link to, representations of policies under which the
> >service wishes to perform.  Per the SOA-RM, policies represent a
> >"wish list" for the service, where some items may be negotiable and
> >some not.  Establishing the "execution context" is the mechanism by
> >which provider and consumer policies are aligned and conflicts
> >resolved;  it may be thought of as a negotiation of policies
> >resulting in a contract between the parties.  A service invocation
> >becomes possible and may occur within an established execution
> >context.  The transaction semantics would not be changed, but some
> >level of semantic mediation may be necessary in the process of
> >creating the contract, including documenting what mediation has occurred.
> >
> >Ken
> >
> >At 12:28 PM 11/21/2005, John Harby wrote:
> > >I joined the WS-Transactions TC and attended their F2F last week.
> > >Although I don't think we have the sort of liason
> > >requirements that we may have in other SOA related TCs, the notion
> > >of SOAs and services did come up in the discussion. One particular
> > >example was compensation (e.g. in a rollback scenario), certain
> > >services may be compensatable and others may not. It wasn't too
> > >certain whether this property should be expressed in the service
> > >metadata or some policies. It was extremely undesirable to that
> > >group for the transaction semantics or protocol to be modified though.
> >
> >--
> >
> >-------------------------------------------------------------------------
> --------
> >    /   Ken
> >Laskey                                                                \
> >   |    MITRE Corporation, M/S H305    phone:  703-983-7934   |
> >   |    7515 Colshire Drive                    fax:      703-983-1379   |
> >    \   McLean VA 22102-7508
> /
> >
> >-------------------------------------------------------------------------
> ---------
> >
>

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



This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient,  you are not authorized to read, print, retain, copy, disseminate,  distribute, or use this message or any part thereof. If you receive this  message in error, please notify the sender immediately and delete all  copies of this message.