Menu
▾
▴
Re: [ebxmlms-develop] channels, classes, jndi etc.
|
From: Ronald v. K. <rv...@ab...> - 2003-07-13 21:56:20
|
While I was working on a small example of looking up connectors for channels (shouldn't we standardize on a name for these?) together with their configuration, it really started to look like I was implementing sessionbeans. I started from http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jndi-resources-howto.html#Adding%20Custom%20Resource%20Factories and then had to add some other functionality. Eventually the list was - Looking-up components by their JNDI name - writing some config mechanism these components could use (deployment descriptors) - having it work with transactions - limiting the amount of simultaneous use (to prevent the application/backend to become overloaded) - ..... At that moment I stopped, took a good night sleep and came up with the following. I think that Hermes should support two different approaches: - Lightweight, just running on a servlet engine - Running on a j2ee server (more complex in some parts, simpeler in others) The reason I bring this up again, becomes clear by the following table which contains current and future functionality: Feature Hermes Tomcat *1 Jetty Plus *2 j2ee ConnectionPool, with jndi No, Proprietary standard standard standard Transactions Proprietary standard *3 standard *3 standard *3 authent. / author. Proprietary jaas jaas jaas Monitoring (jmx?) No yes *4 yes *5 yes (curr. proprietary) Clustering No No (t yet *6) No standard JavaMail Yes,(other config) yes yes yes JCA *7 n/a No No Yes *1 : http://jakarta.apache.org/tomcat/ *2 : http://jetty.mortbay.com/jetty/plus/ *3 : JTA *4 : Tomcat 4.1 and newer *5: http://jetty.mortbay.com/jetty/jmx/index.html *6: http://www.onjava.com/pub/a/onjava/2002/07/17/tomcluster.html *7: Java Connector Architecture, for furture integration with SAP, Siebel, JDEdwards, PeopleSoft, Oracle, DBs, CICS, IMS, MQSeries With this table, I do not, not at all, want to shed a negative light on Hermes. The opposite, I'd like it to be what it currently is, a great and stable ebXML MSH. All the other functionality, like connectionpools, transaction managers etc, which do work without a problem, should be build by those people that have that as their core (opensource-) business. Whatever the difference will be between the 'lightweight' and 'j2ee' versions, providing the hooks to choose either path is needed the most. The step from using the build-in jta,jdbc, etc functionality of a servlet engine to using a j2ee-server is small. Any comment? Highest Regards Ronald Ronald van Kuijk wrote: > While developing the small example with JNDI, some questions came to > mind. What I was doing looked alot like implementing what can be done > with session-beans in a j2ee server. > > Without thinking of ejb's, the questions this raises for me are: > > * How dynamic should new classes (file/url/jms/....) be loaded. > o Should they be deployed expanded e.g. in a expanded > deployed msh.war directory? > o Is a restart acceptible? > * Where and how should they be pre-configured (url, username, > password, certificate etc). > * Does each AppContext has it's own set of maximum of 3 'channel > connectors' (message, error, notify) or should the be shared > between AppContexts? > * Where is the dynamic configuration persisted (if at all?) in > relation to the AppContext (JNDI?, Database?) > * Should there be a limit in maximum connections to the receiving > application? * etc... > > please comment.. > > Regards, > > Ronald > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Parasoft > Error proof Web apps, automate testing & more. > Download & eval WebKing and get a free book. > www.parasoft.com/bulletproofapps1 > _______________________________________________ > ebxmlms-develop mailing list > ebx...@li... > https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop |
