I've been arRESTed!
Yes apparently my babble is causing unREST.
Mark Baker thinks I speak rubbish in my Poor Service Semantics post.
But Mark is just shifting around where the semantics of what your doing is. That's all. All this RESTing has him confused. ;-)
Look when you get down to it everything (in this service world) is just a string coming over the wire. Web services, REST, CORBA etc. are just arguing where the unwrapping of the string occurs.
Take CORBA for example. When you look down into it there is basically one operation called a Request that puts a big blob of data (a document?) on the wire. At some point the data gets unwrapped and examined and a dispatch to piece of coded logic (the business) occurs. So is CORBA RESTful?? Is the Request just really a PUT in disguise?? ;-)
Either you have one location and you put and the semantics of what your doing (the operation) in the document - e.g. orderItem. Or there is a different URL location for each operation. So either the document semantically tells you what you want to do (and you still need to dispatch to the right code) or else each location only performs one operation and you only send the data there. Actually the former sounds very like CORBA ironically. I.e the CORBA dispatcher sends the data to the right location of the business logic. ... But then so does the later. Wow CORBA is definitely not supposed to be RESTful but sounds like it. (I'm being factitious) The reason can you look at it both ways is that again at some point you need to dispatch a piece of data to a specific piece of code and at that point it becomes very "tightly coupled" no matter what the technology. Is a RESTful internet just a big ORB? Well I'm sure many of the REST folks would just say so.
I get back to my point. Everyone is getting bent out of shape about this and really it's just a matter of where the big string of data gets unwrapped and who wants to do the unwrapping. But when you do pick a particular technology to do your unwrapping then you take advantage of the capabilities of that technology. And in CORBA a runIT (in String blob) where there is a dozens of business functions hidden in the string, is definitely not taking advantage of the underlying infrastructure and a waste of money.
The big issue not whether a PUT or orderItem is better. That depends on the technology being used. If REST provides a great framework for maintaining, tracking, documenting etc. the real location and semantics of the operation then I think it's great. I can definitely see where REST makes a lot of sense. There is a LOT of waste and misunderstanding in other technologies. (There is a whole lot of complication in CORBA that I thought made it inaccessible to many developers and would drive anyone to a more RESTful state of mind).
Imagine if the anchor tag of a hyperlink didn't allow you to specify any source. Imagine if it had an implicit "GET" as the source. So on ay web page the only semantic you had was "GET" as the link to the underlying href. Hyperlinks would be rather boring and not very well documented. And that's my point the semantics need not only be there for the operation but also for understanding the way the business works. Where the semantics are depends on the technology used and how rich it lets you document those semantics.
I'm looking forward to understanding more about how that works in REST. Perhaps it's just brilliant. Remember I was the one advocating using RSS feeds as a service lookup repository instead of UDDI a few months back. Boy it doesn't take long to fall from grace.
IP Babble is the personal blog of
Comments
"Either you have one location and you put and the semantics of what your doing (the operation) in the document - e.g. orderItem."
You're missing the difference, William. With REST, there is no operation in the document. It's just a document. Like a purchase order, or an invoice. The operation would be POST. e.g. POSTing a pizza order to a pizza order processor would order you the pizza. There's no explicit or implicit "orderPizza" operation being invoked there. POST is the operation.
The "string" view of th world which you used, hides the important architectural advantages gained when all your services expose the same, general interface.
Posted by: Mark Baker | March 11, 2006 08:59 AM
Hi Mark,
No your missing the difference Mark. At some point you have to open up what is POSTed and at some point you have to do some business logic.
No EITHER where you POSTed it defines what is to be done (as I think your saying) or it must be in the document.
I cant be sending multiple types of documents to the same place if there is no semantics in that document as to what to do with it. In that case the type of the document might define what must be done or something in the document.
But if I just send XML and the type of document isn't defined or there is nothing in the document that says what it is or what to do with it then the only other way is to POST it to a unique place that is always going to process the same way.
The semantics must be somewhere Mark. Where is it???
If I drop a letter in your single mail biox (the one you have such a pretty picture of on your post) then whats in the envelope defines what your going to do with it. You could perhaps pay the mailman to put different types of mail in different mailboxes (bills in one, junk in aother etc.) but then your pushing the choice out to the mailman (kinda the middleware here). In your house I bet that you sort the mail when it comes in into bills, junk, personal etc.
But somewhere, somewhere, a choice must be made as to what it is and therefore what your going to do with it. It's not magic. Though sometimes the middleware or infrastructure makes itlook that way.
Posted by: William Henry (IP Babble) | March 11, 2006 11:43 AM
Actually Mark. You said it yourself its a specific document type.
The document type then defines what you do next. You then dispatch that to the appropriate code. This can be done my your program or by the infrastructure.
IT's all the same thing. We're just arguing where it gets done and who does it. And REST might be just the right infrastructure to do it.
What I said was that if you are using an infrastructure like J2EE or CORBA then you would leverage it's ability to do this for you. If your using REST then you would do it differently.
But a generic operation like runIT( in String) in CORBA or J2EE etc. is waste. It's waste Mark.
It might be different in REST but here it is waste.
Posted by: William Henry (IP Babble) | March 11, 2006 11:49 AM
To me this is an apples-and-oranges discussion and has very little to do with SOA.
First, CORBA is a distributed object technology. Objects are not just RPC's. Objects have a lifecycle, an identity and a state; and this makes them good for solving certain types of problems. By lifecycle I mean, an object is created, lives a (hopefully) useful life and then is destroyed at which time the object's resources are returned to the system. By identity, I mean you can get a unique identifier/handle to a distributed object and share it with others, and if they use it then they know they are communicating with the same object you were communicating with. And of course objects have a state which means they can remember what happened to them and this is very useful for solving certain types of problems.
In many ways REST is the anti-thesis of distributed object technology (which is neither good or bad, just diffent). With REST we separate computing and state (unlike distributed object technology where they are combined). With REST, a document represents the state of a resource and the network computing nodes are available to process them.
At the end of the day, these are two different paradigms and each one of them has created a set of concepts suitable to that paradigm (for example, CORBA allows value-objects to be used in defining the interface to a method - seems like a good choice on the part of the CORBA designers) and moving from one to other requires a paradigm shift.
Now the question is "what is the 'right' set of concepts for defining a SOA" and in my opinion neither CORBA nor REST is the right answer to that question.
Cheers
Greg
Posted by: Greg Lomow | March 11, 2006 10:27 PM
Why is generic a waste? As I discussed before, is submitPizzaOrder() more of a waste than submitPepperoniPizzaOrder? What about submitOrder()? submit()?
I suggest that more general = more reusable = more useful = more loosely coupled.
REST means interfaces are maximally general, aka uniform.
Moreover, *all* of the largest distributed systems we've ever built have used general operations. Coincidence? Of course not.
Posted by: Mark Baker | March 12, 2006 07:24 AM
more general = less type safety & more work on both sides of the implementation.
some specificity in the definition of an operation is effectively self-documentation. potential users of generic operations must rely on disconnected, possibly incorrect design documents to understand what submit() means in every context.
Posted by: Jody Hunt | March 13, 2006 01:08 PM