> ----- Original Message ----- From: "Nigel Deakin" <nigel.deakin_at_oracle.com>
> To: <jsr343-experts_at_jms-spec.java.net>
> Sent: Wednesday, June 22, 2011 5:02 PM
> Subject: [jsr343-experts] Re: JMS 2.0 Priorities: Proposal from Emran Shaik
>
>
>> Emran,
>>
>> On 06/06/2011 10:28, emran wrote:
>>> 2) API enhancements
>>> Multiple features like ...security...
>>
>> Can you please say a bit more about what you have in mind here?
>>
>> Nigel
>>
On 30/06/2011 07:35, emran wrote:
> Hi Nigel,
>
> What I meant here was, the API on connection factories to create connections with secure transport (I have seen this
> feature in the jms containers as a configurable property on connection factories).
>
> Regards,
> Emran.
Thanks for clarifying this.
As you know, the approach taken in the JMS 1.1 spec is that provider-specific configuration information such as how to
connect to the server, the transport used, etc, are defined "by defining JMS administered objects that are created and
customized by a provider’s administrator and later used by clients". These are then stored in JNDI and looked up by JMS
clients which can use them in a standard and portable way. The idea is that all the provider-specific behaviour is kept
out of the client application and concentrated in separate, provider-specific facilities. (Section 2.3).
Because of this, the JMS spec gives vendors complete freedom to support any transport they like, whether TCP, SSL, HTTP,
direct in-VM transport, allowing these to be configured on the connection factory using vendor-specific mechanisms.
So the question here, then, is whether we want to move away from this approach to one in which the connection factory
API is standarised. Julien is asking for something similar in asking for JMS to define a standard "connection string" to
define server IPs, timeouts, etc. I'll group Emran's and Julien's issues together.
Nigel