ASP Model
erik777 Nov 1, 2001 6:13 PMI am moving towards an Application Service Provider (ASP) model for my applications. It will reduce redundancy, increase time-to-market, decrease maintenance, and increase capacity and flexibility.
In the COM world I developed application independent base classes that brought RAD to fruition. One of the features was complete role-based security. Modules, used to define privileges, could represent anything the developer wanted, from tables/classes to business processes or functional groups.
The code was literally shared by multiple projects, minimizing maintenance. The Rose models design shared the base data classes as well. However, since each application required a distinct copy of the role based security data, there was still work to setup all the database instances, as well as configure each application.
The ASP model I envision would encapsulate the role-based security and integration features so that it becomes a distinct service. This would mean that a single application and database instance of this service would be able to service multiple applications, decoupling the two. To further pursue the ASP model, a single application it will be able to service many domains, simulating distinct instances of an application. The security model will need to support this as well.
Because this will be a separate service, it may or may not be on the same server as the actual application. In order to support redundancy and scalability features, an application also needs to be able to switch to a different instance of the service in production.
This distributed architecture requires versatile configuration options as well as robust transaction management.
For configurability, a deployment descriptor will not suffice since configuration will need to be managed on an instance by instance basis (one deployment descriptor will not suffice, and multiple deployment descriptors will be a pain for a single application.) Additionally configuration needs to be modifiable in the live production environment. This configurability will definitely be accessed by a server administrator, but may also become part of an automated process to ensure application reliability.
Transactions may need to span EJBs across JBoss instances. If the security service happens to be on a different instance, the calling beans will not know because this will be configurable.
JBoss specific questions include:
1> How can we achieve transactions across multiple JBoss instances?
2> How can we achieve such dynamic configurability. Deployment descriptors are undesirable, and I do not want to use a database, because I am trying to configure the way different components access each other, and this should include how the database is accessed. If we view the configurability as a service, it should permit applications to define configurations, like the way we add keys to the Windows registry. Any application accessing that instance should then be able to access the configuration.
In other words, this is not configuration that the container would actually use, although I can see this becoming a standard, and then it might.
3> Davidjencks, you mentioned MBeans. Do you think the role-based security or dynamic configurability can best be achieved with Mbeans? I haven't looked much into JAAS, but it appears to be too tightly coupled with EJB concepts to give the developer absolute freedom when defining privilege mappings, and may not support the ASP model. If these assumptions are right, then this may be worth turning into an Mbean. I would be willing to make it to open-source.
Thanks for your help,
Erik
erik@openstandards.net