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

Re: Business cases for REST

Expand Messages
  • jgorlick19
    [oops, sorry, missed this while i was on vacation - Mark] ... Tracking SOA along a technical pathway gleans an interesting difference. The business advantage
    Message 1 of 14 , Aug 28, 2009
    • 0 Attachment
      [oops, sorry, missed this while i was on vacation - Mark]

      --- In rest-discuss@yahoogroups.com, Justin Cormack <justin@...> wrote:
      >
      >
      > I am trying to collect business rather than technical cases for REST/
      > resource oriented rather than "service oriented" architectures. If
      > anyone has anything I would be interested. I started writing some
      > thoughts at the link below, as a first pass based on some recent
      > experiences.
      >
      > http://blog.technologyofcontent.com/2009/08/the-resource-oriented-enterprise/
      >
      > thanks
      >
      > Justin
      >

      Tracking SOA along a technical pathway gleans an interesting difference. The business advantage of ROA can be likened to other information systems that thrive due to transparency.

      SOA services should be used to model service-to-service interactions (read: opaque services interacting). For example, ship this package for me to her. The package only needs to be inspect-able up to the point that the service is responsible. In this example, the shipper needs only provide the shipping service transparency into the weight, addressing, legality of the contents (stretch case area), yada yada.

      Within the services that spawned SOA, most interactions were one-way messages. The SLA is simple. The service provider must acknowledge (or non-acknowledge) receipt (ownership of delivery). The service provider should also provide a means for the shipper to receive (or check up on (poll)) the final acknowledgement (or any non-acknowledgement along the path). Every service within the chain follows the SLA (or the calling service compensates to ensure they meet their SLA).

      The shipping example can provide good insight into where ROA would have provided the optimal transparency from the start. (And conversely where SOA opaqueness leads to much re-negotiation.)

      After the shipper ships the package, they get antsy, they want to track status all along the shipment path. A reply of "That's not our SLA!" is not very service-oriented (albeit technically correct).

      Within SOA, the SLA is re-negotiated and all services within the chain go through this same re-negotiation. The services introduce storing of acknowledgments. And a storage invalidation scheme is introduced (wouldn't want to keep acknowledgments that no one will ask for). As a sidenote (from the SOA perspective), each service models the acknowledgment for transmission up chain(s) as well as down chain(s) and for storage.

      The storing and representation of acknowledgments pretty well models the world without computers shipping scenario. That is how information flowed. And it is also very resource oriented. It is how a ROA service would be designed from the start.

      We must think both in terms of resources and services. We are here to fulfill our clients' expectations (read: get paid). And we are here to be well served.

      ROA services model requester -> resource action(s) including potentially triggered actions. The modeling actions within ROA is HATEOS. Through a reduction of verbs and a plethora of resources, the modeling of actions is transparent to consumers of the service as well as the implementers of the service.

      Contract negotiation, being a necessary evil, cannot be avoided. ROA services are generally modeled and can be propped up (or mocked) quickly. By focusing on the resources, risk can be reduced by constructing the "edge cases" resources. This can be done in SOA, but most SOA developers do not understand their tools to that level or do not understand that in the end they are constructing a resource.
    • Subbu Allamaraju
      There are a number of ways to spin the benefits of any architecture (and we have seen them all), but the key benefit that matters most is the ubiquity of HTTP.
      Message 2 of 14 , Sep 1, 2009
      • 0 Attachment
        There are a number of ways to spin the benefits of any architecture
        (and we have seen them all), but the key benefit that matters most is
        the ubiquity of HTTP.

        Subbu

        On Aug 26, 2009, at 1:55 PM, Justin Cormack wrote:

        >
        > I am trying to collect business rather than technical cases for REST/
        > resource oriented rather than "service oriented" architectures. If
        > anyone has anything I would be interested. I started writing some
        > thoughts at the link below, as a first pass based on some recent
        > experiences.
        >
        > http://blog.technologyofcontent.com/2009/08/the-resource-oriented-enterprise/
        >
        > thanks
        >
        > Justin
        >
      • Bill Burke
        I was thinking more about this after JBoss World last week. I think the message needs to be *REAL* simple. Something like: SOAP has failed miserably as an
        Message 3 of 14 , Sep 7, 2009
        • 0 Attachment
          I was thinking more about this after JBoss World last week. I think the
          message needs to be *REAL* simple. Something like:

          "SOAP has failed miserably as an interoperable, cross-platform protocol.
          REST has proven otherwise."

          I heard this over and over again last week at our conference. From SOAP
          users and those customers that have started to define RESTful interfaces.

          Subbu Allamaraju wrote:
          >
          >
          > There are a number of ways to spin the benefits of any architecture
          > (and we have seen them all), but the key benefit that matters most is
          > the ubiquity of HTTP.
          >
          > Subbu
          >
          > On Aug 26, 2009, at 1:55 PM, Justin Cormack wrote:
          >
          > >
          > > I am trying to collect business rather than technical cases for REST/
          > > resource oriented rather than "service oriented" architectures. If
          > > anyone has anything I would be interested. I started writing some
          > > thoughts at the link below, as a first pass based on some recent
          > > experiences.
          > >
          > >
          > http://blog.technologyofcontent.com/2009/08/the-resource-oriented-enterprise/
          > <http://blog.technologyofcontent.com/2009/08/the-resource-oriented-enterprise/>
          > >
          > > thanks
          > >
          > > Justin
          > >
          >

          --
          Bill Burke
          JBoss, a division of Red Hat
          http://bill.burkecentral.com
        • Sebastien Lambla
          I m very interested in that statement. Is the comment coming from developers using POD or using ReST architectures? We ve had many discussions with people
          Message 4 of 14 , Sep 8, 2009
          • 0 Attachment
            I'm very interested in that statement. Is the comment coming from developers
            using POD or using ReST architectures?

            We've had many discussions with people around ReST here, and it seems that
            on the one side, people have been saying they prefer ReST when talking about
            POD RPCish services. On the other side, the feedback has been that we've not
            been communicating in a pragmatic enough fashion the differences /
            advantages of various architectures, including DDDD, EDA etc.

            What would you reckon is the proportion of people that want to get ReST, as
            opposed to flat RPC-style POD apis?

            Seb

            -----Original Message-----
            From: rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com] On
            Behalf Of Bill Burke
            Sent: 07 September 2009 18:43
            To: Subbu Allamaraju
            Cc: Justin Cormack; Rest List
            Subject: Re: [rest-discuss] Business cases for REST

            I was thinking more about this after JBoss World last week. I think the
            message needs to be *REAL* simple. Something like:

            "SOAP has failed miserably as an interoperable, cross-platform protocol.
            REST has proven otherwise."

            I heard this over and over again last week at our conference. From SOAP
            users and those customers that have started to define RESTful interfaces.

            Subbu Allamaraju wrote:
            >
            >
            > There are a number of ways to spin the benefits of any architecture
            > (and we have seen them all), but the key benefit that matters most is
            > the ubiquity of HTTP.
            >
            > Subbu
            >
            > On Aug 26, 2009, at 1:55 PM, Justin Cormack wrote:
            >
            > >
            > > I am trying to collect business rather than technical cases for REST/
            > > resource oriented rather than "service oriented" architectures. If
            > > anyone has anything I would be interested. I started writing some
            > > thoughts at the link below, as a first pass based on some recent
            > > experiences.
            > >
            > >
            >
            http://blog.technologyofcontent.com/2009/08/the-resource-oriented-enterprise
            /
            >
            <http://blog.technologyofcontent.com/2009/08/the-resource-oriented-enterpris
            e/>
            > >
            > > thanks
            > >
            > > Justin
            > >
            >

            --
            Bill Burke
            JBoss, a division of Red Hat
            http://bill.burkecentral.com


            ------------------------------------

            Yahoo! Groups Links
          • Bill Burke
            ... I ve never heard of the terms POD, DDDD, or EDA, but I think I understand your question. I still think the vast majority don t know the difference between
            Message 5 of 14 , Sep 10, 2009
            • 0 Attachment
              Sebastien Lambla wrote:
              > I'm very interested in that statement. Is the comment coming from developers
              > using POD or using ReST architectures?
              >
              > We've had many discussions with people around ReST here, and it seems that
              > on the one side, people have been saying they prefer ReST when talking about
              > POD RPCish services. On the other side, the feedback has been that we've not
              > been communicating in a pragmatic enough fashion the differences /
              > advantages of various architectures, including DDDD, EDA etc.
              >
              > What would you reckon is the proportion of people that want to get ReST, as
              > opposed to flat RPC-style POD apis?
              >

              I've never heard of the terms POD, DDDD, or EDA, but I think I
              understand your question. I still think the vast majority don't know
              the difference between RPCish stuff and REST. Many think REST is
              "pretty" URLs. Its what I thought a few years ago when I first started
              looking at REST and I find it is a common perception.

              This is why I think the most important step is to get people to conform
              to the uniform interface. Stress the importance of conforming to it.
              From my own experience, once you start designing interfaces that
              conform to the uniform interface it starts making you think more
              RESTfully. It starts pushing you to make RESTful decisions even if you
              don't know what REST truly is.

              --
              Bill Burke
              JBoss, a division of Red Hat
              http://bill.burkecentral.com
            Your message has been successfully submitted and would be delivered to recipients shortly.