Aehso’s Output

WOA/Client makes my head explode.

Dion Hinchliffe’s recent WOA/Client article went pretty close to making my head explode.  Calling WOA/Client the “Pragmatic Service-Oriented Architecture”, the article contains a pretty diagram that reduces the use of web services to five key patterns that are defined in detail in another article Dion wrote for The Architecture Journal titled Patterns for High-Integrity Data Consumption and Composition:

• Frequent run-time checking of only the part of the contract you care about
• Minimal surface area dependence on Web service
• Lowest possible distance between client data representation and server representation
• Tolerant, robust, federated data modification (incomplete updates must never break the application)
• Managing multiple data sources in a maintainable way.  Use MVC to knit them/update them.

How this differs from any other SOA, beyond being an incomplete subset of considerations for any enterprise architect to muse over, is very questionable.  Why we need another term for this set of patterns is questionable.   How these patterns qualify as pragmatic when others (such as defining an interface versioning strategy up front) are somehow not is questionable. 

On a deeper level, how well-defined these patterns are is also questionable.  For example, I find it difficult to reconcile the use of the MVC pattern on an enterprise architecture level.  Are we supposed to define model services and view services?  Where does the controller get implemented and do we have to provide view callback interfaces (for the model to update the view).  Do the view services have to maintain state?  Sorry, the granualarity and complexity doesn’t fit distributed services at all.
 
And I’m still not sure what the term Client in WOA/Client signifies.  I have to agree with Sam Ruby - articles like this signify that the term SOA has entered the realm of Newspeak.  WOA/Client seems to be bordering on the stuff that Dilbert cartoons are made of.  It may only serve to further disconnect and confuse the very architects who are struggling to embrace existing, concrete, service oriented architecture definitions.

3 Comments to WOA/Client makes my head explode.

1. 

   Hi John,

   Thanks for your comments and taking time to read my article. Specifically, I’d like to address your concerns about the specifics of the patterns.

   The ‘client’ in WOA/Client refers to the specific techniques the client uses to interact with a WOA. For instance, in my sample code, a link to which is in the article, I provide three clients that actually perform contract checks before using the Web service (ala Bertrand Meyer’s Design by Contract, the reason for WSDL in the first place). In the industry, Web service contract checks are typically done at design-time, and we’re finding out this is entirely unacceptable for creating a resilient SOA/WOA out on the Web. This is an example of how existing SOA techniques, designed more for the controlled environment of the enterprise, are entirely inadequate to the Web.

   In any case, each of the other patterns has a matching force in the real-world that traditional SOA is not addressing, such as how to maintain relational and hierarchical data integrity in a browser,which isn’t designed to enforce such things. This is how we’re seeing MVC data management model work that keeps data in its native presentation but provides the client with a clean interface to multiple “mashed-up” data sources.

   And above all, WOA/Clients must be simple to create and maintain. This is a lot to document since there needs to be simple examples of each pattern and so I hope you’ll bear with me as we explicate each one.

   Finally, I stand by the statement that this is not only the the best way currently to think about and implement reliable and high-integrity SOA/WOA clients in heterogenous environments, but that it’s the shortest path to achieving it as well. With a little more work, I hope you agree too.

   Best Regards,

   Dion Hinchcliffe
Dion Hinchcliffe on August 9th, 2006
2. 

   Dion,
   Your reference to Meyers Design by Contract pattern is interesting. Personally, I think it actually highlights the problem with relying on lists of high level patterns for architects to use when designing enterprise services.

   WOA or SOA, at the end of the day each service must be defined by a machine readable contract (WSDL PortTypes/REST URLs and XML schema etc) augmented by a set of policies and rules.

   At the moment we are stuck with policies and rules that are encapsulated in service documentation or worse still are assumed to be known because the service interface was based on an ‘enterprise pattern’ that assumes certain usage. A problem is that when we want to we are lacking in the facilities we need to Design by Contract consistently when developing distributed services. WS-Policy, an example of such a mechanism, is not yet fully supported in SOA stacks yet and WOA stacks have no equivalent.

   Placing arbritrary checks on the service interface (as you do in your example clients) is just one small part of verifying a remote service will still be accessible at runtime. It does not deal with the multitude of other changes (security etc) that can occur that are not often encapsulated in the published service interface. Another issue is how often should the interface be checked? In stateless systems (common) the only way to be certain would be to check prior to every invocation but that would cripple the performance of any high volume service. Correctly, most service clients would not assume it is valid to do this.

   So, in short, I still don’t see what is different about WOA/Client that distinguishes it in any way from the patterns that most (respectable) SOA systems employ.

   Lastly, I’m afraid I still don’t see how MVC fits with any desire to deliver enterprise mashup applications into browsers - perhaps you need to illustrate this more clearly. The view for mashup applications is still generated by a web server but the content may actually be coming from many services elsewhere (and in fact, may not even be delivered by the view - Sam Ruby touched on this when he noted the absence of any reference to hyperlinks in your article).

   John.
Aehso on August 9th, 2006
3. 

   [...] previously criticized a post by Dion Hinchliffe’s on WOA/Client but to be fair to Dion I have to compliment him on his latest post about the SOA world beginning to [...]
Aehso’s Output » ROA is a subset of SOA - but is WOA a superset of ROA? on September 8th, 2008

Leave a comment