Re: [soa-blueprints] WS-TX

[John Harby <jharby@gmail.com>]

The universal bus notion reminds me of the universal relation in
database theory considered impossible by Chris Date and others :).
However from the vendor perspective I think it's a smart move since
these buses are probably still necessary even if they aren't
universal.

On 11/22/05, marchadr@wellsfargo.com <marchadr@wellsfargo.com> wrote:
>
> More comments below
>
> -----Original Message-----
> From: Jones, Steve G [mailto:steve.g.jones@capgemini.com]
> Sent: Tuesday, November 22, 2005 7:22 AM
> To: Ken Laskey
> Cc: Marchant, Dan R.; jharby@gmail.com;
> soa-blueprints@lists.oasis-open.org
> Subject: RE: [soa-blueprints] WS-TX
>
>
>
>
> Comments inlined….
>
>
>
>
>  ________________________________
>
>
> From: Ken Laskey [mailto:klaskey@mitre.org]
> Sent: 22 November 2005 15:14
> To: Jones, Steve G
> Cc: marchadr@wellsfargo.com; jharby@gmail.com;
> soa-blueprints@lists.oasis-open.org
> 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: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.
>
>
>
>
>
>
>
>
>
>
> ---
>
>
> 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.
>
>