Re: [ebxmlms-develop] channels, classes, jndi etc.

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

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
>