Hi Rajith,
> I think we as a project *must* have the same connection url/string
> syntax across all clients.
I don't think this works in the WCF context. But I believe it is
merely because WCF has different conventions, not that the proposal
lacks merit in general.
In WCF, the constituents of the proposed connection string are
traditionally split apart, not least because the bits of the string
would be looked at and applied at different times.
The specifics of specifying (e.g. TLS and SASL PLAIN) connection
related parameters in the WCF/C++ client is a work in progress, so I
don't have a handy example. But as an analogy, using TLS with a
client side certificate for the WCF TCP binding:
NetTcpBinding b = new NetTcpBinding();
b.Security.Mode = SecurityMode.Transport; // versus "None", i.e. no TLS
b.Security.Transport.ClientCredentialType =
TcpClientCredentialType.Certificate;
EndpointAddress a = new EndpointAddress("net.tcp://contoso.com/TcpAddress");
ChannelFactory<ICalculator> cf = new ChannelFactory<ICalculator>(b, a);
cf.Credentials.ClientCertificate.SetCertificate(
StoreLocation.LocalMachine, StoreName.My, X509FindType.FindByThumbprint,
myCertThumbprintId);
(extracted from http://msdn.microsoft.com/en-us/library/ms729700.aspx,
which contains the config file too; other WCF bindings have their own
specific XyzSecurity and XyzCredentialType classes)
There is an expectation that the transport security mode is set up in
a separate object, which is associated with the binding, and that the
credentials (if any) are associated with the channel factory (of which
there could be many for each binding instance, each with separate
credentials).
Similarly, this division flows to the config file with the security
mode and credentials separated into unrelated "bindings" and
"behaviors" XML config sections, respectively (detailed in the link
above).
This division has its detractors. Obtuse programming gymnastics can
be necessary in certain cases, such as where separate credentials are
required by separate layers of the stack (i.e. message versus
transport security, or if the messages pass through a server proxy).
However, WCF programmers are used to this paradigm.
Note that any attempt to use the System.ServiceModel.EndpointAddress
class (above) to combine these properties into a single string would
fail whenever the string fails to parse into a valid URI, long before
the Qpid transport layer gets called.
Cliff
-----Original Message-----
From: Rajith Attapattu [mailto:rajit...@gmail.com]
Sent: Monday, March 15, 2010 10:48 AM
To: dev@qpid.apache.org
Subject: Re: Client configuration & Connection URL
On Mon, Mar 15, 2010 at 12:35 PM, Gordon Sim <g...@redhat.com> wrote:
> On 03/11/2010 11:41 PM, Rajith Attapattu wrote:
>>
>> Hi All,
>>
>> Currently quite a bit of options can be configured via the Java
>> Connection URL, which tends to make it ungainly and quite error prone.
>> If we are to think in terms of a "Connection String" instead of a
>> "Connection URL" , then I believe we could come up with a more simpler
>> solution.
>>
>> Therefore I'd like to make the following proposals.
>>
>> 1) Introduce a simple scheme for a "Connection String" ( inspired by
>> the new addressing format)
>> 2) Also allow the ability to specify the config using a property file.
>>
>> * I hate having to specify user/pass when the auth mech (ex kerberos)
>> is not even using it. Therefore it should be optional !
>>
>> 1. 0 Connection String
>> ---------------------------
>> 1.1 Examples
>> "tcp://localhost"
>> "tcp://localhost:8672; {ssl: true, sasl-mech : EXTERNAL,
>> ssl-trust-store : ~/cert.jks ..} "
>> "tcp://host1.example.com; {user: bob, pass: nuts} ,
>> tcp://host2.example.com; {user: ding, pass: dong} ..."
>>
>> 1.2 Syntax
>> <broker> [ ;<options> ] [ ,<broker> [ ;<options> ]] *
>>
>> Where broker is::
>> <protocol>:// [ host [ ":" port ] ] (protocol = {tcp|vm|rdma}
>
> The c++ client currently supports the AMQP 0-10 definition of a url syntax.
> Do we want to support that more widely? It would be good to improve
> consistency across clients a little.
Well my motivation behind the thread was to get this out in the open.
IMO I think we as a project *must* have the same connection url/string
syntax across all clients.
I thought I'd start with the Java side and then take it from there.
The connection "URL" has been used for two reasons.
1) To identify which broker(s) to connect to
2) As a configuration mechanism.
My issue is if we treat the whole thing as a "URL" then supporting the
latter makes the whole thing ugly and error prone.
The Java connection url is a case in point.
I would rather treat it as a connection string which consists of two
**distinct** parts.
a) A broker (identified by a URL - ex tcp://localhost:5672/vhost )
b) A bunch of key:value pairs associated with the broker url.
Based on past experience, munging them together to form a URL is a
good recipe for disaster.
> The approach for specifying SSL is also different across the different
> clients.
Which is a pity I think.
>
>> Where options is::
>>
>> {<key> :<value>, ... }
>>
>> And values may be:
>> - numbers
>> - single, double, or non quoted strings
>> - maps (dictionaries)
>> - lists
>>
>>
>> 2.0 Config file
>> -----------------
>> Example
>>
>> JNDI prop file
>> connection.my-connection = "tcp://localhost; {id : 1}"
>> connection.my-con = "tcp://host1.example.com; {id: 2} ,
>> tcp://host2.example.com; {id: 2}, tcp://host3.example.com; {id: 3}"
>
> I'm not hugely keen on the split file approach or on the id as a way to
> reference externally defined options. What is the motivation for that?
Sometimes the connection string gets quite crowded especially if you
have a few props to specify.
I was just exploring the possibility of pushing that part to a config file.
Another advantage of the given format is that it makes it easy to see
the diffs btw different versions of the config file, something that is
quite impossible with the current approach.
Through experience I have seen that most companies version control the
deployment descriptors/config files etc., so that any given time they
could rollback to a previous deployment.
Rather than talk things in the abstract I decided to express my
questions/ideas via a proposal.
Therefore I was more keen on getting it out quickly with some
examples, than coming up with a solid proposal.
I hope the latter objective could be achieved through a discussion
that starts of from some basic idea.
>> =========Connection.properties=========
>> con id : 1 {
>> ssl: true
>> sasl-mech : EXTERNAL
>> ssl-trust-store : ~/cert.jks
>> ssl-key-store : ~/keys.jks
>> ssl-verify-hostname : true
>> }
>>
>> con id : 1 {
>> sasl-mech : GSSAPI
>> sasl-hostname : host1.example.com
>> sasl-protocol : qpidd
>> sasl-encryption : true
>> tcp-nodelay : true
>> }
>>
>>
>> con id : 3 {
>> user : ding
>> pass : dong
>> tcp-nodelay : true
>> }
>>
>> ==================================
>>
>> Connection.properties can be loaded from the classpath or specified as
>> an option in the connection string.
>> (You could also trivially have a connection property file per connection).
>>
>> Comments and suggestions are most welcomed !
>> Regards,
>>
>> Rajith Attapattu
>> Red Hat
>> http://rajith.2rlabs.com/
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
