Thanks David for answering. I'm changing the Subject to Service and ESB in accordance to the suggested guideline.
Anne, just checking if everybody awake. : ) TGIF! H.Ozawa Anne wrote: >I don't recall that we were discussing ESBs as part of this >conversation. David A. Chappell wrote: > ------------------------------------------------------------------------ > > From: [email protected] > [mailto:[EMAIL PROTECTED] On Behalf Of > Michael Poulin > Sent: Thursday, September 07, 2006 7:02 AM > To: [email protected] > 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 <[EMAIL PROTECTED]> 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! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
