Alright, we’ve previously established that at least some enterprises have a substantial software investment outside of the classic business process arena. We’ve also seen an example of advice that fails to take account of this class of enterprise. Now it’s time to talk architecture.
The more traditional enterprises (those that only need software for business process automation and support) made a mistake in their past which needs undoing. They focused on building applications not systems. Each application was designed to tackle some individual aspect of their business processes which when they needed to be integrated caused much pain. The result has been a trend (SOA) to break up all those application silo’s into a collection of shared services on top of which appropriate applications can be built by the enterprises themselves or others. In the latter case shared services must in some way be exposed to others outside the firewall.
Creating services as above is merely one method of partitioning code and data. This method does not apply so well outside of business processes so we must find another model. ROA presents one such model, one that is data centric and works well in the world of the Web where we desire ad-hoc (chaotic) assembly of resources (mashups). The nature of the Web is such that it can be difficult to know who your users are (there are too many) and to manage transitions from one version of an API to another. Basically you don’t know what your dependencies are and it can be difficult therefore to measure the impact of changes. Some have suggested that it’s not appropriate to retire old APIs or resources but this can have significant impact in terms of maintenance such that at least some organisations do deprecate old APIs and retire them eventually. ROA like any other architecture has it’s limitations.
ROA is of course derived from REST. REST includes a set of constraints which are essentially just useful architectural patterns. Some would claim they deliver scalability but I prefer to state that they are “scalability enabling”, they don’t inhibit scaling. However it’s important to realise that behind the Web layer one must still build scalable infrastructure. Building this infrastructure the right way (architecturally) yields scalability not REST itself. Many websites rely on running multiple copies of their web application, scaling via their database and caching solution which will often be more than enough.
However there is a class of enterprise website for which this approach fails, because the consistency models provided by databases and the like actually can’t scale as far as is required. A further complication is that managing everything as a single web application becomes impossible. Each part of the application has its own unique demands in respect of tuning, configuring, monitoring and maintenance:
- Tuning for one part of the application has adverse effects on other parts.
- Configuration becomes a nightmare because there are so many different settings to worry about. Something that works well in testing isn’t appropriate for production leading to separate profiles that must be maintained and kept in sync leading to forgotten changes etc.
- Monitoring produces so much of a mixture of data that it becomes a major exercise to filter out just what you need.
- Maintenance becomes an exercise in chasing down long chains of dependencies to make a simple change.
It becomes necessary to break up the application, storage, caching and so on into more manageable pieces that can run separately as a distributed system. Each element provides a service but not as would generally fit with the “classic” definition of SOA. Our requirements for partitioning are driven by multiple forces and thus the decision as to how exactly to break up the application must be determined on a case by case basis. Such a decision could be driven by amongst other things business model (web applications are still surrounded by business processes), scaling needs, specific storage requirements of underlying data or provision of a specific feature for the website.
One might choose to expose such a service using WS-*, messaging, a Web/Resource approach, CORBA or even some form of custom service invocation layer. Perhaps surprisingly there’s a growing number of examples where the custom service invocation layer option is used. I believe this is because all other approaches represent a compromise achieved through limitation of architectural options in such a manner as to be inappropriate for these demanding cases.
We cannot call this architectural approach SOA, ROA, EDA or anything else, it is simply about creating isolated, independent elements and minimising dependencies. It is something we’ve been doing inside of our programs for years. It also allows us to construct a working, manageable system at large scale. It is common sense. CSA anyone?
Technorati Tags: architecture, distributed systems, scalability, software
Entries (RSS)
Dan — first two posts in this series clicked for me. This one has not clicked yet.
I think the middle part of the post is the key message: for sufficiently large systems there may be more than one style of distributed architecture. And for some systems there may be a single style, say ROA, but although logically, or conceptually, it is a “single” system, the parts may conflict with each other if they were forced to co-exist to closely in a single implementation.
And so the lessons are, I think I am reading:
1) Don’t lock into a single style just to have a single style.
2) Don’t lock into a single implementation just to have a “single implementation”.
Or something?
I became lost in the last couple of paragraphs about “custom service invocation layer” — do you mean like Jini’s?
And finally with the CSA — “Common Sense Architecture” — what’s that architecture? What’s the common sense that does not exist in ROA or EDA (I’ll leave SOA out of it — that one leaves me feeling queasy in and of itself.)
Hi Patrick,
Belated Thanksgiving wishes – wondering a little why you’re reading a techblog on the holiday
Custom service invocation layer – I’m aware of a couple of examples some of which at least have properties of JERI but aren’t typically focused on Java. However this is just a distraction. The important point is that most of the invocation infrastructures one might choose are locked in some part to a particular architectural approach. Or at least they represent a particular set of compromises chosen by the vendor/developer that may not fit with all cases one finds in implementing these large systems. Ideally one would like a single invocation infrastructure that can cope with all eventualities which is leading some to build their own that take the best bits of a selection of infrastructures and combine them to get exactly what is required.
As to the rest of the posting, you’re pretty close to what I was trying to say which amounts to:
Systems of a certain scale and diversity do not easily fit within a particular style. When this happens, one must fall back on what I’m (perhaps wrongly) calling common sense – focusing on partitioning, various patterns that might pop up in one or more styles, past experience and so on.
Bruce Lee wrote something that I feel fits with what I’m getting at:
“Jeet Kune Do favors formlessness so that it can assume all forms and since Jeet Kune Do has no style, it can fit in with all styles. As a result, Jeet Kune Do utilizes all way and is bound by none and, likewise, uses any techniques which serve it’s end.”
My (architectural) style is no (architectural) style, all I have are my wits and experience…..