The wonders of EndpointReference.Via in WSE 2.0

I recently extended a chat program written in _WSE_ 2.0 utililizing the TCP transport protocol. I wanted it to run over the internet now. This was prompted by some members of our Singapore Professional DotNet Usergroup who wanted to implement a mini Pub-Sub (aka WS-Eventing) project using the tcp protocol.

They had indicated that they had some trouble binding the FQDN specified for the URI in the EndpointReference to a local network interface. If this cannot be resolved, the binding will fail.

At the most basic level, the EndpointReference.Address is both the name of the target and its location. For example, [http://localhost/SomeService] can be used as a name and a transport address. WSE 2.0 comes with an extended model to allow a single named service to be hosted on multiple transport addresses. This can also be useful if we want to apply a single corporate policy on them.

This is where EndpointReference.Via comes in. It allows you to host a well-known service that can only be accessible via different transports such as the soap.tcp protocol of WSE 2.0 and others.

For example, my well-known service is hosted at soap.tcp://softwaremaker.net:2088 (or soap.tcp://219.74.47.214:2088, if you dont have a DNS tagged to it). This is the public FQDN address of the service. For the broadband cable and ADSL users of dynamic IPs, this address may be the address of your home network router.

Now, your WSE 2.0 application has a SOAP Receiver object that allows your application to listen for SOAP requests coming in on WSE2-custom defined transports. Once you define your own address on your own listening machine such as soap.tcp://192.168.2.100:2088/Softwaremaker, you would now have 2 URIs:

Public Facing: soap.tcp://softwaremaker.net:2088
Private Internal: soap.tcp://192.168.2.100:2088/Softwaremaker

The Public Facing well-known URI becomes the EndpointReference.Address while the transport address mechanism becomes the EndpointReference.Via

In other words, soap.tcp://192.168.2.100:2088/Softwaremaker will listen for any messages that is sent to soap.tcp://softwaremaker.net:2088 (the address element in the WS-Addressing headers). Put it in another way, the custom soap.tcp transport will only accept messages sent to soap.tcp://softwaremaker.net:2088 if they arrive via the internal address:192.168.2.100.

The Via address is not in the message itself, only the well-known URI is. Based on the network address the message is being received on, the custom soap.tcp transport mechanism will know how use both well-known and private URIs to dispatch the message to the registered and configured-properly SOAP Receiver.

    EndpointReference EPR = new EndpointReference
    (new Address(new Uri("soap.tcp://softwaremaker.net:2088")),
    new Via(new Uri("soap.tcp://192.168.2.100:2088/Softwaremaker")));

    SoapReceivers.Add(EPR, yourOwnSoapReceiver);

The last step you need to take is to be able to forward all requests going to the well-known URI (soap.tcp://softwaremaker.net:2088) to your local machine with the internal IP 192.168.2.100:2088

This is not something you can do in WSE 2.0 or in your machine. This has to be done at your broadband or cable router. You just have to forward requests coming in to your Public port:2088 to the Private port:2088 of machine 192.168.2.100 (Note that these ports doesnt have to be the same number at all)

Of course, the huge assumption is that you have control over the port routing and forwarding of your broadband or cable router (which may be rather tricky if you are within a corporate or organizational boundary) BUT technically, you will be able to carry out a p-2-p SOAP message chat or even do a Pub/Sub model approach with your own implementation of the “Notification” and “Solicit-Response” message-exchange patterns over the internet using the custom soap.tcp protocol of WSE 2.0

[Author Note] What do ya know ? I just found that that Hervey has got an even better post on the EndpointReference.Via of WSE 2.0 here.