1 2 Previous Next 20 Replies Latest reply on Mar 31, 2008 6:11 AM by camunda Go to original post
      • 15. Re: New jBPM Console

         

        "mark.proctor@jboss.com" wrote:

        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.


        JBoss Seam is aligned with jBPM as well. Richfaces + Ajax + Seam provide us with a good combination of tools to build what we require, I'm more keen on using an in-house tool where I can get quick support and assistance from the team and where I can contribute back whenever possible.

        At least from an integration perspective it would look much better the more we integrate our products.

        • 16. Re: New jBPM Console
          tom.baeyens

           

          "mark.proctor@jboss.com" wrote:
          "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.


          Similarly I asked the rethoric question: "Why can't drools console be build in JSF and so be aligned with jBPM ?"

          You ignore the fact that JSF knowledge is much wider spread. Which means that buiding the site in JSF makes it easer for us to deliver JSF components which will be an interesting asset for our project. Also JSF related expertise is easier to find/get/manage.

          Apart from that, I don't see GWT being the strategic direction for JBoss. I only see drools using it within JBoss. I see JBoss in general as somewhat neutral (seam supporting many UI techs) but a big tendency towards JSF related technologies.

          From my perspective, all in conclusion, the drools GWT route currently doesn't have enough weight to make it an easy decision.

          • 17. Re: New jBPM Console
            tom.baeyens

             

            "adeeljaved" wrote:
            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.


            I had a look. What you sketch is indeed something we need to improve. But the biggest problem still open is how to make this concrete.

            What are the different roles that we'll define, and what features will we offer to each of them. Then we need to go through the difficult excercise of building a set of pages that depending on the role, shows the appropriate content.

            With that in mind, I created http://www.jboss.org/wiki/Wiki.jsp?page=JbpmConsolePageHome

            That was aimed to work out such issues. Do you think it's effective for you if you help working out all the pages in the wiki like that ?

            We could define the roles we target and then on each page indicate for which roles the page is and/or which parts are hidden/added for which roles.

            • 18. Re: New jBPM Console
              adeeljaved

              Sure Tom, I'll take a look at Wiki and try to add the content in your specified format. Thanks.

              • 19. Re: New jBPM Console
                kukeltje

                 

                JBoss Seam is aligned with jBPM as well. Richfaces + Ajax + Seam provide us with a good combination of tools to build what we require, I'm more keen on using an in-house tool where I can get quick support and assistance from the team and where I can contribute back whenever possible.


                Yep, I'll contribute to when going for this technology stack. GWT is not on my list to learn. Besides that there are so many other things that *are* on that list but keep slipping, among which are ESB and Drools

                • 20. Re: New jBPM Console
                  camunda

                   

                  You ignore the fact that JSF knowledge is much wider spread. Which means that buiding the site in JSF makes it easer for us to deliver JSF components which will be an interesting asset for our project. Also JSF related expertise is easier to find/get/manage.


                  I absolutely agree with that statement! I see JSF Knowledge growing everywhere, and it makes sense, it is a Java EE 5 standard! By the way, JSF is a full day in the JBoss and EJB 3 Training, so it should be a direction JBoss is going...

                  And the approach started with the current console (providing facelets for reusable components) is perfectly the right one I would say.

                  And currently there is some effort going on to integrate JSF applications into portals as portlets (again standards everywhere!), so I think this will make it easy for customers to leverage the console also as starting point for own web guis....

                  Since EJB3 seems to be seen as too limiting, I would vote for POJO + JPA. In the implementation, this can be also annotated to be a EJB3 app if the container supports it (at least it works in my mind at the moment ;-)).

                  Cheers Bernd

                  1 2 Previous Next