Dennis, I am not saying that this pattern is wrong or bad, on a contrary. I am only saying that its representation, as it is done, is not for SOA Patterns. The devil is in details, as usual. First issue - (class->WSDL). However, there is one more obstacle the definition of contract in managing of multiple contracts is the problem. Just refresh what Standardized Service Contract means in Erls books and tell me if you understand my concern.
You say that "pattern ... basically gives you another level of indirection for the internal design of your services". Before, I used to use this pattern for separating/representing entities rather than decoupling interface from the service; I think GoF identified another pattern for such task - Bridge; Facade (according to GoF) is needed only if you set a superposition of interfaces (it is exactly how Web Service is used for integration and which has very little to do with service orientation) I have no doubts that vendors will use this 'word' and this is another headache for the architects. - Michael ________________________________ From: Dennis Djenfer <[email protected]> To: [email protected] Sent: Friday, January 23, 2009 3:12:30 PM Subject: Re: [service-orientated-architecture] Service Façade 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 Michael Poulin wrote: Thank you, Herbjörn, I will follow your idea and publish my book with this regard. As of now, I would like to notice that "SOAP based services with WSDL are the most used technology for building services" is true statement but does not articulate all truth. SOAP and WSDL are, actually, technologies used to build service INTERFACE, which, certainly, is a part of "building services" but only the part. If an interface reflects only access to the business functionality of the service instead of its internal logic, the only case where Facade is needed is when an exposed interface has different granularity regarding to internal service operations. I have an example of this kind published at http://ajax.sys-con.com/node/730632?page=0,2. This pattern looks similar to UI Mediator pattern from Thomas' book but I will write a BLOG (next week) about very significant differences between them - Michael ________________________________ From: Herbjörn Wilhelmsen <[email protected]> To: [email protected] Sent: Friday, January 23, 2009 8:55:42 AM Subject: Re: [service-orientated-architecture] Service Façade Michael, I do not agree with your reasoning. Giving examples in articles should be just fine, and SOAP based services with WSDL are the most used technology for building services as of today. The article does not say that a Service is the same thing as a Web Service; that line of thought comes from your mind only. If the examples bothers you that much maybe you could do something constructive like publishing something by yourself where you have examples that are not making readers misunderstand what a service is? - Herbjörn Wilhelmsen 2009/1/22 Michael Poulin <m3pou...@yahoo. com> Herbjörn, there is aFaçade Pattern and ... Façade Pattern described in GoF book, J2Ee, etc. The description makes the only difference. I do not have any doubts in the value of the Façade Pattern in general. Particular description in the article makes 100% sense if the reader keeps 'WebService = Service' (which is wrong) in mind; otherwise, there are a lot of questions and I asked some of them. Thus, I conclude that REPRESENTED Service Façade Pattern is, actually, the WebService Façade Patter. That's simple, nothing more. - Michael ________________________________ From: Herbjörn Wilhelmsen <herbjorn.wilhelmsen @yahoo.se> To: service-orientated- architecture@ yahoogroups. com Sent: Thursday, January 22, 2009 4:25:11 PM Subject: Re: [service-orientated -architecture] Service Façade The Service Façade pattern is useful for services that are implemented as Web Services; there is no doubt about that. But when you claim that this pattern is only about Web Services just because the example in the article happened to refer to Web Services and WSDL it seems to me like you are jumping to conclusions. Service Façade is applicable for services that are implemented as Components as well: For a Component the contract consists of a proprietary API (which of course, just like WSDL, has its advantages and disadvantages) and Service Façade can be used there too exactly like described in the article. If your technology of choice is REST then your contract will be of a more uniform nature (an http verb), but even RESTful services may have to evolve, e.g. in order to support new versions of messages. And when that happens Service Façade is a pattern worth considering. As Service Façade is applicable for these three implementation mediums it seems to me that there is a pretty good chance that it will be applicable even for future implementation choices. But that remains to be seen. - Herbjörn Wilhelmsen 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.>> -- Med vänliga hälsningar Herbjörn Wilhelmsen -- Med vänliga hälsningar Herbjörn Wilhelmsen ________________________________ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.12/1910 - Release Date: 1/22/2009 6:28 PM
