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.

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