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

Re: [service-orientated-architecture] [ZapFlash] How I Became a REST "Convert"

Expand Messages
  • Ashraf Galal
    ... Ashraf: What about long-life process. If you cannot maintain the process state in the server side how then you do that by REST as you understand it? ... 2)
    Message 1 of 97 , Aug 1, 2011
      On 29/07/2011 6:47 PM, Steve Jones wrote:  



      Ashraf: State could be maintained in the server side without violation to the REST architecture principles and constraints because the stateless is applied for the communication between the requester and the provider.


      Seriously?  Do you have any evidence to back up that statement?

      Ashraf: What about long-life process. If you cannot maintain the process state in the server side how then you do that by REST as you understand it?


       
      The server should maintain some sort of states to achieve the request. For example when we have a resource request that requires aggregation the result from different resources in the back-end systems.

      Again, two things

      1) This has nothing to do with the claim of a RESTful transaction manager
      2) Why does back-end aggregation require a gateway?  Surely that is just normal behavior?

      Ashraf: How do you think that this normal behavior works? Please explain

       

      In the part you cited from Roy's dissertation he stated 
      "A gateway (a.k.a., reverse proxy) component is an intermediary imposed by the network or origin server to provide an interface encapsulation of other services, for data translation, performance enhancement, or security enforcement. Note that the difference between a proxy and a gateway is that a client determines when it will use a proxy."

      we can have an interface for the transaction management as a service.

      How?  The dissertation explicitly forbids conversation state (another part of this thread) so how on earth can you have a transaction manager without extremely explicit conversational state.

      Ashraf: Again the provider side needs to maintain the process state until it completes the response.
      If you think it doesn't need that tell us how do you think the server can provide such results to the client?
      Please read the part that Roy said, which mentioned above, about  gateway(reserve proxy) I highlighted to you.
      As you know the reverse proxy is  "is a type of proxy server that retrieves resources on behalf of a client from one or more servers." from wikipedia. 

      Lets be 100% clear.  I'm totally against the concept of distributed transaction management, WS-TX was a crap idea, and Transaction Management gateways are a crap idea to.  I don't however see a single thing in the dissertation or anything anyone apart from yourself has said which allows transaction management gateways in a RESTful system.

      If REST allows Transaction Management gateways then its 100% bullshit from a distributed systems perspective, and I personally don't think it is.

      It is your opinion, right or wrong, but please let's make our discussion more practically by providing why do you think it is the words that you used.
      Please I don't like such words in any discussion. 
       

      All the best

      Ashraf Galal

      Steve

       


      All the best

      Ashraf Galal

      On 28/07/2011 6:25 AM, Steve Jones wrote:
       



      On 28 July 2011 00:38, Ashraf Galal <ashrafwg@...> wrote:
       


      Steve: I'm pretty sure however you can't do REST and have your transaction managing gateway.

      Ashraf: This is not right! The REST allows for that intermediaries. Please read chapter 5 in the Roy fiedling dissertation to understand the REST architectural style.


      REST allows for intermediaries but I'm not seeing where it allows for transaction management which by definition would mean that the gateway is retaining conversational state

      "Intermediarycomponents act as both a client and a server in order to forward, with possible translation, requests and responses. A proxy component is an intermediary selected by a client to provide interface encapsulation of other services, data translation, performance enhancement, or security protection. A gateway (a.k.a., reverse proxy) component is an intermediary imposed by the network or origin server to provide an interface encapsulation of other services, for data translation, performance enhancement, or security enforcement. Note that the difference between a proxy and a gateway is that a client determines when it will use a proxy."

      From the dissertation 


      Steve: It really is very rude to copy and paste stuff without attribution (http://www.mirandanet.ac.uk/fellowship/profile.php?prof=1280) even if you do change the formatting.

      Ashraf: Wow, Please tell me how did you get and make such link and how did you know that I used this article that I never see it before?!! but your guessing is totally wrong!.
      There are thousands of links regarding semantic web, books, organizations, researches too.
      I think it is rude from you to say that for the second time !!


      I do get slightly suspicious when things are word for word identical and represent a very different style of English from previous sections, particularly when there is some additional formatting which makes the paragraph stand out.  I apologise if this was your original work.



      steve:This actually says that 'yes you can do this with RDF and GET', the challenge is how to describe the POST elements in particular.   I've personally said this for yonks, the 'REST' GET model is very effective for information navigation (querying) but this is a huge distance away from the sort of distributed transaction management via gateways that you talked about earlier.



      Ashraf: I speak about the future but as usual you changed the words.

      Nope, I've been pretty consistent here but I do have a real challenge accepting that REST allows for transaction gateways.

      Steve


      All the best

      Ashraf Galal

      On 25/07/2011 4:48 AM, Steve Jones wrote:
       



      On 24 July 2011 19:41, Ashraf Galal <ashrafwg@...> wrote:
       

      Your question was "Please tell me how REST can do notifications, security or transactions.... "
      I answered but you asked different question: "Deploy a gateway in your DMZ. it gives the ability to involve run time governance across all your services. "
      Then you asked another question different the original one "Not sure how that answers the question, how is a gateway REST compliant?"
      My answer:
      This question is quite bit strange, any way, gateway can do any things for REST as it does for WS*.
      There is nothing called "gateway/ESB is REST compliant!"
      gateway is gateway.


      I'm still confused and it doesn't answer the question.  Yes quite clearly you can technically put a gateway in that does these things, but how will the interactions still be REST compliant if you have a gateway acting as a transaction manager?  I'm really unsure as to how an intermediary transaction manager can possibly be used in a REST compliant system.

      Technically of course you can lob one in, I'm pretty sure however you can't do REST and have your transaction managing gateway.
       


      Your second question "That doesn't explain how REST fits well with this rather than it just being about standard HTTP and RDF, for instance what stops RDF only using GET?"
      It is not easy to give a short answer. I will do my best.
      Unlikethe current Web of linked documents, the Web of linked data (semantic objectives) will allowus to describe data models, data concepts, and data records in such a way that they can be linked, described, and queried as if they were part of a single database.

      It really is very rude to copy and paste stuff without attribution (http://www.mirandanet.ac.uk/fellowship/profile.php?prof=1280) even if you do change the formatting. 
       


      It uses graph data concept where every data concept, data record, relationship is described using URI.
      Which is the same way as resources in REST architectural style (SOA)
      By combing the data moving mechanism with the data model and metadata as resources fits well with REST in my opinion. I think it will be easy to use document page and linked data in the same manner.
      Any other opinions will be appreciated.


      This actually says that 'yes you can do this with RDF and GET', the challenge is how to describe the POST elements in particular.   I've personally said this for yonks, the 'REST' GET model is very effective for information navigation (querying) but this is a huge distance away from the sort of distributed transaction management via gateways that you talked about earlier.

      Steve


      I cannot understand why you are sorry! or sorry about.
      If you need any more details, unfortunately I will not be able to answer before next weekend.


      All the best

      Ashraf Galal

       
      On 22/07/2011 7:08 PM, Steve Jones wrote:
       



      On22 July 2011 23:26, Ashraf Galal <ashrafwg@...> wrote:
       

      Please see my comments in line.



      All the best

      Ashraf Galal

      On 20/07/2011 11:51 AM, Steve Jones wrote:
       



      On20 July 2011 16:06, Ashraf Galal <ashrafwg@...> wrote:
       

      REST is an architectural style. It is not just design patterns.
      It is alternative solution to SOAP WS* in some specific solutions.  It is not a low-level than SOA.
      We can use  REST in an enterprise SOA solution, we can implement tricky features like encapsulation, transactions, stateful communication, reliable messaging, notifications, and security.


      Please tell me how REST can do notifications, security or transactions....
      Deploy a gateway in your DMZ. it gives the ability to involve run time governance across all your services.

      Not sure how that answers the question, how is a gateway REST compliant?
       
       
      Your second question "That doesn't explain how REST fits well with this rather than it just being about standard HTTP and RDF, for instance what stops RDF only using GET?"


       

      REST is very useful for human interaction and we can mixing it with WS* .
      REST fits well to with semantic web & semantic data graphs which I think it will have a big impact in the future. Who knows!


      How does REST fit well with those over simply these approaches using HTTP?
       
      For semantic web it is all about graph data that linked with each other using URI (RDF/OWL)
      Semantic web is designed from the ground up on web architecture principles and constraints.

      That doesn't explain how REST fits well with this rather than it just being about standard HTTP and RDF, for instance what stops RDF only using GET?
       
       

      REST was initially described in the context of HTTP, but is not limited to that protocol.


      What other implementations are there?

      Almost the same as WS*.
      REST guys, Please confirm. Thanks in advance.

      I've no idea what these last two sentences mean together.  Sorry

      Steve
       




      Steve
       


      (Message over 64 KB, truncated)
    • Steve Jones
      On 1 August 2011 10:36, Alexander Johannesen
      Message 97 of 97 , Jan 9, 2012
        On 1 August 2011 10:36, Alexander Johannesen <alexander.johannesen@...> wrote:
         

        Steve said:
        > If REST allows Transaction Management gateways then its 100% bullshit from a
        > distributed systems perspective, and I personally don't think it is.

        I'm curious; why do you say this? Is this falling back on what you
        said earlier, that REST can't do stateless sessions?

        Transaction Management Gateways require the maintenance of state and it requires the calling 'manager' to know not only the state but to link a number of distributed systems into a single transactional state.  This manager therefore is not only a significant issue from a distributed systems perspective (single point of failure, etc) but also governs how everyone calls the services it 'manages'.  So if you have 15 services delivered by 12 companies then suddenly this uber-manager is laying down the internal transitions on each of the services (i.e. it has to tell them when they are able to then actually start work, it tells them when stock decrements happen, etc, etc, etc).

        This would require everyone to agree to the use of this manager and for their internal policies to be dictated by this and the manager to actually have the overall stateflow for each of the services as well as itself.

        Its client server thinking.

         


        Ashraf said:
        > Please I don't like such words in any discussion.

        Steve was strongly worded, but I couldn't detect any particular nasty
        words? Or do you mean that bullshit is such a word? When in Texas ...

        If you think my English can be strongly worded you should hear my French ;)

        Steve
         

        Regards,

        Alex

        --
         Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
        --- http://shelter.nu/blog/ ----------------------------------------------
        ------------------ http://www.google.com/profiles/alexander.johannesen ---


      Your message has been successfully submitted and would be delivered to recipients shortly.