Herbjörn, the book of GOF is not called 'Object-oriented Pattrens'; this is why it does not obfuscate object-orientation. Thanks to David Ch., I will look closer at the Erl's pattrens.
Right now, here are two examples of those patterns: 1) "Version Identification (Orchard, Riley) How can consumers be made aware of service contract version information?" 2)"Legacy Wrapper (Erl, Roy) How can wrapper services with non-standard contracts be prevented from spreading indirect consumer-to-implementation coupling?" This looks like Erl's "service contract " has almost nothning to do with OASIS SOA RM's service contract. Moreover, it seems that Erl's "service contract " is defined by WSDL, i.e. it is a Web Service. As we know, Web Service is just an interface and service contract, according to the standard, is much more than WS interface. Thus, are we talking about Web Services or SOA service in "Version Identification " pattern? After all, why a consumer might be interested explicitly in the interface version rather than in the service version? To the consumer, it does not matter what has been chnaged in the service; the consumer cares only about the answer to 'Should I change anything on my side and do I want to use this service after the change?' I believe that versioning separate parts of the service results in the consumer's nightmare, i.e. the service that exposes such versioning is a dead/unused service. But, one moment, this pattern is abot Web Service, not SOA service. Thus, it is OK. Another example - Legacy Wrapper - is a pattern for purely interface-based problem derived from Web Services again. Can anybody explain me how a legacy system wrapped with "non-standard contracts " or even "standard contracts ", i.e. interfaces, can become a Service while the legacy system itself does not demonstrate any implementaion of SO principles? Since when a car door placed on a cart made it a car? This is what I call obfuscation of service orientation. - Michael ________________________________ From: herbjorn.wilhelmsen <[email protected]> To: [email protected] Sent: Friday, January 16, 2009 9:00:55 PM Subject: [service-orientated-architecture] Re: Vaughan reviews Erl's Tome > SOA Design Patterns is published in 2009, when OASIS SOA RM is known for long enough to understand (accept or deny) that Service Inventory is not a pattern of service orientation, it is a pattern of technology inventory, IMO. > > - Michael Some of the patterns that are presented in the book are applicable in other areas as well. This is in my opinion no reason for excluding those patterns. And if you would want to exclude such patterns I have a question for you: What patterns in the SOA book is only applicable in the field of SOA? I would be very surprised if you found even a single pattern with that characteristic. Comparing with the GOF patterns book: As you yourself said quite a few of their object-oriented design patterns are not object specific, meaning that they can be applied to other areas than object-oriented development. Do you think that the GOF design patterns book obfuscated the meaning of object-orientation? As I see it the important thing is that the patterns are appicable in the field of SOA and that the patterns are described specifically with SOA in mind. - Herbjörn Wilhelmsen
