REST makes the OO purist mistake

Reading a post about Thinking about REST I suddenly realised one of the things that I didn't like about REST's view of the world, its the concepts that resources can always "do" things on their own. This is one of the big challenges that people tend to come across when doing object modelling and I really hope that REST isn't (in the traditional way of IT) revisiting the errors of previous generations.

The line that brought it home to me was

5. Services are seldom resources. In a REST design, a "stock quote service" is not very interesting. In a REST design you would instead have a "stock" resources and a service would just be an index of stock resources.

Now the point here is that the idea is that the "stock" resources are able in themselves to perform the required actions of their consumers.

First stage is to take a step back to explain what I mean by the object purist mistake.

The scenario is this, you are modelling a Payroll system and you "know" that objects contain both the behaviour and data for everything in the enterprise, everything that isn't an object is just about looking for objects, all functionality and business logic must be implemented in an object. This then leads to an "Employee" object which contains the method "pay" which enables that employee to be paid, the payroll process therefore just loops through all the employees hitting the "pay" method and all is fine.

The problem is that this isn't how a payroll system works from a business perspective and it certainly isn't how Employees work in the real world (imagine if you could pay yourself, whenever you wanted, and were in control of the amount to be paid). The point here is that certain pieces of business logic work at a higher level of abstraction than objects and you need something else to co-ordinate those elements and apply the business rules that are specific to the business rather than the employee.

The REST example above is making the same mistake, but using an even more obvious example to prove it. Think about a piece of "stock" sitting in a warehouse, even if we say its "smart stock" and its got a sensor tag and an RF-ID tag on it there really isn't much that a box can actually do. You can ask it questions like "what are you" but its not actually possible for a piece of stock to be ordered, it can't pick it self up, it can't write a shipment note and it can't drive a van.

Asking a piece of stock to order itself doesn't make sense in the real world and modelling something in a "pure" way in the virtual world that doesn't represent how businesses actually work is not a great idea.

Now what could work is exactly the same as what worked with Objects, namely that you have a service providing discovery, co-ordination and higher level business logic capabilities with the resources providing that information which is relevant to the specific entity. Limiting Services to just discovery and trying to shoe-horn logic into a resource that doesn't belong there is liable to lead to a system that is unable to match the changes of the real world specifically because it doesn't model how the real world works.

"Pure" models don't work, its why lots of economics is bunk as it assumes that people don't exist and then the theory holds, IT must not fall into the same comfortable trap of beholding a system as conceptually elegant when logically and physically its a bust.

Technorati Tags: SOA, REST, Service Architecture

SOA, Mashups and the importance of Virtual Services

With all the talk of SOA and Mashups and SOA and Ajax its nice to see that the general consensus is that SOA and Web 2.0 work well together.

With this in mind I thought I'd revisit something from the SOA Book and the OASIS paper around virtual services. The concept of virtual services is pretty simple

Virtual Services should be used where a collection of internal services is combined to provide an external view for a customer, thus creating a "virtual service" that is one which provides no direct business function but which offers a facade over those services.[...] Virtual Services therefore provide a way to indicate where business logic can be co-ordinated and potentially simplified.

As people are beginning to look more at Ajax and Mashup applications on top of SOA infrastructures I thought it was worth going over some of the guidelines and rules for what virtual services are and how they should be used.

The first point is that a virtual service is not a trivial thing they can be immensely complicated beasts in their own right, for instance a voice based processing interface and can do some fairly complex aggregation of information. This is however different from actually handling the processing of the information itself. So a virtual service should be pulling in information from various sources, creating the most effective interface, whether via REST, WS, Ajax, Flex or something else and then delivering that to its consumers. So some basic rules for Virtual Services

1. No business process should be managed in a virtual service
2. No transactions should be managed in a virtual service
3. No comparison based validation of content should be done, only validation against data format (schema)
4. Virtual Service should be focused on the consumers view of the service
5. Virtual Service should be subject to "light touch" management
6. Virtual Service should be focused on the presentation of information and not its processing
7. Always enable mediation to be done between the virtual service and the services it consumes

Think of these Mashup applications as virtual service which contain the page flow and the information aggregation and representation but which forward the information for processing to the "back-end" services. In effect the Mashup is the bloke on the till at Burger King and the services are the people behind the bin flipping burgers.

Technorati Tags: SOA, Web 2.0, Mashup, Service Architecture

Why Quality of Service depends on the Consumer and the Producer

One of the things that is often over looked when people consider quality of service is the impact of the consumer on that service. Sometimes, rarely, people consider the concept of "high value" customers and the idea that these should have some form of "fast track".

There is however another piece that impacts on both the cost and the quality of service, and that is the ability of the consumer to subvert the "standard process". Returning from our Christmas break we had one of those annoying "bugger its broken" moments on something we pay a monthly subscription for. Basically the hardware is shagged but because its five years old we now "own" it and the buggers are trying to charge us about 70 quid (500 dollars by the start of 2008) to "fix" something which probably doesn't even cost 30 quid. I'm on the phone for about 30 minutes pointing out how this isn't fair.

Then in steps the Mrs with a "oh god just give it to me", twenty minutes later we've got a contract upgrade, better equipment and its costing us 50 quid to get something we thought about spending 100 quid to get and to get everything else all sorted.

What my wife new was that playing poker with these folks involves the "bluff" of canceling the contract, this means that she gets a much better quality of service than I do as I tend to follow the rules of "what is said to be available".

The point here is that while a system might have a perceived process, indeed a process which the server side wishes to enforce and that a rigid enforcement of that process can lead to lower customer satisfaction and potentially reduced value being handled by the service.

What this means is that it is actually not up to the server to purely dictate a straight process and response to the consumer it is up to the consumer and producer to negotiate the right result for both parties a QoS policy that assumes that the producer is the final arbiter of quality is liable to produce a very unfriendly service and one which doesn't interact with people in the manner which they wish.

Its fine for the service to give you three options, but if my wife can't find the fourth then we'll be going somewhere else.

Technorati Tags: SOA, Service Architecture

Hey Ma look at me! I do SOA now.

One of the worst things about SOA has been the band-wagon jumping by vendors. These have fallen into broadly three groups

1. Hey look something new, bugger its not technology, quick lets develop some implementation stuff and claim the badge anyway.
   
2. Hey look its a techy thing, we do that already don't we? Quick jig and bob's your uncle.
   
3. Bloody hell that has a lot of Buzz, lets slap some lipstick on the pig and claim its SOA.

The first group include the likes of IBM, BEA, Oracle, SAP, Sonic and a few others. Companies that have recognised that they don't have the current products to do the business impact side of SOA, but have at least recognised that their technology stack needs to be different to older style technologies (I'm talking about IBM product here BTW not things like CBM). So Oracle have actually built middleware, IBM have abandoned the old MQ based technologies for new development and BEA have clearly split application development from business as a domain. I'd lob REST in this group too. Behind the scenes they'll all say that they see the business thing, its just that they can't see how to build or flog products that do that right now.

The second group are the EAI vendors and the vendors who had some sort of "component" based approach and are just seeing XML and WS-* as another implementation pattern. They've pretty much decided that its a techy thing and its just another protocol for them to handle. These are the people who can't believe their luck. 2 years ago no-one was buying EAI, suddenly its an "SOA stack" and its popular again. At least these folks though are misunderstanding within a specific context (technology), they say that SOA is important, they just tend to stress technology and implementation more than the first group, often because they can't afford the re-development costs. They too see the business thing, but they are even further away from being able to do it than the first group.

The third group is the worst though, these are the people with a particular world view and a particular line to pedal who decide that "SOA cannot be done without X", linked from this post is an article by IDS Scheer on how SOA "requires" BPM, indeed how SOA "starts and finishes with business process". IDS Scheer are far from being alone in this group, but this is a cracking example of the sort of thing that is wrong with IT.

Here we have a paper in 2006 that actually does the WS = SOA thing, something that actually proposes that Services should be created bottom-up and it is process, including the execution level processes that drive and define SOA. I've talked about POA v SOA before but to be brief, if you start with process and do process based definition then you are doing POA and are 100% not doing SOA. On page 95 of Enterprise SOA Adoption Strategies I discuss how business process works in an SOA context (and the similarity of process & service at high levels of abstraction), but this isn't want IDS Scheer or the other "business" modelling tools are doing, what they are doing is taking exactly the same model they had before and just going "hey look if we consume a WSDL we are doing SOA".

This last group is easily the worst and most disreputable, particularly as they claim that they can model businesses effectively and are the most disconnected from the technology. Their claim that they are a requirement for SOA without actually offering anything that is SOA is quite gobsmackingly bold faced.

Anyway I hope everyone has a great break and comes back in 2007 ready to face SOA as a business challenge rather than as just technical implementation. Oh and to people around the world, there are two British Christmas things that you need to get, firstly Christmas Crackers and secondly Mince Pies. Christmas isn't Christmas without gunpowder, a silly hat and alcohol laced titbits.

Technorati Tags: SOA,BPM, Snake Oil,Service Architecture

The perfect SOA environment?

At my department's Christmas bash last night the discussion was many and varied, ranging from the stupidest thing we've been asked at US immigration (an impossible to judge competition due to the level of entries), getting a bill through the houses of parliament to starting off in IT and your first language/OS.

Well my Boss cracked up with his first platform and it enable the dynamic provisioning of services, each service ran in its own dedicated partition and could be tuned, upgraded or deployed independently of all the others had a rigid definition for these service environments while enabling efficient communication via distributed shared memory and clustering. Development could be done in various different languages and still run on the same common platform.

So what exactly do modern platforms have over VME(Virtual Machine Environment), isn't this exactly what efforts like VMWare and the Hypervisor on Intel chips are trying to re-create today? While the concept of containment and deployment of individually active services sounds very like the goals of SCA.

This is one of the major reasons that SOA can't be about throwing away old systems and replacing them with new technologies. VME, if architect correctly, could act as a very efficient way of delivering certain types of services in an organisation, similar claims could be made for LPARs and other "older" technologies. If they are working and delivering effectively against the business goals, and are actually providing facilities not currently available in "modern" environments which are helping management and control then take advantage of that rather than ripping and replacing.

The perfect SOA environment is heterogeneous and takes account of what you already have and what you need to do, and is managed and evolved in line with the services and capabilities of the business. The worst is one where technology is being used as the driver and words like "Web Services", "REST", "BPEL" and "WCF" are being used as justifications.

Technorati Tags: SOA, Service Architecture

Sad but it is December...

A simple game of blog tag for Christmas, on Sunday, Jeff Pulver started a game of "blog-tag" in which participants are asked to share 5 little known things about themselves, and then tag 5 people on their blogroll. Well as per the headline link I got tagged and hell its December.

Okay here are my five

1. I hate horror films
   
2. I'm nuts about snowboarding and watersports, I don't just mean I like them but that I'll drive 5 hours from SFO to Tahoe for 2 days and catch the red-eye to Toronto when there are only 5 open runs at Heavenly type nuts
3. Every father in the world thinks his kids are the best... but only I am right
4. I think Java (and all other C syntax languages) are rubbish, and much prefer Ada/Eiffel
5. I met my wife in an Irish Pub in Paris, we went to a club, chatted the night away ended up walking along the Seine and then having breakfast in a little cafe just across the river from Notre Dame.

So who shall I tag... well why not Stefan Tilkov, Mike Morris, Andy Hedges, Dan Creswell and Cliff Richard?

Technorati Tags:SOA, Service Architecture