Re: Design for single database, multiple applications
Re: Design for single database, multiple applications
- Subject: Re: Design for single database, multiple applications
- From: Chuck Hill <email@hidden>
- Date: Mon, 9 Aug 2010 20:47:37 -0700
Hi Mark,
On Aug 9, 2010, at 2:02 PM, Mark Wardle wrote:
>
> The time has come for me to sketch out the next version of my patient
> record system.
>
> I have several frameworks and one application. The latter is a bit
> gnarly (to use a technical term) and unwieldy and I think it would
> make sense logically (and from a user interface point of view) to have
> separate applications for different specific functionality.
Why not partition the UI functionality into frameworks and then combine them in the (now probably mostly empty) application?
> Is there a WebObjects-way of passing sessions between applications or
> is it simply a case if using a manually created cookie with an
> encrypted username and somehow safely providing a time-limited
> credential?
I once broke up an application into two for the same reason you are considering. I have regretted it ever since. It uses more memory on the server (more app instances) and you have the problem of different sessions on different applications.
If you really want single sign on, look at something like Cosign, or WebAuth or Shibboleth.
> I have enabled different sub-applications as part of the single main
> app dynamically based on runtime data - and I'm definitely undecided
> whether breaking it up is the right way forward. On the other hand,
> factoring out the common stuff and creating a robust core framework
> has a certain aesthetic quality to it.
Based on your description, I'd refactor the common stuff into frameworks and keep the single point of access (application) for the users.
Chuck
>
> All opinions gratefully received.
>
> Many thanks,
>
> Mark
>
>
> --
> Dr. Mark Wardle
> Specialist registrar, Neurology
> (Sent from my mobile)
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/products/practical_webobjects
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden