15133Re: What do you think about REST being a synonym of Service creation technique?
- Apr 6, 2010Great input, Stefan!
Actually, Bryan used similar words to explain to me what SOA was for him. He said:"my take: REST and WS-* are the main choices for an SOA, so REST news is under SOA (where SOA != WS-*, but holistic arch choice)".
That is interesting, since it is the first time I see it that way.
Sorry, I'm more academic than practical, still being pragmatic. That means I do differentiate both concepts based on the concepts rather that just how things are done in a de facto way.
Since my evil part is on, please excuse me if the following analysis sounds like breaking your logic. (It is clearly trying to do so but for academic purposes.)
Any reader can jump to the summary part, if not compelled to read much blah, blah :D
Ok. First the style concept. At any time, when building system, you have the architecture (the real thing, the instance) of the work already done (meaning, the first line of code starts creating an architecture). You can also have your architecture design, which is the architecture-to-be, which many Agile people confuse with the architecture itself. And you can have a style, which is the set of architectural element types, relations and principles that, if you follow them, will give some benefits after some trade of. You can even have several styles, applied together to form a bigger one.
So, from your take, there is also the "high-level approach to an organization's IT holistically", which, if I understand correctly, is the actual "way of doing things" for the complete IT department. That means all individual systems should be created and integrated that way, following those rule and generic goals. That is of course not the architecture of one system, but the organization of all systems as a whole. A system of systems? At the end all that is an organizations of elements and interactions, where an element can be a complete system by itself. To me that fits the architecture definition, just in a higher level. And as such, we can talk about an underlying style. See, no difference to me if I tweak a little bit.
The other part is also interesting. REST is indeed an architectural style that may be a great fit for some "way of doing things", but not for all. It is specific to a particular type of system, with particular needs in transfer, with a particular workflow technique.
From your take, that style is the best to achieve the "way of doing things". Good. From mine, that is a style used to implement another style. Humm.
Finally, the concept of SOA as a WS-* style. You are right about how other people see it. Let me tell you how do I see it to be clear. SOA is an architectural style that uses a component called Service, which behaves like a business service metaphor. There are other components as well, and interactions defined (using documents as data elements and messaging as a transport). The idea of this style is to get the architecture as close to business as it can.
Now, we have the Web Services Architecture, WSA, and that is an standard, and that is not SOA. The WSA has also components based on services that live in the web (that restriction is very important!). It defines some standards like the WSDL and SOAP (worst choice ever!), with a resource view and all.
Now, I know that in practice, a service in WSA is not more that a decorated RPC, that people believes SOA is WS-*, that people like "REST" because they can use URLS and HTTP to create services (many times just RPC) without SOAP. This is what this kind of discussions tries to clarify.
So, there is a difference, SOA is a style with architectural elements and interactions based on business and the service metaphor, with underlying messaging transport and documents as data elements, while REST is a mashup of styles based on the resource concept as data element, optimized for large hypermedia transfers on top of a networked system, with an state machine based workflow. Humm.
Your take is SOA is not an architectural style but a "high-level approach to an organization's IT holistically" ("way of doing things") for the whole IT department, and that the best style to do that is REST. From that, I take that either: SOA is service oriented and thus REST is then a style base on services or to create services, or SOA is not Service related anymore, and REST is the underlying concept.
My gut feeling is the first one is the one people accept the most. I've been asking around, outside this forum, and you see that REST is a synonym of service to many.
Yep. I am complicated, I know. But it is interesting to compare how people see from outside and from inside. Your take at InfoQ is very interesting, but from my outsider point of view you were just publishing REST under SOA because REST is to create services. That is why I asked, and now I see I was wrong. Still, there are many out there with the same point of view of mine.
Next question would be: Should we change that perception? If no one writes about SOA anymore, but only about REST, should we think about renaming SOA channel to REST channel? Is REST community interested in keeping this view of REST under SOA?
--- In firstname.lastname@example.org, Stefan Tilkov <stefan.tilkov@...> wrote:
> On Apr 2, 2010, at 1:08 AM, William Martinez Pomares wrote:
> > The question is still the same. REST discussions are held in the SOA arena, as if REST is a SOA sub product. If SOA is dead, is then REST dead the same? Does REST lives only in the SOA realm? Is REST just a web services alternative? Is Services the only topic we can talk about in REST?
> > I wonder.
> As you can define SOA to mean whatever suits your purposes, it all depends. I happened to be InfoQ's SOA lead editor for a long time, and I personally define SOA to be a high-level approach to an organization's IT holistically, not as an architectural style. I've personally found REST to be the most compelling architectural style, and RESTful HTTP as the most useful technology stack, to achieve those high-level goals (much more so than SOAP/WSDL/WS-* and whatever you'd like to call the architectural style it embodies, if you happen to believe that it actually does so). Only if you define SOA (as I believe Roy and many other REST folks do) as the unnamed architectural style underlying WSDL, SOAP & Co., this seems a conflict.
> One of the more interesting experiences I had at InfoQ (I'm no longer the lead editor and only loosely associated) was that it got harder and harder to find anyone willing to write a useful technical article that was not REST-related. Of course this may have been selection bias, but I really tried but at some point 90% of the people I respected from the WS-* side of things had become RESTafarians.
- << Previous post in topic Next post in topic >>