Loading ...
Sorry, an error occurred while loading the content.

Nearly finished

Expand Messages
  • Adam Flinton
    Dear All, Nearly finished. In & tested on J2EE: Weblogic 5.1, 6.0 & HP BlueStone JMS: SonicMQ, SwiftMQ, MQSeries & Weblogic s JMS. Some points for those
    Message 1 of 1 , May 1, 2001
    • 0 Attachment
      Dear All,

      Nearly finished.

      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
      etc.etc.etc.

      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
      XMLDBMS.

      & 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.

      Ah welllllll......

      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
      work) tomorrow.

      & 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.


      Adam
    Your message has been successfully submitted and would be delivered to recipients shortly.