Baz,
Interesting discussion. However, it's not clear to me why you're not just
using the User component, as opposed to creating a facade for it.
Could you touch more on what the problem is?
Sam
On Jan 18, 2008 7:42 PM, Baz <[EMAIL PROTECTED]> wrote:
> We all know about remote facades - clean and simple components that expose
> some or all of your local functionality remotely as webservices. One
> interesting characteristic of remote facades, is that since they are invoked
> remotely, no createObject statements are run, and therefore there is no
> ability to inject or manage their dependencies (through Coldspring, for
> example). So by their nature, they are dependency-free.
>
> Now to switch gears for a second, I have a server that hosts a whole bunch
> of applications. One of those applications manages users, groups and
> authentication for the rest, so all other applications have to interact with
> it. Our development team created and maintains these apps, so whomever has
> access to the server can be trusted with any application. So the question
> is, how do you share this central application's functionality with the rest.
> There are several options:
>
>
> - *Webservices*: Build a remote facade that all other applications
> can interact with.
> - Con: Need to build a complex security and authentication
> scheme so that the rogue .NET developers down the hall can't invoke your
> deleteUserDatabase() webservice
> - Con: Performance hit with the unnecessary soap and wddx
> translation layer
>
>
> - *Custom Coldspring: *Not every application needs all of the
> central functionality, so why not configure the services that are needed in
> the local coldspring file.
> - Con: Duplication. What happens if the UserService now
> requires a new dependency. You have to change that in multiple places.
> - Con: Documenting which applications are using what foreign
> components is awkward and annoying.
>
>
> - *Re-Instantiate Coldspring Factory:* Each of the apps can
> instantiate their own copy of your central coldspring factory.
> - Con: Performance! Depending how big your central app is,
> having duplicates all over the places consumes ram and is just ugly.
> - Con: Synchronization. What if some of your singletons store
> and refresh globally-used data on a timed basis. How do you keep all the
> copies in synch? There are ways, but thats more of the ugly.
>
>
> - *Server Scope: *Instantiate the central coldspring factory in the
> server scope so that any application on the machine can reference it.
> - Con: Every application has to make sure that the server
> scoped factory is properly instantiated
>
> My favorite of those options is using the server scope. But there's
> something inherently freaky about it. It just sits there in the desolate,
> murky depths of memory watching you, tempting you to venture in - just to
> throw some never-before-seen race condition into your wheels. I JUST DON'T
> KNOW!
>
> But what about creating a "Local Facade" instead? A simple,
> dependency-free, public-facing component that can be instantiated by all the
> other apps using nothing more than createObject('Component', '
> CentralApp.UserFacade'). All the methods would be access=public, rather
> than remote, so there are no security risks from those .NET bastards. We rid
> ourselves of the in-efficient soap/wddx translation layer. We don't need to
> duplicate any coldspring code. There is very little wasted resources. And no
> need to use the scaaaaary server scope.
>
> Thoughts?
>
> Baz
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"CFCDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cfcdev?hl=en
-~----------~----~----~----~------~----~------~--~---
