In the ongoing MSDN Architecture Webcast Series with broad coverage of all things WCF (see the "Next Generation: .NET Framework 3.0 and Vista" section for archived and upcoming content), I am on today (8AM PST, 11AM EST, 17:00 CET), live from my kitchen table in Germany, with a remix of my "RSS, REST, POX, Sites-as-Services" talks from MIX06 and TechEd.
Cool. I hadn't even seen this demo until now, even though we already have it for a while. Our technical evangelist Craig McMurtry posted the "Digital Fortress" demo, which is an implementation of the computer systems that play major roles in Dan Brown's novel "Digital Fortress". There are several reasons why I find this demo interesting and pretty amusing.
First of all, it has a "Hollywood-Style UI", which is funny. It's got the huge full-screen login screen with a "sort-of-looks-like-the-NSA" logo, a big count-down clock and a "control screen" (below) with the gratuitous graphics and big buttons one might expect. The other thing that's very interesting is that it is a management tools demo (of all things). The key to bust the evil conspiracy is to trace suspicious network activity across many nodes on the network and the script packaged with the demo shows you how to get that done using the built-in WCF tracing facilities. Download.
The other reason why it's good to be back near my stuff for World Cup watching. Projection surface approx. 3.20m x 1.80m.
[Note to self: Schedule the video taping session early in a bound-to-be-stressful week, not 2 hours before you need to leave for the airport on Friday.]
MSDN TV has a new episode featuring yours truly speaking about WCF bindings (and what they cause in the channel stack).
I was sad when "Indigo" and "Avalon" went away. It'd be great if we'd have a pool of cool legal-approved code-names for which we own the trademark rights and which we could stick to. Think Delphi or Safari. "Indigo" was cool insofar as it was very handy to refer to the technology set, but was removed far enough from the specifics that it doesn't create a sharply defined, product-like island within the larger managed-code landscape or has legacy connotations like "ADO.NET". Also, my talks these days could be 10 minutes shorter if I could refer to Indigo instead of "Windows Communications Foundation". Likewise, my job title wouldn't have to have a line wrap on the business card of I ever spelled it out in full.
However, when I learned about the WinFX name going away (several weeks before the public announcement) and the new "Vista Wave" technologies (WPF/WF/WCF/WCS) being rolled up under the .NET Framework brand, I was quite happy. Ever since it became clear in 2004 that the grand plan to put a complete, covers-all-and-everything managed API on top (and on quite a bit of the bottom) of everything Windows would have to wait until siginificantly after Vista and that therefore the Win16>Win32>WinFX continuity would not tell the true story, that name made only limited sense to stick to. The .NET Framework is the #1 choice for business applications and a well established brand. People refer to themselves as being "dotnet" developers. But even though the .NET Framework covers a lot of ground and "Indigo", "Avalon", "InfoCard", and "Workflow" are overwhelmingly (or exclusively) managed-code based, there are still quite a few things in Windows Vista that still require using P/Invoke or COM/Interop from managed code or unmanaged code outright. That's not a problem. Something has to manage the managed code and there's no urgent need to rewrite entire subsystems to managed code if you only want to add or revise features.
So now all the new stuff is now part of the .NET Framework. That is a good, good, good change. This says what it all is.
Admittedly confusing is the "3.0" bit. What we'll ship is a Framework 3.0 that rides on top of the 2.0 CLR and includes the 2.0 versions of the Base-Class Library, Windows Forms, and ASP.NET. It doesn't include the formerly-announced-as-to-be-part-of-3.0 technologies like VB9 (there you have the version number consistency flying out the window outright), C# 3.0, and LINQ. Personally, I think that it might be a tiny bit less confusing if the Framework had a version-number neutral name such as ".NET Framework 2006" which would allow doing what we do now with less potential for confusion, but only a tiny bit. Certainly not enough to stage a war over "2006" vs. "3.0".
It's a matter of project management reality and also one of platform predictability that the ASP.NET, or Windows Forms teams do not and should not ship a full major-version revision of their bits every year. They shipped Whidbey (2.0) in late 2005 and hence it's healthy for them to have boarded the scheduled-to-arrive-in-2007 boat heading to Orcas. We (the "WinFX" teams) subscribed to the Vista ship docking later this year and we bring great innovation which will be preinstalled on every copy of it. LINQ as well as VB9 and C# incorporating it on a language-level are very obviously Visual Studio bound and hence they are on the Orcas ferry as well. The .NET Framework is a steadily growing development platform that spans technologies from the Developer Division, Connected Systems, Windows Server, Windows Client, SQL Server, and other groups, and my gut feeling is that it will become the norm that it will be extended off-cycle from the Developer Division's Visual Studio and CLR releases. Whenever a big ship docks in the port, may it be Office, SQL, BizTalk, Windows Server, or Windows Client, and as more and more of the still-unmanaged Win32/Win64 surface area gets wrapped, augmented or replaced by managed-code APIs over time and entirely new things are added, there might be bits that fit into and update the Framework.
So one sane way to think about the .NET Framework version number is that it merely labels the overall package and not the individual assemblies and components included within it. Up to 2.0 everything was pretty synchronized, but given the ever-increasing scale of the thing, it's good to think of that being a lucky (even if intended) coindicence of scheduling. This surely isn't the first time that packages were versioned independently of their components. There was and is no reason for the ASP.NET team to gratuitously recompile their existing bits with a new version number just to have the GAC look pretty and to create the illusion that everything is new - and to break Visual Studio compatibility in the process.
Of course, once we cover 100% of the Win32 surface area, we can rename it all into WinFX again  (just kidding)
[All the usual "personal opinion" disclaimers apply to this post]
Update: Removed reference to "Win64".
I've been quoted as to have said so at TechEd and I'll happily repeat it: "XML is the assembly language of Web 2.0", even though some (and likely some more) disagree. James Speer writes "Besides, Assembly Language is hard, XML isn’t." , which I have to disagree with.
True, throwing together some angle brackets isn't the hardest thing in the world, but beating things into the right shape is hard and probably even harder than in assembly. Yes, one can totally, after immersing oneself in the intricacies of Schema, write complex types and ponder for days and months about the right use of attributes and elements. It's absolutely within reach for a WSDL zealot to code up messages, portTypes and operations by hand. But please, if you think that's the right way to do things, I also demand that you write and apply your security policy in angle bracket notation from the top of your head and generate WCF config from that using svcutil instead of just throwing a binding together, because XML is so easy. Oh? Too hard? Well, it turns out that except for our developers and testers who are focusing on getting these mappings right, nobody on our product team would probably ever even want to try writing such a beast by hand for any code that sits above the deep-down guts of our stack. This isn't the fault of the specifications (or people here being ignorant), but it's a function of security being hard and the related metadata being complex. Similar things, even though the complexity isn't quite as extreme there, can be said about the other extensions to the policy framework such as WS-RM Policy or those for WS-AT.
As we're getting to the point where full range of functionality covered by WS-* specifications is due to hit the mainstream by us releasing WCF and our valued competitors releasing their respective implementations, hand-crafted contracts will become increasingly meaningless, because it's beyond the capacity of anyone whose job it is to build solutions for their customers to write complete set of contracts that not only ensures simple data interop but also protocol interop. Just as there were days that all you needed was assembly and INT21h to write a DOS program (yikes) or knowledge of "C" alongside stdio.h and fellows to write anything for everthing, things are changing now in the same way in Web Services land. Command of XSD and WSDL is no longer sufficient, all the other stuff is just as important to make things work.
Our WCF [DataContract] doesn't support attributes. That's a deliberate choice because we want to enforce simplicity and enhance interoperability of schemas. We put an abstraction over XSD and limit the control over it, because we want to simplify the stuff that goes across the wire. We certainly allow everyone to use the XmlSerializer with all of it's attribute based fine-grained control over schema, even though there are quite a few Schema constructs that even that doesn't support when building schema from such metadata. If you choose to, you can just ignore all of our serialization magic and fiddle with the XML Infoset outright and supply your own schema. However, XML and Schema are specifications that everyone and their dog wanted to get features into and Schema is hopelessly overengineered. Ever since we all (the industry, not only MS) boarded the SOAP/WS train, we're debating how to constrain the features of that monster to a reasonable subset that makes sense and the debate doesn't want to end.
James writes that he "take[s] a lot of care in terms of elements vs. attributes and mak[es] sure the structure of the XML is business-document-like", which only really makes sense if XML documents used in WS scenarios were meant for immediate human consumption, which they're not.
We want to promote a model that is simple and consistent to serialize to and from on any platform and that things like the differentiation between attributes and elements doesn't stand in the way of allowing a 1:1 mapping into alternate, non-XML serialization formats such as JSON or what-have-you (most of which don't care about that sort of differentiation). James' statement about "business-document-like" structures is also interesting considering EDIFACT, X.12 or SWIFT, all of which only know records, fields and values, and don't care about that sort of subtle element/attribute differentation, either. (Yes, no of those might be "hip" any more, but they are implemented and power a considerable chunk of the world economy's data exchange).
By now, XML is the foundation for everything that happens on the web, and I surely don't want to have it go away. But have arrived at the point where matters have gotten so complicated that a layer of abstraction over pretty much all things XML has become a necessity for everyone who makes their money building customer solutions and not by teaching or writing about XML. In my last session at TechEd, I asked a room of about 200 people "Who of you hand-writes XSLT transforms?" 4 hands. "Who of you used to hand-write XSLT transforms?" 40+ hands. I think it's safe to assume that a bunch of those folks who have sworn off masochism and no longer hand-code XSLT are now using tools like the BizTalk Mapper or Altova's MapForce, which means that XSL/T is alive and kicking, but only downstairs in the basement. However, the abstractions that these tools provide also allow bypassing XSLT altogether and generate the transformation logic straight into compiled C++, Java, or C# code, which is what MapForce offers. WSDL is already walking down that path.
A lot of people loved the party location choice for this year's TechEd: Boston's Fenway Park. For anyone even less familiar with the sport that is so American that the Americans run the World Championship every year without even bothering to ask anybody not from North America whether they'd be willing to participate in it: Fenway Park is the home of the Boston Red Sox Baseball team.
Anyways ... I felt like an Atheist in the Vatican. Even though I've already lived in New York for two years, which might be the best place to come as an foreigner if you want to be opportunistic and adopt a local team as your favorite (however, Steve Forte, a big Mets fan would not speak to me if I'd root for the Yankees) I couldn't bring up a lot of interest for the sport and I doubt that that will change a lot in Seattle where I'll move some time this summer. The Green Monster meant nothing to me ("How can you not know about it!?"), sitting the visitor's dugout didn't do much for me, and so on. I mean, my only distant relationship to Baseball is that I am battling for a higher search rank on Live, Yahoo and Google with baseball super-star Roger Clemens. The concert with the band Train was very cool.
Now, I hear that there are discussions about getting rid of Fenway Park for a new stadium, and given that it is obviously such a historical site, I hope it's spared the fate of my home town Mönchengladbach's Bökelbergstadion, home of my team Borussia (Wikipedia) and the site of 5 German Bundesliga championships, which was recently replaced with the (great!) new stadium Borussia-Park. (To turn things around, I wouldn't forgive Forte if he rooted for Bayern).
While I am at it: Great performance yesterday at the wild Italy-USA 1:1 World Cup game by our Borussia goalie Kasey "The Wall" Keller.
Wow. I am so happy to be back home. Not because of TechEd, but because of the Football (sic!) World Cup TV coverage over in the U.S. (luckily I have my TV everywhere solution which made it less of a problem). I wholeheartedly agree with comments around the web on how bad the commentators are. They have no idea of the game, keep chatting and chatting and chatting cluelessly without giving anyone a break. Seems they are paid by words spoken. Adding to the misery are the annoying black score and advertising bars and the news scroll on the bottom of the screen on ESPN2 and occasional huge graphics inserts that obscure a third of the screen -- and the game.
Of course, if NBC had the rights, they would - if the experience with the Olympic Games coverage on their network were any indicator - show all games with a 3 hour time delay and only in a 20 minute summary and would add 60 minutes of reports about how the players have overcome hardships like smelly feet, great-grandma's untimely departure 5 months before the games, the common cold or maybe even Ebola.
empox v. (ĕm-pŏks)
1. The act of adding POX endpoints to an application.
My first of two sessions this week here at TechEd is on Thursday, at 2:45pm in room 153ABC on "Designing Bindings and Contracts".
I realize that the title sounds a bit abstract and a different way to put this would be "How to choose the correct bindings and what to consider about contracts in a variety of architectual scenarios", but that would have been a bit long as a title. in the talk I'll explain the system-defined bindings that we ship in the product so that we've got stuff to work with and then I'll get out the tablet pen and draw up a bunch of scenarios and how our bindings (read: communication options) make sense in those. What's the best choice for N-Tier inside and outside of the corporate perimeter, what do you do for queueing-style apps, how do you implement volatile or durable 1:1 pub/sub, how do you implement broadcasts and where do they make sense, etc.
We've just released the "Windows Communication Foundation RSS Toolkit" on our new community site. This toolkit, which comes with complete source code, illustrates how to expose ATOM and RSS feeds through WCF endpoints. I will discuss the toolkit in my session CON339, Room 107ABC, Friday 10:45am here at TechEd.
Just so that you know: In addition to the regular breakout sessions, we have a number of interactive chalk talks scheduled here at the Connected Systems Technical Learning Center in the Expo Hall. Come by.
This is my first TechEd! - as a Microsoft employee. It's of course not my first tech event in my new job (Egypt, Jordan, UK, France, Switzerland, Holland, Belgium, Denmark, Las Vegas/USA, Slovenia, and Israel are on the year-to-date list - on top of three long-distance commutes to Redmond), but the big TechEds are always special. It'll be fun. Come by the Connected Systems area in the exhibition hall and find me to chat if you are here in Boston.
Frankly, I didn't expect a Sunday night keynote to be nearly as well attended as it was, but it looks that experiment mostly worked. The theme of the keynote were Microsoft's 4 Core Promises for IT Pros and Developers nicely wrapped into a video story based on the TV show "24" and with that show's IT superwoman Chloe O'Brian (actress Mary Lynn Rajskub) up on stage with Bob Muglia (our team's VP far up above in my chain of command), who acted as the MC for the show. Finally we got an apology from a Hollywood character for all the IT idiocy the put up on screen. Thanks, Chloe.
Our team has a lot of very cool stuff to talk about at this show. The first highlight is John Justice's WCF Intro talk (Session CON208, Room 157ABC) today at 5:00pm with a "meet the team" panel Q&A session at the end. Block the time.
Late last night, my colleague James Conard, who has worked and worked and worked tirelessly on this for the past few months and has shown great patience with a big group of people pulling into all sorts of directions as we got this together has flipped the switch to turn on the new .NET Framework 3.0 community portal family at netfx3.com
The new Windows Communication Foundation community home is at http://wcf.netfx3.com and it's a great improvement over the small, hastily-thown-together site that we used to have. There'll be a number of news bits and announcements throughout and after TechEd at the new site, so it might be a good idea to subscribe to the feed now.
My official "Welcome!" post over on the new site is here, the James' site-wide welcome message can be found here.
|