Monday 17 May 2010

Alfresco Creates Activiti

Today, Alfresco launches a new open source project called Activiti (http://activiti.org) It's a open source Apache licensed BPM engine supporting BPMN 2.0 natively. We are very excited as we believe this project will be very disruptive in the BPM industry. Activiti will be run as a independent project. Me and Joram Barrez left Red Hat and joined Alfresco as employees to lead Activiti. We've assembled an impressive list of team members and companies involved over the last two months.

The first target of Activiti is to achieve the same developer friendliness that we established at jBPM. But this time, with the we have more liberal license, more companies involved and more resources. So we'll be able to build out very slick tools on top of the embeddable engine. A big thanks to the Alfresco UI designers for shaping the UI of these first alpha version.

Thanks to the Process Virtual Machine design, apart from BPMN 2.0, Activiti will also be able to support other process Domain Specific Languages (DSL). And because we're building it from the ground up, we can prepare it properly for the cloud as that has a profound impact on the design of a BPM engine.

Take a look at our website and the first alpha version that we also release today that includes several components and even a REST interface.

SpringSource is also excited to be part of the Activiti community. SpringSource is very interested in adding BPM capabilities to their stack. So they will help ensuring that this engine runs smoothly on the SpringSource stack. They will also contribute knowledge to run Activiti in the cloud.

Signavio is participating in the Activiti community by contributing a customized version of their leading web based BPMN modeler.

And Camunda brings a vast amount of experience with practical BPM implementations into the mix.

Together our ambition is to build the clear #1 BPM engine. And with this initial community, I am confident we'll be able to do exactly that.

27 comments:

  1. Congrats, sounds like you've got exciting times ahead. :)

    ReplyDelete
  2. Great to finally hear what you've been up to! Can't wait to dig into the details. Good luck on this next adventure!

    ReplyDelete
  3. Happy to have you on board at Alfresco Tom, definitely an exciting time for Alfresco and the BPM / ECM community!

    ReplyDelete
  4. Great so see such collaboration!

    ReplyDelete
  5. That sounds great. I'm really looking forward to a process engine with native BPMN 2.0 support. Great!

    ReplyDelete
  6. Good luck Tom!!!!!!! May the 12 gods be with you :D!

    ReplyDelete
  7. Exciting times ahead for BPMN 2.0 and open source. :)

    ReplyDelete
  8. Hi Tom,

    Congratulations, this projects seems to address exactly what i was looking for in a modern BPM paltform

    Good luck

    Andrea

    ReplyDelete
  9. how much code is taken from jBPM? I had a quick look on the user guide and it looks VERY similar to jBPM.

    ReplyDelete
  10. This project looks very promising.

    One aspect is interesting for me at the moment:
    * will a CODE (not the db schema) migration from jBPM be possible? As far as I saw from the *Test-classes the API seems to be similar.

    Best wishes for your efforts!
    Roman

    ReplyDelete
  11. @All Thanks for the compliments.

    @Anonymous There is zero jBPM code in Activiti. The license change prohibits that. So we had to start completely from scratch.

    ReplyDelete
  12. Good to see the real thing. I can't wait to try it out!

    ReplyDelete
  13. Awesome stuff; a process engine in your app .. wow stuff

    ReplyDelete
  14. Setup did not work on Mac :-(
    anthos-mac:setup anthos$ ant
    Buildfile: build.xml
    [echo] Activiti home = ..
    [echo] Activiti version = 5.0.alpha1

    h2.install:
    [mkdir] Created dir: /Users/anthos/projects/activiti-5.0.alpha1/apps/h2
    [copy] Copying 5 files to /Users/anthos/projects/activiti-5.0.alpha1/apps/h2

    internal.classpath.libs:

    internal.taskdef.launch:

    h2.start:

    BUILD FAILED
    java.lang.NoSuchMethodError: java.io.File.canExecute()Z
    at org.activiti.impl.ant.LaunchTask.isExecutable(LaunchTask.java:73)
    at org.activiti.impl.ant.LaunchTask.getExecutable(LaunchTask.java:63)
    at org.activiti.impl.ant.LaunchTask.execute(LaunchTask.java:40)
    at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
    at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:592)
    at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
    at org.apache.tools.ant.Task.perform(Task.java:348)
    at org.apache.tools.ant.Target.execute(Target.java:357)
    at org.apache.tools.ant.Target.performTasks(Target.java:385)
    at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337)
    at org.apache.tools.ant.Project.executeTarget(Project.java:1306)
    at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
    at org.apache.tools.ant.Project.executeTargets(Project.java:1189)
    at org.apache.tools.ant.Main.runBuild(Main.java:758)
    at org.apache.tools.ant.Main.startAnt(Main.java:217)
    at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
    at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)

    Total time: 1 second
    anthos-mac:setup anthos$ pwd
    /Users/anthos/projects/activiti-5.0.alpha1/setup

    ReplyDelete
  15. Anil,

    please post your question on the user forum. including what jvm you're using.

    http://forums.activiti.org/en

    ReplyDelete
  16. @Anil - I installed on a mac and it worked like a champ. I'd take it to the forum to figure out why it didn't work for you.

    @Tom: congratulations to you and Joram. I know there's a lot of work to do to get to GA, but you're off to a good clean start. Keep things as clean as the initial alpha is - uncluttered and focused.

    And thanks to Alfresco for supporting the effort, along with Signavio, Springsource, et al -

    scott

    ReplyDelete
  17. Thanks, Scott! Such a compliment from you means a lot to us and it keeps us going.

    ReplyDelete
  18. @Tom & Joram: congratulations on your new project. You have done a great job so far on jBPM and I am sure that you will deliver even a better product given the team you have assembled for this project.
    I like the idea of supporting Spring from the very beginning. Also nice to know that you will invest in tooling because that was and remains one of weak spots in jBPM.

    ReplyDelete
  19. BTW while browsing a little through your source code just out of curiousity ;-) I noticed you are using iBATIS for persistence. What is the reason behind that? While it surely is a robust framework, wouldn't it have been better to use JPA with the possibility to configure your own persistence provider? (which we missed so much in jBPM 4.x).

    ReplyDelete
  20. @Yury We first tried JPA, but couldn't find an Apache licensed implementation that was easy to develop with. Then we tried iBatis. It was more coding work on our side, but we are now in full control. It's looking more and more that we'll stay with iBatis.

    But I would be really interested to find out why you want to plug your own persistence provider. If it is for another storage then JDBC, then I can understand. But if we work with your JDBC connection and your persistence framework also translates to JDBC, does it matter what persistence framework we use internally?

    I can see that on a first glance, it is nicer to have just 1 persistence framework. But I think that mostly developers with this question underestimate the effort needed to build a full persistence layer for all those engine and API capabilities.

    Embeddability is key for us. So if we missed something, we really want to learn. Especially reasons why it would be inconvenient for you to flush your domain model persistence framework to the same JDBC connection as the Activiti persistence framework.

    ReplyDelete
  21. Hi Tom, Joram,

    Congratulations on the new project! Looking forward to working with the new engine... will try it soon.

    ReplyDelete
  22. I have been waiting to see a BPM module in alfresco and thanks for bringing this up.All the best for your efforts.

    ReplyDelete
  23. @Tom: I didn't mean the non-JDBC storage but rather thought about the way you managed persistence in jBPM3.x or 4.x where you used Hibernate being probably one of the most widely used ORM frameworks out there.

    On the one hand, you are right pointing out that the way Activiti manages its internal persistence shouldn't be of interest for the outside world as long as we can plug a Data Source into it e.g. using Spring dependency injection. So far I agree with you. But then, talking about embeddability I am thinking about all those projects using JPA being part of the JEE standard.
    It would be really nice to have the possibility to use domain objects in your workflow as process variables. You offered that in jBPM with Hibernate persistence but it was restricted to the same data source which jBPM used and JPA was not supported. With JPA, using different persistence units we could use different data sources.

    In many cases it is reasonable to separate the workflow engine database from the database containing business data. Now imagine how flexible your WF engine would be if it allowed to access JPA based domain objects and query them. That is one point I would really take into consideration when starting from scratch like you do.

    Of course you could say that if we "separate concerns" a workflow engine shouldn't deal with persistence at all. But you offered that already in jBPM and not without a reason I guess.

    ReplyDelete
  24. Yuri, I absolutely that we need to focus on what you point out here: "But then, talking about embeddability I am thinking about all those projects using JPA being part of the JEE standard.
    It would be really nice to have the possibility to use domain objects in your workflow as process variables. You offered that in jBPM with Hibernate persistence but it was restricted to the same data source which jBPM used and JPA was not supported. With JPA, using different persistence units we could use different data sources. "

    Whatever persistence Activiti uses, we should support automatic linking to user domain model objects and cover as much persistence frameworks as possible.

    ReplyDelete
  25. Tom, I totally agree with you!
    "
    Whatever persistence Activiti uses, we should support automatic linking to user domain model objects and cover as much persistence frameworks as possible.
    "

    Yuri

    ReplyDelete
  26. Hi Tom,

    Congratulations !

    Good luck

    ReplyDelete