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.)
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.
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)
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.
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 ?
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.
2) Analytics View: A view for the business owners, where they can view cross-process reports, dashboards and may be rules as well.
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.
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.
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
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.
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.
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
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 ?
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.
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.
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: