Hi all, first off, thanks Sathwik for triggering this discussion. It is good and important to have it now.
I believe that there are several assumptions ODE is built upon that are not valid anymore: 1. BPEL is a thing. 2. WS-* is a thing. 3. Service Orchestration is a thing. WS-* is nowadays a legacy technology, which still exists but nobody is eager to further invest in it. BPEL has lost the competition with BPMN 2.0 due to the lack of people activities and a visual representation. Although BPMN 2.0 has all the means for data transformation and service orchestration (like in BPEL) in turned out, that it is better to refrain from using such features, push it to the task implementations and keep the technical process model as close as possible to the real business model. Activiti/Camunda has followed that approach and seem pretty successful with this. So plain old service composition and in-process data transformation let models diverge from their business process model and are quite cumbersome to model. The problem that I now see is that ODE deeply relies on BPEL and WS-*. I doubt that it can be refactored to fit modern purposes. I did some experiments to build a BPMN 2.0 navigator using JaCOB a while ago (which somewhat worked but was not the best fit as well), but implementing the full spec is quite a bit of work and with the decreasing interest in WS-* I was not sure if it is worth the effort. So I see a couple of questions: 1. Of course we can continue to maintain ODE and make small maintenance release, but: Is it worth the effort? Is there a vital user base that justifies a hospice team? 2. Is it worth to add a BPMN 2.0 navigator to ODE, which would make ODE the first engine that implements BPMN in the way it was intented by the BIOS team, that contributed the execution semantics to the standard? It would be still mainly about service orchestration. Would that attract users and dev? 3. Would it be better to think about a next-generation engine architecture, since smart and experienced people are already around here? Though, we're already pretty late to the party, as there is already Netflix's Conductor, Uber's cadence, Camunda's zeebe.io. Also, would this still be ODE? Or rather a subproject? I like Aarons thoughts and we should keep up the discussions but should also consider the current state, the willingness to invest time and effort and see how we could proceed with the status quo. Thanks, Tammo PS: Paul, I believe JaCOB was beyond state-of-the-art back then. On Fri, Oct 6, 2017 at 6:26 PM, Paul Brown <paulrbr...@gmail.com> wrote: > There is a *lot* of stuff to think through. At the time we built what > became ODE, there was no Akka, no Pony, Zookeeper didn't exist, the Dynamo > paper hadn't even been thought about (that started in 2005), etc. > > On Fri, Oct 6, 2017 at 9:20 AM Zubin Wadia <zwa...@gmail.com> wrote: > > > Hi All, > > > > Speaking of advancement, this is pretty interesting too, odd name > > notwithstanding: https://tendermint.com/ > > > > Cheers, > > > > Zubin > > > > On Fri, Oct 6, 2017 at 12:10 PM, Paul Brown <paulrbr...@gmail.com> > wrote: > > > > > Hi, Aaron -- > > > > > > All sorts of things like that should be on the table, IMHO. The > original > > > design for ODE dates back to 2003 or so, and the state of the art > across > > > the board in middleware has advanced a bit in the last 13 years. > > > > > > Cheers. > > > -- Paul > > > > > > > > > > > > > > > On Fri, Oct 6, 2017 at 9:07 AM Aaron Anderson <aander...@apache.org> > > > wrote: > > > > > > > Hi Sathwik, > > > > Is there any plan to support any other execution languages like > > > executable > > > > BPMN 2.0 or SCXML in the future or is the main focus of the project > now > > > > maintaining the current 1.X functionality? Perhaps I should continue > to > > > > research using Ignite for process execution and come back with my > > > findings. > > > > Regards, > > > > Aaron > > > > > > > > On Friday, October 6, 2017 1:18 AM, Sathwik B P < > > > sathwik...@gmail.com> > > > > wrote: > > > > > > > > > > > > Hi Aaron, > > > > > > > > Good to hear from you. > > > > > > > > We have added basic clustering capabilities using Hazelcast. JACOB > now > > > uses > > > > JSON serialization with JACKSON. Both these feature are on the trunk > > and > > > > will be coming in 1.4. > > > > > > > > We can definitely discuss improving the engine. I am game to make ODE > > > more > > > > modular in design, reactive and scalable keeping in mind a migration > > > path. > > > > > > > > regards, > > > > sathwik > > > > > > > > On Fri, Oct 6, 2017 at 3:01 AM, Aaron Anderson <aander...@apache.org > > > > > > wrote: > > > > > > > > > Hi Sathwik, > > > > > I am a dormant Apache ODE committer and I would be interested in > > > > > contributing to new development on Apache ODE. I attempted to > build a > > > > > prototype several years ago on github (https://github.com/ > > > > > aaronanderson/ODE-X) but I lost steam building the runtime > execution > > > > > engine. Based on my experience with the 1.X code base there was a > > large > > > > > amount of complexity around concurrency, key value storage, and JPA > > > > > persistence. These issues made clustering challenging if not > > > impossible. > > > > > These are the same challenges I tried to overcome with my own > runtime > > > > > engine design. > > > > > Within the last year I got very excited when I came across the > Apache > > > > > Ignite in memory fabric which can solve all of these scalability > > > > problems. > > > > > Recently Ignite introduced built in persistence which would remove > > the > > > > > requirement of needing a DB for persistence. Apache Ignite has many > > > > useful > > > > > features beyond simple caching such as messaging, flexible > > transaction > > > > > management, and of course clustering. It is not difficult to > imagine > > a > > > > thin > > > > > business process execution layer on top of Apache Ignite hydrating > > and > > > > > dehydrating processes as requests are received and handled. > > > > > I have my own ideas on building a general purpose virtual process > > > > > execution runtime leveraging CDI and binary XML but the existing > ODE > > > > JACOB > > > > > java serialization framework could work just as well with Apache > > > Ignite. > > > > If > > > > > interested I can elaborate on my ideas further. > > > > > Apache ODE uses antiquated technologies and there is a huge > > opportunity > > > > to > > > > > build a modern Cloud friendly Open Source business process engine > > > > > exclusively using Apache sponsored technologies. > > > > > Regards, > > > > > > > > > > Aaron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Saturday, September 30, 2017 1:43 AM, Sathwik B P < > > > > > sathwik...@gmail.com> wrote: > > > > > > > > > > > > > > > Hi Community, > > > > > > > > > > Contributions and involvement from the community towards the > > project's > > > > > growth over the time has considerably diminished. We are seeking > new > > > > > contributors / committers to continue the growth of the project. > > > Anybody > > > > > willing to help the community are welcome. > > > > > > > > > > There has been no much feedback post 1.3.7 release from the > > community. > > > > > > > > > > Am working on 1.3.8 release bringing on Java 8, Moving to JPA2 from > > > JPA 1 > > > > > (OpenJPA 2.4.2 & Hibernate 4.3.11), Upgrading to Axis2 1.7.6 and > > > Embedded > > > > > server on TomEE7.0.4 which is now under release vote. Hope I might > be > > > > able > > > > > to bring in the 1.3.8 release in the next quater. > > > > > > > > > > regards, > > > > > PMC Chair. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Tammo van Lessen - http://www.taval.de
