Hi, some comments off the top of my head... a lot depends on other factors, like team skills budget and policy...
> So the question is, what must be taken into consideration thinking this > far ahead? Things like sessions -- we can't use the standard session > scope because this won't work across load-balanced sites (unless each > initial request gets allocated to a certain box and all future requests > go to the same box, but we don't want this constraint). > Are there any suggestions for using user sessions across (possibly) > load-shared boxes? Yes we could leave it up to the load-balancer > (sticky sessions etc) but I'd rather have the control myself and make > it part of the application functionality. If you use JSESSIONS and CFMX for JRUN you can share your in memory sessions across a cluster. Other j2ee apps do this also, tomcat and jboss both have this availability. The other option is obviously OBDC client vars. In my experience the problem is basically that you can't put anything but simple values into those, and if you use, say wddx to serialize complex var into a client var, the overhead, is an issue. > *** Database > We have generally always used MySQL as the database for sites we develop > but considering the possible "enterprise" scale nature of this > application we're starting to look elsewhere. In my opinion MySQL isn't > quite there in that respect -- lack of stored procs, relationships etc. > I have just started looking at PostgreSQL which appears to be a GPL'd > version of Oracle. Has anyone got any thoughts on this? > >The system will be accessed in a number of different ways -- simple > "template" based sites, more complex bespoke sites, flash (remoting) > sites etc. Due to this we are planning on building a set of core CFCs > to hold the business logic; these can then be accessed via different > mechanisms for each site "type", e.g. a set of facade CFCs for the > remoting side etc. It might worth your while investing the time to do your business layer in EJBs, and wrap them in CFCs. In addition to giving options in the future (like moving to J2EE completely ) it also gives you other options like transaction management, method security at runtime, and the other enterprise technoligies that are lacking in MySQL etc... In theory (*S*) it also allows you to change to another DB solution later. Build Entitiy beans isn't as difficult as it sounds. Especially if its a new app. The problem with using a reporting tool via stored procs, is that it can circumvent any business logic in your business logic tier. Of course, as its read only as such this may not be and issue. > There may also be the need to enable access to the application via > webservices (again, CFCs come in useful) but of course these must be > properly authentised -- only "proper" calls with the appropriate > authentication tokens should be processed. Anyone got ideas on how this > could/should be handled? LDAP, or another JAAS solution will give you the most freedom in this respect. Try not to tie your security system tightly to your app, but abstract it and use roles etc. JRUN allows you to build a custom JAAS modules, Jboss can whatever you want in this area too/// Justin -- ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For human help, e-mail: [EMAIL PROTECTED]
