RE: [service-orientated-architecture] Policy, Contract, and Service Description

[David A. Chappell]

From: service-orientated-architecture@yahoogroups.com [mailto:service-orientated-architecture@yahoogroups.com] On Behalf Of Michael Poulin Sent: Thursday, September 07, 2006 7:02 AM To: service-orientated-architecture@yahoogroups.com Subject: Re: [service-orientated-architecture] Policy, Contract, and Service Description   [snip]   >ESB to me is a communication pipeline with a capacity in data transformation, not an "intermediary" in the of policy-contract space. If an ESB would be >the intermediary, the consumer and the provider were not needed to negotiate with each other but rather with ESB(?) from both sides. If a service is >provided via an ESB, the ESB becomes a part of the service offering. Period.   It could be done either way.  If an ESB works in conjunction with a WSM to actually implement the policy then it may make more sense to take the latter view.  Organizational practices may be put in place that specify policies from a business level point of view (all personal information involved in transaction must be encrypted) and delegate the implementation of that to the ESB/WSM infrastructure to negotiate and enforce what that actually means at the WS-Policy level.  From the “outside” perspective of either a consumer or provider implementation its not aware that an ESB or WSM is in place.  From an “internal” perspective (the organization that has adopted an ESB/WSM infrastructure) this isolates the individual developers from having to worry about building this negotiation and implementation into every service endpoint.   An ESB may not become an excuse for the Service if it fails. I’m not exactly sure what you mean by that.  I will point out however, that an ESB can eliminate failure scenarios by providing fault tolerance and failover at both the service level and the service delivery level (the WS-ReliableMessaging processor). Dave >&n! bsp; >- Michael Dave     Hitoshi Ozawa <Ozawa_Hitoshi@ogis-ri.co.jp> wrote: As you mentioned, a policy usually does not cover the entire contract, but I personally don't like the idea of a "policy" turning into a contract. I view a policy to be a set of conditions a consumer and provider brings to a "table" to negotiate on the terms of a contract. We usually don't negotiate to change the other's policy, we use policy to negotiate on the contract. Consequently, terms of a contract may end up being different on each negotiation, but a policy usually remains the same across several negotiations. Additionally in my view, an ESB acts as a "intermediary" between a consumer and a provider. H.Ozawa Dennis Djenfer wrote: > Steve, > > I would like to add a comment to my first response to your answer. I > like your "simplistic" way of discriminating between a policy and a > contract, however I don't see that a policy on its own can turn into a > contract. Before something can turn into a contract there must be > enough information to make a successfull interaction between the > parties, hence a policy is only a part of a whole that will turn into > a contract when the actual interaction occurs. > > I think that an exemple of something that could turn into a contract > when the interaction occurs is a WSDL-file together with adequate > assertions (policies). > > // Dennis Djenfer > > > > >     Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less. __._,_.___ SPONSORED LINKS Computer software program Computer software spy Computer job Database software Discount computer software YAHOO! GROUPS LINKS  Visit your group "service-orientated-architecture" on the web.    To unsubscribe from this group, send an email to:  [EMAIL PROTECTED]    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. __,_._,___