Biff's 2005 PDC Newsletter

Technical Content of this issue - 4.5 out of 5

All the Seats in the Building are Up

Once again I am struck by how much the PDC is a dude-fest. I would the attendees are probably 99% male - this is a much higher percentage than I have experienced in the industry. On the other hand, this is one large gathering where there isn't a line for the Women's room.

Close Captioning

Very interesting addition to the General Sessions this year. The presentations are all close-captioned real-time on the big screen. The fact that they can be transcribed so quickly is just amazing to me, but it is funny to see what comes up for various computer terms. The other day we learned about "Pier to Pier" communications - I always thought that was a boat. If I were on the stage I would work in the words "Renaissance" and "Deuteronomy" just to see what came out.

Los Angeles Convention Center

Readers of 2003 newsletter will remember that I was pretty critical of the LA Convention Center as the host of the PDC. Many of the issues have improved, and I was much happier with the facility this year-

First - Microsoft made much better use of the facility this year. They converted several big halls that were dedicated to things like the hands-on lab and made them breakout rooms for the big draw topics. Full sessions have been much less of a problem this year. Also, the grouping of everything thing of general interest (The MSFT store, the exhibit hall, the Hands on Labs, public PCs, dining and the track lounges in one big room (labelled "The Big Room" - go figure!), has worked out really well.
Second - The food has been much better. The meals have all be excellent (so far), and the munchies in the hallways more than sufficient. Still not the level of the free Starbuck's Frapacino's and Twinkies in Denver and Orlando, but pretty darn good. Hmmmm - Twinkies...
Third - The CC staff is excellent, they are beyond polite to downright friendly and everything seems to be happening very efficiently.

Presentation and Designer Fans

If you're looking for info on Windows Presentation Foundation and the cool new designer tools, I'm afraid I haven't been alot of help as I have focused on other things. Fortunately, Pete Brown of Applied Information Sciences (free plug) is interested in these topics and has covered their introduction at this conference in his blog.

General Session

This morning was the last, and shortest general session. The usual pattern of these is that each day you get fewer big announcements and lower and lower level officials from Microsoft (starting from Bill Gates and working downward). Being that this was the third day and everything that had been leaked to me had already been announced, I didn't bother to attend. I heard a rumor that the session consisted of a Microsoft intern introducing the new vacation policy.

Seriously, the speaker was Bob Muglia, Senior VP, discussing the next three years of the Windows platform. The part about my skipping the session was true, though. Dmytro went, he said it was pretty good. To get more info, email him at dmytro.dolgopolov@nasd.com - he won't mind.

Breakout Session - Deep Dive Into Best Practices in WCF

This session covered 10 (base 7) practices when using WCF. BTW - The base 7 gag is his, not mine, although I wish I'd thought of it - it is wonderfully geeky. The presenter was pretty good, with a very mellow presentation style, augmented by nice jokes such as this one and a reference to "No Soup For You" - nice session.

1 - Choose a binding that fits your needs

Indigo ships with a collection of Bindings, Interoperable (HTTP based, etc.) and WCF to WCF (Msmq, NamedPipes, TCP, Peer to Peer, etc.). Your choice should be based on Interoperability requirements, performance needs, security needs, etc. For instance, if you need tremendous speed in a non-interop manner, NamedPipes might be your call. Bindings are controlled via app configuration (XML), and you can assign multiple bindings to service multiple clients.

2 - Stay Flexible with Config

Whenever possible, especially in an enterprise scenario, use configuration to define deployment whenever possible (addresses, bindings, etc.) This gives you the greatest degree of flexibility to accomodate changes, whether planned (dev to QC to Prod) or unplanned (we're having another tech refresh?). If you have firm requirements for certain aspects (eg - the security policy is set and should not be changes), that can be locked down in code.

3 - Send Faults, not Exceptions

Throwing exceptions can expose your implementation details, whereas faults are defined at the contract level and should be sent at the business level, not implementation. WCF makes it simple to create custom faults - I can vouch for this as this was one of the tasks in the Hands-On lab that I completed.

4 - Avoid UI Threading Contracts

Windows forms and WPF use the main thread for updates, but WCF services use the main program thread for processing requests - uh-oh! If you host a WCF service in a Windows Forms of WPF app, you'll need to be careful. He did do a demo of how the problem manifests itself, then updated the code to start the code the does the processing on a different thread, only to invoke the final return by marshalling it over to the main thread at the last possible instant. This worked pretty well. It is such a common situation that they actually created an attribute that handles this thread trickery automatically.

5 - Use UDDI Internally

I was non-plussed by this when he put it on the screen - I've never been a UDDI fan, I always thought it was over-hyped and no-one was going to trust a web service they found on the Net from some white pages of services. His claim is that these are gaining traction within Enterprises and very usefule whenever you need a layer of indirection between your app and a web service. This helps to switch clients from using dev to test to production. This sounded interesting, I might have to rethink the technology for this situation. Also, at NASD we are currently working to get a Java client accessing a .NET web service we have out there and we are accomplishing that by giving them the URL and they are getting the WSDL with the ?WSDL tag - this may not be optimal if we reach the point where we have dozens of services at NASD (we're already up to over a dozen I can think of off the top of my head).

6 - Go beyond XML Interoperability

His point is that when defining the contract, think about more than the "XML goo" compatibility aspect of the contrat. Is your client going to have decent coding experience? Sure, a .NET dataset is going to be converted to XML, but a Java client is going to be pretty pissed off if he or she has to parse all the XML extras in the XML generated by a dataset. Use typed, self-contained complex types. He suggests avoiding <xsd:AnyType /> and <xsd:Choice />, I've heard Don Box imply otherwise when it comes to AnyType.

7 - Plan the details of your Service Lifecycles

Know the session lifetime of your channel (HTTP - One Operation, TCP - Connection, MSMQ - One Operation). When you need session lifetime, turn on Reliable Sessions - this is as simple as adding a config tab in the app.config file. You can gain finer-grained control with attributes IsInitiatiing and IsTerminating - defining code that will happen at these stages of the lifecycle. There are several settings (controlled by attributes) for how instances of your session will be created - Per Call (no state), Private (state with session scope), shared (state shared across sessions) and Singleton (a single session and state shared by all).

Breakout Session - Windows Sharepoint Services: Developing Custom Workflows

Wow, this one appeared to be custom scheduled for me, and I almost missed it. I was watching my laptop battery charge (what a glamourous life) outside an about to begin session on Debugging and Managing Web Applications when I saw this session on the track list. Of course this meant I had to pack everything up and hightail it to the other end of the Convention Center, but there is no limit to what I am willing to do for you, dear readers. It was listed as a 400 level (highly technical) session. Although it was interesting and somewhat informative, it was really only about a 300 level session.

There are a number of out-of-the-box solutions that will come out with WWF, such as Routing & Approval, Tracking Applications, List Moderation and Document Expiration. FrontPage provides the next level of support with the ability of knowledge workers to create flows. Visual Studio and the SDK allow developers to build flows, as well as custom activities that would be exposed in FrontPage for knowledge workers to utilize. This then begs yesterday's question about what space is left for K2.NET?

The workflow hosting in Sharepoint uses existing Sharepoint artifacts and repositories to provide the neccessary functionality needed from a host, such as SP tasks, lists, etc.

Office 12 apps can begin a workflow from within the authoring application (fancy term for Word, Excel, etc.) The browser can be used to track and administer tasks and flows. Outlook is used for task notification and task completion (if you Outlook 12 on desktops, steps can be executed directly in Outlook to speed things along).

The first quick demo was assigning a workflow to a document library. Once configured by admin, became an option in Word from menus - user started workflow, then was prompted to assigned a reviewer list and add short comment. The reviewers were then notified with Outlook and completed their assigned task in Word. It was pretty cool.

There are two authoring tools to create WWF workflows in Sharepoint-

FrontPage - This is the "easy designer," suited for no-code workflows that can be created by non-developers. It is limited to activities already deployed on a SP server, the flow being designed via an included Workflow Designer. The tool will verify workflows and handle deployment to a Sharepoint Server (or maybe an Office Server, that wasn't completely clear to me). FrontPage is not allowed to deploy any assemblies on the server (for security reasons), but the info created within FrontPage is uploaded and the workflow is code generated on the server automatically. At one point they showed a list of 23 out-of-box, genereal purpose activities available to FrontPage workflow developers.
Visual Studio - Developers using Visual Studio can make more sophisticated flows, creating custom forms (in ASPX), writing custom activities and utilizing more flexible flow control. There is a specific namespace/assembly (Microsoft.Sharepoint.Workflow) created to facilitate writing activities and workflows for Sharepoint. Once you have completed your workflow, the resulting assembly is deployed to the Sharepoint server, with the specific details of the workflow being defined for Sharepoint via an XML file called a Manifest.

When you need UI for your workflow you can create forms. ASPX forms give you more power, but are harder to create and usually require a developer. They also can't show up in Office tools such as Outlook 12. InfoPath forms are easier to build and can be displayed inside the Office tools such as Outlook, but don't provide the power or functionality available with ASPX.

Breakout Session - WCF: Web Services Interoperablity with Web Services J2EE*

OK, here's a session for Larry and Doug! Greetings from sunny LA guys!

This was the first session where there were significant space issues - the room held 400 people, and it looked like about 500 wanted it. At around 450 they cut it off and the rest had to watch the monitor in the hallway.

Simon Guest, the presenter, had a terrible cough going into the session and finally gave up and asked the crowd if there was a doctor in the house. At this point, his co-presenter came up out of the crowd wearing a doctor's costume and set up the premise of the talk around interactions between health care systems, keeping up the concept of doctor and patient throughout the course of the talk. The concept was thin and the acting was lame, but it was a break from the ordinary and I thought that having a theme for the technical discussions actually worked out pretty well. All the demos for the talk centered around health care operations that were required to "heal" Simon.

The first demo was a request for Simon's medical records. In the scenario, Dr. WCF (the other presenter) had a Windows system and needed to request Simon's records from the system of Dr. Java (hey, I didn't write this stuff). Beyond showing that WCF could call a web service written on BEA's WebLogic server (at this point, that's not really news), it also showed a new type of project available for the Visual Studio wizard - guidances (I think). In this case they created a new HL7 project - HL7 us a standard health care collaboration taxonomy and protocol). By starting with this project, they automatically got XML schema that could be used to define the contracts for interacting with Dr. Java. There looked to be several other such standards in the guidance list as well. Note that all calls in this demo and the rest were protected by WS-Security.

Second, Dr. WCF wanted to request a copy of an xray of Simon, stored as an image on an Apache Axis 2.0 web server based system.. As this would require binary data transfer, that was the center of the discussion. The straw man solutions they put up to tear down were-

base64Binary - although an early standard, this method adds extra size and extra processing to the transfer and is not efficient.
SwA - SOAP with attachments. This solution isn't really standard yet, splitting popularity with DIME (below). It also keeps the the attachment separate from the SOAP package.
DIME - Direct Internet Message Encapsulation. This solution suffers from exactly the same drawbacks as SwA.

Enter MTOM - Message Transmission Optimization Mechanism. This is the new emerging standard. This includes the binary Information into the SOAP message and is rapidly gaining acceptance. Here's a sampling of current support-

Apache
gSOAP
WSE 3.0 B1
WCF B1
Sun
WhiteMesa
BEA
IBM

They took a moment here to discuss the Java side of the interaction - Eclipse was actually shown on the big screen! They delved into the Java code pertaining to the communication, but I'm not going into detail on the Java code here - I do have some standards!

The last thing they did was hook Simon up to an Oximeter to monitor his oxygen level and heart rate. Through this they could show WCF interacting with a piece of hardware as well as exercise WS-Reliable Messaging. With a health machine such as this, reliability is a key. In WS-Reliable Messaging, essentially there is an open session and each message must get an ack. If no ack is received then the message is resent. A very cool demo showed that WS-Reliable Messaging could be introduced to the WCF app merely by changing the configuration information. Simon appeared to be pretty nervous during the presentation - his heart rate was up around 130 and climbed to about 145 when the Java graphing app (written in Swing) wouldn't work. Turns out that the scale on the Java app display only went to 90 and his rate was literally off the scale.

WS-Reliable Messaging supported by-

WCF B1
IBM ETTK - Alpha works
BEA Weblogic
Cape Clear
Systinet
Blue Titan
Apache Axis 1.3 Sandesha
Sonic
Tibco

This concludes today's extended interoperability moment.

*Today's Interoperablity Moment!

Workflow + Messaging + Services: Developing Distributed Applications with Workflows

This was my first chance to catch a Don Box session at this year's PDC. As the crowd filed in, the atmosphere was electric, almost like a rock concert. Several developers were throwing their room keys at the stage. I heard people around me commenting "I hear he comes out of the ceiling!" "I hear he spits blood at the end of the show!" Jon Landau was heard to say "I have seen the future of technology presentations and its name is Don Box."

OK, maybe that's overkill, but there were alot of people there. Free subscription to next year's newsletter for anyone who can fill in the real name in the Jon Landau quote.

Don's presentation was excellent as always, well structured, entertaining and informative. I didn't spend much time taking notes as it would be tough to really do the talk justice, but I did jot down a couple of statements he made that I found interesting. First, he asserted that "all distributed apps had to connect by passing messages. Anything else is brittle, is fragile and impossible to scale." I'm not going to try to explain or support, I'll just let you consider the implications of his statements on your own.

Second, he laid out some qualities of workflow enabled services. He stressed repeatedly that he was not claiming these to be absolute truths or tenets of workflow (see TFTOSOA), just guidelines that they used around the office when talking workflow. "Do not blog these, I don't want to see them on a T-Shirt tomorrow." Since this is a newsletter and not a blog, I figure I'm in the clear.

Workflow enabled services are (potentially long running) transparent processes
Transparency enables visibility into the state off the aggregate system
Transparency is necessary (but not sufficient) to enable post-deployment modification of process definition.

Wow - deep stuff, kind like a Rush lyric (see pop music - early 80's). Again, I will leave it for you to ponder, perhaps while you enjoy your favorite adult beverage and listen to Pink Floyd (the really early stuff - like Meddle).

Biff's PDC Mailbag

SC from NJ writes - "Why not a blog? Why no Bags? Why no power? Why me not there?"

SC - I can't definitively answer that last one, but if that is the presentation style you used when you floated the idea to your boss then I might have an idea why you're not here.

Tomorrow

The PDC concludes, Biff covers 2 or 3 more sessions and crams in all the gags that he hasn't had room for so far. Sometime he takes the opportunity to bloviate in his annual editorial.

Biff
Organizer, Office of Birthday Parties, Biff's PDC Newsletter