Pragmatic SOA: Introducing the WOA/Client


News: Pragmatic SOA: Introducing the WOA/Client

  1. Pragmatic SOA: Introducing the WOA/Client (1 messages)

    The world of Web services has expanded far beyond SOAP and even REST. A practical, common-sense engineering discipline is emerging to consistently address the feeds, Web APIs, and other HTTP services we build software from today, called WOA (Web-Oriented Architecture). An article called "Pragmatic Service-Oriented Architecture: Introducing the WOA/Client" discusses some of the design patterns involved. It's been discussed before, in "The SOA with reach: Web-Oriented Architecture," but the new article discusses the actual design patterns involved. WOA essentially describes the subset of service-oriented architecture (SOA) that is most useful in highly federated systems. And by this we specifically mean distributed systems made up of very diverse and unlike types of clients and servers. Of course, this is the natural, everyday environment of the Web itself, as well as many large enterprises.
    In general, WOA/Client is based on what seems to be working "in the wild" as best practices for Web-scale systems. This usually means 1) avoiding automatically generated stubs, 2) reducing serial abstractions between the service and the client, 3) clearly understanding what's happening over the network on your behalf, and 4) periodically rechecking basic assumptions programatically. In most cases we're finding that WOA works best using REST or or POX over HTTP, though REST is clearly more desireable. Do keep in mind that REST can require more effort and better engineering capability to implement, at least initially, though that should do nothing to discourage you from using it.
    The tenets of WOA are as follows:
    • Inclusive: The concept of Web services must be expanded to include anything transported over HTTP, and a workable engineering approach must be applied to this realization.
    • Agnostic and Consistent: Service interaction must be agnostic yet consistent across platform, technology, protocol, data format, contract description language, and programming language.
    • Expect Constant Change: One must assume that changes to the service's contract, protocol, or endpoint location is not only normal and inevitable, but can happen suddenly and unexpectedly.
    • Mashup-Oriented: Integrating data from many sources and then defusing it again reliably, securely, safely across federated services is now a central activity in modern software systems.
    • Deeply Resilient: Failure tolerance must be extreme since failure modes, degraded operation, and incomplete outcomes are actually normal occurrences on the Web. Pessimistic assumptions about the quality of the run-time environment are mandatory and must be regularly rechecked programatically.
    • Bare Data: Lack of postive control, the developer maintenance and run-time cost of transforming data across many representations, and the abstraction impedance between them becomes unmanageable in Web-scale systems the farther one gets from the wire.
    • Extreme Loose Coupling: The tolerance continuum is surprisingly shallow once one gets out onto the Web, and software architectures should reflect that.
    Do you think we need yet another new model for architecting and building Web clients? Message was edited by:
  2. Hi Dion, Thanks for this article, it is a nice synthesis of the patterns involved when using WOA-style services. I have some remarks concerning the part on REST: "REST solely uses HTTP to function and is designed to leverage its best qualities." This is mostly true because though HTTP is the natural father of REST, but REST in itself is not limited to the HTTP protocol. In the Restlet project, we have implemented REST connectors for the AJP, SMTP, JDBC and FILE (local file system) protocols. "Unfortunately, that a canonical description of REST does not exist for the layperson is an almost tragic circumstance. In my opinion, this has significantly interferred with WOA's ability to be implemented and adopted effectively in a widespread manner, though I also believe that will soon resolve itself." There maybe a lack of practical documentation (anyone for a book on REST?) but we are actively working on filling this gap in the Java world and other efforts have started in RoR, Python and PHP too. The Restlet project is primarly a framework designed to support the development of REST/WOA applications, both client and server side. In addition, it is an alternative to the classic Servlets and the HttpUrlConnection class, but it can also nicely work with them if needed. To answer your question, I don't think we need a new "model" for building Web clients. The difference betwen clients and servers in the WOA world is becoming less and less obvious because every node can potentially act as a client and as a server. Even Ajax-enabled applications are starting to use techniques like Comet to act more like Web servers. Jerome Louvel