Hey Sam,
The problem, as I see it, is that the User component relies on a lot of
composition and dependencies. So I could duplicate those in each of my
Coldspring files, but now I am maintaining multiple definitions for one
service. Perhaps thats the standard operating procedure?
Baz
On Jan 19, 2008 4:50 PM, Sam Larbi <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
