Log in

No account? Create an account
Adventures in Engineering
The wanderings of a modern ronin.

Ben Cantrick
  Date: 2006-09-14 22:55
  Subject:   MSDN Event 2006/09/14 - WCF preview

Signed up for this at the recommendation of my boss. I missed the first session, which was about all the cool stuff that is so easy to do with the .NET API. Things like initiating and accepting HTTP connections, sending email, getting files via FTP, etc, etc. I think this session probably would have been a lot of fun, since it's basically showing off a bunch of whiz-bang programmer toys, so I'm kind of sad I missed it. I didn't plan to stay for the third session, which was about Atlas, which looks to be MicroSoft's attempt to jump on the AJAX bandwagon.

The second session was all about WCF, the Windows Communication Foundation. Basically this is a very nice set of APIs and automated proxies that makes it possible to do RMI-ish stuff with ease. "Web services" and "service oriented architecture" being the buzzwords employed. My naive summary of WCF is: "Oh look, MicroSoft has discovered XML!" Basically, you can create code to do something, create an interface (MS word: "contract") to it, and then wrap this all up as a "service". The service can be called by any of several transports. The transports being HTTP(/S), TCP or a couple flavors of IPC. (One flavor of IPC was amusingly named "ICP". So yo, word to the juggalos!) HTTP is restricted to a text-only encoding when exchanging data, but the other transports have binary encodings which make them ~10x faster.

The major parts of a WCF service as presented were an address, a binding, and a contract. Think "ABC" or better, as the presenter astutely pointed out, think "CBA" because that's much more the order that you really care about. The contract of course specifies the interface to the service. The binding seems to specify what transport you're using. And the address what the network address of the machine providing the service is. I wasn't sure why they didn't combine the binding and the address. A typical URI can specify both reasonably nicely. I couldn't see what benefit splitting them up and giving them vague names created. It certainly allows you to access the same service over multiple bindings, but a URI allows the same thing, i.e. "http://blah.com" and "ftp://blah.com".

Another interesting part, that I'm also not entirely clear on, was how you publish your service's "contract" e.g. interface. Because if other people don't know what your interface is, they can't really use your service. XML uses DTD's for this, but I didn't hear about anything comparable in WCF. There seems to be something in the works called "UDDF", which was explained as "the yellow pages of the Internet." To me that sounds like something you're going to have to pay MS money for in order to "advertise" your network service. I'm not sure how, say, a random webserver offering a WCF service would communicate the service's interface (and thus offer the service) without using UDDF.

Despite these problems, WCF seems to be both a powerful and reasonably simple API. We'll see if it lives up to its potential. I've always been a little skeptical about the feasibility of "web services" in general. It seems to me that we need a whole lot more security and QoS guarantees before anyone would be willing to make their core business dependent on someone at the other end of a net connection. Time will tell...

Part of my attendance packet junk was a DVD-ROM with a copy of Vista Beta 2 on it, complete with legit product key sticker on the envelope. If anyone wants this, just let me know. (I asked around at the event - Beta 2 is not the same as RC1, but apparently you can upgrade Beta 2 to RC1 after installation.)
Post A Comment | 4 Comments | | Link

  User: j_b
  Date: 2006-09-14 23:51 (UTC)
  Subject:   (no subject)
I think UDDI is the "Directory of Web Services(*)" http://www.uddi.org/

* That will be about as successful as ISO/OSI
Reply | Thread | Link

  User: jigenm4c
  Date: 2006-09-17 06:58 (UTC)
  Subject:   (no subject)
Agreed. Completely agreed. I think UDDI is a great idea that is poorly executed, and rarely supported.
Reply | Parent | Thread | Link

Alex Belits: iskra
  User: abelits
  Date: 2006-09-15 05:57 (UTC)
  Subject:   (no subject)
Microsoft: We have just discovered that RPC can work without any ties to OLE^H^H^HCOM! Who knew!
Reply | Thread | Link

  User: jigenm4c
  Date: 2006-09-17 06:57 (UTC)
  Subject:   (no subject)
It's interesting to note that UDDI and SOAP have been known technologies for the past few years, as well as UDDI being a supported standard that Microsoft has employed for almost as long as it's been in use. (I even believe someone at Microsoft was part of the UDDI design group.)

UDDI is similar to .NET in a way - it provides a central way to look up services provided by a certain software company or URL, and tells you how to contact them. SOAP simply provides the mechanism in which TO contact them.

It's interesting that Microsoft is calling a WSDL request a "contract" - I guess you can never have too many buzzwords. I like the fact that SOAP is out there, and there are many different types of transports on which to transmit the data, but the whole point of the SOAP code is to be able to use XML as the transporting mechanism from which a request/response chain is made.

I think that transporting the XML requests over HTTP(s) is a better way to transport data than, say, FTP. But true, there are other mechanisms in which soap requests can be made. Even via SMTP. I've seen implementations of SSH and SCP SOAP requests, but they're convoluted. I like the fact that HTTP(s) can be used as the main transport (which is the preferred transport) but I don't like the fact that you have to create specific soap messages for the server to support the request. Instead of extending the HTTP protocol to do that, it makes more sense to me to use the established protocol to do that. But que sera' sera'...

'Tis the next wave for Microsoft. I just think they're a few years behind. Will be interesting to see how they incorporate this into Vista and their Web-based Office suites.
Reply | Thread | Link

May 2015