Re: [Babeldoc-devel] A few more questions

[<ek...@ba...>]

<<
Do you plan to release this project as open source? If you have such
plans
can you describe more what exactly are you planning to implement. Maybe
we
(company that I work for) will need something similar  so I could help
you
with these.
How do you plan to "put" documents into pipeline? By some web UI or
using
scanners or something else?
>>

The project is for use internally within my company (The Bank of NY).
Rather than rebuilding "the wheel" from scratch, I discovered that
Babeldoc's core engine did most of what I needed.  I was planning to
"build around" Babeldoc for the additional functionality that we needed
while having as small an impact on "code modification" within Babeldoc
as possible.  Of course, if I find a good reason to improve/extend
Babeldoc, I shall (according to Babeldoc standards) and will offer it to
the open source community (i.e. you guys) for inclusion if you choose to
-- I've been starting to think about a Pipeline Stage for talking to
EJBs using Rhino or Jython, for example, since this is one of my needs.

The current plan is for us to feed the pipeline directly using
com.babeldoc.call.command.PipelineFeeder.process() method from a
Message-Driven Bean that runs on Weblogic Server v6.1 and is triggered
by a JMS message that is dropped on a Weblogic JMS Queue.  We will also
have an adminstrative user interface that will permit someone to create
or update a pipeline and its stages (including its config key/value
pairs) interactively where it will be persisted to our Sybase 12.5
database.  The system will run in a clustered Weblogic environment on a
Solaris platform.

The purpose of the project is to accept "Alert Messages" in XML format,
derive additional information from "Resource systems" (which can be
implemented as Stored Procedures, EJBs, Web Services, etc.), combine the
XML input message with the derived additional information (most likely
using XSLT), and send the resultant information to one or more Recipient
Systems (which can be implemented as EJBs, Web Services, JMS Queues,
etc).  The problem we have is that during development of this system, we
cannot code in Java for any of the following:
1. The Source systems that will send us XML
2. The Resource systems that will provide us with additional information
3. The Recipient systems that will receive the finished information

This is because we will be getting requests constantly within the
company for new "Alert Messages" and we cannot be deploying new code to
our environment for every request (due to rigourous testing, data center
standards, etc).  Therefore, the only way for us to "deploy code" is via
interpretive-language code that is placed in the database (i.e. XSLT
scripts, JavaScripts, Jython Scripts).  It must be in the database
because our clustered environment means that files written to the "file
system" on one box will not be available to instances of our servers on
other boxes.  We cannot share mounted disk devices between systems.
Additionally, the operations folks frown upon us writing to the file
system a lot, as does the EJB standard.

That is the unabridged description ... I bet you're sorry you asked,
right???

Erik