Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] What do you think about REST being a synonym of Service creation technique?

Expand Messages
  • Jan Algermissen
    Stu, very well said! Jan ... Jan Algermissen, Consultant NORD Software Consulting Mail: algermissen@acm.org Blog: http://www.nordsc.com/blog/ Work:
    Message 1 of 18 , Apr 5, 2010
    • 0 Attachment
      Stu,

      very well said!

      Jan

      On Apr 5, 2010, at 10:38 PM, Stuart Charlton wrote:

      >
      >
      >
      > To answer your questions:
      > - I don't think it's a good idea to equate REST with "easy services creation". I'd be more inclined if people equated specifics like "Atom/Atompub" or "OData" with "easy DATA services creation", personally.
      >
      > Enterprises should keep building SOAP web services if they are happy with RPC or messaging systems, and can force their vendors to make it "easier".
      >
      > - The actual *idea* for REST is not "easy services creation" -- it is "large-scale information sharing & manipulation". It is for interoperability at very-large scale, a "system of systems" architecture: http://www.infoed.com/Open/PAPERS/systems.htm
      >
      > As such, it is not necessarily "easy" to apply to all situations, it requires knowledge & experience (like most things).
      >
      > - Explaining REST as an architectural style works for some, but more likely there's also a need to explain REST in the context of SOA's verbiage (e.g. governance, interoperability, loose coupling, contracts).
      >
      > - Probably there will need to be more mainstream books and tooling for the lay-developer, that gets into *how* the development experience is different. Unfortunately, that's a moving target.
      >
      > Some comments:
      >
      > The general trend among the SOA crowd has been to equate REST with "Plain XML over HTTP", and to this day, it remains the popular understanding in most enterprises. Most don't really understand the key features (URIs and hyperlinks), though I have had some exposure that some are beginning to explore deeper once they dig into Atom & Atompub.
      >
      > The problem with using REST as "easy services creation", is that you may be committing greater sins to your maintainability than using WSDL & SOAP if you don't use HTTP & URIs properly (e.g. performing state changes with GET, using a single URI as an "endpoint", including application-specific methods in the XML body, etc. ) At least with SOAP & WSDL there is tooling & infrastructure for governing the little interoperability you do get with it. With REST, the tooling & written literature is still very young, and the vast majority of developers are never going to read Roy's thesis.
      >
      > Part of the problem is that the Web Architecture and REST are very different ways to think about distributed systems design, whereas SOAP-style SOA services are an evolutionary descendent of (depending who you talk to) distributed objects ala CORBA/COM, or message queues ala MQ or TIBCO, which have a much longer history in some people's minds.
      >
      > Cheers
      > Stu
      >
      >
      >
      > From: William Martinez Pomares <wmartinez@...>
      > To: rest-discuss@yahoogroups.com
      > Sent: Wed, March 31, 2010 6:25:48 PM
      > Subject: [rest-discuss] What do you think about REST being a synonym of Service creation technique?
      >
      > Hello all.
      > I got the newsletter from InfoQ this week, and suddenly I noticed something that has been there since long, but till now I didn't realize it.
      >
      > In the SOA channel articles and news, there were only one of each. One article about the REST maturity levels, and one news item about REST security. Oh my...
      > I thought there was some mistake, that those two items belong to the REST channel, and then I realized that there was no REST channel in InfoQ!
      >
      > Then, I had a quick twitter chat with Ryan Sloboyan, Editor from InfoQ. It seems, REST is seen just as a way to create services, opposite to SOAP / WS-* lineage. Ryan told me there is always a possibility to create a REST only channel, but he thinks that will be a narrow one, with not so many readers. The expectation is then REST readers will come just to learn how to create easy services nos using SOAP.
      >
      > Now, Jack Vaughan from SearchSOA was in a fireside chat with me, at the Java Symposium from TheServerSide, where I was to talk about REST apis, and their real meaning. He told me his idea of REST was similar to that one of the new way of doing services for SOA. We got a full room, and I asked if someone as ever read Roy's dissertation. None, and some with faces of "who the hell is that Roy guy?". The question of how many thought REST was a new way of doing services yield to several hands up. Also the one about REST as an HTTP driven RPC.
      >
      > So, all in all, it seems the idea of REST as an Easy Services Creation technique is strong, even influenced in the InfoQ categorization of articles and news.
      >
      > I know some of you do post on InfoQ, and are even editors.
      > What are your thoughts? Do you think it is good to keep that idea?
      > Do you think that is actually the idea?
      > What do you think of posting REST as an architectural style?
      >
      > I want to hear your opinions, since I feel that would be an interesting discussion.
      >
      > William Martinez Pomares.
      >
      >
      >
      > Looking for the perfect gift? Give the gift of Flickr!
      >
      >

      -----------------------------------
      Jan Algermissen, Consultant
      NORD Software Consulting

      Mail: algermissen@...
      Blog: http://www.nordsc.com/blog/
      Work: http://www.nordsc.com/
      -----------------------------------
    • Jan Algermissen
      ... The above statement deserves special emphasis. Leveraging the value of REST not only requires a different way to think about the solution but also a
      Message 2 of 18 , Apr 6, 2010
      • 0 Attachment
        On Apr 5, 2010, at 10:38 PM, Stuart Charlton wrote:

        > Part of the problem is that the Web Architecture and REST are very different ways to think about distributed systems design, whereas SOAP-style SOA services are an evolutionary descendent of (depending who you talk to) distributed objects ala CORBA/COM, or message queues ala MQ or TIBCO, which have a much longer history in some people's minds.
        >

        The above statement deserves special emphasis.

        Leveraging the value of REST not only requires a different way to think about the solution but also a different way to think about the problem.

        Jan



        -----------------------------------
        Jan Algermissen, Consultant
        NORD Software Consulting

        Mail: algermissen@...
        Blog: http://www.nordsc.com/blog/
        Work: http://www.nordsc.com/
        -----------------------------------
      • William Martinez Pomares
        Great 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,
        Message 3 of 18 , Apr 6, 2010
        • 0 Attachment
          Great 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.

          In Summary:
          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?

          Cheers!

          William Martinez.

          --- In rest-discuss@yahoogroups.com, 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.
          >
          > Best,
          > Stefan
          >
        • Jan Algermissen
          ... Incidently, I am personally in the process of slowly developing the idea that the notion of service is[1] actually harmful to REST-oriented thinking. I
          Message 4 of 18 , Apr 6, 2010
          • 0 Attachment
            On Apr 6, 2010, at 2:58 PM, William Martinez Pomares wrote:

            > Is REST community interested in keeping this view of REST under SOA?

            Incidently, I am personally in the process of slowly developing the idea that the notion of 'service' is[1] actually harmful to REST-oriented thinking.

            I think 'service' is commonly perceived in the context of 'service layer', of exposing business functionality as a set of operations and operation-oriented thinking is somewhat contrary to REST.

            Maybe it is nit-picking, but maybe it is necessary to re-think networked systems development from the ground up to overcome the many apparent misconceptions about REST (and the associated dangers in making things worse as Stu mentioned).

            Jan

            [1] or 'might be' because I have not yet made up my mind :-)
          • William Martinez Pomares
            Hello Stuart. Thanks, very complete answers!. 1. Actually, I don t think either that REST= easy services creation idea is good, so I m with you totally. On
            Message 5 of 18 , Apr 6, 2010
            • 0 Attachment
              Hello Stuart.
              Thanks, very complete answers!.

              1. Actually, I don't think either that REST="easy services creation" idea is good, so I'm with you totally. On the contrary, I feel that idea is carving into developers that jump right into "REST" after reading a couple of blogs, and then find out they didn't got REST at all.

              2. Making SOAP Services (Read RPC) is the easiest thing to do. Making them work together is another issue. Making real Web Services (using documents and messaging) is a pain in your little finger since there is not top down approach. Your system may be a fit for WSA, or a fit for SOA (slightly different benefits and requirements), but the implementation side is failing terribly.

              3. The "actual" idea is not the "popular" idea, right? It is the Idea we need to pursue to become popular. Agree totally that is not the easy one to understand, apply and identify as the best to use.

              4. "SOA's verbiage" you mention is not actually from SOA, but sadly those concepts were made popular by SOA and from there people get confused. Governance and contracts came from the business world, the first one to increase the interest of business people to invest on the technology (yep, a worm to catch the fish) and the second one came from WSA. Interoperability and loose coupling came from OO world, and thus created the illusion that SOA was a OO system in disguise. Actually, many SOA implementations out there are Distributed OO in disguise. A pity, since Pure SOA has nothing to do with it.

              5. Totally agree with your point to maintainability! We need to make that clear and loud. (Just don't call them sinners).

              6. Same, I agree about the descendants part. Still, the SOA idea is different from Implementation. I'll be naive enough to think the SOA and Services idea were born pure, and when implementation started, tool vendors took what they have at that time (SOAP as the next Corba/Dcom generation, and Message queues) and did some rebranding to get to sell SOA tools! So, I still think we can save the pure ideals of SOA (but not with REST, which is a different kind of beast).

              Now, question, what should we do about it?

              Thanks again, Stuart.

              Cheers!

              William Martinez

              --- In rest-discuss@yahoogroups.com, Stuart Charlton <stuartcharlton@...> wrote:
              >
              >
              >
              > To answer your questions:
              > - I don't think it's a good idea to equate REST with "easy services creation". I'd be more inclined if people equated specifics like "Atom/Atompub" or "OData" with "easy DATA services creation", personally.
              >
              > Enterprises should keep building SOAP web services if they are happy with RPC or messaging systems, and can force their vendors to make it "easier".
              >
              > - The actual *idea* for REST is not "easy services creation" -- it is "large-scale information sharing & manipulation". It is for interoperability at very-large scale, a "system of systems" architecture: http://www.infoed.com/Open/PAPERS/systems.htm
              >
              > As such, it is not necessarily "easy" to apply to all situations, it requires knowledge & experience (like most things).
              >
              > - Explaining REST as an architectural style works for some, but more likely there's also a need to explain REST in the context of SOA's verbiage (e.g. governance, interoperability, loose coupling, contracts).
              >
              > - Probably there will need to be more mainstream books and tooling for the lay-developer, that gets into *how* the development experience is different. Unfortunately, that's a moving target.
              >
              > Some comments:
              >
              > The general trend among the SOA crowd has been to equate REST with "Plain XML over HTTP", and to this day, it remains the popular understanding in most enterprises. Most don't really understand the key features (URIs and hyperlinks), though I have had some exposure that some are beginning to explore deeper once they dig into Atom & Atompub.
              >
              > The problem with using REST as "easy services creation", is that you may be committing greater sins to your maintainability than using WSDL & SOAP if you don't use HTTP & URIs properly (e.g. performing state changes with GET, using a single URI as an "endpoint", including application-specific methods in the XML body, etc. ) At least with SOAP & WSDL there is tooling & infrastructure for governing the little interoperability you do get with it. With REST, the tooling & written literature is still very young, and the vast majority of developers are never going to read Roy's thesis.
              >
              > Part of the problem is that the Web Architecture and REST are very different ways to think about distributed systems design, whereas SOAP-style SOA services are an evolutionary descendent of (depending who you talk to) distributed objects ala CORBA/COM, or message queues ala MQ or TIBCO, which have a much longer history in some people's minds.
              >
              > Cheers
              > Stu
              >
              >
              >
              >
              >
              > ________________________________
              > From: William Martinez Pomares <wmartinez@...>
              > To: rest-discuss@yahoogroups.com
              > Sent: Wed, March 31, 2010 6:25:48 PM
              > Subject: [rest-discuss] What do you think about REST being a synonym of Service creation technique?
              >
              >
              > Hello all.
              > I got the newsletter from InfoQ this week, and suddenly I noticed something that has been there since long, but till now I didn't realize it.
              >
              > In the SOA channel articles and news, there were only one of each. One article about the REST maturity levels, and one news item about REST security. Oh my...
              > I thought there was some mistake, that those two items belong to the REST channel, and then I realized that there was no REST channel in InfoQ!
              >
              > Then, I had a quick twitter chat with Ryan Sloboyan, Editor from InfoQ. It seems, REST is seen just as a way to create services, opposite to SOAP / WS-* lineage. Ryan told me there is always a possibility to create a REST only channel, but he thinks that will be a narrow one, with not so many readers. The expectation is then REST readers will come just to learn how to create easy services nos using SOAP.
              >
              > Now, Jack Vaughan from SearchSOA was in a fireside chat with me, at the Java Symposium from TheServerSide, where I was to talk about REST apis, and their real meaning. He told me his idea of REST was similar to that one of the new way of doing services for SOA. We got a full room, and I asked if someone as ever read Roy's dissertation. None, and some with faces of "who the hell is that Roy guy?". The question of how many thought REST was a new way of doing services yield to several hands up. Also the one about REST as an HTTP driven RPC.
              >
              > So, all in all, it seems the idea of REST as an Easy Services Creation technique is strong, even influenced in the InfoQ categorization of articles and news.
              >
              > I know some of you do post on InfoQ, and are even editors.
              > What are your thoughts? Do you think it is good to keep that idea?
              > Do you think that is actually the idea?
              > What do you think of posting REST as an architectural style?
              >
              > I want to hear your opinions, since I feel that would be an interesting discussion.
              >
              > William Martinez Pomares.
              >
              >
              >
              >
              >
              > __________________________________________________________________
              > Connect with friends from any web browser - no download required. Try the new Yahoo! Canada Messenger for the Web BETA at http://ca.messenger.yahoo.com/webmessengerpromo.php
              >
            • William Martinez Pomares
              Then we may need to start discussing about the pros and cons of using a concept. Problem is many use a name detached from the meaning, which leads to people
              Message 6 of 18 , Apr 6, 2010
              • 0 Attachment
                Then we may need to start discussing about the pros and cons of using a concept. Problem is many use a name detached from the meaning, which leads to people understanding different things.

                For instance, Service is not RPC. People started using them as synonyms. When I came to do a Service, all that tools can offer is RPC, under the service name, and I cannot do my work!.

                What you get? JAX-RS, a REST framework, that allows you to put an annotation before your method and some other annotations before my parameters, to map to a URI context and query section. That is REST services support in Java!???

                Evil.

                William Martinez.

                --- In rest-discuss@yahoogroups.com, Jan Algermissen <algermissen1971@...> wrote:
                >
                >
                > On Apr 6, 2010, at 2:58 PM, William Martinez Pomares wrote:
                >
                > > Is REST community interested in keeping this view of REST under SOA?
                >
                > Incidently, I am personally in the process of slowly developing the idea that the notion of 'service' is[1] actually harmful to REST-oriented thinking.
                >
                > I think 'service' is commonly perceived in the context of 'service layer', of exposing business functionality as a set of operations and operation-oriented thinking is somewhat contrary to REST.
                >
                > Maybe it is nit-picking, but maybe it is necessary to re-think networked systems development from the ground up to overcome the many apparent misconceptions about REST (and the associated dangers in making things worse as Stu mentioned).
                >
                > Jan
                >
                > [1] or 'might be' because I have not yet made up my mind :-)
                >
              • António Mota
                ... That is my opinion too, fwiw, the terms (and notions) of service and API should not be used in REST...
                Message 7 of 18 , Apr 6, 2010
                • 0 Attachment
                  On 6 April 2010 14:18, Jan Algermissen <algermissen1971@...> wrote:


                  Incidently, I am personally in the process of slowly developing the idea that the notion of 'service' is[1] actually harmful to REST-oriented thinking.


                  That is my opinion too, fwiw, the terms (and notions) of "service" and "API" should not be used in REST...
                • William Martinez Pomares
                  Quick Fe de Erratas. Whenever you see Components mentioned about architecture styles, please correctly read Elements . Yep, they are different
                  Message 8 of 18 , Apr 6, 2010
                  • 0 Attachment
                    Quick Fe de Erratas.
                    Whenever you see "Components" mentioned about architecture styles, please correctly read "Elements". Yep, they are different things/concepts, and being as found of concepts as I am, you bet I read back the message in horror.

                    Sorry about that one.

                    William Martinez Pomares.

                    --- In rest-discuss@yahoogroups.com, "William Martinez Pomares" <wmartinez@...> wrote:
                    >
                    > Great 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.
                    >
                    > In Summary:
                    > 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?
                    >
                    > Cheers!
                    >
                    > William Martinez.
                    >
                    > --- In rest-discuss@yahoogroups.com, 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.
                    > >
                    > > Best,
                    > > Stefan
                    > >
                    >
                  • Stuart Charlton
                    Comments inline Sent from my iPad On 2010-04-06, at 6:21 AM, William Martinez Pomares wrote: 2. Making SOAP Services (Read RPC) is
                    Message 9 of 18 , Apr 6, 2010
                    • 0 Attachment
                      Comments inline

                      Sent from my iPad

                      On 2010-04-06, at 6:21 AM, "William Martinez Pomares" <wmartinez@...> wrote:

                       

                      2. Making SOAP Services (Read RPC) is the easiest thing to do. Making them work together is another issue. Making real Web Services (using documents and messaging) is a pain in your little finger since there is not top down approach. Your system may be a fit for WSA, or a fit for SOA (slightly different benefits and requirements) , but the implementation side is failing terribly.

                      I tend to believe this is because "real services" are a concept created by SOA consultants (I was one of them, sorry).... it is hard for vendors to apply to their products.   

                      That and my sense is that the adoption of WS technology peaked in the WSDL 1.1 days, doing "just enough" for most cases that the truly advanced cases with WS-AT or WS-RM only have relatively small investments behind them.   There needs to be $$$ to drive vendors to improve these stacks, and it's clearly not there to the extent they had hoped.  

                      4. "SOA's verbiage" you mention is not actually from SOA, but sadly those concepts were made popular by SOA and from there people get confused. Governance and contracts came from the business world, the first one to increase the interest of business people to invest on the technology (yep, a worm to catch the fish) and the second one came from WSA. Interoperability and loose coupling came from OO world, and thus created the illusion that SOA was a OO system in disguise. Actually, many SOA implementations out there are Distributed OO in disguise. A pity, since Pure SOA has nothing to do with it.

                      It's a bit of a stretch to say pure SOA has nothing to do with OO; design by contract was a big innovation in a couple OO languages, as were many of the tenants such as separation of interface from implementation, composition,  etc.  SOA eschews object state and identity, which is ironic, because that's exactly what REST embraces, if you look at it through an object-oriented lens. 

                      Otherwise, again speaking from my former life as a SOA consultant with BEA, things like governance and contracts weren't just sell jobs, they were an attempt to separate and save the valuable ideas in SOA from the atrocities of the WSA...

                      My broader point is that REST as an architectural style to enable SOA has been an idea I have heard and supported dating back to 2003 or so... the problem is that the REST community has limited interest in SOA, and the SOA community thinks in different terms from architectural constraints and styles.   So if there is going to be bridge building, there has to be some terminology agreement, but I haven't really seen much effort there for several years.   After the W3C workshop on the "Web of Services", agreement was declared, but the reality was that most advocates moved on from bridge-building and stayed in their own world.   

                      6. Same, I agree about the descendants part. Still, the SOA idea is different from Implementation. I'll be naive enough to think the SOA and Services idea were born pure, and when implementation started, tool vendors took what they have at that time (SOAP as the next Corba/Dcom generation, and Message queues) and did some rebranding to get to sell SOA tools! So, I still think we can save the pure ideals of SOA (but not with REST, which is a different kind of beast).

                      Now, question, what should we do about it?

                      Well, it's not clear what can be done.  Enterprises clearly don't have money to replace yet another generation of middleware, so there's little incentive for investment to learn or adopt a different approach (by customers or vendors).  Most of the REST improvements and understandings are happening on the Web and in consulting engagements, not by traditional vendors and their patrons.  That may change, but it will require some economic shifts and/or killer product breakthroughs.   Cloud computing, for example, seems to be very REST-infected, for better or worse.

                      Stu

                       



                      Make your browsing faster, safer, and easier with the new Internet Explorer® 8. Optimized for Yahoo! Get it Now for Free!
                    • William Martinez Pomares
                      Hi Stuart. ... Cool! Quick adoption that is. ... Didn t mean really that. I actually mean what you said: SOA concepts were created somewhere else. Governance
                      Message 10 of 18 , Apr 6, 2010
                      • 0 Attachment
                        Hi Stuart.
                        > Sent from my iPad
                        Cool! Quick adoption that is.

                        > It's a bit of a stretch to say pure SOA has nothing to do with OO;
                        Didn't mean really that. I actually mean what you said: SOA concepts were created somewhere else. Governance and Contracts are pure business ones, although OO may have used the contract metaphor in some languages, the concept is not from there, as OO didn't have it originally. It became a core concept in WSA.
                        I meant to say SOA is different from Distributed OO. May share some concepts, but try to get them in a different way.
                        You know, that is actually another discussion in the SOA forums. How much a Service reassembles an Object, if there is any difference in properties, etc. That is off-topic in this forum, I guess, but my take is SOA and OO share quality properties, but they differ in the core metaphor.

                        Nice discussion!

                        William Martinez.

                        --- In rest-discuss@yahoogroups.com, Stuart Charlton <stuartcharlton@...> wrote:
                        >
                        > Comments inline
                        >
                        > Sent from my iPad
                        >
                        > On 2010-04-06, at 6:21 AM, "William Martinez Pomares" <wmartinez@...> wrote:
                        >
                        > 2. Making SOAP Services (Read RPC) is the easiest thing to do. Making them work together is another issue. Making real Web Services (using documents and messaging) is a pain in your little finger since there is not top down approach. Your system may be a fit for WSA, or a fit for SOA (slightly different benefits and requirements), but the implementation side is failing terribly.
                        >
                        > I tend to believe this is because "real services" are a concept created by SOA consultants (I was one of them, sorry).... it is hard for vendors to apply to their products.
                        >
                        > That and my sense is that the adoption of WS technology peaked in the WSDL 1.1 days, doing "just enough" for most cases that the truly advanced cases with WS-AT or WS-RM only have relatively small investments behind them. There needs to be $$$ to drive vendors to improve these stacks, and it's clearly not there to the extent they had hoped.
                        >
                        > 4. "SOA's verbiage" you mention is not actually from SOA, but sadly those concepts were made popular by SOA and from there people get confused. Governance and contracts came from the business world, the first one to increase the interest of business people to invest on the technology (yep, a worm to catch the fish) and the second one came from WSA. Interoperability and loose coupling came from OO world, and thus created the illusion that SOA was a OO system in disguise. Actually, many SOA implementations out there are Distributed OO in disguise. A pity, since Pure SOA has nothing to do with it.
                        >
                        > It's a bit of a stretch to say pure SOA has nothing to do with OO; design by contract was a big innovation in a couple OO languages, as were many of the tenants such as separation of interface from implementation, composition, etc. SOA eschews object state and identity, which is ironic, because that's exactly what REST embraces, if you look at it through an object-oriented lens.
                        >
                        > Otherwise, again speaking from my former life as a SOA consultant with BEA, things like governance and contracts weren't just sell jobs, they were an attempt to separate and save the valuable ideas in SOA from the atrocities of the WSA...
                        >
                        > My broader point is that REST as an architectural style to enable SOA has been an idea I have heard and supported dating back to 2003 or so... the problem is that the REST community has limited interest in SOA, and the SOA community thinks in different terms from architectural constraints and styles. So if there is going to be bridge building, there has to be some terminology agreement, but I haven't really seen much effort there for several years. After the W3C workshop on the "Web of Services", agreement was declared, but the reality was that most advocates moved on from bridge-building and stayed in their own world.
                        >
                        > 6. Same, I agree about the descendants part. Still, the SOA idea is different from Implementation. I'll be naive enough to think the SOA and Services idea were born pure, and when implementation started, tool vendors took what they have at that time (SOAP as the next Corba/Dcom generation, and Message queues) and did some rebranding to get to sell SOA tools! So, I still think we can save the pure ideals of SOA (but not with REST, which is a different kind of beast).
                        >
                        > Now, question, what should we do about it?
                        >
                        > Well, it's not clear what can be done. Enterprises clearly don't have money to replace yet another generation of middleware, so there's little incentive for investment to learn or adopt a different approach (by customers or vendors). Most of the REST improvements and understandings are happening on the Web and in consulting engagements, not by traditional vendors and their patrons. That may change, but it will require some economic shifts and/or killer product breakthroughs. Cloud computing, for example, seems to be very REST-infected, for better or worse.
                        >
                        > Stu
                        >
                        >
                        >
                        >
                        >
                        >
                        >
                        > __________________________________________________________________
                        > Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now
                        > http://ca.toolbar.yahoo.com
                        >
                      • Stefan Tilkov
                        Hi William, Frankly, I m not interested in discussing what SOA is or is not, as there s nobody who can decide who s right. It suits my purpose to define SOA as
                        Message 11 of 18 , Apr 6, 2010
                        • 0 Attachment
                          Hi William,

                          Frankly, I'm not interested in discussing what SOA is or is not, as there's nobody who can decide who's right. It suits my purpose to define SOA as something that's high-level enough (or vague enough, if you prefer); the reason is that I see many people who want something from SOA (easy interoperability, loose coupling, wide support in different platforms, …) that they can achieve more easily with RESTful HTTP than with SOAP/WSDL/WS-*. I can give them REST and they can still have their SOA cake.

                          Related to that, I define "service" more as a mini-application than as an individual interface. When implemented using RESTful HTTP, it becomes a set of related resources (more commonly called a Web app) instead of a Web service (a set of WSDL-described individual SOAP interfaces).

                          If you define SOA differently, this logic is flawed. Which is OK.

                          Best,
                          Stefan

                          On Apr 6, 2010, at 2:58 PM, William Martinez Pomares wrote:

                           

                          Great 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.

                          In Summary:
                          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?

                          Cheers!

                          William Martinez.

                          --- In rest-discuss@ yahoogroups. com, 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.
                          >
                          > Best,
                          > Stefan
                          >


                        • William Martinez Pomares
                          Hi Again, Stefan ... That is totally fair!. My idea of setting it is to be clear upfront what the named concept means for each of us. Now I know yours and you
                          Message 12 of 18 , Apr 6, 2010
                          • 0 Attachment
                            Hi Again, Stefan

                            > Frankly, I'm not interested in discussing what SOA is or is not, as there's nobody who can decide who's right. It suits my purpose to define SOA as something that's high-level enough (or vague enough, if you prefer);

                            That is totally fair!. My idea of setting it is to be clear upfront what the named concept means for each of us. Now I know yours and you know mine. :D

                            Actually, I agree completely with your point of view about what people want and how should they get it. What I dislike a little bit is the naming confusion.

                            I came up with a great idea. Let's create a new style called Ice Cream Oriented Architecture (ICOA). It has restrictions A and B, that will give you benefits X and Y. Someone reads about benefits, ignores the restrictions, and starts doing a flawed ICOA. Even worse: there is no Ice Cream, only nuts.

                            After some years, someone else discovers the NOA (I'll let you figure out the acronym), that using nuts alone can get benefits W, X and Y. All is fine, you try to sell NOA and nobody buys it. Then you rename NOA as the next generation of ICOA (ICOA-NG), that uses the revolutionary nutty flavored HARD ice cream, that does not melt and has no milk (And it doesn't even need cooling anymore), and voila! Everybody loves it. Branding that is. And nobody, ever, enjoyed an Ice Cream in the process.

                            So we agree in the core, not sure if we agree that the names can get to confusion, and may cause trouble thereafter.

                            William.

                            --- In rest-discuss@yahoogroups.com, Stefan Tilkov <stefan.tilkov@...> wrote:
                            >
                            > Hi William,
                            >
                            > Frankly, I'm not interested in discussing what SOA is or is not, as there's nobody who can decide who's right. It suits my purpose to define SOA as something that's high-level enough (or vague enough, if you prefer); the reason is that I see many people who want something from SOA (easy interoperability, loose coupling, wide support in different platforms, …) that they can achieve more easily with RESTful HTTP than with SOAP/WSDL/WS-*. I can give them REST and they can still have their SOA cake.
                            >
                            > Related to that, I define "service" more as a mini-application than as an individual interface. When implemented using RESTful HTTP, it becomes a set of related resources (more commonly called a Web app) instead of a Web service (a set of WSDL-described individual SOAP interfaces).
                            >
                            > If you define SOA differently, this logic is flawed. Which is OK.
                            >
                            > Best,
                            > Stefan
                            >
                            > On Apr 6, 2010, at 2:58 PM, William Martinez Pomares wrote:
                            >
                          • Jan Algermissen
                            ... The notion of service is indeed harmful, IMHO, because it emphasizes interfaces as the point of contract between client and server. REST on the other
                            Message 13 of 18 , Apr 8, 2010
                            • 0 Attachment
                              On Apr 6, 2010, at 3:18 PM, Jan Algermissen wrote:

                              >
                              > On Apr 6, 2010, at 2:58 PM, William Martinez Pomares wrote:
                              >
                              >> Is REST community interested in keeping this view of REST under SOA?
                              >
                              > Incidently, I am personally in the process of slowly developing the idea that the notion of 'service' is[1] actually harmful to REST-oriented thinking.

                              The notion of 'service' is indeed harmful, IMHO, because it emphasizes interfaces as the 'point of contract' between client and server. REST on the other hand emphasizes representation semantics (media types, link relations, etc.) as establishing that contract.

                              I have a hunch that this difference creates a tension that is the reason for much of the apparent misconceptions about REST.

                              Jan





                              >
                              > I think 'service' is commonly perceived in the context of 'service layer', of exposing business functionality as a set of operations and operation-oriented thinking is somewhat contrary to REST.
                              >
                              > Maybe it is nit-picking, but maybe it is necessary to re-think networked systems development from the ground up to overcome the many apparent misconceptions about REST (and the associated dangers in making things worse as Stu mentioned).
                              >
                              > Jan
                              >
                              > [1] or 'might be' because I have not yet made up my mind :-)
                            Your message has been successfully submitted and would be delivered to recipients shortly.