Aaron
On 8/1/05, Adam Churvis <[EMAIL PROTECTED]> wrote:
* right now, there are 3 applications combined into one: Public site, Owners area (login req'd), and Admin intranet. In my opinion, since these have completely different footprints (usage, number and types of queries, and types of users), we should split them out at least into separate apps, if not separate instances of CF. This would allow us to "tune" each one accordingly; if one goes "down" or is bogged down by long-running reports, it won't affect the other; and we can release a new version of one area (Admin for example) without releasing a new version of the whole app. Let's just say, based on our infrastructure, business requirements, and development resources, this is probably our best option moving forward...
* But if we had a common library (centralized repository) of code that almost never
changes, then we could leverage it from multiple applications. Without going into too
much detail, I guess you just have to trust me on this one... ;-)
Yes, I like that tool!
* Sorry, my statement apparently didn't make sense *sheepish grin*. What I'm getting at is:
how would you go about exposing this central repository of CFCs from outside a single application AND
outside a single instance of CF, other than with Web Services. So, with our architecture, we'd have 4
instances of CF:
1) Public
2) Owners
3) Admin
4) CFCs
The Server scope is tied to an instance of CF, so if there's separate instances, then you couldn't put
the CFCs in the Server scope, right? The only other way I can think of is exposing them as WSs.
Do you know of another way?
* Actually, yes, it would be the exact same data (once we merge DBs) and DB.
And the idea is to get all our sites/companies on a single code base: for scalability,
maintainability, and ease of development, etc.
* Yes, exactly. This would be kind of a option "enterprise" feature that larger scale infrastructures, like our's, could use.
* Thanks. I always learn at least a couple of things every time I chat with you, Adam. Peace.
Respectfully,
Adam Phillip Churvis
Member of Team Macromedia
Certified Advanced ColdFusion MX 7 Developer
http://www.ProductivityEnhancement.com
Download Plum and other cool development tools,
and get advanced intensive Master-level training:
* C# & ASP.NET for ColdFusion Developers
* ColdFusion MX Master Class
* Advanced Development with CFMX and SQL Server 2000
----- Original Message -----
From: "Aaron Longnion" <[EMAIL PROTECTED]>
To: < [email protected]>
Sent: Saturday, July 30, 2005 11:08 AM
Subject: [plum] Architecture question
Hi all -
I have a question about the flexibility of PLUM in regards to software
architecture.
We're working on a potential architecture for our CF apps moving forward
that is highly scalable and flexible, with as little redundant code as
possible.
We're thinking of something like this:
1. a centralized repository of CFCs (which are not dependent on any
scopes, especially Application and Session, that are tied to the
CFAPPLICATION)
This brings up my first question: what compelling reason do you have for
separating your code based into multiple applications?
* right now, there are 3 applications combined into one: Public site, Owners area (login req'd), and Admin intranet. In my opinion, since these have completely different footprints (usage, number and types of queries, and types of users), we should split them out at least into separate apps, if not separate instances of CF. This would allow us to "tune" each one accordingly; if one goes "down" or is bogged down by long-running reports, it won't affect the other; and we can release a new version of one area (Admin for example) without releasing a new version of the whole app. Let's just say, based on our infrastructure, business requirements, and development resources, this is probably our best option moving forward...
2. multiple applications/sites that use the same set of CFCs from the
centralized repository
Plum purposefully gives each application its own framework so that one
application doesn't "wag the dog" on any other application. This enables
one application to have its framework modified without affecting the others.
Again it comes down to the central question of why you would want to
separate your code base into multiple application spaces.
* But if we had a common library (centralized repository) of code that almost never
changes, then we could leverage it from multiple applications. Without going into too
much detail, I guess you just have to trust me on this one... ;-)
3. the majority of the CFCs will be used for data abstraction, mostly
business logic and calls to stored procedures (SQL Server 2000)
Cool. Try out Plum's tools for generating stored procedures, the component
methods that call them, and the invocations for each method.
Yes, I like that tool!
4. we want to be able to create multiple instances of CF (MX 7), and
yet call the central repository of CFCs directly (without exposing them
as
Web Services, although now that I think of it this is probably a
limitation
of CF and unrelated to PLUM?)
This sounds more like a storage issue, where you might pull from a shared
NAS or SAN device.
* Sorry, my statement apparently didn't make sense *sheepish grin*. What I'm getting at is:
how would you go about exposing this central repository of CFCs from outside a single application AND
outside a single instance of CF, other than with Web Services. So, with our architecture, we'd have 4
instances of CF:
1) Public
2) Owners
3) Admin
4) CFCs
The Server scope is tied to an instance of CF, so if there's separate instances, then you couldn't put
the CFCs in the Server scope, right? The only other way I can think of is exposing them as WSs.
Do you know of another way?
5. the reason we like the architecture described above is because we
have multiple sites (and we're adding additional sites rapidly), all
which
basically do the same thing, and so rather than dealing with multiple
versions and instances of the same (or nearly the same) code base for
each
site, it would be nice if at least the business logic was separated out
from
the presentation layer. This way, each site could simply be given it's
own
"skin" (using HTML/CSS, a plain text site, a Flash site, etc) , and
simply
make calls to the CFC library to deal with data.
Do they do basically the same thing with the exact same data in the same
database? If not, then each should have its own set of CFCs that deal with
its own data. I know having one central "repository" of CFCs and such
sounds convenient, but to me it's not so good because you inevitably get
stuck when you want one app to break out of the mold and go in a slightly
different direction.
* Actually, yes, it would be the exact same data (once we merge DBs) and DB.
And the idea is to get all our sites/companies on a single code base: for scalability,
maintainability, and ease of development, etc.
6. the main problem I see with the out-of-the-box implementation of
PLUM is that CFCs are tied to each PLUM project, though the Application
scope. I'd like to move the CFCs outside of the framework, so that each
new
PLUM project could access the CFC library. Then, we'd be able to rapidly
deploy each new "skinned" sites to the CFC library rapidly, without
needing
a redundant set of CFCs in each project.
Are you talking about instantiating the CFCs in the Server scope instead,
and accessing them that way? Hmmmm. Sounds like something we should look
at for the next version (at least making it easy for developers to do this
themselves). There would of course be a real headache trying to do this in
a shared server environment, but I suspect that most developers wanting to
do this would be on their own server boxes anyway.
* Yes, exactly. This would be kind of a option "enterprise" feature that larger scale infrastructures, like our's, could use.
7. For # 6 above, I realize this would require some custom
manipulation of a PLUM project, and once the CFCs are moved outside of
the
project, then I probably wouldn't be able to manage PLUM from the IDE any
longer. So, am I missing something? And would you recommend using PLUM
(at
least for the initial build of the code-base) for our planned software
architecture?
There comes a time in every Plum project when it becomes divorced from the
Plum IDE and coding continues by hand (preferrably using the custom tag
editors for ease of use), so no, you're not missing a thing, Aaron.
This is some good food for thought, and David and I will add it to our
discussion for "what's next."
* Thanks. I always learn at least a couple of things every time I chat with you, Adam. Peace.
--
Aaron Longnion
[EMAIL PROTECTED]
512-470-1211
--
Aaron Longnion
[EMAIL PROTECTED]
512-470-1211
**********************************************************************
You can subscribe to and unsubscribe from lists, and you can change
your subscriptions between normal and digest modes here:
http://www.productivityenhancement.com/support/DiscussionListsForm.cfm
**********************************************************************
--
Aaron Longnion
[EMAIL PROTECTED]
512-470-1211
