I am not saying that the this not good pattern; I use it a lot as well. I am only saying that the pattern explanation promotes the idea of service=WebService instead of explaining the pattern and mention that "heir way of thinking is wrong" if they assume such 'service'. And, moreover, that explanation mismatches current definition of service contract (authorised by Thomas himself) but perfectly matches the old one (several years old) when service=WebService was OK.
BTW, how do you use Facade for "Single central service with multiple interfaces". Do you simply name those interfaces Facades ? - Michael ________________________________ From: Steve Jones <[email protected]> To: [email protected] Sent: Thursday, January 22, 2009 2:23:44 PM Subject: Re: [service-orientated-architecture] Service Façade I think you might be being a little harsh on this one Michael. Service Facade is a very strong SOA pattern (IMO), in fact with the organisational re-org stuff I'm doing at the moment its exactly the sort of approach I'm taking. Single central service with multiple interfaces delivered via Facades, no technology, no web services. The book has to cater to people who are thinking in a WSDL or other generation type of way and to explain why their way of thinking is wrong. Had he ignored that mentality then they will not have realised why the pattern is an effective one (its not simply a patch, its a good practice). Steve 2009/1/22 Michael Poulin <m3pou...@yahoo. com>: > Comment to "Service Façade, a design pattern focused on intra-service > design. > > When designing a service, there are several negative coupling types you need > to look out for. Contract-to- logic coupling, for example, results in a > service contract that is derived from (and therefore may have formed > dependencies upon) the underlying service logic, which makes the contract > subject to change whenever the logic changes. The result is, predictably, a > cascading effect whereby all service consumers are impacted (usually > negatively) by the changes. > > Service Façade can help avoid these situations by establishing an > intermediary processing layer in between the core service logic and the > service contract. ": > > "Contract-to- logic coupling" is typical to Web Service (WSDL) generated from > the programming class. This (class->WSD) is the worst possible approach to > services. 'Service contract' in this context, as well as in many other > places in the book, is comprehended as interface=service_ contract while > definition of the Service Contract by Thomas himself is (now) more lean to > OASIS definition, which includes policies, descriptions of business > functionality [not business logic], possibly SLA, Execution Context and > interfaces. If keep such definition of the service contract in mind, the > pattern description becomes ambiguous; if assume interface=service_ contract > - description is fine. > > So, based on OASIS and Erl's definition of Service Contract, statement > "...which makes the contract subject to change whenever the logic changes" > in not true because service logic should not be visible to consumers (in the > case of class->WSDL the logic becomes exposed exactly as the description > states) > > Based on OASIS and Erl's definition of Service Contract "Service Façade can > help avoid these situations by establishing an intermediary processing layer > in between the core service logic and the service contract " is not true > because "service logic and the service contract" are not directly connected > (unless it is class->WSD). > > So, the pattern does not 'treat the problem' but its consequences. The > problem in in class->WSD, which better be prohibited together with all > attached 'theory' of service=class. > > > My point is that the entire book considers service=WebService in spite of > modified principle of Standardized Service Contract (which now is not about > WebService only according to same Thomas Erl). This leads to the question: > is it SOA Design Patterns or WebService Design Patterns we are offered? > > - Michael > > ____________ _________ _________ __ > From: Gervas Douglas <gervas.douglas@ gmail.com> > To: service-orientated- architecture@ yahoogroups. com > Sent: Thursday, January 22, 2009 1:12:56 PM > Subject: [service-orientated -architecture] Service Façade > > You can read the following article at: > > http://soa.sys- con.com/node/ 815612 > > Gervas > > <<SOA Pattern of the Week (#1): Service Façade > > One of the fundamental goals when designing service-oriented solutions is to > attain a reduced degree of coupling between services, thereby increasing the > freedom and flexibility with which services can be individually evolved. > Achieving the right level of coupling "looseness" is most often considered a > design issue that revolves around the service contract and the consumer > programs that form dependencies upon it. > > However, for the service architect there are opportunities to establish > intermediate layers of abstraction within the service implementation that > further foster reduced levels of coupling between its internal moving parts > so as to accommodate the evolution and governance of the service itself. > These intermediate abstraction layers are created by the application of > Service Façade, a design pattern focused on intra-service design. > > When designing a service, there are several negative coupling types you need > to look out for. Contract-to- logic coupling, for example, results in a > service contract that is derived from (and therefore may have formed > dependencies upon) the underlying service logic, which makes the contract > subject to change whenever the logic changes. The result is, predictably, a > cascading effect whereby all service consumers are impacted (usually > negatively) by the changes. > > Service Façade can help avoid these situations by establishing an > intermediary processing layer in between the core service logic and the > service contract. The façade logic allows the service contract to remain > decoupled from the underlying logic and further shields it from changes to > the core business logic. This applies to both functional and behavioral > changes, the latter of which may (often inadvertently) come about as a > result of applying the Service Refactoring pattern. The façade layer can > compensate for internal changes so that the service contract does not need > to be modified as a result of the changes and/or the behavior of the > functionality expressed in the contract is also not affected. In both cases, > the service can evolve internally while existing service consumers remain > protected from any potential side-effects. > > Another scenario that can be effectively managed through the application of > this pattern is when a single body of core service logic requires multiple > contracts (a situation that actually pertains to another pattern called > Concurrent Contracts). In this case, a separate service façade component can > be created for each service contract, thereby retaining a clean abstraction > of core service logic from the contract layer. This avoids having to augment > and bloat the core service logic over time in order to accommodate different > contracts and can further leverage the aforementioned benefits of functional > and behavioral compensation when that logic is subject to functional change > or refactoring efforts. > > The Service Façade pattern can result in an elegant service architecture > with clean layers of abstraction, but it can also impose extra processing > overhead that naturally comes with increasing the physical distribution of > service logic. The fact that service logic ends up being more distributed > can also be perceived as increasing the complexity of the service design as > well. Carefully minding the type of logic placed in façade layers will help > mitigate these issues. > > Overall, though, the intelligent and regulated application of this pattern > can result in an effective separation of intra-service processing > responsibilities, which brings with it numerous governance benefits that can > accommodate the long-term evolution of the service and further help to > preserve on-going relationships formed with service consumer programs. > > The SOA Pattern of the Week series is comprised of original content and > insights provided courtesy of the authors and contributors of the > SOAPatterns. org community site and the book "SOA Design Patterns" (Erl et > al., ISBN: 0136135161, Prentice Hall, 2009), the latest title in the > "Prentice Hall Service-Oriented Computing Series from Thomas Erl" > (www.soabooks. com). Copyright 2009 SOA Systems Inc.>> >
