(This is a summing-up of several threads from the past.)
When do we say that SOAP usage is RPC-style?
1. When we pretend to pass domain objects by reference but pass them by value?
2. When we use the "rpc/encoded" style instead of "document/literal"?
3. When we use WSDL (which forces request/response semantics) instead of SSDL?
4. When we expose domain methods as service operations without a viewpoint flip?
Not surprisingly, although all these criteria have merit, I'm now leaning towards the last view, because that represents my latest thinking. I believe that what makes SOA service-oriented is the flip in viewpoint from the inward-facing domain model to the way an external consumer would view the domain.
Example:
How we humans view our world (our "domain"):
Our behaviours - eat(), sleep(), makeMillionDollars(), payOffMortgage(), etc.
How aliens may view our world:
"Services" they can use - explore(), trade(), conquer(), etc.
I now think that if we achieve a semantic flipping of viewpoint from the methods within domain objects to the verbs that a "service interface" must expose, then we have decisively broken the RPC link.
1. There is no way we can pretend to be passing objects by reference. There is a very tenuous link between a method inside a domain object and a service verb, so the illusion of calling a local method on an object simply cannot exist.
2. The "rpc/encoded" style really doesn't hurt after the viewpoint flip is achieved. Does it really matter if we say
<param1/>
<param2/>
at the top level instead of having a single document root like this:
<param1/>
<param2/>
</method-name>
I don't think so. I think that's a technicality.
3. And even if WSDL forces request/response semantics on SOAP, a suitably viewpoint-flipped service is still not a remote procedure call because the service consumer still sees things their way.
On the other hand, if you take a domain method and (without a Viewpoint Flip) turn it into a SOAP operation in the doc/lit style, and also describe it in SSDL, I would say it's still RPC, because we're merely making domain methods remotely invocable.
So if that's all there is to it, let's call RPC "domain-oriented" in contrast to "service-oriented".
When do we say that SOAP usage is RPC-style?
1. When we pretend to pass domain objects by reference but pass them by value?
2. When we use the "rpc/encoded" style instead of "document/literal"?
3. When we use WSDL (which forces request/response semantics) instead of SSDL?
4. When we expose domain methods as service operations without a viewpoint flip?
Not surprisingly, although all these criteria have merit, I'm now leaning towards the last view, because that represents my latest thinking. I believe that what makes SOA service-oriented is the flip in viewpoint from the inward-facing domain model to the way an external consumer would view the domain.
Example:
How we humans view our world (our "domain"):
Our behaviours - eat(), sleep(), makeMillionDollars(), payOffMortgage(), etc.
How aliens may view our world:
"Services" they can use - explore(), trade(), conquer(), etc.
I now think that if we achieve a semantic flipping of viewpoint from the methods within domain objects to the verbs that a "service interface" must expose, then we have decisively broken the RPC link.
1. There is no way we can pretend to be passing objects by reference. There is a very tenuous link between a method inside a domain object and a service verb, so the illusion of calling a local method on an object simply cannot exist.
2. The "rpc/encoded" style really doesn't hurt after the viewpoint flip is achieved. Does it really matter if we say
<param1/>
<param2/>
at the top level instead of having a single document root like this:
<param1/>
<param2/>
</method-name>
I don't think so. I think that's a technicality.
3. And even if WSDL forces request/response semantics on SOAP, a suitably viewpoint-flipped service is still not a remote procedure call because the service consumer still sees things their way.
On the other hand, if you take a domain method and (without a Viewpoint Flip) turn it into a SOAP operation in the doc/lit style, and also describe it in SSDL, I would say it's still RPC, because we're merely making domain methods remotely invocable.
So if that's all there is to it, let's call RPC "domain-oriented" in contrast to "service-oriented".
1 comment:
Ganesh:
I have followed with interest your discussion on the viewpoint flip of Service Orientation vs Object Orientation.
I must admit that I cannot agree with you, though I generally do.
For instance, you say: SOA thinking requires a fallback to procedural logic. This is one of the fundamental drivers for the Viewpoint Flip.
For me, a Service is often if not always either collection-oriented or instance-agnostic. GetQuote Service manages a collections of quotes. the Transfer service using fromAccount and toAccount is instance agnostic.
It looks RPC, but I think RPC does not have the notion of "instance", while service does.
The fundamental distinction between (good) Service Orientation and prior art, including REST is that SO is about thinking really hard about "inter-actions". People often talk about "Coarse Grained", but the gist of it is that Service Orientation makes us think really hard about the interactions between provider and consumers. This is the only way you can provide a service. This is what happens in the real world, this is how efficiencies are driven in the real world. This is how we should think about it in the software world. Inter-actions don't just make sense from a "connected systems"'s perspective, it makes sense from a service definition.
This is I think the "flip" that is happening. We flip from a CRUD oriented view point where the "consumer" of some information knows intimately how to manipulate the data, to a service oriented view point where the consumer only knows about possible inter-actions.
Clearly the consumers looses freedom, but how much more do we gain in terms of reusability and evolution capabilities?
For me the "flip" you are talking about are simply the two faces of the same inter-action (coin).
when someone says: getQuote or provideQuote, you are really looking at the point of view of the consumer and the provider, there is no "viewpoint" flip. Now, you can say that we never really looked at the consumer view point in the past because we pushed on the consumer the burden of ultimately manipulating the resource, in essence making it impossible to achieve a "service oriented" inter-action. But, at the end of the day, there is no flip, there is just the emergence of a better factoring in terms of inter-actions and inter-actions by definitions can be looked at from each point of view.
The issue I have with REST is that it is half baked. Resource and Resource Representations are great concepts to adopt an "inter-action" point of view. But, the so-called uniform interface prevents all clear definitions of "inter-actions" so people are back CRUDing like crazy instead of going all the way towards SO.
I know some people will tell me GET, PUT and DELETE are the only interactions you'll ever need. But you know my response to that: PUTing a resource to express an inter-action is not a valid approach. I don't thing anyone can argue with that.
JJ-
Post a Comment