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

FOREST: a GET-only REST Integration Pattern

Expand Messages
  • Duncan Cragg
    Hi! ... FOREST is a GET-only REST Integration Pattern defined simply as: A resource s state depends on the state of other resources that it links to. This
    Message 1 of 5 , Oct 8, 2009
      Hi!

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

      FOREST is a GET-only REST Integration Pattern defined simply as:

      "A resource's state depends on the state of other resources that it
      links to."

      This means that resource servers must also be clients in order to see
      those dependencies.

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

      FOREST is a REST Pattern derived from GET-only or polling Web use-cases,
      including mashups:

      - feed aggregators or filters
      - search index results pages
      - pages that depend on a search
      - Google's mobile versions of pages
      - sites that create summaries of other Web pages
      - sites that create feeds from Web pages
      - creating pages or feeds from REST 'APIs' (GET only)
      - Yahoo Pipes

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

      FOREST is a REST Pattern for building 'Enterprise Mashups' in a ROA /
      WOA / SOA.

      OK - those of you without Dion Hinchcliffe in your feed reader may be
      feeling a little
      queasy at this point, but I'd encourage you to read on ... Actually, I
      quite like the
      phrase 'Enterprise Mashup' since it lightens the gravity of that
      'Enterprise' word.

      Enterprise Mashup Markup Language* is the nearest thing to this that I
      know about, but
      FOREST is quite different: it is much simpler and is /only/ a REST Pattern.

      * http://www.openmashup.org/omadocs/v1.0/emml/createMashupScript.html

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

      Patterns can be implemented in frameworks...

      A FOREST implementation would inevitably be over HTTP. It would
      initially be just XHTML
      or Atom. I imagine fetching XHTML resources within which are expected
      to be links to
      more such documents. Any XHTML could depend on any other, and they're all
      interlinked. If you depend on another resource, you must have found it
      directly or
      indirectly through links in your body. Alternative discovery: a
      resource could be told
      that it is being watched using an HTTP header in the GET request listing
      the URIs of
      the resources that depend on it - then it could watch and link back.
      Etag would be used
      for an automatically incremented version number.

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

      I would ideally see this work towards a formal description via 'rough
      consensus and
      working code'. I intend to knock up a prototype of FOREST in a Jetty
      servlet and post
      it to GitHub; if that code works, I may get rough consensus...

      What a FOREST XHTML/HTTP formalisation would specify:

      + link-rels in XHTML heads to watched resources found through body links
      + use of HTTP headers (Etag, Cache-Control, Content-Location, Observers*)
      + API*: doc builder, XPath body get/set*, set-observe*, callbacks
      (observed, notified*)

      * - 'Observers' is a possible name for the header with the URIs of
      dependent resources
      - the API would be language-independent, but probably Java-like
      - the XPath would be extended to jump links from doc to doc
      - 'set-observe' adds the link-rel, so watched resource URIs can be
      persisted
      - 'notified' means being told when the GET returns with the observed
      state

      What a FOREST Java servlet and client library would implement 'under'
      these specs:

      + a driver module loader: drivers animate resources through the API
      + a document cache - in memory and maybe saved to disk or database

      Resource animation would either be by the application of business rules
      driving the
      API, or by adapting between external state and the API.

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

      What do you think? Enthusiatic replies preferred! =0)

      Duncan Cragg

      --
      http://duncan-cragg.org/blog/
      http://twitter.com/duncancragg
    • duncan_b_cragg
      I ve expanded a little on the motivation behind FOREST in this blog post: http://duncan-cragg.org/blog/post/forest-get-only-rest-integration-pattern/ Duncan
      Message 2 of 5 , Oct 9, 2009
        I've expanded a little on the motivation behind FOREST in this blog post:

        http://duncan-cragg.org/blog/post/forest-get-only-rest-integration-pattern/

        Duncan Cragg
      • William Martinez Pomares
        Hello Duncan. Didn t get it on your problem case. First, why the resource is at one server. It should be location-less, or in IT words shared . Second, a
        Message 3 of 5 , Oct 10, 2009
          Hello Duncan.
          Didn't get it on your problem case.
          First, why the resource is "at" one server. It should be location-less, or in IT words "shared". Second, a resource may have all the URIs you want, or that it needs, that is not a restriction.

          Third, I plenty support that resources are locatable and accessible by any node in a network, and REST is for networking systems, so I don't see why is there a restriction for servers to be clients.

          Now, as FOREST to be a pattern and not an style, means it is applicable to tactic design. That means it is local, and thus may not be applicable to the whole system. In fact, as you actually go into details of implementation, it IS a pattern.

          What I mean is that your REST applications may contain parts implemented using FOREST and others using other patterns. Thus, you need:
          1. Identify the context where your pattern can be used (as the title suggest, cases where we need integration may be).
          2. Identify the particular problem it is solving.
          3. You already defined the solution, even getting down to propose implementation.
          4. List the consequences of applying it.

          Will read it again, trying to understand each bit.

          Cheers!

          William Martinez


          --- In rest-discuss@yahoogroups.com, "duncan_b_cragg" <rest-discuss@...> wrote:
          >
          >
          >
          > I've expanded a little on the motivation behind FOREST in this blog post:
          >
          > http://duncan-cragg.org/blog/post/forest-get-only-rest-integration-pattern/
          >
          > Duncan Cragg
          >
        • duncan_b_cragg
          Hi William! Thanks for the reply. ... Sorry - I don t understand this! =0( ... Good... I think... ! ... No - it s a whole-system Pattern. If Patterns have to
          Message 4 of 5 , Oct 12, 2009
            Hi William! Thanks for the reply.

            > First, why the resource is "at" one server. It should be location-less, or in IT words "shared". Second, a resource may have all the URIs you want, or that it needs, that is not a restriction.

            Sorry - I don't understand this! =0(

            > Third, I plenty support that resources are locatable and accessible by any node in a network, and REST is for networking systems, so I don't see why is there a restriction for servers to be clients.

            Good... I think... !

            > Now, as FOREST to be a pattern and not an style, means it is applicable to tactic design. That means it is local, and thus may not be applicable to the whole system. In fact, as you actually go into details of implementation, it IS a pattern.

            No - it's a whole-system Pattern. If Patterns have to be local, then I have to stop calling it a Pattern. Any ideas? 'Sub-style'? Ug.

            > What I mean is that your REST applications may contain parts implemented using FOREST and others using other patterns. Thus, you need:
            > 1. Identify the context where your pattern can be used (as the title suggest, cases where we need integration may be).

            Yah - Enterprise Mashups! =0)

            > 2. Identify the particular problem it is solving.

            OK - this is tricky, because I think it has a very wide applicability. It may even satisfy /all/ your Integration Needs! =0)

            > 3. You already defined the solution, even getting down to propose implementation.

            Wait till I write the FOREST prototype for Jetty...

            I'm going to call it "a type of FOREST that begins with 'J' - for Java": 'Jungle'! =0)

            > 4. List the consequences of applying it.

            Ka-ching! $$ Profit!! =0)

            Can't really say this until I've got some real-world experience of applying 'Jungle' and the FOREST Pattern/Sub-Style.

            > Will read it again, trying to understand each bit.

            Thanks - again, I really appreciate the feedback.. If it resonates with you (or anyone else) I'd be really happy to explore the ideas with you, and to be challenged on the details.

            Duncan Cragg

            >> I've expanded a little on the motivation behind FOREST in this blog post:
            >>
            >> http://duncan-cragg.org/blog/post/forest-get-only-rest-integration-pattern/
          • William Martinez Pomares
            Hello Duncan. ... Ok. In your blog you mention that you have one resource in one server. The location-less in this case is that a resource cannot be bound to
            Message 5 of 5 , Oct 12, 2009
              Hello Duncan.

              --- In rest-discuss@yahoogroups.com, "duncan_b_cragg" <rest-discuss@...> wrote:
              >
              > Hi William! Thanks for the reply.
              >
              > > First, why the resource is "at" one server. It should be location-less, or in IT words "shared". Second, a resource may have all the URIs you want, or that it needs, that is not a restriction.
              >
              > Sorry - I don't understand this! =0(
              >

              Ok. In your blog you mention that you have one resource in one server. The location-less in this case is that a resource cannot be bound to one server, since that hurts scalability. So, the resources are usually "shared" by various servers.

              Now, I now understand you post, I think. You describe a situation where two different applications are used, so each one has its own resource, that happens to be the same (semantically, at least). Well, not quite. Here you have actually two resources meaning different things, but a similar thing for the client. In this case, the client must work toward integration, by requesting from one app (A) and sending to the other (B) what this B one requires.

              Another way is to have the B able to talk directly to A. Which I get from your post.

              > > Third, I plenty support that resources are locatable and accessible by any node in a network, and REST is for networking systems, so I don't see why is there a restriction for servers to be clients.
              >
              > Good... I think... !
              >
              > > Now, as FOREST to be a pattern and not an style, means it is applicable to tactic design. That means it is local, and thus may not be applicable to the whole system. In fact, as you actually go into details of implementation, it IS a pattern.
              >
              > No - it's a whole-system Pattern. If Patterns have to be local, then I have to stop calling it a Pattern. Any ideas? 'Sub-style'? Ug.
              >

              Ok, I would say it is local, since it is a pattern for integration.
              You can read more about the pattern, styles and idioms here http://wmp-archi.blogspot.com/2009/10/styles-pattern-and-idioms.html.

              > > What I mean is that your REST applications may contain parts implemented using FOREST and others using other patterns. Thus, you need:
              > > 1. Identify the context where your pattern can be used (as the title suggest, cases where we need integration may be).
              >
              > Yah - Enterprise Mashups! =0)
              >
              > > 2. Identify the particular problem it is solving.
              >
              > OK - this is tricky, because I think it has a very wide applicability. It may even satisfy /all/ your Integration Needs! =0)
              >

              I would check the particular problem of integration you are solving.

              > > 3. You already defined the solution, even getting down to propose implementation.
              >
              > Wait till I write the FOREST prototype for Jetty...
              >
              > I'm going to call it "a type of FOREST that begins with 'J' - for Java": 'Jungle'! =0)
              >

              Good one!

              > > 4. List the consequences of applying it.
              >
              > Ka-ching! $$ Profit!! =0)
              >
              > Can't really say this until I've got some real-world experience of applying 'Jungle' and the FOREST Pattern/Sub-Style.
              >

              Actually, that is the other part of a Pattern that is required: a Pattern should be a proven solution that is normally used. So, I guess you are proposing a solution and if everybody buys it, then you got yourself a pattern! :D

              > > Will read it again, trying to understand each bit.
              >
              > Thanks - again, I really appreciate the feedback.. If it resonates with you (or anyone else) I'd be really happy to explore the ideas with you, and to be challenged on the details.
              >
              > Duncan Cragg
              >

              Sure!. It would be a pleasure!


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