In WSE 2.0 we had the ability to run web services over TCPIP and other transports. Did you use it? I didn’t. Too confusing. Loved the demos at TechEd & PDC, though. The Messaging API has in it SoapSender and SoapReceiver, but it is disconnected from all of the security I was doing with WSE – or maybe I just couldn’t ever figure it out. I think it even required a lot more angle bracket programming, too, though I don’t recall now.
With WSE 3.0, Microsoft has made transport independent Web Services much more accessible. You can now write web services the way most of us luddites are used to, with the VS IDE (or even graduate to contract first web services) – – add in all of your WSE goodness – i.e. policies for security, etc.
With a HTTP hosted web service, you write the web service and build it in VS2005, deploy it if necessary (I’m still working in a development environment), then write your client, and ( in the simple world), add a web reference which creates a proxy, then make calls to the proxy.
With the example of a console application hosted web service, you write the web service and write a console app that fires up the web service in a URI with a tcp scheme.
The key code for the console app is
1) Create a URI that will be the endpoint
dim myTCPServiceURI as URI= new URI(“soap.tcp://mytcphost/mynicewebservice”)
2) Add the endpoint and the class for your web service to the Microsoft.Web.Services3.Messaging SoapReceivers
SoapReceivers.Add(new EndPointReference(myTCPServiceURI), GetType(myService))
Then you can fire up this console app and it will sit and wait for messages on that URI, just the way IIS does, but in the case it’s coming through TCP. You can also specifiy a port eg: soap.tcp:90. The web service processing just happens right there.
On the client side, the code is not too much different than calling an HTTP Web Service.
For those who only know how to get at web services through web references, remember that this is an existing HTTP Web Service, right? So you can get a proxy to that the way you know, by pointing to the original HTTP Web Service. Otherwise, you can use the wsewsdl3 tool (included with the SDK) that will create a proxy class directly from WSDL. The proxy is just to make it easier to code against the web service and has nothing to do with where the endpoint is. We will still access it through TCP when we run our client app.
1) Create a proxy web reference (let’s say that becomes localhost)
2) Instantiate the proxy
Dim myWS as localhost.MyServiceWSE=new localhost.MyServiceWSE()
3) Change the URL to point to the uri that is waiting on the TCP Wire (above)
myWS.URL=”soap.tcp://mytcphost/mynicewebservice”
4) Define the operation that will be called (eg Web Method)
myWS.RequestSoapContext.Addressing.Action=new Action(“GetSomeData”)
5) Create a ReplyTo endpoint (as per the WS-Addressing specs)
myWS.RequestSoapContext.Addressing.ReplyTo=new ReplyTo(new URI “soap.tcp://receiver”)
6) SetPolicy if that is required
myWS.SetPolicy(“mypolicy”)
7) Make your call!
Like I always say, if I can do it, so can you! More importantly, it’s taken a while for me to finally comprehend it. Which says to me, that Microsoft has gotten it to the proper place for non-plumbers.
Don’t Forget: www.acehaid.org