Re: [ebxmlms-develop] Design questions

[Patrick Y. <kc...@ce...>]

The original design philosophy of Hermes is "simple". That's why we use only
servlet container, but not J2EE server. In the very beginning, we even tried
to get rid of database! So, you can see that, only minimal data, i.e. meta
data, is stored in DB. Another concern is JDBC. We are in favour of
supporting multiple DB servers via JDBC. That's why our SQLs are all SQL-92
compliant, and it is relatively hard to get the message stored in DB.
Transaction is a big issue, and to make Hermes run on servlet container
only, we paid the price of doubled effort to implement our own transaction
object. :-)

Regards, -Patrick


----- Original Message -----
From: "Ronald van Kuijk" <rv...@ab...>
To: "freebxml" <ebx...@li...>
Sent: Saturday, March 29, 2003 09:16 AM
Subject: [ebxmlms-develop] Design questions


> Hi,
>
> Hermes is now more or less an atomic application. I you build or use a
> servletcontainer (e.g. embedded tomcat or so) nothing else is needed.
> This is good in many cases, but we like to make as much use of features
> of a full j2ee application server as possible. The parts that come to
> mind are:
>
> - Authentication
> - DBConnectionpooling, based on JNDI
> - Transactions
> - File based persistence
>
> I can imagine that doing this, means that it can run in simple servlet
> engines and that the performance is probably higher. In our case however
> it has to run in a Weblogic server at an ASP. They do not allow us to
> configure database connections outside the appserver connectionpools.
> The same goes for the ba accounts and certificates. They have to be
> checked against an ldap server, so the username/password file is not an
> option for us.
>
> For High Availability reasons file based persistence is not an option.
> I've seen that all the meta information is stored in a database, but the
> messages themselves are not. Correct me if i'm wrong.
>
> Again, I do not mean this as an attack on your choices, but making this
> configurable in one way or another, would benefit all (well at least us
> ;-)). There are several developers in our company that could spend time
> on this once we get permission/funding to redesign our messaging server
> a little (it's now partly ebms 1.092 compliant, with extensions to
> backwards compatible with our previous x.400 system)
>
> We also like to extend the system with several other options, many of
> which need tapping into the message flow in our central MHS (is muli-hop
> supported?)
> - EDI2XML and XML2EDI, depending of customer profiles
> - Virusscanning (yes, even with application to application communication
> and pure xml/edi documents customers want this)
> - Generating Management Information based on the envelope and/or content
> of the attachments
>
> We are thinking of implementing this in a kind of a 'bus' way, where the
> bus is a jms queue and a kind of a businessrule/processflow component to
> decide in which queue to place the message. We do not like to have this
> tightly coupled with ejb's but loosly with queue's and mdb's.
>
> Does anyone of you have any ideas on these subjects?
>
> Regards,
>
> Ronald
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> ebxmlms-develop mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>