One of the issues I've been struggling with while writing my experimental Windows Communication Foundation transport channel has been designing a proper URL syntax for the transport.
If you're writing a channel for a protocol that has a standard URI syntax (such as HTTP or FTP), then you won't have to worry about this at all. Otherwise, you need to give some thought as to what URI scheme you'll use, as the use of URIs (and in many cases, specifically URLs) to address endpoints is required in WCF, as Kenny Wolf mentioned in a past article.
If your protocol has an obvious, explicit addressing scheme, then this might not be too big a deal, as your URI syntax will likely derive easily from that. For example, for MSMQ, your addresssing will be based on referencing machines and queue names, so that's a good place to start from.
The reason I'm struggling a bit with this is that the protocol I want to work has these particularities:
- It does not have an obvious addressing scheme. By this I mean that just addressing, say, a host name, port and resource name is not enough to successfully open a transport connection.
- There are several important fields or properties the developer needs to specify for the transport to be able to open a connection. However, it also has quite a few fields that, while optional, it would be desirable for the developer to be able to set them (and even be encouraged to do so). What's worse, some of the required fields have optional, list-like components that are important to support.
- The basic information needed to open a connection to a remote endpoint is not composed of the same set of fields needed to define a local endpoint for receiving messages, which means that it would be very likely that the URI scheme would need to be different for the sending and receiving sides of the transport channel. This is due to a basic assymmetry at the protocol level that I can't avoid.
Regarding 1 and 2 above, the basic issue I struggle with is: How much information should go into the URI syntas versus other means, such as the Binding configuration element for the transport channel?
Problem 3 is a bit more annoying because it just doesn't quite feel right to have the same transport channel dealing with two different URI syntaxes but sharing a single URI scheme.
Does anyone have any good suggestions or rules of thumb for dealing with stuff like this?
