(New diagrams - download from here)
In a previous post, I tried to argue that the REST and SOAP/WS-* models were duals, and that they could be seen as two views into the same domain. Mark Baker disagreed, and his point centred around the decoupling of interface from implementation.
Now, as an architect, I am rather sensitive to issues of tight coupling, and have often railed against examples of this, such as the SOAP-RPC style itself and the generation of WSDL files from Java implementation classes. But Mark goes much further. He would like to change the implementation of a service from a Stock Quote service to a Weather Report, and he would like to see his interface unchanged! To my mind, this goes beyond the reasonable. It's like changing from pasta to soup, and expecting to continue using a fork.
The decoupling I expect is far more modest, and dare I say, more of the kind expected to be encountered in practice? A change in an algorithm, an extra parameter or two, changes to qualities of service or a change of business domain owner. All of these except the second (extra parameters), I would expect to support without breaking the service interface. For the second, I would expect to be able to create a new version of the service while supporting the older version in parallel for a time until deprecated.
I don't know if it's a Zen thing. On the "uniform interface" issue, I'm hearing the words, but I'm not seeing the REST vision. Maybe one day it'll come to me in a blinding flash, and I'll be a RESTafarian myself, but for now, I'm in the "both models are valid" camp.
So with my current state of understanding, I've drawn a new set of diagrams which shows how one can implement services using the SOAP/WS-* and REST models, and the degree of decoupling between the Service Contract (the interface) and the Domain Model (the implementation) in each case. I see no difference in concept between the two approaches. In fact, the two are extremely similar. I would agree with Mark on one point, though. The SOAP/WS-* world today does not practise the kind of decoupling I describe in this diagram. I guess I'm proposing what I think to be "best practice" in this space. Let's see what responses I get.
In a previous post, I tried to argue that the REST and SOAP/WS-* models were duals, and that they could be seen as two views into the same domain. Mark Baker disagreed, and his point centred around the decoupling of interface from implementation.
Now, as an architect, I am rather sensitive to issues of tight coupling, and have often railed against examples of this, such as the SOAP-RPC style itself and the generation of WSDL files from Java implementation classes. But Mark goes much further. He would like to change the implementation of a service from a Stock Quote service to a Weather Report, and he would like to see his interface unchanged! To my mind, this goes beyond the reasonable. It's like changing from pasta to soup, and expecting to continue using a fork.
The decoupling I expect is far more modest, and dare I say, more of the kind expected to be encountered in practice? A change in an algorithm, an extra parameter or two, changes to qualities of service or a change of business domain owner. All of these except the second (extra parameters), I would expect to support without breaking the service interface. For the second, I would expect to be able to create a new version of the service while supporting the older version in parallel for a time until deprecated.
I don't know if it's a Zen thing. On the "uniform interface" issue, I'm hearing the words, but I'm not seeing the REST vision. Maybe one day it'll come to me in a blinding flash, and I'll be a RESTafarian myself, but for now, I'm in the "both models are valid" camp.
So with my current state of understanding, I've drawn a new set of diagrams which shows how one can implement services using the SOAP/WS-* and REST models, and the degree of decoupling between the Service Contract (the interface) and the Domain Model (the implementation) in each case. I see no difference in concept between the two approaches. In fact, the two are extremely similar. I would agree with Mark on one point, though. The SOAP/WS-* world today does not practise the kind of decoupling I describe in this diagram. I guess I'm proposing what I think to be "best practice" in this space. Let's see what responses I get.
No comments:
Post a Comment