processi

about processes and engines

Archive for the ‘dev’ Category

how does Ruote work ?

(note: this blog post is from 2008, ruote evolved a lot since, for an up-to-date “how does ruote work”, see sample workflow run)

Well, as “ruote” means “wheel”, it just spins…

Ruote being a workflow/BPM engine, interprets process definitions and runs them as process instances. But how does that happen ?

The few graphs I’ll use in this post were meant as “embedded documentation” in the HTML rendition of ruote-rest. But the final result, a mini-slideshow in the /expressions collection wasn’t very convincing.

I’ll walk through those graphs, detailing what’s happening and giving information about the engine, its components and how they cooperate to interpret process definitions and run process instances smoothly.

Let’s consider this very simple process definition, expressed in Ruby for readability :

class MyProcessDef < OpenWFE::ProcessDefinition
  sequence do
    alpha
    bravo
  end
end

A sequence routing work from participant “alpha” to participant “bravo”.

When Ruote is asked to run an instance of that process, usually via an incoming LaunchItem containing the process definition or a pointer to the process definition somewhere off the web, it will first create an initial RawExpression with an expression id of “0” (and some unique process instance id) containing the process definition as a tree of s-expressions.

Read the rest of this entry »

Written by John Mettraux

September 7, 2008 at 2:21 pm

Posted in bpm, dev, openwferu, ruby, ruote, workflow

Scrum according to Emerson

ninjava_aprilYesterday evening, Emerson Mills talked about “Scrum according to me (how scrum saved my personal life)” at the last Ninjava meeting.

Here’s a Wikipedia link to Scrum (Pick your favourite, maybe limit your choice to the first three items in the list there, oh, Snap does limit itself to Rugby).

I was busy polishing a test suite while he was talking, so my attention wasn’t 100% (gomen), but here are a few fragments I gleaned :

– interruptions are bad, they ruin focus and delay projects
– put the team in the same, open, space. No [head]phones allowed
– split sprint goal into tasks, task go on a post
– a sprint is some kind of iteration (2-3 week)
– someone picks the post-it, write his name on it with a time estimate
– “post-it are cheap, their learning curve is nil, there is no license for using them”
– managers shouldn’t bother developers, if they want to know the status of the project, they look at the post-it board
– once per month a day is dedicated to demos (status demos ?), managers do attend. Bring beer and junk food
– getting better at time estimation, task after task
– be flexible

about stand-up meetings :

– stand-up meetings seem to originate from Japan
– first thing in the morning
– managers attend, but only devs speak
– make them short
– if you have a free-spirited dev willing to develop from home, it’s OK as long as he shows up to the meeting (same, open, space ?)

The discussion that followed was rather intense and included things like :

– new projects or maintenances ?
– XP and Scrum
– pair programming means real-time code review
– sales and management people ‘observe’ the process, they give goals, but not time goals
– is pair programming protecting the pair from interruptions or actually just diluting them ?
– what about open source programming and scrum ?
– what about teams having to multitask on legacy maintenances ?

Zev had to interrupt the discussion at 10pm (damn managers, interrupting again) to let the crowd have an opportunity for beer and food in a restaurant.

There were many things said and ideas exchange, can’t relate everything here… An excellent Scrum evangelism session by Emerson, and not a slight scent of dogma, ideal.

Thanks a ton to Cerego for hosting the meeting. The next one will be in June probably.

Update : the PDF of Emerson’s talk is now available.

Written by John Mettraux

April 20, 2007 at 3:59 am

Posted in coding, dev

sudoku

(warning : half baked text, posted anyway)

Mixed threads of thought :

I was a bit verbose, I told my brother that ruby quizzes were the sudoku of Ruby developers.

Ruby and sudoku, then, via reddit, I came across this post by Eli about sudoku as SAT problems :

When sudoku became popular, I solved a few and quickly reached a conclusion that I don’t find these puzzles interesting. The solution process just felt too mechanic

He went on solving sudoku in a very interesting way…
The computer has to do the repetitive work. We all write programs to solve sudoku, but what about generating them ?

Is this number a prime ?
or
Please generate me the list of primes between 1 and 1000

Bad parallel, a is used by b.

Catalog of openings.

And I can’t find a link to an article detailing the usage of the first computers for generating logarithm tables…

Written by John Mettraux

April 8, 2007 at 11:26 am

Posted in blahblah, dev

find based tools

find” is one of the most useful program/command in a unix[-like] environment.

I wrote two small shell scripts based on it.


vf stands for “Vi[m] Find”, you type

vf '*Servlet.java'

and it will open in your editor ($EDITOR) the first file ending with “Servlet.java” that it’ll find in the current tree (the current dir and its subdirs, recursively).


fijar stands for “Find In JAR”. You can type

fijar 'Servlet'

and it will scan all the jars in the current directory to list the ones with files whose name contain the ‘Servlet’ string. If you add the ‘-r’ option, it will search in all the jars in the current directory and in the subdirs, recursively.


Just thought it might interest some hardcore command line coders. I’ll try to add more of my scripts there : http://www.openwfe.org/tools/.

After a discussion with my colleague Alain Hoang, I release those two scripts under the MIT License, which is very close to ‘public domain’. Thanks for the hint Alain.

Written by John Mettraux

September 28, 2006 at 4:14 am

Posted in dev, java, shell, technical

faster OpenWFE

Let me start with a quote from Tony Hoare : “premature optimization is the root of all evil”. The wikiquote page has other gems from him.

Nicolas benchmarked his embedded OpenWFE and asked me to reduce the parsing time of process definitions, he had identified it as a major bottleneck. The initial releases of OpenWFE cached the process definitions, but that implementation was awkward and the caching came in the way of users in process design environments, they wanted their modified process definitions to be immediately available, other problems were also induced by this initial optimization.
Nicolas’ tests are against the latest releases of OpenWFE which do not contain any optimization on the process definition parsing front.

The solution was simply to cache any XML being loaded into OpenWFE from files (URLs) or strings. As soon as a request for something already parsed once arrives, the cache replies by cloning the corresponding JDOM XML tree. A short process definition could take 200ms to be turned into a JDOM document instance from its file, cloning the [whole] JDOM tree takes usually less than 1 ms.
Of course, if the file or the URL yields a newer version, it will be parsed (and then cached).

Nicolas’ benchmark times thus got cut in two.

When the initial optimization got removed, the remaining code was slower but could evolve with more freedom (a point for aspect-oriented programming).
The new optimization requested by Nicolas occurs in the OpenWFE library in charge of XML loading, whereas the initial one occured in the engine itself when loading new XML process definition. The engine’s code doesn’t include caching concerns (as before this new optimization).

This change is part of the upcoming OpenWFE 1.7.2 (since its pre4).

(Yes, I use JDOM and I’m happy with it).

Written by John Mettraux

August 8, 2006 at 11:34 am

Posted in dev, openwfe

scripting languages for testing

I need a scripting language for testing an application at a high level (the highest level would be with a GUI robot, but I don’t have the time).

For OpenWFE, Jython was used within ‘droflo’ and the ‘webclient’ to implement quick (and dirty sometimes) web controls. It is great for speeding up development on top of Java. Unfortunately, Jython was a bit asleep for a while, but they’ve put up a 2.2 alpha release, that’s good news, this project deserve to be kept alive (I have to say it has always worked just fine, never had to post any bug report for it).

These days, like many developers, I’m tinkering with Ruby, it’s refreshing and performs as expected, as much pleasure and joy as with Scheme.

I just had a quick glance at JRuby. Unlike Jython (and if I understood their ‘limitations.html’ well), you can’t currently implement/extend java classes in JRuby and call them in Java. It’s possible with Jython. The JRuby guys say it shouldn’t be long before this capability is made available.
I don’t need that peculiar feature for the current project development, I just need to quickly ‘run the last mile’ and put up my tests in pseudo-Java (well in fine Ruby).

I will use JRuby for this application testing. I’ll certainly find usages for it within OpenWFE too.

As a final note : OpenWFE uses vanilla Python and Ruby in its test suite. Scripting languages are great tools for building tests around less dynamic languages.

Written by John Mettraux

August 2, 2006 at 8:08 pm

Posted in dev, openwfe, python, ruby

Lukas’ OpenWFE IDE : second pre-release

Lukas [pre-]released his OpenWFE IDE for the second time yesterday.

It’s a very promising IDE, it’s based on Eclipse and currently, is unfortunately only available as a ‘windows binary’, (but there goes the source).

I’m very happy with Lukas’ work. This time I convinced the student to upload his work within OpenWFE source repository and to use sf.net trackers and the mailing lists. I should have done that sooner with the previous students I had.

Unfortunately, it will certainly be my last project at the EPFL as I’m leaving this place. I’m having two job interviews next week. I’m focusing on leaving Switzerland.

I’ll have to think about a student project proposal though, maybe something that I can remotely manage, it’s open [and distributed] source after all.
Maybe, a project extension could consist in tying an embedded OpenWFE within the IDE to simulate newly designed or reengineered process definitions.

Lukas’ IDE is available from the Download page.

Your feedback is welcome.

Written by John Mettraux

June 2, 2006 at 9:42 pm

Posted in blahblah, dev, openwfe, workflow

openwfe-ruby

openwfe-ruby is a library for interacting with OpenWFE, as its name implies, it’s written in Ruby. Yes, you can leverage OpenWFE from your Ruby application.

I wrote openwfe-ruby as I was spending some time in Costa Rica. I taught myself Ruby by writing a simple drill program for revising my spanish vocabulary and verbs. Then I wrote a first version of openwfe-ruby, based on the openwfe-python and openwfe-dotnet connectors.

Ruby is very elegant, as elegant as, well, I won’t tell.

I just wrote a listen / dispatch pair in Ruby for receiving / sending back workitems directly. An usage example :

require 'ocodec'

sl = OpenWFE::SocketListener.new('127.0.0.1', 7010)
    #
    # listens on port 7010 of the local interface

sl.listen do |workitem|

    workitem.attributes['ruby?'] = 'yes'
    puts "received workitem for flow #{workitem.attributes['__subject__']}"
        #
        # let's perform some modifications on the workitem

    OpenWFE.dispatchWorkitem('127.0.0.1', 7007, workitem)
        #
        # and then, let's send it back to the engine (listening on port 7007)
end

As you can see, this piece of code, once running will listen for incoming OpenWFE workitems on port 7010. You have to set up a participant in etc/engine/participant-map.xml for it :

    <participant name="my-ruby-participant">
        <param>
            <param-name>dispatcherClass</param-name>
            <param-value>openwfe.org.engine.impl.dispatch.SocketDispatcher</param-value>
        </param>
        <param>
            <param-name>host</param-name>
            <param-value>127.0.0.1</param-value>
        </param>
        <param>
            <param-name>port</param-name>
            <param-value>7010</param-value>
        </param>
        <param>
            <param-name>workItemCoder</param-name>
            <param-value>xmlCoder</param-value>
        </param>
    </participant>

It’s important to set the ‘workitemCoder’ to ‘xmlCoder’, other workitem encoding formats are not supported by openwfe-ruby.

Then you can use the new participant from your process definition :

<sequence>
    <participant ref="alice" />
    <participant ref="my-ruby-participant" />
    <participant ref="bob" />
</sequence>

openwfe-ruby is still very young, this listen/dispatch pair, for example, doesn’t handle delivery problems. Some workitem attribute types encoding have not yet been implemented (XmlAttribute, Base64Attribute).
So if someone with Ruby experience and lots of passion is willing to enhance this connector, he (or she) is welcome.

download : openwfe-ruby-1.7.1pre3-src.zip

Written by John Mettraux

June 1, 2006 at 8:41 pm

Posted in dev, openwfe, oss, ruby, workflow

InfoQ

Floyd Marinescu ‘unlaunched’ his new Uber-Community site : InfoQ.

Alexandru Popescu (aka “The Mindstorm“) is one of his fellow ‘unlaunchers’.

Alexandru being a Magnolia contributor/committer, no surprise, the site’s running on Magnolia CMS.
Scroll down their about page to learn more about Alexandru.

I’m looking forward seeing this site grow and publish quality content… Hey, there’s even a welcome goodie : a book named “Java Transaction Design Strategies” (available as a free PDF download), 188 pages on java transactions.

Congratulations to the InfoQ team !

Written by John Mettraux

May 18, 2006 at 3:40 pm

Posted in cms, dev, magnolia, oss

Listen.java

From time to time, on the forums, there are very challenging threads, this one makes no exception : it’s about making a java application listen to OpenWFE workitems.

If you scroll down the thread, you’ll see that, in the end a fairly nice snippet of java code saw the light. I just integrated this example within the OpenWFE manual.

Of course, after this redaction exercise, I thought, there got to be a simpler way. Why not having something like :

import openwfe.org.engine.impl.listen.OwfeHook;
    //
    // OwfeHook is an abstract class 
    // its very similar to something like java.awt.event.ActionListener

(...)

    new OwfeHook(7303, "engine.host.com", 7007)
        //
        // constructor parameters are
        // listen-port, engine-host, engine-port
    {
        public void service (WorkItem wi)
        {
            System.out.println("got workitem");

            wi.getAttributes().puts("my-field", "Kilroy was here");

            // the hook takes then care of replying to the engine
            // ...
        }
    };

That’ll be for OpenWFE 1.7.1.

Now that I have put my hands on a Visual Studio environment, I’m refreshing openwfe-dotnet and I’ll write a couple listen / dispatch (as used within this OwfeHook example) for .NET. The OpenWFE engine will then be able to directly feed workitems forth and back to a .NET application.

Written by John Mettraux

May 13, 2006 at 9:24 pm

Posted in dev, openwfe