Book
01/26/10 :: [REST] PUT vs POST [permalink]
My post on REST, Processes and Resources is the most read on ebpml, month after month (I am not sure who linked to it). I stand by every word in this post, but I would like to reiterate a truism that apparently even some of the most senior architects and developers seem to ignore.
Lots of people who have read about REST would tell you that the "resource representation" pattern is a great progress in information system construction, in particular because you can "PUT" the representation back. That's in line with the DTO pattern that CORBA or JEE aficionados are/were so accustomed to. Of course, they often pass on the fact that having a standard "Change Summary" definition as the resource representation would be a terrific feature to have, one day the RESTafarians will look around and discover (Stefan?) that the industry had already solved all these problems well before they even started to understand them: Microsoft came out with the DataSet concept around 2003 and later, in 2005, SDO generalized that concept in both Java and .Net world. But it is so easy to ignore all the work that has been done and start over. Right.
So here the argument goes, REST is great because I can PUT stuff back. Complete Freedom, they argue. This is what Bill DeHora stated a while back:
So, in a business process where GET and PUT (and friends) apply to *all* business entities and are not just per process defined methods, why can't I GET the state and have a well-understood formal document returned citing the state of that entity? Or for that matter PUT the updated state to that entity? What's the actual limitation induced by applying REST?
For those of you who still believe that PUT is all you'll ever need, let's look at the physical world: everything is in a "given" state. From the smallest particle to the heaviest piece of equipment. Each state has a well defined transitions to other states. I can't "PUT" a particle in any state I want, I can't PUT an elevator or a can of soda in any state I want. Actually, state is such a profound foundation in our universe that it defines "time". Time only exist because the universe can never return arbitrarily to a given state. If that were possible (who would decide which state to go to?), time would simply not exist.
Before you get too bored with metaphysical considerations, let's go back to information system construction. Information entities are like physical objects. First, they often represent physical objects and model their primary "States", if they are a more abstract concept, say like a contract, they nearly always have distinct states which control their lifecycles.
The question becomes how do you express the intent of transitioning from one state to another. I say intent, because, just like in the physical world THY SHALL NOT PUT STATE directly into the information entity. Yes there are attributes, say like the color of a soda can that can change idempotently and then there are attributes which represent the states of the information entity which can only be changed by the entity itself. The business logic that transitions from one state to another must be owned by the entity. If not? if not, terrible things happen when you have more than one consumer of that entity, you start duplicating the state/transition logic in the consumer of that entity. You get the picture. In the days we built monolithic systems, there was little value in correctly factoring that kind of business logic. In the SOA days - and I would argue the principal reason people fail at SOA - THY SHALL LET THE ENTITY DECIDE FOR ITSELF whether it can transition from one state to another. Most people do SOA and actually expose a Data Access Layer as a bunch of Services. They encourage people CRUDing. Worse, people like Dave (Microsoft) Chappell would tell you that the only thing that works is a "data service", SOA is a failure. I can safely say that he doesn't understand a thing about SOA. Now, when the RESTafarian like Stefan, Bill DeHora, Bill Burke, Jim Webber, ... come to you and encourage you to PUT up with CRUD as a key success factor for your "SOA", I smile loudly.
Now, people might tell you that PUT can express an intent, why not (Roy would disagree), they can tell you, but we use POST to encode all intent. I say why not, as long as the logic to transition from one state to another resides on the resource side, but have we gained? Nothing, we have just found another encoding (actually 2, PUT or POST) and we have lost so much (bi-directional interfaces, events, orchestration, we have coupled access and identity ...). So what is the point? What is the point of yet a new encoding? Browser access, ok, so what, do you need to displace entire technologies for that? Is that a game? I am amazed, in awe actually, at how such bogus arguments took hold in our industry, how little, nice to hear, stories ended up where they are today. Yet, REST is nowhere, no proof of any massive and successful use outside the browser.
So if you want to use PUT to the attributes that can change idempotently, great, if you want to use POST for invoking actions on a resource, even better, but don't tell me you invented anything. Information systems have been working on these principles for 8000 years. They didn't need computers, the Web, Stefan, Steve or Bill to figure that out.
The (other) REST is a fraud, and there is nothing clearer today.
01/16/10 :: [MDE] Solution vs Problem Abstractions, does it matter? [permalink]
As Google just launched a "new" programming language (what for?) more and more people are asking about and somewhat demanding better abstractions. The question is should they be problem or solution side abstractions or possibly both?
Udi recently complained about solution side abstractions:
If we want our architecture to be stable, we need to base it on stable abstractions. The only thing is that there aren’t any inherently stable abstractions in the solution domain (as we’ve had the chance to witness). That really only leaves one other place to look for them – in the problem domain, also known as the functional requirements.
Udi believes that the solution is on the problem side :-):
If we could find a way to capture those stable elements and represent them as core elements in our architectural structure, and then balance the non-functional requirements within those functional contexts, maybe, just maybe, our architecture will stand the test of time.
His position is quite ironic as the BPM punditocracy interprets the current wave of acquisition of the BPM space as a "the end of BPM" as we know it. This particular rash of BPM products built their business on the fallacy that you could somehow build solutions directly from "problem-side abstractions", i.e. BPMN. Ten years later, we are still waiting for large enterprise deployments where all business processes are somehow implemented from problem-side definitions. These vendors have for long claimed victory, this is somewhat of a Phyrric victory for our industry. Sincerely, I am glad they are going away. They have taken away tremendous resources, delivered hardly anything, and prevented the right solution-side abstractions to emerge. I have had some discussions with Keith and Scott on that topic after Keith detailed the "process trends" he saw unfolding in the last 20 years.
These "process trends" are precisely the problem you are going to face if you go find your abstractions in the problem space. First you will never succeed at converting problem side analysts that can achieve the level of rigor necessary to build a solution and because you will adopt their language, you will have less than optimal abstractions to build the solutions. The little known secret of "BPM" is that once you quickly pass the pretty (process) pictures, when you look under the hood, you see all kinds of ugly scripting language dropped wherever possible. Scott thinks that JavaScript is the "ideal" complement of BPMN. Anyone who has written more than 10 lines of JavaScript understands what I mean, and JavaScript is possibly one of the better ones I have seen over there.
So Udi, I am sorry, but starting on the the problem side has been tried and it's a mess. Developers will never be able to design abstractions that make business analysts comfortable, they need freedom and fuzziness. They want the solution side to build the solution, not them. Hence, the problem-side needs a) as fewer abstraction as possible and b) (what is the most important) whatever runs in production (once the problem has been solved) must be "visualizable" by the business analysts. That is the most important direction: solution->problem, not the other way around. So far, the problem->solution is just a pipe dream, an immense distraction for our industry and a general failure.
There is another reason, more fundamental, for why abstractions (problem or solution side) cannot emerge. If you spend some time exploring Ecore in EMF (or MOF in UML) and if you look at EMF's M3 layer (i.e. Ecore):
You can see that, the center is the "EClass". Just like in MOF, the M3 layer is OO based. OO is the enemy, sorry, I can't find another word. There is nothing abstract about OO and there is nothing architectural about OO. OO is a tiny little pattern which success is out of control. Actually, I am a bit unfair. I teach mathematics to my kids using UML. So, yes OO, provides a generic modeling capability to describe systems statically, or static abstractions. At a certain level, everything is a bag of attributes with relations to other things. But you can't efficiently describe dynamic systems in OO, the behavior is an after thought in Ecore and OMF, well beyond the OO cave.
Udi, look no further for the problem you see in creating solution side abstraction. Static solution side abstraction are not very common. Once the modeler realizes that he or she needs behavior, that's when he or she starts throwing a scripting language into the mix and everything becomes ugly, impossible to dissociate from the underlying architecture (the script has to run somewhere, call some APIs...). Once your abstraction is tied into an architecture, you know what happens next. I have raised this concern with some of the fathers of MDA but I always a distant glare and no response. I may be wrong, but IMHO, MDA is built on the wrong foundation, OO. It is going to be hard for them or for the OMG to change course, but there has been enough surges in that domain to think the solution to MDE is more OO.
I like textual-DSLs because they are conducive to modeling behavior in addition to the abstraction. You tend to create your own programming language along-side the abstractions. This is why I was generally excited about SSM and things like MService. Note that people understand the problem, some people have shown how to extend Ecore to model "code" as well. But I think OO is the problem, abstractions need to exist completely outside the OO cave. This is why I suggest to adopt a Metamodel Oriented Programming approach.
I am certain that this problem will be solved in the next 10 years and that the abstraction will be more on the solution side, completely outside the OO space.
01/03/10 :: [Cloud] The "Techtonic" Shift of 2010: the iTablet [permalink]
I don't know about you, but I feel ripped off. I got the incredible opportunity to live to 2010 and I feel except for a couple things I can only buy technologies that were mostly available 10 years ago. I don't know what Apple will release this month. Some talk about the iTablet, but it will certainly look like an iKindle, a larger iPhone. Whether the geeks like it or not, the computer has become a consumer product, driven by consumers who want to do what consumers expect to do, i.e. they never dream of becoming a sysadmin. The devices of this decade will be designed for humans by humans, not for geeks by geeks.
So what will be the characteristics of the devices (not computers) of this decade? That's quite easy:
- touch, touch, touch
- apps, apps, apps... hu?... I mean connected apps
- location, location, location
- no sysdamin required
Many of us would feel that this is back from the future, but let's face it, just compare using a browser based app and an iPhone app. Not convinced? Do you use Netflix? Just compare browsing Netflix with a... web browser and Microsoft media center. You get the picture, right?
In 2005, I was making fun of Microsoft's "SaaS" strategy. Shortly thereafter they changed the course and came out with a "Software+Services" strategy. Yes, that was the right move, but we all know how well Microsoft executes strategic moves.
In this new landscape devices will be easy to use, loaded with "apps+services". The browser is out, whether you like it or not, we are back to the wonderful idea of multi-platforms. Did I talk about form factor of an app? Cheap, small, downloadable. The "price" of an app: $1 or $2 sound reasonable, well suited to a mass market of hundreds of million of people. Who's going to buy a $60 box+DVDs running on an operating system that requires a Geek Squad just to keep running?
So here we are, at the onset of a tectonic shift (it has already happened, it will just become visible). Who's going to win? We know that won't be Microsoft, unfortunately for Seattle. Successful people at Microsoft are too busy boating and driving their fancy cars, they never use their own product, let alone watch how people are using them. Google may have bet on the wrong horse, the browser may be laid to REST in this decade. That prediction is easy to make: finger stokes are not RESTful and JavaScript can't access "local" information (accelerometers, location...).
So Steve Jobs may have done it again after the Apple II, the Mac, the Laser Printer, NeXT, the iFamily is breaking our industry's mold. Well done Steve.
If you want to see the future, just look at this app, that one too. Now, look at your browser...