Jonathan's Pancheria

dotcom Thousandaire

So I disagree with the way the argument in this post is framed, but I am glad to see the “mainstream” tech press realizing there’s a better way to get to SOA:

A growing number of companies are finding that lower-visibility Web-oriented architecture (WOA) developments, spawned through grassroots movements, are a better route to the service-oriented architecture. WOA, like SOA, is an architectural approach to system design, though WOA is resource-oriented rather than service-oriented. What’s the difference? While the core SOA design unit is a reusable service that fulfills a distinct business function, resource-oriented services are more limited and data-focused.

SOA and WOA work at different layers of abstraction. SOA is a system-level architectural style that tries to implement new business capabilities so that they can be consumed by many applications. WOA is an interface-level architectural style that focuses on the means by which these service capabilities are exposed to consumers. Governance, quality of service, security, and management are of equal importance, whether the functionality is being delivered via SOA or WOA.

I think the delineation between SOA design units as a service fulfilling a distinct business function and WOA as a resource-oriented service being more limited and data-focused is so much dissembling for SOA being an attempt to force a top-down, waterfall-based model on what services you offer in your architecture versus an iterative or even agile strategy of building the individual services and then gluing them together.

I think SOA was also overblown in the framework for tying them together, which is the root of this problem, and leads to the conclusion I made up above. Put a bunch of webservices out there that handle orthogonal responsibilities, make it easy to access them (personally, preferably with easy HTTP/POX or a light SOAP layer), rather than a huge management stack that services have to a priori fit into, with the up-front design and overhead that comes with it.

Published on 11/08/2008 at 07:21PM under . Tags , , , , , ,

Paul Graham first wrote about a strawman hypothetical programming language blub that examined the constraints that people who choose to stay firmly embedded in only one language seem to impose upon themselves and their programming capabilities and creativity.

Steve Vinoski, who has been writing a bunch about some of the failures of RPC-style distributed systems technologies (and should know, having been involved in CORBA), I think just extended the theme to distributed systems programming here.

Published on 02/07/2008 at 06:07AM under . Tags , , , , ,

I have posted several times about it, made a bunch of different arguments, and anybody who has talked to me about web services has heard me try and make the argument not to force a web service to be the serialized transfer of object artifacts. But here’s the summary in a nice single sentence from the post CommonRESTquestions:

REST can be seen a documented-oriented subset of Object-Orientation. It deliberately reduces the expressiveness of Objects down to the capabilities of resources to ensure compatability and interoperability between components of the architecture.

The rest of that paragraph goes on to say

Object-Orientation allows too great a scope of variation for internet-scale software systems such as the world-wide-web to develop, and doesn’t evolve well as demands on the feature set change. REST is Object-Orientation that works between agencies, between opposing interests. For that you need to make compromises rather than doing things your own way.

So there you go, someone said in a paragraph exactly what it has taken me 2 years to try and say.

Published on 02/10/2006 at 02:17AM under . Tags , , , , ,

Earlier, I posted about how not forcing all access to web services to go through objects that were serialized into and back out of XML but instead were XML documents that were designed to stand on their own made it easier to implement both web services and web services clients.

Elliotte Rusty Harold sets out a nice short example of the nature of the problem. He summarizes the problem nicely in this quote

“don’t “help” users out by changing XML into something else, especially not objects. Don’t assume you know what they’re going to want to do with the data. Give them the XML and let them use the classes and objects that fit their needs, not the ones that fit your needs. XML is exchangeable. Objects are not."

Again, for the record: if I work with your web service, you do not know what data, data structures, or code artifacts I will have in place to access your web service. Please don’t try to guess by forcing me through your view of how the software artifacts should look. Let me figure out how to make the raw message, and how to interpret what you send back. SOAP toolkits that closely map XML to particular language-specific data structure constructs and back make this hard.

Published on 09/12/2005 at 07:47PM under . Tags , , , , , , , ,

Powered by Typo – Thème Frédéric de Villamil | Photo L. Lemos