Recently in REST Category

More RESTful clarity

| No Comments | No TrackBacks

So I talked, well actually chatted via instant-messaging, with Steve Vinoski and I do need to clear up some points from my last blog entry.

Steve pointed out that RPC does NOT require synchronous communications. This is true. One can simulate the request-response of a remote procedure using asynchronous communications. But the idea is that RPC appear synchronous - like a programming language procedure that blocks.

Some synchronous technology can appear asynchronous. E.g. CORBA has oneway operations. And many queue based (messaging) technologies use connection based technology underneath. E.g. Some publish subscribe technologies are actually connection based. The publisher connects to the notification service and so does the subscriber when retrieving messages. They are asynchronous to the application in the sense that they are decoupled.


Shame on me for not delving into this deeper, sooner. It was high time I took on some of the myths in the REST community again.

First let me say that I like REST. I think the architecture makes a lot of sense in many cases and I look forward to implementing my first RESTful services(s). Having said that the REST community don't do themselves many favors with the enterprise community, especially those that have been around the block several times and have built several flavors of architectures over the years. We know our architectures -we know our terminology. It seems the REST guys confuse some terms. So I'm going to target some areas to help unravel the muddle.


I thought it would be useful for some people if I gave a brief overview on what my take is on JBI, WCF and SCA. Remember this is my take. Research it for yourself using the links provided.


I've been arRESTed!

| No Comments | No TrackBacks

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.

Who is IPBabble

William Henry IP Babble is the personal blog of William Henry.

William has 20 years experience in software development and distributed computing and holds a M.Sc from Dublin City University. He is currently working in the office of CTO at Red Hat on the MRG product. This weblog is not funded by Red Hat.

Posts are intended to express independent points of view, but understand that there is probably a bias based on the influence of working with standards based middleware for over a decade. (See disclaimer below)

December 2008

Sun Mon Tue Wed Thu Fri Sat
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

Disclaimer

The views expressed in this blog are solely the personal views of the author and DO NOT represent the views of his employer or any third party.

About this Archive

This page is an archive of recent entries in the REST category.

Red Hat is the previous category.

SOA is the next category.

Find recent content on the main index or look in the archives to find all content.