Menu
▾
▴
Re: [ebxmlms-develop] channels, classes, jndi etc.
|
From: Patrick Y. <kc...@ce...> - 2003-07-23 08:29:16
|
We don't like lock-in to a particular app server. Configuration is an issue. If the configuration complexity is on Hermes, then we can make it easier by providing more tools. But if the complexity is on the external server, it will be hard to solve the problem. A raw connection is a connection created directly, bypassing the connection pool manager. You know, in the past we have a mechanism to check the validity of a connection before checking out from the connection pool. The checking method is to do a "select 1" on a particular table. Obviously, before that table is created (e.g. in the early init state of Hermes), we need to get a connection which bypassed the connection pool checking. Cheers, -Patrick Ronald van Kuijk wrote: >For using ejb's etc I can understand that a little, we ourselves do not >use the env parameters to pass values to ejb's, we use config files as >well. > >For datasources and app servers in general, I hope you do not mean that >configuring a datasource on a j2ee appserver is to difficult and should >prevent Hermes from using them? > >Even Tomcat supports connectionpools and transactions. Configuring them >is easy, just as easy as it is in Hermes. > >Ronald > >btw, can you confirm that the rawconnection is only needed to do >database things outside of a transaction? > > > >>-----Oorspronkelijk bericht----- >>Van: Patrick Yee [mailto:kc...@ce...] >>Verzonden: dinsdag 22 juli 2003 17:43 >>Aan: ebx...@li... >>Onderwerp: Re: [ebxmlms-develop] channels, classes, jndi etc. >> >> >>One of the concerns for using more J2EE services (we are >>suffering this in >>another product we are doing now..) is configuration. We can >>assume that the >>J2EE services provided by different app servers can be >>accessed without >>modifying any code. But the configuration way of different >>app servers would >>be different, even when JMX is used. There is no a standard way to >>configure. This makes the configuration work complicated, and >>eventually >>leads to difficult deployment. >> >>Any experience to share in this direction? >> >>-Patrick >> >>----- Original Message ----- >>From: "Ronald van Kuijk" <rv...@ab...> >>To: <ebx...@li...> >>Sent: Monday, July 14, 2003 05:55 AM >>Subject: Re: [ebxmlms-develop] channels, classes, jndi etc. >> >> >> >> >>>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 >>>> >>>> >>> >>> >>> >>>------------------------------------------------------- >>>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 >>> >>> >>> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: VM Ware >>With VMware you can run multiple operating systems on a >>single machine. >>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual >>machines at the >>same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 >>_______________________________________________ >>ebxmlms-develop mailing list >>ebx...@li... >>https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop >> >> >> |
