Has anybody tried to get Runa WFE work on Tomcat Servlet Container. I am curious to know what benefits does RUNA get using an EJB container. What should be my approach to get it working on Tomcat. Ofcourse moving out of Stateless Session beans would be one of them.
Best Regards
Prashanth Sukumaran
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The architecture is straightforward.
DAO level does all persistent operations. (it could be replaced/substituted via Factory mechanism). You can substitute our DAO implementation by EJB3/Hibernate3/JDO2 or Oracle Toplink. We use patched Hibernate2 for DAO.
Logic level does all business logic operations (it can't be substituted).
Service level provides means to access Logic (so far we have only Session Beans implementation of service level, we have WEB services implementation in future plans). Each service provided by factory.
Delegate level provides API for all top level classes(it hides complexity of services invocation from user). Each delegate implementation calls corresponding Service. Each delegate is provided by factory (client knows nothing about implementation).
re:I am curious to know what benefits does RUNA get using an EJB container.
Session Beans are used for transaction demarcation and remote method invocation.
Bots, task notifiers, thick clients, script runner (from admit kit) use remote method invocation.
Runa WFE is not just a web app ;-)
re: What should be my approach to get it working on Tomcat. Ofcourse moving out of Stateless Session beans would be one of them.
Runa WFE can runs on multiple tomcat servers at once (without removing anything).
Just configure delegates to use appropriate application server (so far we support only JBoss but we plan to migrate to EJB3 and I hope the descriptors hell will desapear).
If you want to run Runa WFE on tomcat server without any application server you'll have to reimplement service/delegate layers (e.g. replace it with plain method invocation + AOP for transaction demorcation).
Regards,
Vitaliy S
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Vitaliy for the reply. RUNA team is doing a great job with RUNAWFE.
I have one question though, are you saying that by replacing the service/delegation layer i will be able to get rid of the Application Server. Will JBMP not crib that i requires App Server.
Best Regards
Prashanth
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
re:I have one question though, are you saying that by replacing the service/delegation layer i will be able to get rid of the Application Server. Will JBMP not crib that i requires App Server.
jBPM can works as stand alone application.
PS What are the benefits of removing EJB container?
Regards,
Vitaliy S
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As far as possible i would like to keep it simple with the servlet container (Tomcat). All my applications are servlet based. I love tomcat for its simplicity. This way it will be easy for junior developers to be productive quickly and accomplish the task.
I am sure i can achieve RUNA WFE on tomcat just fine and i will not require an App Server at all. Also i don't want to introduce a dependecy on Application Server. I stopped working on App Server 5 years ago and moved to Tomcat.
Thanks
Prashanth
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you are going to implement light weight service/delegation level I could help you with it in developers forum.
I'd prefer to use Spring framework for this purpose (we are going to use some parts of Spring anyway).
Transaction demarcation can be done with the help of Spring AOP.
For remoting Spring has support for "traditional" RMI, web services(JAX RPC) and two Caucho's RPC technologies (Hessian and Burlap).
I think JAX RPC is best for this.
However, Spring does not support propagation of transaction contexts across remote calls.
In this case Rod Jonson recommends to use EJB.
Regards,
Vitaliy S
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Has anybody tried to get Runa WFE work on Tomcat Servlet Container. I am curious to know what benefits does RUNA get using an EJB container. What should be my approach to get it working on Tomcat. Ofcourse moving out of Stateless Session beans would be one of them.
Best Regards
Prashanth Sukumaran
Prashanth,
First, let me explain RUNA WFE architecture.
The architecture is straightforward.
DAO level does all persistent operations. (it could be replaced/substituted via Factory mechanism). You can substitute our DAO implementation by EJB3/Hibernate3/JDO2 or Oracle Toplink. We use patched Hibernate2 for DAO.
Logic level does all business logic operations (it can't be substituted).
Service level provides means to access Logic (so far we have only Session Beans implementation of service level, we have WEB services implementation in future plans). Each service provided by factory.
Delegate level provides API for all top level classes(it hides complexity of services invocation from user). Each delegate implementation calls corresponding Service. Each delegate is provided by factory (client knows nothing about implementation).
re:I am curious to know what benefits does RUNA get using an EJB container.
Session Beans are used for transaction demarcation and remote method invocation.
Bots, task notifiers, thick clients, script runner (from admit kit) use remote method invocation.
Runa WFE is not just a web app ;-)
re: What should be my approach to get it working on Tomcat. Ofcourse moving out of Stateless Session beans would be one of them.
Runa WFE can runs on multiple tomcat servers at once (without removing anything).
Just configure delegates to use appropriate application server (so far we support only JBoss but we plan to migrate to EJB3 and I hope the descriptors hell will desapear).
If you want to run Runa WFE on tomcat server without any application server you'll have to reimplement service/delegate layers (e.g. replace it with plain method invocation + AOP for transaction demorcation).
Regards,
Vitaliy S
Thanks Vitaliy for the reply. RUNA team is doing a great job with RUNAWFE.
I have one question though, are you saying that by replacing the service/delegation layer i will be able to get rid of the Application Server. Will JBMP not crib that i requires App Server.
Best Regards
Prashanth
Prashanth,
re:I have one question though, are you saying that by replacing the service/delegation layer i will be able to get rid of the Application Server. Will JBMP not crib that i requires App Server.
jBPM can works as stand alone application.
PS What are the benefits of removing EJB container?
Regards,
Vitaliy S
Hi Vitaliy,
As far as possible i would like to keep it simple with the servlet container (Tomcat). All my applications are servlet based. I love tomcat for its simplicity. This way it will be easy for junior developers to be productive quickly and accomplish the task.
I am sure i can achieve RUNA WFE on tomcat just fine and i will not require an App Server at all. Also i don't want to introduce a dependecy on Application Server. I stopped working on App Server 5 years ago and moved to Tomcat.
Thanks
Prashanth
Hello Prashanth,
I understood you point of view.
If you are going to implement light weight service/delegation level I could help you with it in developers forum.
I'd prefer to use Spring framework for this purpose (we are going to use some parts of Spring anyway).
Transaction demarcation can be done with the help of Spring AOP.
For remoting Spring has support for "traditional" RMI, web services(JAX RPC) and two Caucho's RPC technologies (Hessian and Burlap).
I think JAX RPC is best for this.
However, Spring does not support propagation of transaction contexts across remote calls.
In this case Rod Jonson recommends to use EJB.
Regards,
Vitaliy S