Tuesday, January 09, 2007

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: , ,

11 comments:

Anonymous said...

Steve,

Interesting post. When I was reading it, I was thinking about Thomas Earl's book "Service-Oriented Architecture: Technology, Concepts, and Design". One of the methods he advocates in that book for creating web services, is to create "entity-centric" services, or those which are based on objects, and he argues that these are usually more reusable than a "task-centric" service. Although I initially liked his argument, after considerable thought and discussions with others I don't like entities all that much, because they are not that understable sometimes since they don't correlate well with business processes, and like you are saying I believe they don't always make sense in the real-world. You are saying though that this applies to REST, and Erl's book definitely focuses on web services... do you think it is ever appropriate to create services based on entities/objects then?

Regards,
Matt

Anonymous said...

I'd suggest taking this to the rest-discuss mailing list. Your ideas about RESTful design are pretty simplistic (and wrong). I won't go into too much here but employee "objects" would not have pay "methods". You would more likely have a separate resource that processed (probably via POST) payment resources that referenced employee resources.

You could learn a lot by taking these scenarios to the list and letting people help you through the design process. Specific scenarios are generally met with lots of discussion as opposed to non-specific, high level stuff so you're already moving in the right direction.

I'd also suggest reading a bit more into what Joe Gregorio was talking about in regards to the stock quote service. I'm fairly certain you're making a bunch of assumptions here since he was talking about stocks as in stock in companies and their current and historic price. Your example refers to stock of goods in a warehouse.

Steve Jones said...

Matt,

I'd say that some entities can be worthy of having their own services. In Snowboarding SOA I talked about different elements as services that are resources, a lift is a great example. Its automated and you really do "GET" on the lift :)

Ryan,

I'm clearly "learning" REST right now, I was aware that yet again the Stock Quote thing was being used as an example which is why I shifted it to a more physical reality scenario, which better illustrates the challenge. You are right that no-one should model employee with payment (but I've seen that done)_ but the question on both the stock service and the payroll service is what is the "resource" that is being invoked. If a business department and its functions is considered as a "resource" then there really isn't any difference at an architectural level between the term resource and service. I'm struggling to see what a "resource" would be that would take "payment" resources that reference employees as a payment is a temporal entity.

The point of the article that I referenced was that it claimed that resources did everything and services just did discovery, this is a mistake. A link to the REST-discuss list would help BTW.

Anonymous said...

You would never have a 'pay' method on an Employee object or resource. It's not Employees that do the paying it's the Accounting Department in any real business. The way you would model this in REST (and in OO) would be to create a Payment resource/object and POST/add it to the Accounting Department list of upcoming payments.

Steve Jones said...

So what you are saying is that there are higher order controlling elements (services) which act as co-ordination points for business logic and business level transactions. I'm not disagreeing, in fact that is exactly what I was saying. The article I referenced however delegate services to purely a discovery approach.

This is my point, you need to think about those things that can be modelled as entities/resources and those things that need to be modelled as services.

Glad we agree

Anonymous said...

Steve,

There is no meaningful distinction between entities and services. They are all 'objects' and they are all collections of behavior and state. This is just like Resources in REST. I think this distinction between entities and services will lead only to bad OO design and bad REST design. I'll blog on this more later at http://blogs.concedere.net:8080/blog/discipline/

Steve Jones said...

You can argue that a service is "just a grown up object" but conceptually I'd argue that there is a fundamental difference between an object/resource and a service. An object or resource represents a real world "thing" a physical entity that has, as you say both behaviour and data, a service however represents a real world "what we do", so while both could arguably be considered as having data and behaviour the principles, goals and conceptual models are different.

Object and entity modelling works well in the small to medium scale but is a nightmare in the large.

There is a difference between service and object/entity/resource in the same way as there is a difference between an employee and an HR department, considering HR as an object/resource is a brave choice.

psd said...

Yes, REST is far more OO than SOA, with or without the evil, broken EPR

Anonymous said...

Its a very nice blog for...
architects in bangalore , architects in bangalore , interior designers in Bangalore , interior designers in Bangalore , architects in bangalore , architects in bangalore , interior designers in bangalore

Knowcow said...

If you model the business process correctly using the OO methodology there won't be any need for services which are really procedural calls to be frank. The collaborations of objects will in the real world as well as in software systems which will give the illusion of work being done.

Steve Jones said...

I'm sorry to say that just isn't true, that is exactly the purist mistake I mean. It isn't collaborations of objects that really drive the real-world its the collaborations of people and services. Does an invoice 'collaborate' with an order? No its the procurement, shipment and finance services that do the collaboration.

Services aren't procedure calls, they are containers for capabilities (which might look like procedure calls) which includes governance and management, basically a service is a object that has grown up and got real responsibilities.

Most crucially an 'object' in one service domain does not have the same behaviour or information in another service domain. A customer for sales is different to a customer in finance.