Sure, Anne. I prefer OASIS SOA definition and it is my business to promote it. BTW there is one more OASIS standard on the way (public draft) on SOA Ontology, and they also in sync with OASIS SOA (thanks God!). So, my 'flexibility' is in that I prefer to setup the terms before the conversation though this is not easy some times. - Michael
________________________________ From: Anne Thomas Manes <[email protected]> To: [email protected] Sent: Thursday, January 29, 2009 1:50:55 PM Subject: Re: [service-orientated-architecture] Re: Service Façade I think the OASIS SOA Reference Model provides an excellent description of the way service consumers and service providers interact. I'm comfortable with the terminology they use. When I'm talking with other people that have read the OASIS SOA RM, and we agree to use its terminology, it helps use communicate more effectively because was share its vocabulary and semantics. But I will not assert that the OASIS SOA RM is the one true source of vocabulary definitions. Thomas Erl's use of the word "contract" is certainly not uncommon in the industry. I prefer the OASIS SOA RM definition of "contract", but I believe that I need to be flexible in my terminology when speaking to others. Thomas defines his terms in the book, and that's what really matters. Anne On Mon, Jan 26, 2009 at 4:29 AM, Herbjörn Wilhelmsen <herbjorn.wilhelmsen @yahoo.se> wrote: > 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 <atma...@gmail. com> >> >> 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 <m3pou...@yahoo. 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 <atma...@gmail. com> >> > To: service-orientated- architecture@ yahoogroups. 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 >
