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