[Design of JBoss jBPM] - SubjectAuthenticationService / ActorId from JAAS
by camunda
In the code base there is a SubjectAuthenticationService. The intention is, that the actor-id is set to the currently logged in JAAS-Subject. Unfortunately, this isn't implemented consequently.
In a current project we want to exchange the AuthenticationService, because we try to use Single-Sign-On Semantics in JBoss SOA Platform.
Currently there are 3 problems:
1.) There is no SubjectAuthenticationServiceFactory, so this AuthenticationService cannot be used
2.) subject.getPrincipals(principalClass) results in a list of Principals, containing groups as well. So by the current code, the actor isn't set correctly
3.) And this is the bigger SHOWSTOPPER: The AuthenticationService interface only defines the method "getActor". But at several places jbpmContext.setActorId is called (e.g. WebConsole PhaseListener, ESB BpmProcessor, ...). This results in an exception if the DefaultAuthenticationService is not used! This makes it impracticable to exchange the AuthenticationService.
So what to do at this front?
I see two possibilities:
a) Change the AuthenticationService interface to include a setActorId method. This can be ignored by implementations like the SubjectAuthenticationService (cannot and don't want to change the JAAS subject).
b) Change the JbpmContext to ignore setActorId depending on the AuthenticationService implementation.
The third possibility isn't really an option I think: Change all clients to NOT call the setActorId without any good reason.
I tend to option (a). What I could imagine is, that the actorId is queries from JAAS if null, but can be overwritten with setActorId and then remembered locally. Please refer to the forum for discussion....
I will open a JIRA for it as well...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195844#4195844
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195844
16 years, 10 months
Re: Migration
by Tom Baeyens
These are the ideas that we came up with in the jBPM team meeting:
> B- Side-by-Side - execute concurrently in same AS/ESB container
A big drawback that we identified was that users would not be able to deploy new
versions of existing processes to the new jBPM instance. Cause in that case, our
users (or we) would have to write code to determine on which jbpm instance, the
execution is running. That is so impractical that we believe this is a showstopper.
In most deployment environments, I don't think our users will have an option to run
jBPM 4 in a different DB schema then their own app and jbpm 3. Also mixing the
libraries will be a very hard or impossible.
> C- New Engine, New Projects - start new projects on the new engine
This would mean completely different SOA-P installations ? I don't think that would
be feasible for our users.
> A- Migrate - tools & documents
We came to the conclusion that migration was the only viable option that we had left.
On top of that, users can be expected to migrate code and do significant conversion
work when they do a major version upgrade.
If they are not able to do this migration, they still have the option of sticking
with jbpm 3 for a couple of years longer.
For the API, things will change. jBPM 4 will be the version where we introduce a
new, more limited API that will be easier to keep stable.
For the jPDL XML, we think its feasible to provide the migration tools that will
cover +90% of the jPDL XML, document which features are not supported and provide
pointers on how users should proceed with those non automated parts of the jPDL XML
migration.
For the DB just the same. We think it is feasible to supply a serialization to file
of the DB contents and then load it back into the new DB. Again, this will not be
100% but we must be able to indicate how our users should proceed for the features
that are not automatically supported.
jBPM 4 has a lot of improvements/changes, but the structure of the XML and the DB is
still similar. That is why we believe that migration is a viable route.
regards, tom.
Burr Sutter wrote:
> I was traveling when this thread started and just now getting back to
> it. One thing to keep in mind is that the ESB embeds jBPM for its
> service orchestration capabilities. We have to consider that use case
> otherwise it might take many months/years to migrate SOA Platform
> codebase & userbase from jBPM 3 to 4. That will delay the official
> support date of jBPM 4.
>
> There are 3 options that I can see:
> A- Migrate - tools & documents
> B- Side-by-Side - execute concurrently in same AS/ESB container
> C- New Engine, New Projects - start new projects on the new engine
>
> A - Migrate Negatives
> - Very expensive to build all the tools & document all the elements
> - Requires a complete re-testing of the customer's end-user
> applications, a process that could take years in larger customers
> - Automated tools are likely to be error prone and will not address 100%
> of the customers solution, for instance, their custom reports (SQL
> scripts) won't be automatically migrated and will need to be re-written.
> - Large customers will take multiple years to move due to the
> re-testing, re-writing effort
> - Will the Action API also change? Even if not I don't see great value
> in automated JPDL migration tools, the average end-user app has much
> more invested in actions & other jBPM API usage than it does JDPL
> "coding". The cost associated with re-drawing a diagram in a visual
> tool is pretty marginal.
>
> B - Side-By-Side Negatives:
> - QA requirements to verify that the 3 and 4 DB schemas can live happily
> and perform well in the same DB instance
> - QA requirements to verify that the 3 and 4 JARs can live happily in
> the same AS container and/or same .WAR
> - Timer & other enterprise features shouldn't interfere with each other
> - The downside is that the customer has to learn about and administer
> essentially two different environments. For example, customers are
> likely to have custom reports on the old data model which will need to
> "join" data with the new data model for a comprehensive report.
>
> C - New Engine, New Projects:
> - Current users can only start their next .war, .ear with the new API,
> new DB schema in a new DB instance, therefore they must wait for the new
> project to start
>
> Give me some more pros & cons for the various approaches. The odd thing
> is that on B & C look more reasonable based on what I've stated here.
>
>
> Tom Baeyens wrote:
>> to what extend will we be able to avoid DB migration if we make sure
>> our users can run jBPM 3 and jBPM 4 next to each other ? That should
>> make a difference, no ?
>>
>> regards, tom.
>>
>>
>> Martin Putz wrote:
>>> IMO, we will need all of it:
>>>
>>> 1. DB migration
>>> 2. process migration
>>> 3. API migration
>>>
>>> If we don't offer tools for 1 and 2, we will definitely face much
>>> pressure from our customers. So although it's true that we might save
>>> some resources beforehand, we will have to deal with those issues and
>>> questions afterwards. For 3 I think having docs should be sufficient.
>>>
>>> Regards,
>>> Martin
>>>
>>>
>>> Tom Baeyens wrote:
>>>> Jeff, Burr, Martin,
>>>>
>>>> Afaict, you are the guys closest to our customers. Next week, we'll
>>>> be discussing migration between jBPM 3 and 4 in the team. We would
>>>> appreciate your input.
>>>>
>>>> If we had unlimited resources, we'ld simply provide DB, process-XML
>>>> and API backwards compatibility, but given that our resources are
>>>> limited and the improvements numerous, here are my initial thoughts
>>>> on how we currently think to handle migration:
>>>>
>>>> Probably DB migration will be too hard to supply in a decent
>>>> manner. So we'll probably target that users will be able to use
>>>> jBPM 3 and jBPM 4 in parralel. That way they can start deploying
>>>> new processes to jBPM 4 and let jBPM 3 processes fade out.
>>>>
>>>> For each process in jBPM 3, they could migrate the process to jBPM 4
>>>> (see below), redeploy and start new executions in jBPM 4. Although
>>>> from the user client code perspective this will be hard or impossible.
>>>>
>>>> We also anticipate that we'll have to supply a process translation
>>>> tool that can translate jPDL 3 process XML files to jBPM 4 process
>>>> XML files. Most of the process file will be converted. But
>>>> probably there will be some things in jBPM 3 that we will not
>>>> support in the exact same way in jBPM 4. So some converted
>>>> processes might not be complete or might not execute exactly the
>>>> same way as in jBPM 3.
>>>>
>>>> API will be different. Only migration docs. The good news is that
>>>> with the arrival of jBPM 4, we'll start to ship a more limited API
>>>> that is more decoupled from the engine internals so that it will
>>>> remain much more stable from then onwards.
>>>>
>>>> Feedback from our jBPM Community Day in Dublin was very clear:
>>>> Migration is one of the biggest concerns for our users.
>>>>
>>>> So here are my questions:
>>>>
>>>> What aspect of migration will be the biggest challenge for our
>>>> customers ?
>>>>
>>>> Which aspects of migration will be showstoppers for ourcustomers ?
>>>>
>>>> Suppose that we ship the above migration strategy and a really
>>>> really really important client wants to migrate his DB really really
>>>> really badly. Would we
>>>> a) be able to say no.
>>>> b) provide him with skeleton code that the client can use as a basis
>>>> to write their own DB migration in code.
>>>> c) let our consultants work out the DB migration for the first
>>>> customer that wants to pay for it and then add it to the jBPM codebase.
>>>>
>>
>
--
regards, tom.
16 years, 10 months
