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 cover 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