Hi,
SUMMARY
I would like to contribute to Turbine to make it a more effective
tool for developing ASP-architected applications.
I would like feedback on the following four suggestions before
I start submitting patches.
At the moment, they mainly affect the database, laying the
groundwork. (Java code would follow in the future.)
I have experimented with this, and I could make the modifications
(with suitable defaulting) so that it would not break any existing
code, but it would enable new ASP-oriented future development.
This would enable a site hosting (for example) Scarab to host
it for multiple customers in the same database.
1. Inclusion of an "org" table to represent all the
organizations being hosted
2. Inclusion of "org_id" in many of the tables to
distinguish the data belonging to different organizations
3. Inclusion of more tables (see below) to support
more of the ASP infrastructure
4. Inclusion of a unique ID as the primary key in every table
(even the associative tables). (not necessarily for ASP but
it supports more uniform data access code)
Thanks. (Background detail follows.)
Stephen
__________________________
DETAILED BACKGROUND INFO
You are all aware of the trends toward web-enabled software
being hosted by Application Service Providers (ASP's) and
rented to users on a subscription basis. (We are a startup
ASP.)
One of the biggest obstacles to providing ASP-hosted software
is that it is not architected for true "one-to-many" hosting,
where data from multiple customers are hosted in the same
database. The database needs to support the identification
of each row of data as belonging to a particular organization
and the security mechanisms of the application need to enforce
this separation of data very robustly. Otherwise, two
competitors in the same industry would never consent to having
their application hosted by the same ASP.
Most people recognize the trend toward ASP's as a huge
change in the software industry. The non-ASP-friendly
architecture of most current applications means that there
will be a whole new set of application winners and losers
in the new ASP-driven era.
I would like to help Turbine support the new generation
of ASP-architected applications.
The following is a design document I wrote a while ago which
explains these ideas in more detail. Please note that this design
was done independent of Turbine. The table names correspond
to Turbine tables in the following way.
usr => Visitor
role_usr_grant => VisitorRole
org_role => UserRole
perm_role_grant => RolePermission
perm => Permission
org_usr_memb <new>
org <new>
org_app_access <new>
app <new>
app_partnership <new>
app_partner <new>
===========================
ENTITY-RELATIONSHIP DIAGRAM
===========================
=========== ============= =========
usr app_partner app
=========== ============= =========
| | | o | | | |
| | +--------+ +---+ | +---+ | |
| | | | | | | |
| | M o M M | |
| | ============ =============== | |
| | org app_partnership | |
| | ============ =============== | |
| | | | | | | | |
| +----+ +--+ | | | +---------+ +----+ |
| | | | | +-----+ | | |
| M M | M | M M M
| ============ | ======== | ============== ========
| org_usr_memb | org_role | org_app_access perm
| ============ | ======== | ============== ========
| | | | | |
+------+ +-----+ | | | |
| | +---+ | | +--------------+
| | | | | |
M M M M M M
================ =================
role_usr_grant perm_role_grant
================ =================
========================================
Definitions, Uniqueness, and Cardinality
========================================
Definitions for all the tables are given below, and statements
are made between the relationships to other tables.
In addition to an ID used for a primary key,
certain alternate keys are also guaranteed unique.
usr - An independent user of the ASP-hosted suite of application
services. Anyone may become a user, and he immediately has
access to all public applications. He may be granted a
membership
in one or more organizations. He then gains access
to all the applications of the organization with permissions
on those applications in keeping with the roles he has been
granted in the organization.
* a user sponsors zero-or-more organizations
* a user is a member of zero-or-more organizations
* a user is granted a role in zero-or-more organizations
o uniquely identified by (usr_name)
org - An organization is sponsored by a particular user and is a
billable entity. The sponsor is automatically an administrator
of the organization and grants memberships to users, defines
roles, grants available permissions in applications to those
roles, and grants roles to users.
* an organization is sponsored by exactly-one user
* an organization has zero-or-more member users
* an organization has zero-or-more roles within it
* an organization grants zero-or-more permissions to each role
* an organization grants zero-or-more roles to each member user
o uniquely identified by (org_auth_cd)
o uniquely identified by (org_name)
app - An application is a piece of software implementing business
functions which users will want to use.
* an application requires zero-or-more permissions to
operate it
* an application is granted access to zero-or-more
organizations
* an application is hosted in conjunction with zero-or-more
partners
o uniquely identified by (app_cd)
app_partner - An application partner is a party who will benefit when users
use the application. It is the recipient of revenue sharing,
usage information, or whatever is specified in the partnership.
Information about an application partner includes the details
on how to transfer funds or information.
* an application partner may be an organization
* an application partner is a partner on zero-or-more
applications
o uniquely identified by (app_partner_cd)
app_partnership - An application partnership is an agreement between the
application service provider (ASP) and the application partner
that describes the details of the relationship (i.e. revenue
and information sharing).
* an application partnership is valid for a single partner
* an application partnership is valid for a single application
o uniquely identified by (app_id, app_partner_id)
perm - A permission is a feature of an application which can be
granted
or restricted from use to a role. This allows different users
to have access to different permissions within an application
based on the role(s) they play in an organization.
* a permission is a feature of a single application
* a permission is granted to zero-or-more roles in various orgs
o uniquely identified by (perm_cd)
o uniquely identified by (perm_name)
org_role - A role is defined in an organization in order to selectively
assign permissions to users.
o uniquely identified by (role_name, org_id)
org_app_access - Each row describes that access to an application has been
granted to the organization by the ASP or an Application
partner.
o uniquely identified by (org_id, app_id)
org_usr_memb - Each row describes a membership that a user has in
an organization, granted by an administrator of the
organization.
o uniquely identified by (usr_id, org_id)
o uniquely identified by (org_id, usr_id)
o uniquely identified by (usr_name, org_auth_cd)
perm_role_grant - Each row describes that a particular permission has been
granted to a role in an organization.
o uniquely identified by (role_id, perm_id)
o uniquely identified by (org_id, perm_id, role_id)
role_usr_grant - Each row describes that a role in an organization has been
granted to a user.
o uniquely identified by (usr_id, role_id)
o uniquely identified by (org_id, role_id, usr_id)
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
