Tenant Management Services Home

Owned by Patrick Schmitz (Unlicensed)
Last updated: Jun 17, 2009 by Sanjay Dalal (Unlicensed)
2 min read

TBD - Just a placeholder now. Here are some notes from a a back-channel discussion arising out of the configuration discussion on Tuesday (16th June 09) in Toronto.

sanjay dalal: perhaps we could treat configuration of dan's app layer as tenant registration/customizaton service?
Patrick Schmitz: You mean for persistence of the info?
sanjay dalal: not only that. we can think of tenant-specific configuration of the app layer as a service which could be eventually exposed as tenant-initialization service. this service however would not reside with the service layer because this service has to create tenant specific configurations for all the layers. so, logically it should reside at the app layer. this service could create a template based on a tenant administrator's input and some tool can then translate it into various configurations for UI, app and service (schemas, policies, etc.) layers.
Patrick Schmitz: Right - nice.
Patrick Schmitz: Then we also think about what it means to do customization.
Patrick Schmitz: E.g., I would really like to have things like adding fields be done via code, not just restart and read config. I think adding and removing fields can be done better if we actually know what we're doing, and can do smarter things in the DB (actual SQL commands). Eventually, we may even allow conversions (change from int to float), etc.
sanjay dalal: yah, agree. a service like such can do all consistency checks and then invoke similar service in the service layer which can take care of doing the right thing for given input configuration.
Patrick Schmitz: Especially for a running system with data, doing this well will be important.
sanjay dalal: indeed. however, I thought we agreed to restart the server after a tenant registration initially.
Patrick Schmitz: Initially yes. I am talking longer term ideal models.