Anne: You wrote this: "I believe your objection in this thread is regarding Erl's use of the term "contract". Replace the word "contract" with the word "interface" in Erl's pattern description and see if that works for you."
Michael's interpretation of this is that you reject Erl's definition of service and service contract, and is all in favor of the OASIS definition. Is this your position? - Herbjörn Wilhelmsen 2009/1/24 Anne Thomas Manes <[email protected]> > The facade is between the interface(s) and the implementation. > > I believe your objection in this thread is regarding Erl's use of the > term "contract". > Replace the word "contract" with the word "interface" in Erl's pattern > description and see if that works for you. > > Anne > > > On Sat, Jan 24, 2009 at 8:48 AM, Michael Poulin > <[email protected]<m3poulin%40yahoo.com>> > wrote: > > Certainly, Anne. The question is where do you position the facade - > between > > the interface and the rest of the service or above all or some of listed > > interfaces as a Facade in GoF's defintion. > > -Michael > > > > ________________________________ > > From: Anne Thomas Manes <[email protected] <atmanes%40gmail.com>> > > To: > > [email protected]<service-orientated-architecture%40yahoogroups.com> > > Sent: Saturday, January 24, 2009 12:45:19 PM > > Subject: Re: [service-orientated-architecture] Re: Service Façade > > > > I think the Facade pattern also applies to this scenario: > > > > One service implementation exposed and accessible via multiple styles > > of interfaces: > > - a method-oriented interface (e.g., SOAP with 1+ operations > > specificed via WSDL) > > - a resource-oriented interface (e.g., functionality exposed via > > multiple resources/URIs all with a uniform set of methods) > > - a message-oriented interface (e.g., functionality accessed via > > topics and queues) > > > > Anne > > > > On Fri, Jan 23, 2009 at 7:04 PM, Dennis Djenfer <d...@algonet. se> wrote: > >> Rob Eamon wrote: > >> > >> What is the contract to service relationship: > >> 1 to 1? > >> Many to 1? > >> > >> > >> One service may have one or many contracts. > >> > >> >From a consumer point of view, should different contracts be viewed > >> as different services? Or does it not matter? > >> > >> > >> It's the same service, but different interfaces, policys or QoS. > >> > >> If multiple services share a common implementation does it matter > >> from an SO architecture viewpoint? Or is this an implementation > >> detail with the implementation architecture being independent of the > >> service architecture? > >> > >> > >> It matters if it affects the autonomy of the services. > >> > >> At what point does a single service with multiple contracts (assuming > >> this is a reasonable construct) and each contract having multiple > >> interfaces does the "service" become unwieldy? > >> > >> > >> Personally I'm trying to keep the numbers down by: > >> - generalizing operations and schemas > >> - using backwards and forwards compatible message schemas as much as > >> possible > >> - classify QoS in a couple of "standard" classes. > >> > >> However, I've seen other approaches where they've used specialized > >> contracts > >> for each consumer (mostly in B2B scenarios) and utilized a canonical > >> schema > >> between the public interfaces and the internal service logic to be able > to > >> handle some of the complexity. > >> > >> // Dennis Djenfer > >> > >> -Rob > >> --- In service-orientated- architecture@ yahoogroups. com, Dennis > >> Djenfer <d...@...> wrote: > >> > >> > >> Michael, I don't think your interpretation of the pattern is > >> entirely correct. I agree it's unpedagogical to bring forward a > >> bad practice (class->WSDL) as one of the argument for the pattern, > >> but the patterna also has other values, e.g managing of multiple > >> contracts, which Erl also mentions. It's a "classic" pattern and > >> basically gives you another level of indirection for the internal > >> design of your services. I think many people, at least the vendors, > >> would refer to this pattern as virtualization. > >> // Dennis Djenfer > >> > >> > >> ------------ --------- --------- ------ > >> Yahoo! Groups Links > >> Individual Email | Traditional > >> http://docs. yahoo.com/ info/terms/ > >> > >> ____________ _________ _________ __ > >> No virus found in this incoming message. > >> Checked by AVG - http://www.avg. com > >> Version: 8.0.176 / Virus Database: 270.10.12/1911 - Release Date: > >> 2009-01-23 > >> 07:28 > >> > >> > >> > > > > > > > -- Med vänliga hälsningar Herbjörn Wilhelmsen
