Fady Matar wrote:
> Dear Tom,
> Initially when I started to create a workflow console based on JBPM I have
> set the design of an Authorization and Authentication framework, something
> similar to jbpm-identity and we implemented the module in jBoss Seam 1.0. I
> have created as well the user interface for it to allow managing the users.
> I believe we can migrate this module to JBoss Seam 1.2.0.GA if required, few
> modifications need to take place to enhance it, or we can create the same
> for jbpm-identity.
> Now since jbpm-identity uses jdk-1.4.2 I believe it will defeat the purpose
> of Seam and cannot be implemented in any case on it. We could create for
> instance a web app based on JSF to meet that purpose, or even a more daring
> approach would be to create an application in JBoss Seam that manipulates
> the database while jbpm-identity would take care of the functionality. What
> do you say?
> Another way is to create an EJB 3.0 implementation of the module as well and
> offer more flexibility to end users.
> What would you say?
i would assume that seam can handle 1.4.2 beans as well. so it should be able to handle the current identity module as well.
a quick scan through the seam ref manual gives this:
Javabeans may be used just like a stateless or stateful session bean. However, they do not provide the functionality of a session bean (declarative transaction demarcation, declarative security, efficient clustered state replication, EJB 3.0 persistence, timeout methods, etc).
In a later chapter, we show you how to use Seam and Hibernate without an EJB container. In this use case, components are JavaBeans instead of session beans. Note, however, that in many application servers it is somewhat less efficient to cluster conversation or session scoped Seam JavaBean components than it is to cluster stateful session bean components.
By default, JavaBeans are bound to the event context.
Concurrent requests to session-scoped JavaBeans are always serialized by Seam.
So we can always use the data model objects as-is, i think.
What might need a separate ejb3-wrapper and a maybe also refactor the IdentitySession a bit to support that external wrapper. So i think the first effort should be to try and wrap what we have into seam. If we need to update the way that IdentitySession's are created for that, no prob. If the whole identity component becomes dependent on ejb 3, that is a problem.