1 2 Previous Next 20 Replies Latest reply on Mar 31, 2008 6:11 AM by Bernd Ruecker

    New jBPM Console

    Fady Matar Novice

      We're currently building the new jBPM console that will be compliant with future versions of jBPM and I would like to get feedback from different members of the community before we finalize on the adopted strategy / environment for development.

      The application will be built on top of JBoss Seam + Richfaces and in here we have a number of options:
      1. The application can be built using POJOs and hence doesn't become dependent on EJB 3. The persistence mechanism will be either JPA or Hibernate and then the application can be deployed on Tomcat / JBoss AS
      2. The application can be built using an enterprise methodology i.e. Entity Beans for persistence and Session Beans for all kind of business logic / actions. This will require a bootstrapped Tomcat installation or JBoss AS or any other EJB 3.0 compliant application server.

      I would like to get the feedback to see what strategy to adopt, any thoughts on this?

        • 1. Re: New jBPM Console
          brittm Novice

          So much can be gained (and proven) using an EJB3 stack, that I can't think of a good reason not to. Three thoughts:

          * The jBPM/SEAM/Jboss community should be looking for opportunities to demonstrate all these offerings really working together on a modern EJB3 platform. Red Hat/Jboss needs to show the industry that its solutions are modern and to take the lead in demonstrating best-practices in the implementation of its leading technologies.

          * Implementing against EJB3 would be more likely to identify bugs and needed enhancements in up-stream projects--doing more to both improve the upstream projects and provide a greater pool of solid, working examples of utilizing these technologies in a modern framework.

          * Process management is such an "enterprise" type of application, that requiring a modern container seems quite reasonable.

          * Negatives might be any known issues with EJB3 that would hamper delivery of a solid product. (But I don't know of any, so someone else will have to speak about that.)

          • 2. Re: New jBPM Console
            Jeff DeLong Master

            EJB3 is too limiting in terms of platform support. The jBPM console needs to work in many different environment, including application servers that don't support EJB3 as well as the ESB Server which also does not include an EJB container.

            • 3. Re: New jBPM Console
              Ronald van Kuijk Master

              For the most part I agree with Britt, although the number of platforms the console could run on is *currently* limited then. That is where I (to some extend) agree with Jeff. The fact that the jbpm console does not need to run on the same system as the rest of the process or the esb to me is therefore no limitation. Internally we even forbid the console to run on the same system.

              But still I'd go for JPA with pojo's (although I like ejb3 better)

              • 4. Re: New jBPM Console
                Fady Matar Novice

                If EJB 3 can be a limiting factor then I'll resort to a different configuration that can run in at least JBoss AS and Tomcat environment.
                Entity beans can be substituted with JPA persistence and SLSB would be substituted with pojos.

                • 5. Re: New jBPM Console
                  Tom Baeyens Master

                  very good discussion, guys and galls :-)

                  all I know (and more) got already highlighted.

                  what I still don't know is whether there it is more difficult to deploy seam with ejb3 versus seam without ejb3.

                  any thoughts on that ?

                  • 6. Re: New jBPM Console
                    Adeel Javed Newbie

                    Hi All,

                    Tom first of all let me just comment on the technology aspect of console. I would suggest not to go with EJB3, considering the learning curve. My teams past experience with jBPM suggests that customizations of the portal do become necessary, so we have to make sure that we do not make it difficult for jBPM IT users.

                    Now coming to the actual screen layout, I have created some screen shots based on my experience of various BPM platforms. There will be three different views (I have linked them to my picassa web album, was not sure how to add images to this forum):
                    1) User View: This is for the end-users i.e. people who will login to execute processes and tasks.
                    [img]http://picasaweb.google.com/chadeeljaved/JBPMConsole/photo#5182311560964680754[/img]

                    2) Analytics View: A view for the business owners, where they can view cross-process reports, dashboards and may be rules as well.
                    [img]http://picasaweb.google.com/chadeeljaved/JBPMConsole/photo#5182311569554615362[/img]

                    3) Admin View: This is for the application administrators to see status of different processes with their versions, tasks and their status with picture of the actual process, managing users and user groups.
                    [img]http://picasaweb.google.com/chadeeljaved/JBPMConsole/photo#5182311582439517266[/img]

                    I am not sure about JBoss Portal and how much that could be of help to us in this case. So guys feel free to comment. Thanks.

                    • 7. Re: New jBPM Console
                      Ronald van Kuijk Master

                       

                      considering the learning curve.
                      hmm... compared to ejb2 or spring or... it's not steep, not at all. Still I'd not go for it for platform reasons.

                      [quote[My teams past experience with jBPM suggests that customizations of the portal do become necessary, so we have to make sure that we do not make it difficult for jBPM IT users. could you elaborate a little. Might be that you used the console for things it was not meant to be used for and/or curious what you were missing

                      was not sure how to add images to this forum


                      • 8. Re: New jBPM Console
                        Fady Matar Novice

                        There's no point in currently using EJB 3 for the following reasons:
                        1. Entities are managed through the jBPM libraries, the console by itself has no external entities, and since JBPM uses hibernate for persistence then we're using automatically Hibernate
                        2. We would like to make the console portable as much as possible and since EJB 3 support in a number of application servers is not yet implemented we resorted to use plain actions / pojos instead of SLSB.
                        3. The integration of the console with the portal is definitely a plus, however that is delayed with other features until the first release is out. The benefits gained out there are the delegation of authentication through the security of the portal.

                        If we were to limit ourselves to JBoss AS then I would definitely go for EJB 3.0 however we don't want to miss the opportunity of running the console on other application servers / servlet containers.

                        • 9. Re: New jBPM Console
                          Tom Baeyens Master

                          integration of our identity with portal's identity is still undefined. we both have developed and extracted our identity as separate components. but it will probably take another lead to merge those two and then integrate the merged component back into the two projects.

                          there are no concrete plans for that yet. alternatively, we'll provide the identity component implementation that fits in the portal identity interface. i see that as more feasible, but also that is not concrete yet.

                          • 10. Re: New jBPM Console
                            Ronald van Kuijk Master

                             

                            alternatively, we'll provide the identity component implementation that fits in the portal identity interface. i see that as more feasible, but also that is not concrete yet.


                            Sound interesting. I'll file at least a jira issue for this

                            • 11. Re: New jBPM Console
                              Tom Baeyens Master

                              no need. i'm completely aware of the need.

                              on the other hand, all promotion for community tasks is good. didn't we have a jira task that grouped all the community tasks ?

                              • 12. Re: New jBPM Console
                                Ronald van Kuijk Master

                                Yes you are aware of the need, so am I but not everybody. Maybe we (I?, you reviewing) should write an article/blog about some future directions besides the PVM.

                                Regarding the community task, Yes we did..ehhhh do, but not up to date any more... I'll try to revive it and maybe even try to 'promote' it in other JBoss projects.

                                • 13. Re: New jBPM Console
                                  Mark Proctor Apprentice

                                   

                                  "fady.matar" wrote:
                                  The application will be built on top of JBoss Seam + Richfaces


                                  I've made this point before. The web technologies used for jBPM should be aligned with what we are doing with Drools. Mic has proven his stack works and has had great success. I really would recommend you don't go down the RichFaces route.

                                  • 14. Re: New jBPM Console
                                    Adeel Javed Newbie

                                    Hi Everyone,
                                    Ok it's good that we are talking about the technology aspect, but the main point of my post was to talk about the functional aspect i.e. what content should go into jBPM console. I hope you guys had a look at the images that I linked, so let's start talking about that aspect as well, because the a BPM developer might not be as concerned about the technology as we might be.

                                    Posting the links again:
                                    http://picasaweb.google.com/chadeeljaved/JBPMConsole/photo#5182311560964680754
                                    http://picasaweb.google.com/chadeeljaved/JBPMConsole/photo#5182311569554615362
                                    http://picasaweb.google.com/chadeeljaved/JBPMConsole/photo#5182311582439517266

                                    Thanks.

                                    1 2 Previous Next