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

Re: [rest-discuss] Restful Approaches to some Enterprise Integration Problems

Expand Messages
  • Bediako George
    +1 ... -- Bediako George Partner - Lucid Technics, LLC Think Clearly, Think Lucid www.lucidtechnics.com (p) 202.683.7486 (f) 703.563.6279
    Message 1 of 45 , Jun 30, 2010
    • 0 Attachment

      On Wed, Jun 30, 2010 at 1:39 PM, Alan Dean <alan.dean@...> wrote:


      These answers are scoped to REST-over-HTTP:

      1) Guaranteed Delivery

      Your client must PUT (or POST) with an If-None-Match: * header [i] to a unique URI. If the URI responds with 412 Precondition Failed then the representation has been delivered.

      2) Distributed Transactions

      Use compensating transactions [ii] (there is further discussion of this on pages 213-215 of RESTful Web Services Cookbook [iii]).

      3) Long running operations

      Server creates a status URI for the invoked operation. If this is as a result of a client request, a redirect should suffice for URI discovery. Client GETs status. If response is 200 OK then the operation is complete. If operation is incomplete, server responds with 202 Accepted [iv] and an estimate of when the operation is expected to complete can be communicated via the Expires header [v].

      4) Workflow Orchestration

      I don't have a canned answer to this. I'm not aware of a RESTful business process protocol (though I certainly think that we need one) and whilst I am not familiar with BPMN, I note that it's wikipedia entry lists "ambiguity and confusion in sharing BPMN models" as a weakness [vi] which doesn't bode well for it's RESTfulness, I suspect (alongside "converting BPMN models to executable environments").

      Alan Dean

      On Wed, Jun 30, 2010 at 17:41, Bryan Taylor <bryan_w_taylor@...> wrote:

      My company is examining adopting a RESTful model to its enterprise architecture. Part of the discussion comes down to finding RESTful idioms, standards, and/or tools to apply to certain recurring enterprise integration problems.

      Specifically, we are trying to find RESTful solutions to:

      1) Guaranteed Delivery - we need a paradigm to follow so that one service can transfer a sequence of resource representations to another reliably even though both services and the network suffer temporary unreliability

      2) Distributed Transactions - we need a paradigm to allow state changes on multiple services to happen so that the changes succeed or fail as a unit

      3) Long running operations - we need asynchronous invocations between services and a mechanism for the invoking service to find out when the invoked service is done given that this work may take indefinitely long

      4) Workflow Orchestration - we would like to have orchestration services that define business processes via standardized representations (eg BPMN), then execute instances of those processes and build up an process instance execution data resource by interacting with other RESTful resources using message exchange patterns that could specify the above behaviors.

      I'm sure that some of these topics have been discussed to death. I'm not looking to repeat the details in one thread, but just wondering if people can give me quick dump of the conventional wisdom as to how to approach such problems, and/or point me to solutions (or alternatives) that they consider consistent with RESTful approaches.

      I found the Rest-* effort at http://www.jboss.org/reststar . The name of this project tweaks me, but some of the specs under it seem relevant. Are there others? Are these problems that the community sees value in solving through standards and tooling?

      Bediako George
      Partner - Lucid Technics, LLC
      Think Clearly, Think Lucid
      (p) 202.683.7486 (f) 703.563.6279
    • Roy T. Fielding
      ... In this case, yes, though it is true for any client. ... which it gets from the media type definition, yes. ... A user (or configured robot) will
      Message 45 of 45 , Jul 8, 2010
      • 0 Attachment
        On Jul 6, 2010, at 1:00 AM, Jan Algermissen wrote:

        > Roy,
        > On Jul 6, 2010, at 3:03 AM, Roy T. Fielding wrote:
        > > Reliable upload of multiple files can be
        > > performed using a single zip file, but the assumption being made
        > > here is that the client has a shared understanding of what the
        > > server is intending to do with those files. That's coupling.
        > Trying to test my understanding:
        > By 'client' you are refering to 'user agent'?

        In this case, yes, though it is true for any client.

        > My understanding is that the user agent has no shared understanding beyond how to construct the submission resquest upon the activation of a hypermedia control. (Web browsers know how to create a POST request from a user's submission of a form)

        which it gets from the media type definition, yes.

        > The user however does have an understanding (expectation) of what the server is intending to do with those files. This expectation is the basis for choosing to activate the hypermedia control in the first place.

        A user (or configured robot) will understand their own intent,
        yes, but not necessarily how the server intends to accomplish that
        functionality. A user is unlikely to know that a given service
        needs guaranteed delivery, since best-effort delivery is the norm.
        One would have to add that to the interaction requirements, which
        means standardizing that kind of interaction through additional
        definitions in the media type or link relations and sending
        enough information with the request to enable the recipient to
        verify the received message integrity, and both sides need to
        know that the request needs to be repeated automatically if
        the checks fail. And that still doesn't tell us what to put in
        the representations being sent. That's why this kind of
        functionality is more likely found in javascript or a
        browser extension.

        There is also no need to limit yourself to one interface.
        Look at all the interfaces on Apache ActiveMQ, for example


        The so-called REST protocol calls for POST to a given
        queue URI, which I'll just assume isn't guaranteed delivery.
        Guaranteed delivery could probably be added with a simple
        message integrity check if the messages are unique, but I
        would prefer a more explicit pattern.

        For example, we might define a message sink with a URI such
        that each client knows (by definition) that it should append
        its own client-id (perhaps set by cookie) and a message counter
        to the request URI, as in

        PUT URI/client-id/count HTTP/1.1
        MIC: a162b17f

        and then the client can send as many messages as it wants,
        provided the count is incremented for each new message, and
        the server must verify (and store) the MIC before responding
        with a success code. Each message can therefore be logged,
        verified, etc., just like a message queue with guarantees.

        We could try to standardize something like what I describe above,
        but it would require multiple independent implementations and a
        lot more free time than it probably deserves. In any case, it also
        begs the question of why would we want to do this using HTTP
        [aside from just avoiding firewall blocks, which is not a
        rational rationale].

        The fact is that most people write message queues for systems
        that are more operational than informational -- i.e., they are
        doing something, usually at a high rate of speed, that isn't
        intended to be viewed as an information service, except in
        the form of an archive or summary of past events. Would a
        more RESTful message queue have significant architectural
        properties that outweigh the trade-off on performance, or
        would it be better to use a tightly coupled eventing protocol
        and merely provide the resulting archive and summaries via
        normal RESTful interaction? That kind of question needs to
        be answered by an architect familiar with all of the design
        contraints for the proposed system.

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