On 18 juin 08, at 13:31, Asankha C. Perera wrote:
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.
Breaking 1.0 compatibility could also be detected during the unit
tests. To do this we need
* sufficient unit test coverage (required anyway...);
* a wrapper/proxy that intercepts all JMS calls during the unit tests
and throws an exception whenever a JMS 1.1 feature is used.
We should apply the same strategy to test for JEE compliance. I will
provide a solution for this.
* 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.
I have one specific question related to the specs and Axis2. The specs
say that when sending out a JMS message, information is used from
[quote]
* The JMS IRI (which may be specified in the WSDL, programmatically,
on the command line etc.);
* WSDL elements or attributes (in addition to the endpoint IRI), and;
* The environment (for example local program variables, system
environment variables etc).
[/quote]
While the first and last items are obvious, I have some doubts about
the second. How can an Axis2 transport have access to the WSDL of the
remote endpoint?
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..
Should we support only the JEE compliant mode or should we also
support using MessageListener when the transport is deployed outside
of a JEE container?
asankha
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
