Steven Owens wrote:
>
>I'm working on a project where we seem to be developing an extremely
>XML-oriented enterprise application. The application is very
>document-centric, and the various requirements for customizability are
>pushing us towards heavy use of XML DOMs and XSLT transformations, not
>just as an external communications format, but as tools for defining
>the guts of the system. We have XML-based data (as a large XML DOM in
>memory, not as a big XML text file), XML-based permissions, XML-based
>workflow customization, etc.
>
>I'm not unhappy with this direction - it seems to make a lot of sense
>and it seems to fit our requirements. However, it's throwing me a bit
>off; I'm having trouble fitting it into the normal J2EE approach. The
>further we go, the more I begin to suspect EJBs aren't appropriate at
>all.
>
>One thought we've had is to use EJBs to manage caching the large DOM
>structure, but I'm not entirely sure how well they'll be suited to
>this.
>
>Has anybody done something in this vein, or does anybody know of any
>research, papers, white papers, good books, products, etc, that would
>apply to this?
I can't refer you to anything published, but I've had experience of this sort of
architecture before though in a non-EJB/J2EE context. What you are doing is
using XML as a kind of 4GL or scripting language, making development of the
actual application a matter of creating a "document" defining the business
rules. My experience is with an old 4GL.
On the positive side, it's a good idea for certains sorts of applications and
from what you've told us I'm pretty sure yours is one.
On the negative side though the approach presents several additional challenges
to be overcome compared to following a J2EE model more closely.
1. How do you debug an application written in this 4GL. (4GL developers often
think that code written in their 4GL will be so simple and obvious that
debugging will be unnecessary. They are rarely right!) So you will probably find
yourselves building some debug capabilities into your 4GL interpreter to put
back what your 4GL programmer loses by not being able to use an off-the-shelf
debugger.
2. If your application genuinely is a server application you will need a method
dispatcher. You could write your own, but the core of EJB is a case-hardened
method dispatcher addressing remote access, security, scaleability,
manageability and trannsactions. I recommend that you use EJB even if you don't
need all these features. You could program to the servlet environment, but this
could be quite tricky.
3. Unfortunately, even if you use EJB you will probably find the need to
duplicate some of its features. This applies to security (you may need specific
security on your business rules) and management (monitoring and alerts).
4. You will need to develop solution to loading and caching the 4GL code itself
since the JVM loader will not do it for you. Depending on how dynamic your
business rules are you may need to have mechanisms to refresh the cache
periodically or on demand. You may have to synchronise rule changes with running
instances or support concurrent execution of multiple versions of the rules. If
the application is spread over multiple JVMs on multiple systems you will need a
copy of the 4GL code in every JVM. I suggest you load it from a database into
non-final static of a helper class which has no instance methods thereby making
it behave as nearly as possible to read-only code. Even simpler, if the rules
change rarely you could simply generate the rule-holding java class:
public class Rules
{
public static final String RULES=" <?xml version=\"1.0\" ?> <rules>....";
....
}
Hope this helps.
cheers... Ian
Ian McCallion
Alexis Systems Limited
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
