Technical Content of this issue - 2.5 out of 5
Just When You Thought it Was Safe To Open Your EMail Client
Biff's PDC Newsletter is back in Los Angeles for PDC 2005, and we're
bringing it all to you! It's been two years since the our last issue and we're
itching to get started. Since the PDC is again in Los Angeles, there is a
temptation to dig up some of the tired, lame jokes from 2003, but don't worry -
we will try to come up with brand new tired, lame jokes. Remember that these
are all produced real-time, every night in my hotel room (as opposed to
imitation-time). I have no proof reader, and I have a tendency to inadvertently
split infinitives. Actually, that was an intentionally split infinitive, I just
stuck it in there to irritate Lenore.
If you know anyone who you think would enjoy receiving the newsletter, just have
then send me a note at PDCEditor@biffgaut.com.
Free Stuff
Every year I dedicate a segment in one of the early newsletters to
discuss the free stuff, so tradition dictates that I do so this year. That's
unfortunate, because the free stuff this year doesn't warrant a full segment of
the newsletter. It all came in a decent laptop bag, shoulder strap only. Inside
were no books, few CDs and a couple of magazines - one of which was the October
MSDN that I had already read on the plane. Top it all off with a relatively
plain T-Shirt. Maybe I'm just getting jaded, but free conference crap just
isn't what it used to be. We got a coupon to redeem for stuff called "the
Goods" after the keynote on Tuesday, maybe things will improve then.
Today's Sessions
Today was one of the special "pre-sessions" - all day sessions offered
before the official opening of the conference. Today was "Building Web Services
Today with .NET 2.0 and WSE 3.0" WSE (unfortunately pronounced "wizzy") is Web
Services Enhancements, a set of libraries that augment the standard .NET asmx
web service architecture to add things like WS-Security and binary transfers.
The presenter was Aaron Skonnard from a company call Pluralsight (go figure!).
He was an excellent presenter, energetic with clear explanations. The content
was a bit disappointing, as it didn't seem to meet the title. At one point he
stated that WS-Security was "the main use case for using WSE." That being the
case, I would have thought we would have gotten to it before the final 15
minutes of six total hours of presentation. We spent alot of time hearing about
aspects of asmx files as implemented in .NET 1.1. All that being said, there
were some interesting nuggets that I will cover in a moment. At one point
during the presentation he was discussing Infopath and it's role in the Office
family with the phrase "It is a piece of Office." I toss that out for the
opensource afficionados on the subscription list, whom I'm sure could use that
exact phrase with a little different connotation.
The first part of the presentation discussed services in general. Nothing earth
shattering here, just a repeat of the mantra "Boundaries are explicit; Services
are autonomous; Share schema and contract, not implementation; etc." One
interesting tidbit that I was not aware of: W3C has revoked SOAP's status as an
acronym (Simple Object Access Protocol). It was decided that what it described
really has nothing to do with objects - the technology is still called SOAP,
but now it is just a word with no relation to the original 4 words, kind of
like AT&T not selling telegraphs anymore.
A new aspect of asmx files that seemed interesting to me was how web service
code is generated from WSDL files. In .NET 1.1, you can create a class that
implements a web service by using the WSDL command line program with the
/server option. This creates an abstract class defining the functionality in
the WSDL file, along with the required attributes to complete the contract. You
can edit this file directly to create the implementation, but then you lose
everything if you have to regenerate the interface from the WSDL file. You can
derive a class from the abstract class, but the attributes don't follow down
the inheritance chain and you risk screwing up the contract - the best you can
do is derive, then copy all the attributes. In .NET 2.0, the WSDL program has a
new argument, /serverInterface, that creates an interface that maps to the WSDL
file. You then write a class the implements the interface - since attributes on
an interface DO transfer to implementations, your work is protected and you
don't have risky hand copied attributes. This makes writing a service to a
pre-defined contract (the preferred order of doing things) much easier, and
also separates the web service housekeeping details from the business code
nicely at the same time. One possible problem this introduces is that
attributes that affect the contract can now only be put in the interface file.
Since an out of place attribute will trigger a compiler error, this is just an
annoyance rather than a risk.
Today's Interoperability Moment*
The release of .NET 2.0 and asmx 2.0 increases the standards supported by
asmx. asmx 1.1 included support for XML 1.0, XML Schema, SOAP 1.1, WSDL 1.1 and
HTTP. 2.0 adds support for SOAP 1.2 WS-I Basic Profile compliance. BP support
helps ensure interoperability by checking conformance.
Finally we got to WSE 3.0. He focused two specfic features of WSE 3.0, the
ability to host asmx classes in standalone applications and WS-Security. I'll
cover the first one pretty quickly. If you are in a situation where you want to
expose a web service from your app but you are not IIS, it is now possible
(although not great). The service cannot be exposed via http:, only via
soap.tcp: (yes, it's alot like .NET remoting). If that's OK with you, then
you're golden. Just include WSE 3.0 in you app, add the asmx class and expose
it via a SoapReceivers.Add() method - Done! Of course, you need a client that
can call a web service via soap.tcp.
(Note on the next paragraph - I am not a security guru. If I make a
misstatement, please don't flame me) WS-Security is the proposed standard for
protecting Web Services. WSE implements this by setting up a mechanism where
your SOAP call goes through a chain of filters. You can communicate with these
filters with a property of the SOAP proxy called the context. I will probably
get into much more detail later in the week, right now I'm going to keep it
brief (just like it was in the actual session). For now, here's how he did it.
At design time, use the WSE wizards to create the policy. This will create an
XML policy file. Note that in WSE 2.0, this file followed WS-Policy - in WSE
3.0 they abandoned WS-Policy in favor of readability. Also, the policy file
created on the server cannot be shared with the client - the client needs to
use the wizard to create a new policy checking the same settings because the
file formats are different. On the server side, the policy is attached to the
server method vis a an attribute and attached to the call on the client side
via a method call on the proxy. There are several credentail options,
Anonymous, Username, Certificate and Windows. If you use Username, there must
be a cert available on the server for the client to retrieve and use for the
call.
*A daily nugget included to appease the J2EE afficionados on the subscription
list
Biff's PDC Mailbag
This segment is reserved for us to answer your letters. I don't want
to put any pressure on you, but in the past we have had great response and
entertaining and provocative letters. How good the letters we receive this year
is up to you. We actually received our first letter last week:
AF in VA asks - "I expect to see lots of pictures!"
AF - Thanks for your nice note. I was unable to procure a digital camera for the
trip, but I did record some of the first day visuals in our
Photo Album. -Ed.
Send your letters to PDCEditor@biffgaut.com.
Tomorrow
Tomorrow is another early bird session, this one focusing on Service Oriented
Architecture.
Biff
Founder and CEO, Biff's PDC Newsletter