SOA Grammar – Are Services Verbs or Nouns?

I'm not sure that these two choices are the only ones available.

A RESTful interface could produce and entity that has a field "Status:READY_FOR_APPROVAL". A consumer of the interface could post back the entity with "Status:APPROVED". The service will the determine the value change, and make any required validations, then take appropriate action.

This avoids both Task style or OO style API's, and is fundamentally stateless.

This may not seem a natural paradigm, but neither was OO when first unleashed on a function+structure world.

Jason:

it does not matter how you "encode" the approve action. All that you are explaining is strictly (and only) equivalent to :

myOrder.Approve() (you POSTed to /orders/myOrder)

REST is fully object oriented with a global naming service and a ubiquitous ORB. There is nothing service oriented in what you are explaining, it is all Distributed Objects.

Service Orientation is about constructing systems with technologies that support bidirectional message oriented interfaces, explicit separation between interface and implementation, asynchrony, forward compatible versioning, extensible data models, orchestration, assemblies... None of these technologies are available in REST.

As a reminder there is no "service" in REST (I am not sure what you are talking about), REST can only yield synchronous interactions, cannot support versioning, since there is nothing to version, REST is bolting access to implementation. REST is not message oriented, it is RPC all the way.

I'm not sure that these two choices are the only ones available.

Service is never a noun, its either a verb or a collection of verbs and the difference between what Jason calls Entity and Task services is the amount of methods that they are exposing.

it is all Distributed Objects.

REST is bolting access to implementation. REST is not message oriented, it is RPC all the way.

Dilip:

no I really meant object. /orders/myOrder is the instance of a class object. Its methods are accessed via encoding them such as:

myOrder.submit() -> POST /orders/myOrder/submission
myOrder.cancel() -> POST /orders/myOrder/cancellation
myOrder.ship() -> POST /orders/myOrder/shipment
myOrder.getStatus() -> GET /orders/myOrder/status

There is no viewpoint flip, there is just encoding. Unless you want to name this silly encoding the "viewpoint flip". If you don't encode the class's methods, you are simply CRUDing the state of the object directly, which everyone will do, even though they know it's bad.

Before you know it a smart developer who wants to make a name for himself or herself (and frankly tired of doing all this by hand) will create a code generation framework that transforms classes into RESTful calls, including the serialization of standard types (dubbed resource representation) like in the good old days of SOAP RPC.

The only reason behind REST-* is to provide a specification of OTS (still missing in REST), then the picture will be complete for the old CORBA guys. They will finally have achieved an unbreakable ubiquitous Distributed Object model, sweeping under the rug a decade of innovation of Service Orientation.

JJ:

no I really meant object. /orders/myOrder is the instance of a class object. Its methods are accessed via encoding them such as:

myOrder.submit() -> POST /orders/myOrder/submission
...
There is no viewpoint flip, there is just encoding.

So if everything is "just" encoding, could the RESTafarians leave the REST of us alone? For instance, this is how Microsoft implemented REST (transcoding WS-* isomorphically to REST).

RPC is defined by the degree of loose coupling between the interface and the implementation. I have explained in this post a long time ago how strong of a coupling the server-to-server REST was introducing, while it offers a nearly perfect loose coupling in browser-to-server scenario.

At the end of the day, REST offers some canned loose coupling capabilities (routing and caching) but it exposes directly what I call the "internal" interface, the main characteristic of RPC based technology.

What the RESTafarians don't understand is that SOA has introduced an explicit separation between the interface and the implementation (the external and the internal interface). That is not RPC. Of course the vendors decided that it was not RPC enough to their taste and they quickly made sure you could generate WSDLs from Java or .Net classes. This is for instance what InnoQ as they presented recently in InfoQ.

Unfortunately, the very nature of REST that creates a virtuous circle by transferring the internal interface of the resource to the browser induces the very nature of RPC and the strong coupling in case of server-to-server scenarios.

Hello Jean-Jacques.
Sorry I disagree with you, not in the facts, but in the concepts.

1. Yes, web services in general (not only those "RESTful") are made RPCish by tools. My Battle story is actually the WRAPPED thing the they made up to convert truly document style into RPC style, by actually modifying the document! Worst coupling cannot be achieved.
Still, that is NOT REST. REST has nothing to do with objects nor RPC. People that are trying to do services without SOAP, said they will do them REST, and they then started creating the same horrible things like RPC and object distribution into HTTP (NOT REST). SO, you are right on facts, but wrong in the REST concept.

2. Not quite agree of your definition of RPC. To me it generates coupling but is not defined by it. Now, server-to-server coupling is due to bad design. In REST you have a client-server based style, that means you have two components, one is someone offering some services, and the other one consumes them (NOT the same Service concept here, careful). Later, abstraction in communication says you have a client that can perform operations upon a resource. So, a server-to-server is not quite a good abstraction, thus it is probably bad design.

Cheers!

William Martinez

Now, about the post.

God!, There are only two ways of doing services? Just thinking of them as Objects, meaning collections of methods? When in time the concept of an object was changed to just a library?

Or... Think of them as verbs? No way! I have never though of a service as a verb, an entity-less operation!

Services are like live processes. And they should never receive action commands! They get documents, period. They should check those documents, and respond accordingly. If you do anything else, like commanding actions or calling operations on a service, you are just creation a distributed library, not even a distributed object system.

William Martinez Pomares

JJ:

I read your article, and though it does a nice job outlining the problems with reliance on out-of-band change management in RESTful services in regard to message schema's, versioning etc. ...

RPC is defined by the degree of loose coupling between the interface and the implementation. I have explained in this post a long time ago how strong of a coupling the server-to-server REST was introducing, while it offers a nearly perfect loose coupling in browser-to-server scenario.
...
At the end of the day, REST offers some canned loose coupling capabilities (routing and caching) but it exposes directly what I call the "internal" interface, the main characteristic of RPC based technology.

Ah... wait a minute, what happens to Ci and Pi in REST? well they are undefined. You mean that if I change the implementation, I can't really test that Pi or Ci has not been impacted?

See my response

I'll stand by my definition whether you use REST in a CRUD way or via a series of method invocations on an object, encoded as POSTs+Nouns: as long as you wire directly the semantics of the a particular runtime be it OO or SQL, you are doing RPC, you are calling into that runtime.

Runtime invocations are synchronous, uni-directional, quick-running,... all the characteristics of RPC technologies.

I don't know many services which are "truly" autonomic. They all share some kind of container. REST is no different. Actually REST goes even further, REST offers one of the worst autonomy possible as it requires all resources to be under the same network authority, and prevents any kind of migration away from that network authority without breaking any systems that holds URIs that point to the original one. So in the RPC world, REST is one of the worst technology possible because I can't ever move my resources (you remember cool URIs don't change?)

To answer specifically your point #2, this is the definition of loose coupling, there is nothing that conveniently moved. There is no other way to achieve loose coupling, and certainly not by some automagical encoding. Encoding is by definition isomorphic. If you encode some RPC call, the encoding will be RPC. You have gained nothing and lost nothing. This is why function or object oriented RPC technologies failed in the past. This is why REST will fail just as well. People can try to market this encoding for money, but it is not because people pay high consulting fees that your encoding provides any value.

After all, people are signing up in droves for credit cards that charge 20% or more and is going to hurt them significantly months and years later. They are doing that for the instant gratification of getting some money without working for it, then they have to work 20% more for having had this privilege. So it should not be surprising that just as many people in IT would sign up in droves for a technology that give them the instant gratification of simplicity, even if shortly thereafter they start paying a heavy price for dealing with it.

Roy's REST works, works really well, trying to apply REST outside the boundaries for which it was defined does not work, my blog post explains why.

Jason:

it does not matter how you "encode" the approve action.