Making REST a reality…

February 19, 2008

2008_02190006_small1.jpg

The price of being RESTful (I daren’t say ‘simple’) in a complex world…where did that lot come from? (a reality-desk-cam snapshot after a quick tidy-up).

Advertisements

It Aint All About the Tech…!

February 19, 2008

2008_02100060-small.jpg

No words necessary…

It Might Be Just Me….But…

February 19, 2008

So I see REST as a re-claiming of the common-sense ingredient in the whole application integration landscape. I see the how the use and re-use of the web as a means of linking not only customers with business, but with any participant in a complex transaction, a fantastically liberating vision within the Enterprise. I see how REST combined with the Enterprise has the potential to weaken the strangulation of vendors, and their crippling commercial strategies on the progress of the Enterprise. And I see a gradual and accelerating simplification of how we wire together our Enterprise IT assets using web principles, as opposed to the WS/MOM/EAI stacks which have prospered under the false “SOA==WS==Fortune-and-Glory” banners waved by all the vendors over recent years…..

So….when I see a major software vendor claiming that their proprietary, highly expensive product-line will now support REST, why do I suddenly feel my head begin to shake from side-to-side slowly….whilst grinning from ear to ear with that sort of ‘I’ve been here before and it hurt‘ kind of grin?

Disecting this statement further (when my head had stopped shaking) I find that what they actually mean is not ‘supporting the exploitation of REST principles in removing unjustifiable cost and proprietary stranglehold partnership from the Enterprise by rediscovering the power and boundless coolness of HTTP, and liberating some self-confidence to use it properly…. ‘

But instead it actually means ‘you can still use our highly expensive, proprietary technology stack, therefore allowing us to propagate our lock-in strategic-alliance and stranglehold partnership, because we’ve added a http management interface that looks RESTful‘.

Slapping a RESTful management interface on my fridge aint gonna help me simplify my Enterprise is it now? 😦


Implosion of REST Frameworks?

February 19, 2008

Applying REST principles to a complex Enterprise is harder than applying them to a photo-database or a blog-site (aka skinned database). No points for that one. Why do it? Well treating an Enterprise as a set of ‘resources’ with representations and behavioural contracts applied to attributes manipulated through a uniform, ubiquitous interface is a liberating experience on the design-slab. However when we come to take real steps we are beset by 2 key obstacles:

  1. Resource representations are abstractions of a complex information architecture underpinned by many diverse and evolving IT assets, so we do not have atomic control over the assembly of resource representations nor do we have atomic control over key-mastering and complex updates.
  2. The resource Namespace needs to support hierarchy to ensure we can correctly structure context around certain resource-types who’s representations may be context-aware. As such depending on who is looking at what, there is a complex resolution of the public namespace to a potentially complex EAI landscape within the black-box.

Are these problems insurmountable? Well I don’t believe so, but the resulting shape of the framework I’d use to achieve this is significantly different to the emerging frameworks (i.e. JAX-RS/JSR311, Restlet, etc) geared towards resource-enabling stuff. Why?

The primary reason why I seem to be diverging from the direction being taken by the framework guys, is simply that (…note to self…I’m not officially recognising options which would require me to acknowledge that I’m being stoopid 🙂 ) I need more dynamic processing in the mapping of a requested URI to a POJO/Controller. What does this mean?

Well – based on the 2 points I outlined at the start of this article the inspection, validation and refinement of my inbound URI’s are managed within a single control step, fed with meta-data and context info. Similarly, as I resolve a canonical resource (i.e. one which may be reached through a range of public namespace paths) I need to work out how best to ‘go and execute’ the require data-acquisition or functional RPC steps to implement the resource operation. Again – another control step fed with meta-data and context info.

What I end up with, is a processing chain from HTTP request through to Enterprise resource, where the namespace, URI resolution and method variations are simply parameters driving a more complex, dynamic integration broker. As I DRY up my code, I begin to refactor away from having explicit resource controllers be that at a class-oriented or annotation-based level.

Ultimately my ideal ‘REST’ framework is one which enables me to data-drive not only the production of a resource facade, but the linkages between those resources and complex integration/aggregation transactions, therefore imploding the more explicit genre of ‘REST framework’ in favour of a declarative alterative.

At this time I’m prototyping with SpringMVC Servlet/Interceptors and also raw Servlet/Filter chains, both of which are configured to have only 1 front-controller, and a series of processing steps as the inbound request is boiled down to a back-end transaction. The bulk of the manifestation of REST-oriented logic is meta-data consulted by the processing chain within the context of a user-initiated operation.

This is what I mean by Implosion of REST frameworks…


Villages, Cities and Whether SOA Is Hype?

February 18, 2008

Yet more circular debate about whether SOA is just hype or whether it offers anything of value. It’s addictive reading, not that I expect anyone to reach a definitive answer, but moreso to observe the correlation between the debating individual, the scope of his/her problem-space, and his/her corresponding position on whether SOA is hype or not.

The relationship between Enterprise Architecture and SOA (…and here I have just detatched a seprate thread about EA and Hype!!) is significant in my opinion as a result of the hugely important question of ‘scope’. The good old example of the difference between an Enterprise Architect and a System or Application Architect is the analogy with Town Planners and Building Planners. In simple terms Enterprise Architects are focusing at the optimal arrangement of buildings and utilities over a large area, whereas System/Application architects are focusing on the optimal construction of a small number of buildings and their optimal interfacing with the utilities they ‘assume’ will be there at some point.

 The crux of this debate is the fact that the title of Town Planner (Enterprise Architect) becomes subjective, and leads to people with vastly different problem spaces debating who’s strategy is best. Imagine the planner who’s never left the ‘village’ he grew up in debating strategy with the town planner from any major capital city? They aint gonna be talking the same language right? Give em both an ego, and boom….take cover.

The key point I’m making here is simply that there are some Enterprise Architects (aka town planners) who’s environment includes a large-scale problem-space (i.e. 1000’s of applications), and there are Enterprise Architects who’s scope is small (i.e 10’s of applications). I would argue that the latter would see less of a justification (as do those IT architects working on specific applications or infrastructure components) for employing a rigorous SOA discipline.

Given that SOA is more about formalising and decoupling the inter-relationships between organisational and IT oriented domains within the Enterprise (as well as the reliance on, and governance of technology standards in the implementation phase…notice I aint referenced WS* once to this point…) then it’s less attractive to those focusing on a narrower IT problem-space. Conversely SOA is hugely attractive to those battle-scarred architects who are engaged in a large-scale business transformation, in which SOA is predominantly as mapping and governance plane between a EA vision and a chaotic arrangement of legacy functionality, data silo’s and technology tribes.

So to my conclusions:

  1. SOA is not just hype. Too many people talk about this stuff too much too many times for it to be just hot air. I am NOT advocating you should open your door to the wolves vendors though, because it’s much more fun when you have a solid understanding of what you actually need…before you let a sales guy tell you how you should solve your complex integration problems created by the last stuff they sold you.
  2. To say SOA is hype is to say Enterprise Architecture, System Architecture and Software Architecture are all hype too…..where the fundamental problem is disjoint in conversational semantics and personal experiences. Empathise more. Listen more. Debate less about meaningless, subjective topics like ‘hype’.
  3. You can’t buy SOA you have to create it – and no 2 instances will be the same. New and expensive technology is an optional ingredient, from the same shelf as mature opensource, and the good old re-factoring options.
  4. It’s hard. You make mistakes. You learn. There is no quick win…

So, with best foot forwards I propose that we debate less about SOA/Hype, and instead turn our attention to a much more important debate of:

  • Which is the best color, Yellow, Fish or Very Small Stones? Discuss…

(p.s. if you are now blogging about how yellow is just hype you need to seek help immediately!)