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.
Congrats, sounds like you've got exciting times ahead. :)
ReplyDeleteGreat to finally hear what you've been up to! Can't wait to dig into the details. Good luck on this next adventure!
ReplyDeleteHappy to have you on board at Alfresco Tom, definitely an exciting time for Alfresco and the BPM / ECM community!
ReplyDeleteGreat so see such collaboration!
ReplyDeleteThat sounds great. I'm really looking forward to a process engine with native BPMN 2.0 support. Great!
ReplyDeleteGood luck Tom!!!!!!! May the 12 gods be with you :D!
ReplyDeleteExciting times ahead for BPMN 2.0 and open source. :)
ReplyDeleteHi Tom,
ReplyDeleteCongratulations, this projects seems to address exactly what i was looking for in a modern BPM paltform
Good luck
Andrea
how much code is taken from jBPM? I had a quick look on the user guide and it looks VERY similar to jBPM.
ReplyDeleteThis project looks very promising.
ReplyDeleteOne 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
Good luck my friend!
ReplyDelete@All Thanks for the compliments.
ReplyDelete@Anonymous There is zero jBPM code in Activiti. The license change prohibits that. So we had to start completely from scratch.
Good to see the real thing. I can't wait to try it out!
ReplyDeleteAwesome stuff; a process engine in your app .. wow stuff
ReplyDeleteSetup did not work on Mac :-(
ReplyDeleteanthos-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
Anil,
ReplyDeleteplease post your question on the user forum. including what jvm you're using.
http://forums.activiti.org/en
@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.
ReplyDelete@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
Thanks, Scott! Such a compliment from you means a lot to us and it keeps us going.
ReplyDelete@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.
ReplyDeleteI 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.
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@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.
ReplyDeleteBut 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.
Hi Tom, Joram,
ReplyDeleteCongratulations on the new project! Looking forward to working with the new engine... will try it soon.
I have been waiting to see a BPM module in alfresco and thanks for bringing this up.All the best for your efforts.
ReplyDelete@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.
ReplyDeleteOn 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.
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.
ReplyDeleteIt 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.
Tom, I totally agree with you!
ReplyDelete"
Whatever persistence Activiti uses, we should support automatic linking to user domain model objects and cover as much persistence frameworks as possible.
"
Yuri
Hi Tom,
ReplyDeleteCongratulations !
Good luck