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, <> wrote:
>
> 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.
>
>
