Andreas
Please review and provide feedback (in particular on my analysis of
the as-is situation and the proposed to-be situation).
Your analysis is correct, I guess TransportSender will follow shortly
Some additional points where contribution is required:
* Explain the impact of supporting both JMS 1.0 and 1.1.
Unfortunately we cannot depend on the Sun's JMS API jar's and thus we
have a dependency on the Geronimo 1.1 API jar, which creates problems,
as even if we break 1.0 compatibility, its not found until too late. I
think a solution to this and a better design would be to move JMS 1.0
and 1.1 API specific code into separate classes, and make the transport
depend on a common interface. Then at least when someone makes a fix on
the 1.0 code, they can be extra careful.
* I think that a large part of the specifications for the JMS
transport should apply equally to the AMQP transport. In SYNAPSE-303 I
suggested to create some kind of abstract messaging transport from
which both transports would be derived. What is your opinion on this?
I think we should not do anything AMQP specific in the JMS transport,
but rather allow the JMS transport to be configured with additional
properties as required, to support AMQP, MQSeries, Tuscany etc. Someday
there will be a good native AMQP transport, and right now the best
'interoperable' AMQP support there is, is via JMS
* Can anybody with knowledge about the proposed SOAP over JMS
specification comment on what we need to rework to support it?
I think we should support the existing Synapse/Axis2 style addresses, as
well as the new IRI scheme and this shouldn't be much of a problem.
Maybe we can have a switch per service to state whether it prefers the
new style or the legacy, and default to the new IRI etc. I haven't yet
had time to read the links to the new SOAP/JMS spec, but I will try to
do that before next week, but I think this is very much similar to the
one posted to the Axis2 dev list some time ago.
For supporting transactions, I think we should implement this support at
the Base transport level if possible, so that if a transport is
"transactional" its thread pools will only work with an active JTA
transaction. Sometime back I looked at how Spring and Mule supported
this and still be able to work within newer JEE app servers such as
WebSphere 6.1. What they both did was to poll for messages continuously
with small delay. This is 'somewhat' similar to what we do with the
nhttp/s transport, but I guess polling would be much more expensive with
JMS and when transactional. However, I do not think there is a better
way either..
asankha
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
