Intalio, first impressions

29 mei, 2008 | techniek | 1 Comment

I have been playing around with Intalio for and here are my impressions. Remember, I am coming from a JBPM background. It should also be noted that this review is solely based on the freely available information and software on the Intalio website. This could be considered unfair.

Intalio comes in two parts, first the BPMS Designer, comparable to the JBPM GPD Eclipse plugin, that is used to draw and deploy the processes. The processes can be deployed to Intalio BPMS server, the free version only runs on Geronimo. The server also offers a web interface that is really quite equivalent in it’s functionality to the JBPM web console. The Enterprise Edition offers a fully fledged BAM tool.

There are many differences between jPDL and BPMN. Fundamental difference is that jPDL is an XML-based processing language whereas BPMN is a standardized graphical notation, like e.g. UML.  There is no standard  for an underlying XML-format for BPMN. Intalio converts the BPMN graphs into BPEL upon process deployment.

BPMN does not offer state and task-nodes like jPDL does. Interaction with humans or other systems (webservices) is modelled by creating a different Pool (swimlane) for every actor.  Interaction is done by drawing request and response messages to and from the tasks in the other pools.  Only tasks in pools that are marked executable are executed by BPMS itself.

BPMN diagrams created with BPMS designer do offer more clarity and information than the JPDL diagrams do. It has a richer set of shapes and event.
With Intalio designer non-executable tasks in the BPMN graphs can be mapped to existing webservices and XForms. This mapping can roughly be compared to the process decoration in JBPM where one assigns action classes to nodes, events and transitions.

Intalio brags about this mapping feature as ‘zero code‘. It comes down to dragging and dropping webservices in a pool and subsequently drawing lines in the mapper view of the task between form parameters and webservices input or output parameters. This feature is probably nice for demo purposes and will most surely greatly appeal to non-developers. To me it seems utterly unworkable in any serious project of some scale.
Biggest problem is that I couldn’t find a single human readable configuration file in which all these mappings end-up. This would have re-opened a door to textually code these mappings and get an overview of them, rather then drawing them in mapping views scattered all over your process graph

One more practical problem was that I could not find the Intalio designer as a standalone Eclipse plugin. Intalio Designer is based on Eclipse but only offers the Intalio functionality, not even the Java perspective is included. Well, I guess that is compliant to their Zero Code claim.

Biggest showstoppper for Intalio  is that it uses BPEL to convert their BPMN diagrams to. Relying on BPEL is great if you want to orchestrate your SOA in a distributed environment but less optimal, or let’s just say a pain, if you want to embed workflow functionality inside your app/ear like I am used to with JBPM. It would require that every functionality that you want to call from your workflow should be exposed as a Soap WebService.  Why can I not just directly call Java code from a Java based workflow engine ?
I couldn’t find any information so far on how Intalio can be employed in such a Use Case. It more looks like a rather monolithical workflow system than the loosely coupled embeddable component I got used to with JBPM.

The free samples that are available might hint to the solution path Intalio offers for integration with the rest of your app. I find these samples rather pathetic. There is some kind of JDBC interaction mechanism allowing you to write direct SQL statements, stored in a single file per statement, against a database. From these SQL statements a WSDL is generated so that they can be called from the BPEL that Intalio generates.

I would never want to do my database interaction in such way, it violates a lot of design principles: no ORM, no separation of concerns, not loosely coupled.
Another example shows how to interact through a JSP by sending a SOAP message directly from the JSP to the Intalio BPMS server. How nice !

Maybe I am just criticizing BPEL’s limitations here and not Intalio’s. BPEL just seems unsuitable for anything other than it was designed for, orchestration of Web Services in a SOA.

Later more…

Tags: ,

1 Comment

  1. Neville Bradbury

    %d/%m/%y

    I have read with interest your impressions on the differences of Jbpm and Intalio. The Intalio Enterprise edition has many more features than the community and would be happy to share points of what is different.

    I do agree with "Relying on BPEL is great if you want to orchestrate your SOA in a distributed environment but less optimal, or let’s just say a pain, if you want to embed workflow functionality inside your app/ear like I am used to with JBPM" with this statement and each platform will fit a particular need and purpose. We have found that for multiple integration issues that concern b2b, b2g and other models Intalio fits well in that space and this is where a lot of traction is heading. Though there are clients that see the value of orchestration with the need for technical assistance to make it happen.

    It will always depend on the business case and needs and apply the correct technology stack to both the tactical and strategic direction of the business.

  2. modafinil kaufen niederlande modafinil kaufen legal provigil kaufen http://modafinilrezeptfrei.over-blog.com/vigil-kaufen.html tadafinil bestellen modafinil kaufen apotheke

    Your comment is awaiting moderation.


Would you like to share your thoughts?

Would you like to share your thoughts?

Geef een reactie

@2020 Plance. All rights reserved.