Is it just me or does there seem to be even more ways to design solutions using COP ;)
My first container will basically poll a group of spool directories and when a file is move into one of the watched directories, it will ask a component to convert the file to a different format in another spool and moved the original to a third spool (archive).
A bit more information, I will probably use JNDI for the spools. The polling interval/controller could be cornerstone scheduler. The converter might work on streams or files and I might introduce caching later.
My initial design has these three main components: Scheduler - DirContextMonitor - FormatConverter
Scheduler just invokes DirContextMonitor::trigger() at appropriate times.
DirContextMonitor does a single poll of the spool per trigger() and if it locates an entry invokes FormatConverter::convert(), on success it moves the entry to the archive directory.
FormatConverter reads the entry, converts it and writes the converted entry to a destination.
I realise there are few extra components related to scheduling and pool management.
Basically, does this look sensible? Deciding where to make classes, components and blocks at the moment is my biggest mental hurdle.
thanks, Jon
Sounds very similar to a couple of blocks I have in my solutions. I have a block called a DirectoryWatchdog, which uses the Cornerstone scheduler to trigger an action to peek at one or more configured *watch* directories looking for new, modified, or deleted file. The watchdog then uses another service to *publish* a new file discovery. I can provide many implementations of this *publish* service. One simple implementation may simple do a service manager lookup of another component and pass the new file along. However, a more complex implementation may drop a JMS message on a queue containing the new file discovery. Breaking your solution up into fine-grained services, implementations, and blocks like this provide you great flexibility. For instance, you may wish to implement a *simple* solution in the early prototyping of your solution, just to get a skeleton app together. Then, by going back later and proving an alternate more complex implementation of your services, you flesh out the full requirements of your application without having to re-code the rest. Just a jar resource and meta-data change in some block.xml to use a different implementation. That's the power of COP.
Looks to me your are right on track. As with anything, practice improves your architecture. What you are designing today will look like crap a year from now. ;) Trust me. Just keep COP'ing.
I like your idea about hooking JNDI into your directory watch. We might could collaborate and produce a block that could be beneficial and re-usable to others. Another major reason to use this type of development platform.
Timothy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
