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
-~----------~----~----~----~------~----~------~--~---
