processi

about processes and engines

resource lifecycle tuple

I came across this passage :

Moving from design to implementation, we need to think about the protocol in a slightly different way. In a resource-oriented distributed application, an application protocol can be thought of as a function of one or more resource life cycles and the business rules that connect these resources. Because of its resource-centric nature, the Restbucks service does not host an application protocol state machine. In other words, there’s no workflow or business logic for the application protocol as such. Rather, the service governs the life cycles of the orders and payments participating in the application protocol. Any workflows in the service implementation relate to resource life cycles, not the application protocol life cycle. While we’ve been explicit in modeling the business process as an application protocol state machine, we’ve been diligent in implementing it wholly in terms of resource state machines.

REST in practice, page 131, (emphasis mine).

 

I had to link that passage to this blog post :

The bottom line is that a business entity lifecycle represents some business logic that is “business process independent”. This is probably news to many of you and some of you might say that a BEL is a “long running process” but it is not. It is long running. It is a process in the sense of an operating system point of view (nearly), but it is not and will never be a “business process”. The business process is represented by the activities (human or automated) that advance the lifecycle of one or more business entities.

Lifecycle example, from Carnets de Bord

 

Written by John Mettraux

October 27, 2010 at 5:24 am

4 Responses

Subscribe to comments with RSS.

  1. John,

    you can actually make sense of the first paragraph? I tried google translate but it was not help.

    What is totally boggus in Jim, Savas and Ian’s reasoning is this sentence:

    >> While we’ve been explicit in modeling the business
    >> process as an application protocol state machine

    An APSM is NOT the underlying model of a business process. They are trying to find a way out of their initial publication on infoQ which was making absolutely no reference to resource lifecycle: http://www.infoq.com/articles/webber-rest-workflow

    I pointed that to them, but that would certainly hurt their ego that a) they were completely wrong, b) I was right.

    Sorry, these guys really tick me off, because I don’t know many PhDs who respect their title who would behave like this.

    Jean-Jacques Dubray

    October 28, 2010 at 9:30 pm

  2. For the record, I had a long, in person, conversation with Ian, here in Redmond, in early 2009, where I explained how resource lifecycles were related to business processes, and, mysteriously, after that conversation these guys started to introduce “resource lifecycles” separate from APSM.

    Jean-Jacques Dubray

    October 28, 2010 at 9:36 pm

    • Hello Jean-Jacques,

      at first let me thank you for sharing your experience, knowledge and ideas. I’d like you to have a positive view on my linking of the two quotes.

      I want to answer on why this post (linking). But at first a bit of context.

      I’m surrounded by people who equate workflow (in the business process sense) with ‘resource lifecycle’. (look for example at http://github.com/geekq/workflow/blob/master/README.markdown, it’s interesting to see that the initial version of it http://github.com/ryan-allen/workflow/blob/master/README.rdoc had a separation of workflow and lifecycle that got wiped out of the up-to-date version).

      In a sense, why not ? The workflow as a side-effect of a single resource lifecyle.

      People could say to me “I don’t need a workflow engine because, with Ruby, I can rewrite bits of the application when the business process changes”. But what I hear is rather “this workflow engine and business process thing is complicated, fortunately I don’t need it”.

      It’s not that bad, we build filing cabinets and business processes “emerge” out of them. What scares me is when people equate the filing cabinet with the business process.

      From the first quote :

      > an application protocol can be thought of as a function of
      > one or more resource life cycles and the business rules that connect
      > these resources

      So we don’t have a declared/declarative business process, but one that emerges. Granted, it’s called “application protocol” so it may not be the workflow or business process that I’m after, but I dare to think it is.

      I like it, it’s better than “the workflow is the resource lifecycle”.

      > While we’ve been explicit in modeling the business process
      > as an application protocol state machine, we’ve been diligent
      > in implementing it wholly in terms of resource state machines.

      Maybe this APSM is made of empty states and explicit translations… The benefit for me is that the existence of the business process is acknowledged.

      Now I placed your quote in the second position.

      > The business process is represented by the activities (human or automated)
      > that advance the lifecycle of one or more business entities.

      This is gold.

      I’m a programmer, not an architect, sometimes my work borders on architecture. This double linking post of mine is a tool. There have been lots of discussions where I’d wish I could just say “wait, read this https://jmettraux.wordpress.com/2010/10/27/resource-lifecycle-tuple/“.

      First quote is a preparation for the second quote. I hope people will take the time to read both of the quotes and then, since it’s directly available, read your blog post.

      Thanks for your blogging, I especially like the positive posts, not the antagonist ones, but for those, I [hope I can] understand your frustration.

      John Mettraux

      October 29, 2010 at 12:09 am

      • John:

        thank you for the link it is always great to exchange point of views and concepts. I am a bit disappointed at Jim, Savas and Ian and the REST community in general because the concept of resource lifecycle is central to business process management and even though resources are core to the REST programming model, the REST community focuses nearly exclusively on CRUD models.

        Almost everyone needs BPM: pretty much each time your information system has roles, activities and information entities, you have business processes. The distrust in BPM technologies comes from the fact that they are often inflexible. Models such as BPMN have become better over time but most often people are frustrated with BPM technologies because they can code faster in code than using a so called BPM tool. They also often come to a point where they try to do something and the semantics are missing in their business process model.

        One of the main reasons for these two issues is precisely because the business process model touted by standards and vendors is incomplete. Yes, indeed, hardly any use the concept of resource lifecycle. I don’t mean to say that every type of business process can benefit fromt the concept but a large part can.

        If nothing else, this concept is essential because everything has “state”. This is actually the whole point of an information system: manage state transition and report on the resources in a given state (ordered, reserved, shipped, paid…). It is quite an insanity that the whole purpose of an industry is to manage state and yet we do not offer “state management engines” “state models”, …. Who in their right mind would want to manage state without the tools that semantically allow you to manage “state”?

        The irony of all this is that if you take any system, pretty much anyone would be able to identify the main resources, pretty much anyone would be able to define the main state and their transitions and yet when we go implement it, developers never write this down to write their coding and all coding paradigms completely ignore resource lifecycles. Yet, all they do all day is hard code states and transitions in traditional “stateless” programming environment. How smart is that?

        But Resource Lifecycles would not be enough, they are only one side of the problem. It is very important to understand that the business process lives above the resource lifecycle layer (RLL). Sometimes the RLL is so simple that it is implied in the process layer, but most of the time, the BPM products couple the RLL with the Activity Layer. This is yet another tragic mistake of our industry leading to poor results in the BPM space because, once more the semantics of “BPM” are incompatible with Resource Lifecycles. Worse, technologies such as BPEL which is an orchestration language could be used to implement resource lifecycles, but people use it to implement the “flow of activities”, i.e. the workflow.

        I have begged every corner of this industry to consider the factoring of resource lifecycles and activity flows but no it seems that everyone one is camping on its highly inefficient grounds.

        So, yes I am frustrated to see how closed people can be, I am frustrated that people like Jim, Savas and Ian propagate bogus ideas such as APSM and then try to recover by writing arcane paragraphs and expect the REST community to say “ooh aah” simply because they can write a sentence that contains both workflow and resource. Yes, hypermedia requires some form of state machine, yes resource lifecycles are essential to a robust and easy to use BPM framework.

        But please, … please… understand that it is not until we will use the correct factoring that BPM will succeed. REST has no hidden business process based programming model that “they” somehow uncovered, it is criminal to create concept such as APSM (which lack essential elements of BPM such as Activity boundaries, Roles…) and claim that they can be “implemented” as resource lifecycle. This is the kind of attitude that is slowly destroying our industry. It is safe to say that Jim, Sava and Ian have never seen a business process in their life. This is the typical garbo-mambo that our industry is so prompt to produce to marvel their customers and sell them pricy consulting hours to teach this mysterious concept labeled APSM and in the end deliver nothing at all.

        Apologies for expressing my frustration so bluntly, but I have no respect for these people. They represent all that is so wrong with out industry.

        In the end BPM is very simple, just look in your code for activity boundaries, resources and their lifecycles (state, transitions), roles, and events and factor your system around these concepts (I kept service out on purpose). That’s it. If you do that, your system will be easy to build, it will be easy to maintain and you can code in any technology you want you don’t have to invent any concept, my 10 year old son understands all the concepts that are needed for BPM. But what do I know?

        Jean-Jacques Dubray

        October 29, 2010 at 1:25 am


Comments are closed.