Hey that's a good one! I'm surprised I over-looked it.... thanks Brian.
On Jan 19, 2008 5:41 PM, Brian Kotek <[EMAIL PROTECTED]> wrote:
> You could just create one XML file to define these dependencies and import
> them into any other ColdSpring XML files that need to use it.
>
>
> On Jan 19, 2008 8:34 PM, Baz < [EMAIL PROTECTED]> wrote:
>
> > 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
-~----------~----~----~----~------~----~------~--~---
