Re: [ebxmlms-develop] Design questions

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

It was late when I wrote this (and even later now) but ofcourse file 
based persistence is not part of j2ee. That should have been jms..(for 
internal queing, retries etc...with mdb's as the message processors)

Ronald van Kuijk probeerde het volgende duidelijk te maken op 29-03-03 
02:16:

> 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