More
comments below
-----Original Message-----
From: Jones, Steve G
[mailto:]
Sent: Tuesday, November 22,
2005 7:22 AM
To: Ken Laskey
Cc: Marchant, Dan R.;
;
Subject: RE:
[soa-blueprints] WS-TX
Comments
inlined….
From: Ken Laskey
[mailto:]
Sent: 22 November 2005 15:14
To: Jones, Steve G
Cc: ;
;
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.
[Marchant, Dan R.] What is your definition of an
Entity? What is acted upon or what is acting
upon?
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".
[Jones,
Steve G] Those product vendors out there will be disappointed
J
But I agree federation is going to be key (and normal)
[Marchant, Dan R.] In
practice based on Machiavelli principles one governor under the emperor
wouldn't be a solid kingdom once it is scaled to the next
region.
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.
[Jones,
Steve G] USB = Universal Service Bus? An almost perfect confusion point
J
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.
[Jones,
Steve G] Definitely makes sense, to me this is why the mixed mode (and the
concept of hierarchy of IT and business) should be the norm, so policy can
both be delegated upwards “You say who can call me” and downwards “Thou shalt
record everything”. So both service container and bus must be able
to exchange policy and manage policy enforcement. I think I’m agreeing
with you, I just thought it was a good topic for debate as the “single bus”
model is often pushed by vendors, in a similar way to the “one EAI” solution
was 5 years ago.
[Marchant, Dan
R.] Maybe even one object
broker...
Ken
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?
Steve
-----Original Message-----
From: Ken Laskey [mailto:]
Sent: 21 November 2005 19:51
To: ; ; -
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,
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:]
Sent: Monday, November 21, 2005 10:24
AM
To: John Harby;
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.
---
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.
