Activiti in the cloud

[cosmicrider]

Still trying to connect all the 'Activiti dots' in my brain - please bare with me:

Imagine a SaaS service that is using Activiti in a single dB configuration. In this case the users of the SaaS would need to be isolated from each other. To keep it simple lets say a appID is attached to all the dB tables as the mechanism to isolate users from each other. Let's also say, for example, that the Vacation Request process is provided by the SaaS.

For clarification:
SaaS model
appID is used in each table to isolate users of SaaS from each other
a single dB is used
Table holding users already exist and needs to be used by Activiti
Table holding groups already exist and needs to be used by Activiti
Vacation Request process offered in SaaS

Taking one example - the IdentityService:
Through configuration can we tell the IdentityService which table and values to use or do the developers need to roll their own IndentityServiceImpl? If configuration then how is it accomplished, an example would be great.

Vacation Request Process - I suspect the ID's used are unique to all running instances of a process. I am also assuming that this ID gets generated by Activiti upon Process activation. If this is correct, then is it safe to say that the running of a process in an SaaS model should not be an issue?

Of course, the same question would apply to the other Activiti artifacts.

[cosmicrider]

My concern - If Activiti does not provide capabilities to integrate into pre-existing environments where tables such as groups, members, etc already exist then a huge opportunity will be lost. The same goes for SaaS or, like my company. centralized services where many applications, distinguished by application tokens, use the same service - functionality remains the same, just the data operated against (like groups and members) is different

[sstolarczyk]

Yeah, you're partially right, but is it just Activiti responsibility? I also had pre-exsisting databases in my applications, but I managed to change the mappings to proper names in just a few moments, for instance:

@Table(name = "ACT_ID_USER")
public class User implements Serializable

Of course, it won't always be that easy, you don't always have to source code etc. But it's not a pain at all.

[cosmicrider]

User and Group membership/roles within many companies are part of the overall Identity Management (IDM) Authentication/Authorization solution. Security, Legal, etc is involved in determining the overall solution. Once this is established there are many applications that become dependent on the table structure etc. It is not feasible to simply point to another set of tables, especially with such a simple definition of User and Group.

It is also generally the case that users and roles are bound to specific usage, and because of this must be kept separate (example: A companies external customers versus internal employees or, like my SaaS example, imagine you have organization A, organization B and organization C paying for your SaaS service. Each Organization has it's set of users and roles that must be kept separate. Intermixing is not acceptable in this situation and would only lead to confusion.)

I am asking if Activiti has thought through these valid scenarios. The cleanest?? fix would be to add a unique service identifier on their tables where service uniqueness needs to be guaranteed. At least, tho not optimum, I could write a simple app that would take data from our internal dB structure and use it to fill Activiti's tables. Another solution would be to provide a configuration that let's us override the Implementations of classes that need to have knowledge of a service ID (classes identified by Activiti). In this case Activit could provide us example ServiceImpl's that could be used as a template to ensure compatibility.

As an architect I realize we now live in a world where the way applications are crafted can no longer assume dedicated environments, especially as more and more companies are entering the Cloud and SaaS model. My personal belief (my belief and a US $dollar will by you a can of Pepsi) is that we need to ensure projects like this support the SaaS model first, because it does not, in any way, impair a single application approach from using the solution. Simple case, they have to inject a serviceID, which is simple and can be solved once via configuration. Focusing the other way unnecessarily limits where a solution like this can be used.

My company is entering the SaaS model next year and has need for a workflow solution. I am investigating our options now in hopes that we do not need to roll our own