ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Anderson <aaronander...@acm.org>
Subject Re: Is it time for Retire Apache ODE?
Date Wed, 31 Oct 2018 05:15:38 GMT
Hi Sathwik,
Sorry for the 11th hour request for a reprieve but I am still very much interested in working
on a new 2.0 version of Apache ODE. Apache ODE had visionary design patterns such as plugable
service implementations and the Jacob persistence and concurrency framework. Over the many
years since ODE's inception Java dependency injection has been standardized with CDI 2.0 and
Cloud scale persistence and concurrency has be realized with Apache Ignite. 

When I was developing with Apache ODE six years ago there were several pain points I experienced:
1) Limited or difficult extensibility -  Apache Axis is required along with a supported JPA
database. Theoretically other BPM engines could be built using Jacob but practically ODE is
tightly coupled with BPEL
2) Scalability - ODE worked fine with a single node but there were stability issues scaling
it out. 

3) Process debugging and diagnostics - As an end user debugging and viewing the state of a
running process was difficult and required dropping down to a Java debugger to view the process
state in Java variables.
The extensibility challenges can addressed using CDI extensions which not only provide dependency
injection but also bean discovery and custom scopes. Apache Ignite can solve the scaliablity
issues as it provides a wide variety of proven distributed computing capabilities including
important persistence and ACID SQL support that has been added within the last year and a
half. I also have a strong idea on how process execution could be implemented to address the
process manageability issues. What would set this new ODE platform apart from other available
orchestration projects is that it would designed with extreme extensibility in mind and serve
more as a general purpose BPM platform that current and future dialects can be built on instead
of designed to solve only a specific BPM requirement.

I realize I proposed this solution a year ago and unfortunately up until now I was engulfed
in overtime consulting work and internal projects which limited my ability to contribute.
My situation has changed recently and I now have more latitude to work on a second phase of
an internal project that heavily involves process automation. 

I would like to propose that the decision to retire the ODE project be postponed and that
I be given six weeks to finish a prototype ODE BPM platform that I have been working on that
can be evaluated by the ODE PMC members to see if it has merit for continued development as
part of the ODE project.  


Regards,
Aaron
 

    On Tuesday, October 9, 2018 5:22 AM, Sathwik B P <sathwik.bp@gmail.com> wrote:
 

 Hi Devs/Users,

I had started this dicussion thread over an year ago
[
https://lists.apache.org/thread.html/29951cfa866d36d16a5c80b51838b9cc2f5228020d110f607e8b0e1c@%3Cdev.ode.apache.org%3E].


Nothing has much moved forward since then. Our last 2 reporting cycles have
been very dull without much of activity. We do not see any other PMC
members active apart from taking part in the voting of releases.

I presume, we probably do not have the active PMC quorum to fix any
security issues in present and future.

Incase any other PMC member is willing to take over the Chair position and
carry on from here and not want to retire the project, raise your hand and
I will initiate the process.
Otherwise,
" I propose to move Apache ODE to the Attic."
If the PMC agrees, I will start a vote. Let me know your suggestions.

For the users, this basically means if the PMC agrees to the voting and
successfully votes to retire the project, then the project will not be
actively maintained, no future releases, no bug fixes,no security patches.
The source code will be available to all in read only mode, though one can
fork your own copies of the repo on github.com/apache/ode.

regards,
ODE PMC Chair


   
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message