[ebxmlms-develop] Design questions

[Ronald v. K. <rv...@ab...>]

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