Hi,

In last few weeks, I'm playing with two JMS implementations of Axis2 
over SonicMQ and would like to share my thoughts. Many of them already 
posted to the user list.


New JMS Implementation
----------------------------------------
- [New Feature] Handling connections to security enabled brokers [1]
  - There is no support for authenticated connections. But in real life;
    - Each connection may require username and password
    - Each binding/broker(transport.jms.ConnectionFactoryJNDIName) may 
      require a different username & password
    - There is a need for a place to store connection username & password 
      (probably within axis2.xml [2])

- [New Feature] ConnectionFactory cache [3]
  - In SonicMQ, if ConnectionFactory is retrieved from the JNDI for each 
    connection, very high memory usage which prevents access to admin 
    console occurs during high message traffic. And sometimes the server 
    crashes.
  - AFAIK, old JMS implementation uses connectors to achive this.

- [New Feature] Connection pool [3]
  - I'm not 100% sure here. Caching ConnectionFactory would be suffient if
    vendor specific ConnectionFactory internally supports connection pool.
    Or, perhaps, a ConnectionPool which internally holds connections
    and uses ConnectionFactory cache may be written.

The Current JMS Implementation
 -------------------------------------------------
 - [Improvement] Some of the missing points I've figured out [4]
  - Modules are loaded three times
  - jndiName is lost
  - username and password are lost 
  - Ambiguity and incompleteness in the code
    - Configuration file is loaded many times
    - There are lots of static definitions for the repository and 
conf/axis2.xml 
      - These are found under integration module and not part of the core.
    - Unclearness of the differences between connectorMap and cfMap
    - Many TODO comments that indicate incomplete features


Common for both Implementation
  -------------------------------------------------
  - [Bug?] fireAndForget () waits for response when it comes to JMS[5]
   - In JMSSender.invoke(), there is waitForResponse variable that is set 
     according to the separate channel use. Because of this, I need to 
     pass true to options.setUseSeparateListener() before calling 
     fireAndForget (). Does it logically correct? I mean, don't we expect 
     fireAndForget() to be used for one-way messaging? I think fireAndForget() 
     should be irrelevant to the response message and so the listener. 
 
 - [New Feature] Message driven beans  as service endpoints
   - That would be a great feature. JBossWS supports MDBs[6].
 
 - [Improvement] JMS URL concept/proposal/tutorial should be 
clarified/updated[7]
   - There is one proposal for Axis1[8] and none for Axis2. It seems, some of 
     the parameters are not used in Axis2.
 

Regards,

Ali Sadik Kumlali

[1] http://www.mail-archive.com/[email protected]/msg15817.html
[2] http://www.mail-archive.com/[email protected]/msg15404.html
 [3] http://www.mail-archive.com/axis-user%40ws.apache.org/msg15854.html
[4] http://www.mail-archive.com/[email protected]/msg15132.html
 [5] http://www.mail-archive.com/[email protected]/msg15406.html
 [6] http://labs.jboss.com/portal/jbossws/user-guide/en/html/jms-transport.html
[7] http://www.mail-archive.com/[email protected]/msg15257.html
 [8] http://marc.theaimsgroup.com/?l=axis-dev&m=103617964921940&q=p3) 




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to