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


Help: OASIS Mailing Lists Help | MarkMail Help

soa-blueprints message

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

Subject: Re: [soa-blueprints] WS-TX

Metadata enables initial visibility without having to directly interrogate the entity of interest.  In fact, it helps identify the entity as one of interest.  Part of this may be an indication of what policies will come into play and links to the details of those policies.  

Where do the policies reside?  Well, for different implementations, these could reside in different places.  If it is well-known boilerplate, it may reside in some public space where it can be easily referenced by many groups.  It could also be very specific to a given entity and held locally, but from a metadata standpoint, I would expect the policy definition to be separate from the metadata but the metadata to point to it.  Part of policy may be how adherence to policy is evaluated, and an evaluation may make use of a third party mechanism to ensure unbiased tracking of compliance.

So let me get back to your specific questions:

Does the metadata reside with the service or the bus?  It resides some place where users can find it without knowing about the entity.  As for the bus, a single company may have a single bus, but I wouldn't count on a single "universal bus".

Service has all of the policy elements and does all of the management and adherence?  I doubt whether any service will be that self-contained.  Do we really want each service to encapsulate the evaluation function?  Do we really want to try to maintain that?  The policy evaluation will be a "service" (in the business sense, possibly accessed through one in the SOA sense) and the question is just where that function resides.  (See mention above of independent third party.)

Enterprise (the bus) that defines and enforces policy?  Policy is defined by those whose expertise is policy matters and the enterprise will identify where the official definitions reside.  Individual services may have special policies that are coordinated with the enterprise, but mechanisms will be needed (e.g. metadata) to indicate where policies reside and how these are to be evaluated.  Also, see note above about non-ubiquitous USB.

Service has the policy for its minimal state... bus contains the policy related to actual interactions?  It sounds like the higher level policy defines the environment for the service and is not directly of concern to the service.  For example, in the US my income taxes are due quarterly and I know my employer has some mechanism to get the payments in in a satisfactory manner.  I don't directly deal with this.  However, it is also my responsibility to make sure the amount sent to the IRS is sufficient and it is my responsibility to send in any shortfall.  This is my policy on how to handle, using my mechanisms.  In summary, I'll deal with policy that is my direct responsibility and interest and I'll delegate other policies to the appropriate "others", especially when I neither know nor care what these policies are.

Hope this all makes sense.


On Nov 22, 2005, at 4:54 AM, Jones, Steve G wrote:

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?


-----Original Message-----
From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: 21 November 2005 19:51
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.


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
Subject: Re: [soa-blueprints] WS-TX


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.


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.

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]