- Dear All,
In & tested on
J2EE: Weblogic 5.1, 6.0 & HP BlueStone
JMS: SonicMQ, SwiftMQ, MQSeries & Weblogic's JMS.
Some points for those interested
1) If doing JMS work I would recomend SwiftMQ. It's free & it's excellant.
It is better than the JMS in Weblogic. If you're looking for a good JMS
implementation all I can say is that it's very good in just about everyway.
Very stds compliant, lightweight enough for my Laptop, fast, easy to set up
2) If doing J2EE work I would recomend HP BlueStone. Again it's free & it's
much better than Weblogic 5.1. It's about on a par with WebLogic 6.0 but I
prefer it coz I now know it better. It also comes with an excellant
deployment tool which you could use just on it's own (includes an XML ed,
DTD ed, Java Ed & an SQL Ed (all Java)). Definitely worth the Download. It's
EJB2.0 capable (e.g. Message Driven Beans etc). It's proof positive of the
virtues of competition. Go HP.
OK on with the real stuff........
Lot's of changes. None to the GUI etc. I am reviewing this next......
In essence you have a set of libs which can be used in a "pipeline" style of
design. i.e the JMS stuff can be tested independantly of the XSLT stuff &
that can be tested independantly of the MapFile stuff.
I might put in an example app but it's really so easy..........
In essence incoming message comes in as a string. You pass that string to
the XSLT libs & get back a transformed string which you then pipe into
& for outgoing messages.....it's just the reverse. As such the best way is
to simply chain the bit's together via simple class....& then call that from
a message Driven bean's "on message" method.
So the most obvious change is simply that the transfer class & various
methods on the Transfer Engine either accept a string as an arg (i.e. the
incoming XML or return a string (e.g. retrieveDocument). These are almost
identical to the existing classes. You can tell which are which as the
String methods are (a) Public & (b) are ended with _s.
Ditto a couple of parserUtils methods (implemented only for Xerces as it's
the only parser I am using).
2 Things left to do.....
1) Table vs Table1......not obvious but when retrieving by Key the first key
is Key1 whereas with Tables it is table. I think this is an over
sight....RON????? It seems obvious to go for commonality ie. Key1 & Table1
makes sense as does Key & Table but (to me) Table & Key1 is confusing when
using 1 Table & 1 Key.
2) F**king Xalan changed while I was writing it such that they have
introduced the concept to "templates" instead of StyleSheetRoot. It should
be pointed out....that the only thing which uses a Template is.....a
StyleSheetRoot....Also the whole thing has been "JAXP'ed". As such
(unfortunately) we will have to have an Interface so as to support the old
Xalan & the new as we do different parsers.
OK now a request. Once I release the code will someone other than me do a
JAXP version of the DOMUtils (e.g ParserUtils). I can see the way the wind
is blowing & soon people will be asking why we don't have it. Also Xalan 2
is JAXP based.
So......Ron could we decide re Table vs Table1?
I will do the Xalan 2 stuff (no big deal just not something I thought I had
to do (I tested with Xalan 2 & it's "compatability" classes simply don't
& that's about it. XD is now both a single user "one shot weapon" & a ready
to go serverside App with an Object cache,JDBC1 & 2, XSLT & JMS, URL file
loading etc (MAP files are now called .mp to get round the common Webserver
useage of .map)
Oh & I've fixed the Schema / table name handling such that it works with all
DB'es I have tried (Oracle & DB2......)
Oh Oh & a JSP....You what I hear you cry.....surely this is some sort of
Java web pages thingy........Yup. One of them. Why?
OK I'll take this slowly. You've got a server running. It's using XD within
a J2EE environment. XD now comes with an ObjectCache into which are put
Properties objects, Compiled XSLT Stylesheets & MapObjects (not the result
based variety obviously) both for speed reasons & for reasons of "load it
once". Now you want to change a Stylesheet or even load a new interface (in
EAI terms not Java). You don't want to stop the server .....so along comes
this JSP which allows you to look into the Cache & dump either specific
files by ticking a tick box or dump the lot......
Oh & it has a nice side effect which is that (unless they are loaded via
"localhost" & you aren't on that machine) I have been using the URL of the
file as it's "handle" which means that I just wrap the key name with an HREF
et voila! instant browser based viewing of your XSLT,Map & Properties files
(IE realises that map files are XML which is nice).
Phew.......OK ON with the GUI & ease of use stuff & over to Ron for the
"under the covers" stuff.