processi

about processes and engines

Archive for the ‘oss’ Category

Petia Wohed on YAWL at BPMinna

On Monday 30th of June, we were lucky enough to have a presentation by Petia Wohed of the Information Systems Laboratory of the University of Stockholm (and Royal Institute of Technology).

Petia contacted me last year while she was reviewing OpenWFE[ja] (and other open source workflow systems) in the light of the workflow patterns. I already blogged about the result of this work (see links at the bottom of this post).

Petia is a member of the YAWL project (workflow language and open source project) developed by the research groups of Prof. Wil van der Aalst and Prof. Arthur ter Hofstede. She delivered an excellent talk about this research effort and especially about the advantages of systems based on [Colored] Petri Nets (think Verification).

Before Petia’s presentation and my talk about OpenWFEru ruote, we had a demonstration by Zaky-san of iKnow! a social networking site for learning languages. It’s extremely successful in Japan (where it started) and it’s now expanding to the rest of the world.

Here is Petia’s presentation, it was graciously translated by Wakizaka-san to japanese :

What interested me the most was the worklet and the declarative workflow concepts. I will read carefully the papers they published about those.

Next was my talk about OpenWFEru, the slides are skinny, I rushed through them and then I demoed ruote-web, ruote-rest and the new fluo (process editing / rendering) :

Here are a few links :

(I’m certainly missing some blog reports, sorry)

Many thanks to Wakizaka-san and id:GoTheDistance for organizing those excellent BPMinna meetings (and many thanks as well to Sawada-san for inviting me to those meetings).

Written by John Mettraux

July 6, 2008 at 11:33 am

Posted in bpm, openwferu, oss, ruote, workflow, yawl

entreprise ruby

Check this thread started by Alexey Verkhovsky about “Enterprise Ruby”.

Extremely interesting.

Written by John Mettraux

March 27, 2007 at 1:07 am

Posted in blahblah, link, opensource, oss, ruby

Cyclo Saikuro

Yesterday evening was the revival of Ninjava, a gathering of programming enthusiasts (not only Java) in the Tokyo area.

Zev Blut presented one of his open source projects : Saikuro.

“Saikuro” is a japanese transliteration of “Cyclo”. This tool analyses a set of ruby code and outputs a report about its “cyclomatic complexity”.

saikuro.pngIn short, this metric looks at how many branches there are in a piece of code and returns a complexity score.

In this example, the complexity is “3” : the easy way to compute the metric is by counting how many areas are “encircled” by the graph representing the code (plus the area surrounding the graph).

Pointers to articles about that metric are available from Saikuro’s home page.

I ran Saikuro over my OpenWFEru project. Saikuro generated two reports, one about Cyclomatic Complexity and one about the count of tokens per line.
For OpenWFEru the very first written methods (the one dealing with interfacing with the Java engine over REST) were flagged in red. As Zev pointed out, such ‘parsing’ code sports loads of ‘ifs’ and thus yields a high CC score.
To the reports.

At the end of the talk, the discussions centered on the usefulness of the metric for a developer and especially a project manager, and on how to integrate it in a development process. (check in, code review, …)

It’s a simple and effective metric, nice addition to a Ruby toolboox. This utility deserves to be gemified.
It would be nice if the reports actually displayed the methods (at least the ones in the red), maybe with a bit of Erb and a ruby.css…

Emerson Mills will talk about “agile software development process” (“scrum à la Mills” as he said) in the next (April) meeting of Ninjava.

Thanks to the Cerego guys for hosting this meeting !

Written by John Mettraux

March 16, 2007 at 12:11 am

community flame

I’m subscribed to a certain number of open source projects mailing lists.

One of those sported a discussion where a user expressed his discontentment with the project being too much ‘commercial open source’. A project with only two full time developers and no VC backup isn’t worth such fire, wrong target.

The ‘user’ complained about the ‘community’ versus ‘enterprise’ edition. There are lots of projects going that way these days, sometimes the enterprise edition spins off the community one. Since when do we have ‘community editions’ ? My first souvenir of it was sendmail.org versus sendmail.com, it isn’t that recent, but my impression is that the ‘community edition’ got refined into some ‘enterprise edition’ not the inverse, I don’t feel like googling sendmail’s history to assert my impression into a conviction.

(Notice how I/we use sendmail with a lowercase, it is/was ubiquitous, millions of mail messages got routes/dispatched by it, but I was glad to switch to Exim).

On the mailing thread, the user complains about the project ‘mocking users’ by providing some migration tools only in the enterprise edition. There’s got to be some added value in that enterprise edition, why not that ? That project is real open source, I would feel mocked if I had to register in any way to download and/or participate in the ‘community edition’ (some [commercial] open source projects do it).

The only acceptable ‘registration process’ is the process of registering to one of the mailing-lists of the open source project.

I don’t like the ‘community edition’ denomination, it’s the flag of the evolution towards the ‘commercial open source’ only. But maybe that’s just [blogo-]noise and I need to tune my filters.

Written by John Mettraux

August 16, 2006 at 8:23 pm

Posted in blahblah, opensource, oss

gwebclient

OpenWFE gwebclient (0)I took some time to play with the Google Web Toolkit. And I ended up doing a asynchronous rewrite of OpenWFE’s aging webclient.

I’m having lots of fun !

Somehow, I’m having the impression I’m rewriting once again some OpenWFE connector library (like openwfe-ruby or openwfe-python for example). But this time, the target is [a subset of] Java. It’s not a bad thing though, in four years, my skills improved, and the gwebclient is benefitting from that as well; simpler, cleaner code.

The final result should be double : an RPC toolkit à la Google and an assorted webclient. Java developers will be able to build their own GWT stuff on top of the “OpenWFE RPC toolkit” (yet another piece in the puzzle…) by following the example of the new “gwebclient” stuff.

There’s one thing perhaps, that I’m not happy with. There is certainly out there an ajax open source toolkit that should be very decent (Wicket perhaps ?) and that’s not coming from a company like Google (which is putting restrictions on the distribution of the development tools that come with its GWT), some independent toolkit with great ideas, and the GWT is certainly taking away lots of spotlight from it.

I’m looking forward writing an async version of DroFlo ! (but not immediately, and that’s another story)

Written by John Mettraux

June 5, 2006 at 6:52 pm

Posted in java, openwfe, oss

googling for “marketing strategy OpenWFE”

I just had a look at OpenWFE‘s webserver logs. It’s always interesting and instructive. I was a bit surprised this morning to see that a concurrent (or someone in his organization) had googled for “marketing strategy +OpenWFE”.

Whoah, if they want to find it, they’d better fund it !

What puzzles me even more, is that this ‘concurrent’ is academic. Why should they care about OpenWFE ? They’ve got their own reputation (which is good) and I assume they’re faring well, at least being academic, they should be flying well, ‘over the melee’.
Why do I call them a ‘concurrent’ ? Perhaps because I learnt this week that they took over a ‘workflow spot’. That spot had previous links with them, no shame; and that spot didn’t contribute back in any way to OpenWFE, no loss.

The googling hit is certainly coming from one of their undergrads, doing a ‘market survey’ for them. It’s an interesting search string…

The OpenWFE [marketing] strategy is :

* build a useful workflow / bpm tool
* use it and help people using it
* have fun

The last point has a significant impact on the quality of the tool, hopefully.

Written by John Mettraux

June 4, 2006 at 6:41 am

Posted in blahblah, meta, oss

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

Business | IT divide

I’m writing an open source workflow / bpm package. I eat my own dog food, ie I use my engine to power solutions I write for customers, it’s somehow ‘project-driven’.
I’m just trying to provide the workflow engine I would love to work with. Different people have different expectation on what a workflow/bpm engine should be, somehow, my project is positioned within two poles :

– the pure java workflow approach, by and for the java software developer. BeanFlow might be the youngest of the contenders in the radius of that pole. jBPM and OSWorkflow seem to be the other players in the area.

– the pure business approach, Java, C#, Ruby ? They don’t care. Maybe the most radical view on that pole is given by the IT|redux blog zone.

Could the labels ‘bottom-up’ and ‘top-down’ get applied without a thougt to those two poles ? Or is doing so an overly gross simplification ? Bottom-up being the pure-java approach : “we have that workflow library, yes BPM stuff can be derived from it”. Top-down would be summarized by “we’ve got those process definitions, make them run”.

The first ‘pure java’ approach is simple, easily grokkable by the java-literate IT workforce. Users might be really happy with that for a while, but an IT guy is needed for any change.
It seems also to be project-centered : 1 engine embedded within 1 application (or 1 ESB, but that’s another story).

The second approach is about business users that need to get their job done and often, need to change how it gets done.
It’s also about having multiple processes living and interacting within the organizational process engines, with an almost invisible (remote?) IT workforce taking care of keeping those well oiled.
Of course, those guys would also be in charge for providing the various services as participants to business processes.

I’ve got a certain sympathy for the second approach, it’s about people seeking solutions with ‘change built-in’ and trying to get a viewpoint on the whole set/horde of business processes within (across?) their organization.
But the strength of open source might manifest itself more easily through the channel opened by the first approach… Wait, is there more momentum within the java open source movement or within the LAMP[R] open source movement ?

A last reflection : the word ‘process’ is better than ‘workflow’; a workflow/process engine is an operating system for business processes.

And finally, a “dessert“.

Written by John Mettraux

May 26, 2006 at 12:25 pm

Posted in blahblah, bpm, oss, workflow

open source workflow/bpm landscape

From time to time, there is a thread about workflow/bpm on TheServerSide.

I felt verbose and gave my advice.

The list of workflow/bpm engines written in Java : http://www.manageability.org/blog/stuff/workflow_in_java/view

Written by John Mettraux

May 22, 2006 at 10:21 am

Posted in bpms, openwfe, oss, workflow

email and Knowledge Management

I just came across this insighful post by Thomas Ferris Nicolaisen about Email and Content Management. His reflection got triggered by that post from Seth Gottlieb.

Just mentioning one of his points :

Never reply with informative emails. Rather write a wiki-page on the subject and send the link to the correspondents

In french, there’s a saying that goes “les paroles s’envolent, les écrits restent” (spoken words fly away, written ones do stay). Email could be considered as ‘spoken words’ in opposition to knowledge management and sharing tools hosted content. You might argue that gmail does all the ‘archival’ for you, but it’s not shared knowledge (and it’s stored, well, ‘somewhere over the rainbow’).

From time to time I receive private emails requesting support for some open source project. I invariably reply : “please post your request on the mailing list or on the forum, replies do matter for the whole community”. That just displays one tiny aspect of the reflection initiated by Thomas and Seth, but it extends well to knowledge generated for other kind of projects / tasks.


Let me now digress a bit : I just used the word ‘task’. OpenWFE, being a workflow/process engine, shuffles tasks among human participants (mturks?) and automated participants.

The classical trick I’ve used and seen used by OpenWFE integrators is to have the link to a form included in the workitem (taskitem). The client interface to OpenWFE’s worklist reads the workitem, loads the mentioned form and pre-fills it with values from the workitem. That form (sometimes multipage) has to be completed by the participant in order to perform the task. There is potentially one unique form for each task in the process definition, or each task of the complete set of process definitions within an organization. One form may be reused by multiple processes.

One could also include a link within the workitem to a wiki page containing the detailed instructions on how to resolve the task. That page could easily be maintained up to date, and participants could comment / enhance it.

The wiki content could also be augmented by the workflow user filling a ‘comment’ box. A further (automated) participant would take care of commenting/enhancing the associated wiki page.

Written by John Mettraux

May 21, 2006 at 7:18 am

Posted in blahblah, bpm, bpms, openwfe, oss