Building ColdFusion services with ColdSpring and Reactor, part 5

Submitted by Falken on
If you're already familiar with AOP, or you've just finished the interlude reading, you will understand the way we can use ColdSpring to create a 'remote proxy' (or 'remote facade') that can act as the Service layer for a Manager. You've also maybe thought that this also allows cross-cutting concerns of the Service layer such as object type conversion and security to be cleanly addressed in a reusable way. These remote proxies use ColdSpring's RemoteFactoryBean class.

But before we can see how to use some common types of Advice to solve the problems we used to address in a per-Manager hand written Service CFC, I want to show you a handy way to bootstrap all your remote proxies as well as ColdSpring itself.
This will have the benefit that both remote Flex applications and local CFML applications can talk to the same service tier over the same API by connecting to what look like plain old CFCs. Also, as you have probably noticed, we don't need to write the Service layer ourselves any more - ColdSpring remote enables our CFCs automagically !

In 'tradditional' applications, there is always some aspect of application start up, defining constants in the application scope, creating the ColdSpring beanFactory and so on.
In an application based on AOP, 'all' that needs to be done is for each remote proxy CFC to be generated so it can be CreateObject'ed or used as a Flex RemoteObject end point.
You might rightly baulk at the idea of having to write a line of code for each Service, duplicating stuff from your bean config file, and then also having to remember to keep this startup code in sync with changes to your ColdSpring beans.
Enter com.falkensweb.aop.FacadeStarter !

The FacadeStarter is a simple CFC with one method, init(), that optionally takes the path to your bean config. file if it's not '/beans.xml'.
You make sure to call this method during application startup (say in the Flex applications HTML wrapper), or before any Service is used.
FacadeStarter will setup the BeanFactory (which you no longer need to worry about as a user of the service) and make sure all the RemoteProxies have been created.

FacadeStarter works by using the public ColdSpring API to find all the beans that are based on the RemoteProxy class, and calls getBean() for their name.
This creates a concrete CFC file on disk as defined by bean's config, Advice using and all.

FacadeStarter will not replace an existing beanFactory, so I commonly have a CFML file that removes everything in the application scope and calls the FacadeStarter again.
This is then run when ever a bean changes - recall beans in the BeanFactory are singleton's and cached for the life time of the factory. This applies to the underlying target bean of a RemoteProxy too.

The current version lacks several important 'weaponisation' features, such a locking around the creation to prevent half done BeanFactories being used by the application if multiple request arrive close together.
These will be added over time, or if you do so drop me a line with the code.

Previous Part | Interlude | Next Part

Sections

Submitted by Christopher Bradford (not verified) on Fri, 04/18/2008 - 00:42

Permalink

ColdSpring in SVN supports lazy-init="false" on any bean. You can just specify this on the RemoteProxy definitions in the coldspring XML config file, and they will be created as soon as the beanFactory is instantiated. http://cdscott.blogspot.com/2007/11/long-long-awaited-coldspring-updates.html

 "created as soon as the beanFactory is instantiated"
Ahh, that's cool, if your running the latest SVN version of ColdSpring you can skip this startup step.
I suspect most people are more comfortable using the stable release code though.

Even with the latest ColdSpring, FacadeStarter still makes two lines of code one,  and abstracts away from the use of a particular AOP/DI framework.

Have a common point in your code where you touch external code like ColdSpring also helps if there are several sub-apps, any of which might be hit first after the server starts, and so need to create the bean factory.

Tom

Submitted by Christopher Bradford (not verified) on Fri, 04/18/2008 - 00:44

Permalink

See also: http://www.alagad.com/go/blog-entry/im-gateways-and-coldspring-odd-behavior-and-a-workaround