Here's a short video explaining where I’m at now (here’s a map) and what I’m up to. Meanwhile I’ve also figured out how to put sound on both channels with the setup that I have, but here it’s still just on the left channel and also doesn’t sound as good as it should as I don’t have all the white-noise correcting Jedi motions mastered.  

Spoiler: I’ll start doing a video show on a regular basis and need input for content planning, so if you have any ideas, don’t hesitate to send me email or Tweet me at @clemensv.

This session explains how to secure Service Bus using the Access Control Service. This is also an extension session for my session at BUILD, but watching the BUILD session is not a strict prerequisite.

This session is a followup to the Service Bus session that I did at the build conference and explains advanced usage patterns:

Room 398, Tuesday June 8
3:15pm-4:30pm

Session Type: Breakout Session
Track: Application Server & Infrastructure
Speaker(s): Maggie Myslinska
Level: 200 – Intermediate

Come learn how to use Windows Azure AppFabric (with Service Bus and Access Control) as building block services for Web-based and hosted applications, and how developers can leverage services to create applications in the cloud and connect them with on-premises systems.

If you are planning on seeing Juval’s and my talk ASI304 at TechEd and/or if you need to know more about how Windows Azure AppFabric enables federated cloud/on-premise applications and a range of other scenarios, you should definitely put Maggie’s talk onto your TechEd schedule as well. 

Room 265, Thursday June 10
9:45AM – 11:00 AM

Session Type: Breakout Session
Track: Application Server & Infrastructure
Speaker(s): Clemens Vasters, Juval Lowy
Level: 300 - Advanced

The availability of the Service Bus in Windows Azure AppFabric is disruptive since it enables new design and deployment patterns that are simply inconceivable without it, opening new horizons for architecture, integration, interoperability, deployment, and productivity. In this unique session organized especially for Tech·Ed, Clemens Vasters and Juval Lowy share their perspective, techniques, helper classes, insight, and expertise in architecting solutions using the service bus. Learn how to manage discrete events, how to achieve structured programming over the Service Bus buffers, what options you have for discovery and even how to mimic WCF discovery, what are the recommended options for transfer security and application authentication, and how to use AppFabric Service Bus for tunneling for diagnostics or logging, to enabling edge devices. The session ends with a glimpse at what is in store for the next versions of the service bus and the future patterns.

Yes, that's Juval and myself on the same stage. That'll be interesting. 

I put the slides for my talks at NT Konferenca 2010 on SkyDrive. The major difference from my APAC slides is that I had to put compute and storage into one deck due to the conference schedule, but instead of purely consolidating and cutting down the slide count,  I also incorporated some common patterns coming out from debates in Asia and added slides on predictable and dynamic scaling as well as on multitenancy. Sadly, I need to rush through all that in 45 minutes today.

I'm on a tour through several countries right now and I'm talking to ISVs about the Windows Azure platform, its capabilities and the many opportunities ISVs have to transform the way they do business by moving to the cloud. The first day of the events is an introduction to the platform at the capability level; it's not a coding class, that would be impossible to fit.

I've shared the slides on SkyDrive. Steal liberally if you find the material useful.

At the bottom of this post you’ll find the DinnerNow version that I’ve been using for my PDC09 talk. The video of that talk is now available at http://microsoftpdc.com/Sessions/SVC18 and I recommend that you listen to the talk for context.

The DinnerNow drop I’m sharing here is a customized version of the DinnerNow 3.1 version that’s up on CodePlex. If I were you, I’d install the original version and then unpack my zip file alongside of it and then use some kind of diff tool (the Windows SDK’s WinDiff tool is a start) to look at the differences between the versions. That will give you a raw overview of what I had to do. You’ll find that I had to add and move a few things, but that the app didn’t change in any radical way.

Remember that looking at the code is more important that making it run. There’s one particular challenge you’d have right now with the Windows Azure CTP and that’s getting the two (!) Windows Azure compute tokens needed for separating out the web and the service tier as I’ve done here. It’s not difficult to consolidate the Web and the Web Service tier into a single role, but since I had to do the migration within a short period of time, I chose to split them up.

FWIW, I time-boxed the migration to 3 work days – which included learning about what our buddies over in SQL Azure had done in the past months — and that turned out to be a comfortable fit in terms of time.

Another function of time-boxing is that you’re finding me disabling security on most endpoints, including disabling the Access Control integration with Service Bus for most endpoints by setting the relayClientAuthenticationType attribute on the respective binding elements to None.

I know that’s a sin, but I didn’t want to cause too much churn in the first iteration. The original version of DinnerNow is conveniently using Windows authentication/authorization for its communication paths. While that’s ok for a LAN setup, things get more complicated for an actual WAN setup that the DinnerNow scenario calls for. That would spawn a wholly different discussion that shines the spotlight on our Access Control service and why it’s useful – even required – for that scenario. In order not to overwhelm everyone, I left that out for this round and will revisit that aspect in the next weeks – or maybe one of our (aspiring?) MVPs or RDs will beat me to it.

I’m also going to work with the guys who wrote DinnerNow to find a way to host this modified version of Dinner Now with the on-premise runtime bits expressly not on my primary dev machine, where they’d live now.

Here what you need to do to get it to run

I know this is rough. Writing up the long version of this is going to take some time and I prefer getting the bits to you early over me sitting here writing pages of docs. Maybe you can even help ;-)

1. First, you’ll need to go to the Windows Azure portal and get the SDKs and tokens/accounts. The Getting Started page has all the data and links you need so I’m not going to repeat them here in much detail. You will need at least one Windows Azure compute account (apply here), one SQL Azure account (apply here), and an AppFabric account (no application needed, just log in w/ LiveID). 
2. Download and install the regular version DinnerNow 3.1 from Codeplex. This will drop a “Configure DinnerNow 3.1” shortcut on your desktop. Run that, install all prerequisites and make sure DinnerNow runs locally before you proceed.
3. You will later need the databases that the setup created in your local SQLEXPRESS instance by setup. You’ll have to make a few changes, though.
   1. First, (download, install, and) open SQL Server Management Studio, connect to your SQL Server Express instance and switch to “SQL Server and Windows Authentication mode” on the Server Properties under Security. Then you’ll need to go to to the Security settings and either create a new account and grant it all rights on the aspnetdb database or just enable the ‘sa’ account and set its password. 
   2. Then you need to find the “SQL Server Configuration Manager” and enable TCP for your SQLEXPRESS instance like this. The default port will be 1433. If you have a full SQL Server instance on your dev machine and it’s configured for TCP the easiest is to suspend that for the moment and allow the SQLEXPRESS instance to squat the port.
4. Unpack the ZIP file appended below into a directory on your machine. At this point it should be ok to override the existing DinnerNow directory, but I’d keep things side-by-side for reference. If you copy side-by-side, grab the ./solution/DinnerNow – Web/DinnerNow.WebUX/images/’ directory from your local installation and copy it into the location where you unzipped the file here. I left out the images due to their size. And just as with the normal DinnerNow installation you’ll find a solution file named “DinnerNow  - Main.sln” in the unpacked directory – open that in Visual Studio 2008 (not 2010!) because you’ll have to make some changes and edits.
5. If you are lucky enough to have two Windows Azure compute accounts, you can skip this step. Otherwise, you will have to restructure the application a bit: 
   1. In the “DinnerNow – WA” solution branch where the Windows Azure deployment project reside you’ll have to consolidate the DinnerNow.WindowsAzure project and the DinnerNow.WindowsAzureAppSrv projects into one by replicating the DinnerNow.DBBridge reference into the DinnerNow.WindowsAzure project and abandoning/deleting the rest.
   2. In the “DinnerNow – Web” solution branch you will have to modify the DinnerNow.WebUX project by merging the DinnerNow.ServiceHost project from the “DinnerNow -ServicePortfolio2” branch into it, including merging the config files. In the original DinnerNow the hosting default is that the ServiceHost  project lives in the ./services subdirectory of the WebUX app. You can also do it that way, but you’ll have to change the respective client URIs to point to the right path.
6. In the ./database directory is a file called SQLAzureImport.sql. That’s the exported and customized script for the DinnerNow restaurants and menus database. Create a new database (1GB is enough) and load the DB with this script. You can do this with the command line or with SQL Management Studio. The SQL Azure docs will tell you how.
7. Now you’ll need to do a range of search/replace steps across the whole project. These are mostly in *.config files - a few places are in the code, which I count as bugs, but those are faithfully carried over from the original:
   1. Find all occurrences of sqlazure-instance and replace them with your unqualified SQL Azure server name (might look like this: tn0a1b2c3d)
   2. Find all occurrences of sqlazure-dbname and replace them with your SQL Azure database name
   3. Find all occurrences of sqlazure-acct and replace them with your SQL Azure administrator username
   4. Find all occurrences of sqlazure-password and replace them with your SQL Azure administrator password
   5. Find all occurrences of appfabricservicebus-ns and replace them with your unqualified AppFabric namespace name
   6. Find all occurrences of appfabricservicebus-key and replace them with your AppFabric Service Busissuer key
   7. Find all occurrences of windowsazuresvcrole-acct and replace them with the name of your Windows Azure compute account. If you have just one, use that (given you’ve done the rework in step 4), if you have two use the account-name where you will host the service tier.
   8. Find all occurrences of sqlserver-password and replace them with your localSQL Server Express instance’s ‘sa’ account password.
8. Do a full batch Rebuild of the whole project
9. Go to the “DinnerNow –WA” solution and publish the project(s) to your Windows Azure compute account(s). If you had to consolidate them you’ll have one package to deploy, if you left things as they are you’ll have two packages to deploy. You can also run these packages in the local DevFabric to test things out.
10. The executables you need to run are going to be dropped into the .\bin directory by the build. You need to run all 6 apps – but you could run them on 6 different machines – the two workflow hosts each assume the local presence of the DinnerNowWF database:
    1. CloudTraceRecorder.exe – this is the simple event listener app. You can run this right away to observe the apps starting up inside of Azure as they write events to the event listener. You can and should run this as you deploy. You can run any number of instances of CloudTraceRecorder anywhere.
    2. PortBridge.exe – this is the on-premise bridge-head for bridging to your local SQL Server Express instance so that the cloud application can get at its membership database that you host for it on your machine. After the search/replace steps you will notice that you have modified connection strings that point to a SQL Server role peeking out of your *AppSrv role. The secret ingredient is in the DinnerNow.DBBridge role that’s listening for TCP connections on behalf of your on-premise SQL Server and that connects them down to your local server with the logic in Microsoft.Samples.ServiceBus.Connections. This is the same code that’s in PortBridge.
    3. DinnerNow.OrderProcessingHost.exe is the (new) host application for the workflow that handles the order process.
    4. DinnerNow.RestaurantProcessingHost.exe is the (new) host application for the workflow that handles the restaurant process.
    5. DinnerNowKiosk.exe is the only slightly modified version of the DinnerNow in-restaurant kiosk
    6. Not in .\bin but rather to be started/deployed from VS is the also just slightly modified Windows Mobile app for the delivery app

Please also mind that the DinnerNow Powershell support and the other test and diagnostics capabilities haven’t been touched here, yet.

Oh, and … this is provided as-is … I’ll do my best to discuss some of the patterns over the next several weeks, but I don’t have time to provide 1:1 support.

Here’s the code:

We've got a discussion forum up on MSDN where you can ask questions about Microsoft .NET Services (Service Bus, Workflow, Access Control): http://social.msdn.microsoft.com/Forums/en-US/netservices/threads/

According to recent traffic studies, the BitTorrent protocol is now responsible for roughly half of all Internet traffic. That's a lot of sharing of personal photos, self-sung songs, and home videos. Half! Next to text messaging, Instant Messaging applications are the social lifeline for our teenagers these days – so much that the text messaging and IM lingo is starting to become a natural part of the colloquial vocabulary everywhere. Apple's TV, Microsoft's Xbox 360, and Netflix are shaking up the video rental market by delivering streamed or downloadable high-quality video and streams on YouTube have become the new window on the world. Gamers from around the world are meeting in photorealistic virtual online worlds to compete in races, rake in all the gold, or blast their respective Avatars into tiny little pieces.

What does all of that have to do with Web 2.0? Very little. While it's indisputable that the Web provides the glue between many of those experiences, the majority of all Internet traffic and very many of the most interesting Internet applications depend on bi-directional, peer-to-peer connectivity.

These familiar consumer examples have even more interesting counterparts in the business and industrial space. Industrial machinery has ever increasing remote management capabilities that allow complete remote automation, reprogramming, and reconfiguration. Security and environment surveillance systems depend on thousands of widely distributed, remotely controlled cameras and other sensors that sit on street poles, high up on building walls, or somewhere in the middle of a forest. Terrestrial and satellite-based mobile wireless technologies make it possible to provide some form of digital connectivity to almost any place on Earth, but making an array of devices addressable and reachable so that they can be integrated into and controlled by a federated, distributed business solution that can leverage Internet scale and reach remains incredibly difficult.

The primary obstacle to creating pervasive connectivity is that we have run out of IPv4 addresses. There is no mere threat of running out, we're already done. The IPv4 space is practically saturated and it's really only network address translation (NAT) that permits the Internet to grow any further. The shortage is already causing numerous ISPs to move customers behind NATs and not to provide them with public IP address leases any longer. Getting a static public IP address (let alone a range) is getting really difficult. IPv6 holds the promise of making each device (or even every general-purpose computer) uniquely addressable again, but pervasive IPv6 adoption that doesn't require the use of transitional (and constraining) tunneling protocols will still take many years.

The second major obstacle is security. Since the open network is a fairly dangerous place these days and corporate network environments are often und unfortunately not much better, the use of Firewalls has become ubiquitous and almost all incoming traffic is blocked by default on the majority of computers these days. That's great for keeping the bad guys out, but not so great for everything else – especially not for applications requiring bi-directional connectivity between peers.

Since these constraints are obviously well-known and understood there is a range of workarounds. In home networking environments the firewall and NAT issues are often dealt with by selectively allowing applications to open inbound ports on the local and network router firewalls using technologies like UPnP or by opening and forwarding port by ways of manual configuration. Dynamic DNS services help with making particular machines discoverable even if the assigned IP address keeps changing. The problem with those workarounds is that they realistically only ever work for the simplest home networking scenarios and, if they do work, the resulting security threat situation is quite scary. The reality is that the broadly deployed Internet infrastructure is optimized for the Web: clients make outbound requests, publicly discoverable and reachable servers respond.

If your application requires bi-directional connectivity you effectively have two choices: Either you bet on the available workarounds and live with the consequences (as BitTorrent does) or you build and operate some form of Relay service for your application. A Relay service accepts and maintains connections from firewalled and/or NAT-ed clients and routes messages between them. Practically all chat, instant messaging, video conferencing, VoIP, and multiplayer gaming applications and many other popular Internet applications depend on some form of Relay service.

The challenge with Relay services is that they are incredibly hard to build in a fashion that they can provide Internet scale where they need to route between thousands or even millions of connections as the large Instant Messaging networks do. And once you have a Relay that can support such scale it is incredibly expensive to operate. So expensive in fact that the required investments and the resulting operational costs are entirely out of reach for the vast majority of software companies. The connectivity challenge is a real innovation blocker and represents a significant entry barrier.

The good news is that Microsoft .NET Service Bus provides a range of bidirectional, peer-to-peer connectivity options including relayed communication. You don't have to build your own or run your own; you can use this Building Block instead. The .NET Service Bus covers four logical feature areas: Naming, Registry, Connectivity, and Eventing.

Naming

The Internet's Domain Name System (DNS) is a naming system primarily optimized for assigning names and roles to hosts. The registration records either provide a simple association of names and IP addresses or a more granular association of particular protocol roles (such as identifying domain's mail server) with an IP address. In either case, the resolution of the DNS model occurs at the IP address level and that is very coarse grained. Since it is IP address centric, a DNS registration requires a public IP address. Systems behind NAT can't play. Even though Dynamic DNS services can provide names to systems that do have a public IP address, relying on DNS means for most ISP customers that the entire business site or home is identified by a single DNS host entry with dozens or hundreds of hosts sitting behind the NAT device.

If you want to uniquely name individual hosts behind NATs, differentiate between individual services on hosts, or want to name services based on host-independent criteria such as the name of a user or tenant, the DNS system isn't an ideal fit.

The .NET Service BusNaming system is a forest of (theoretically) infinite-depth, federated naming trees. The Naming system maintains an independent naming tree for each tenant's solution scope and it's up to the application how it wants to shape its tree. 'Solution' is a broad term in this context meant to describe a .NET Service Bus tenant – on the customer side, a Service Bus application scope may map to dozens of different on-site applications and hundreds of application instances.

Any path through the naming tree has a projection that directly maps to a URI.

Let's construct an example to illustrate this: You design a logistics system for a trucking company where you need to route information to service instances at particular sites. The application scope is owned by your client, 'ContosoTrucks' which has a number of logistics centers where they want to deploy the application. Your application is called 'Shipping' and the endpoints through which the shipping orders are received at the individual sites are named 'OrderManagement'. The canonical URI projection of the mapping of New York's order management application endpoint instance into the ServiceBusNaming system is
http://servicebus.windows.net/services/contoso/NewYork/Shipping/OrderManagement/

The significant difference from DNS naming is that the identification of services and endpoints moves from the host portion of the URI to the path portion and becomes entirely host-agnostic. The DNS name identifies the scope and the entry point for accessing the naming tree. That also means that the path portion of the URI represent a potentially broadly distributed federation of services in the Naming service, while the path portion of a 'normal' URI typically designates a collocated set of resources.

There is no immediate access API for the Naming system itself. Instead, access to the Naming system is provided through the overlaid Service Registry.

Service Registry

The Service Registry allows publishing service endpoint references (URIs or WS-Addressing EPRs) into the Naming system and to discover services that have been registered.

The primary access mechanism for the Service Registry is based on the Atom Publishing Protocol (APP) allowing clients to publish URIs or EPRs by sending a simple HTTP PUT request with an Atom 1.0 'item' to any name in the naming tree. It's removed by sending an HTTP DELETE request to the same name. There is no need to explicitly manage names – names are automatically created and deleted as you create or delete service registry entries.

Service discovery is done by navigating the naming hierarchy, which is accessible through a nested tree of Atom 1.0 feeds whose master-feed is located at http://servicebus.windows.net/services/[solution]/. Any publicly registered service is accessible through the feed at the respective location.

In addition to the Atom Publishing Protocol, the Service Registry also supports publishing, accessing, and removing endpoint references using WS-Transfer and the Relay service will automatically manage its endpoints in the Service Registry without requiring any additional steps.

The Service Registry is an area that will see quite significant further additions over the next few milestones including support for service categorization, search across the hierarchy, and support for additional high-fidelity discovery protocols.

Connectivity

The core of the connectivity feature area of the .NET Service Bus is a scalable, general-purpose Relay service. The Relay's communication fabric supports unicast and multicast datagram distribution, connection-oriented bi-directional socket communication and request-response messaging.

Towards listening services the Relay takes on the same role as operating-system provided listeners such as Windows' HTTP.SYS. Instead of listening for HTTP requests locally, a relayed HTTP service establishes an HTTP listener endpoint inside the cloud-based Relay and clients send requests to that cloud-based listener from where they are forwarded to the listening service.

The connection between the listener and the Relay is always initiated from the listener side. In most connection modes (there are some exceptions that we'll get to) the listener initiates a secured outbound TCP socket connection into the Relay, authenticates, and then tells the Relay at which place in the naming tree it wants to start listening and what type of listener should be established.

Since a number of tightly managed networking environments block outbound socket connections and only permit outbound HTTP traffic, the socket based listeners are complemented by an HTTP-based multiplexing polling mechanism that builds on a cloud-based message buffer. In the PDC release the HTTP-based listeners only support the unicast and multicast datagram communication, but bidirectional connectivity is quite easily achievable by pairing two unicast connections with mutually reversed client and listener roles.

A special variation of the bi-directional socket communication mode is 'Direct Connect'. The 'Direct Connect' NAT traversal technology is capable of negotiating direct end-to-end socket connections between arbitrary endpoints even if both endpoints are located behind NAT devices and Firewalls. Using Direct Connect you can start connections through the Relay and 'Direct Connect' will negotiate the most direct possible connectivity route between the two parties and once the route is established the connection will be upgraded to the direct connection – without information loss.

With these connectivity options, the Relay can provide public, bi-directional connectivity to mostly any service irrespective of whether the hosting machine is located behind a NAT or whether the Firewalls layered up towards the public network don't allow inbound traffic. The automatic mapping into the Naming system means that the service also gains a public address and the service can, on demand, be automatically published into the Service Registry to make the service discoverable.

In addition to providing NAT and Firewall traversal and discoverability the delegation of the public network endpoint into the Relay provides a service with a number of additional key advantages that are beneficial even if NAT traversal or discoverability are not a problem you need to solve:

• The Relay functions as a "demilitarized zone" that is isolated from the service's environment and takes on all external network traffic, filtering out unwanted traffic.
• The Relay anonymizes the listener and therefore effectively hides all details about the network location of the listener thus reducing the potential attack surface of the listening service to a minimum.
• The Relay is integrated with the Access Control Service and can require clients to authenticate and be authorized at the Relay before they can connect through to the listening service. This authorization gate is enabled by default for all connections and can be selectively turned off if the application wants to perform its own authentication and authorization.

These points are important to consider in case you are worried about the fact that the Relay service provides Firewall traversal. Firewalls are a means to prevent undesired foreign access to networked resources – the Relay provides a very similar function but does so on an endpoint-by-endpoint basis and provides an authentication and authorization mechanism on the network path as well.

If your applications are already built on the .NET Framework and your services are built using the Windows Communication Foundation (WCF) it's often just a matter of changing your application's configuration settings to have your services listen on the Relay instead on the local machine.

The Microsoft.ServiceBus client framework provides a set of WCF bindings that are very closely aligned with the WCF bindings available in the .NET Framework 3.5. If you are using the NetTcpBinding in your application you switch to the NetTcpRelayBinding, the BasicHttpBinding maps to the BasicHttpRelayBinding, and the WebHttpBinding has its equivalent in the WebHttpRelayBinding. The key difference between the standards WCF bindings and their Relay counterparts is that they establish a listener in the cloud instead of listening locally.

All WS-Security and WS-ReliableMessaging scenarios that are supported by the standard bindings are fully supported through the Relay. Transport-level message protection using HTTPS or SSL-protected TCP connections is supported as well.

If the listener chooses to rely on WS-Security to perform its own authentication and authorization instead of using the security gate built into the Relay, the HTTP-based Relay bindings' policy projection is indeed identical to their respective standard binding counterparts which means that client components can readily use the standard .NET Framework 3.5 bindings (and other WS-* stacks such as Sun Microsystems' Metro Extensions for the Java JAX-WS framework).

If you prefer RESTful services over SOAP services, you can build them on the WebHttpRelayBinding using the WCF Web programming model introduced in the .NET Framework 3.5. The Relay knows how to route SOAP 1.1, SOAP 1.2 messages and arbitrary HTTP requests transparently.

The NetEventRelayBinding doesn't have an exact counterpart in the standard bindings. This binding provides access to the multicast publish/subscribe capability in the Relay. Using this binding, clients act as event publishers and listeners act as subscribers. An event-topic is represented by an agreed-upon name in the naming system. There can be any number of publishers and any number of subscribers that use the respective named rendezvous point in the Relay. Listeners can subscribe independent of whether a publisher currently maintains an open connection and publishers can publish messages irrespective of how many listeners are currently active – including zero. The result is a very easy to use lightweight one-way publish/subscribe event distribution mechanism that doesn't require any particular setup or management.

The discussion of the close alignment between the Relay's .NET programming experience and the standard .NET Framework shouldn't imply that the Relay requires the use of the .NET Framework. Microsoft is working with community partners to provide immediate and native Relay support for the Java and Ruby platforms of which initial releases will be available at or shortly after PDC with more language and platform support lined up in the pipeline.

The Relay provides connectivity options that allow you build bidirectional communication links for peer-to-peer communication, allows making select endpoints securely and publicly reachable without having to open up the Firewall floodgates, and provides a cloud-based pub/sub event bus that permits your application to distribute events at Internet scale. I could start enumerating scenarios at this point, but it seems like a safe bet that you can already think of some.

Find out more here:
http://www.microsoft.com/azure/default.mspx
http://www.microsoft.com/azure/servicebus.mspx

You are in North America and not in Europe? You want more content than what fits into a track at TechEd?

No problem! Just come to the SOA and Business Process Conference that we're running October 29 - November 2 at the Microsoft Conference Center here in Redmond. There'll be lots of very interesting new stuff from teams across our division here at Microsoft. And our boss speaks, too.

If distributed systems and composite applications are your thing, you should be here for that conference. No debating, sign up and come!

Even though the TechEd Europe Developer Website doesn't yet clearly say so, Steve Swartz and myself will "of course!" be back with a new set of Steve & Clemens talks in Barcelona for TechEd Europe Developer (November 5-9). And for the first time we'll stay for another week and also give a talk at TechEd Europe ITForum (November 12-16) this year.

What will we talk about?

Last year we've started with a history lesson, did a broad and mostly technology agnostic overview of distributed systems architecture across 4 talks and closed with a talk that speculated about the future.

This year at the TechEd Developer show, we'll be significantly more concrete and zoom in on the technologies that make up the Microsoft SOA and Business Process platform and show how things are meant to fit together. We'll talk about the rise of declarative programming and composition and how that manifests in the .NET Framework and elsewhere. And as messaging dudes we'll also talk about messaging again. At TechEd ITForum we'll talk about the end-to-end lifecycle of composite applications and how to manage it effectively.

And of course there'll be "futures". Much less handwavy futures than last year, actually.

So .... We'll be in Barcelona for TechEd. You too?

For those of you who couldn't make it to MIX, here are the (Silverlight-) videos of the talks from the Connected Systems Division deep-linked to sessions.visitmix.com

• Don Box, Steve Maine: Navigating the Programmable Web
• Garrett Serack, Mike Jones, Pat Felsted: Enable Windows CardSpace and Information Cards on Your Web Site
• Kim Cameron and Panel: Digital Identity and the Psychology of Security

We love WS-* as much as we do love Web-Style services. I say "Web-style", full knowing that the buzzterm is REST. Since REST is an architectural style and not an implementation technology, it makes sense to make a distinction and, also, claiming complete RESTfulness for a system is actually a pretty high bar to aspire to. So in order to avoid monikers like POX or Lo-REST/Hi-REST, I just call it what it what this is all about to mere mortals whose don't have an advanced degree in HTTP Philosophy: Services that work like the Web - or Web-Style. That's not to say that a Web-Style service cannot be fully RESTful. It surely can be. But if all you want to do is GET to serve up data into mashups and manipulate your backend resources in some other way, that's up to you. Anyways....

Tomorrow at 10:00am (Session DEV03, Room Delfino 4101A), our resident Lo-REST/Hi-REST/POX/Web-Style Program Manager Steve Maine and our Architect Don Box will explain to you how to use the new Web-Style "Programmable Web" features that we're adding to the .NET Framework 3.5 to implement the server magic and the service-client magic to power all the user experience goodness you've seen here at MIX.

Navigating the Programmable Web

Speaker(s): Don Box - Microsoft, Steve Maine

Audience(s): Developer

RSS. ATOM. JSON. POX. REST. WS-*. What are all these terms, and how do they impact the daily life of a developer trying to navigate today’s programmable Web? Join us as we explore how to consume and create Web services using a variety of different formats and protocols. Using popular services (Flickr, GData, and Amazon S3) as case studies, we look at what it takes to program against these services using the Microsoft platform today and how that will change in the future.

The WinFX Tour is coming to Europe!

Mark it in your calendar and, if you can, sign up! Locations: Rotterdam (20 Apr), Nice (25 Apr), Zurich (2 May), Copenhagen (4 May), London (9 May), Eilat/IL (9 May), Reading/UK (10 May), Cairo (15 May), Moscow (19 May)

I'll be speaking at the Zurich, Copenhagen, and Eilat (TechEd Israel) events.

[If the event near you does not have a sign-up page linked, watch your local MSDN portal or MSDN newsletters for updates]

I have been invited to speak at the Denver Visual Studio Usergroup on Monday, March 28th. Because I just happen to be in Denver I am delighted to volunteer and talk about the principles of Service Orientation and how to make it happen for real now (ES, ASMX) and tomorrow (Indigo). Mind that this is after VSLive! and I'll be able to tell things I've been told not to tell.

I feel like I have been "out of business" for a really long time and like I really got nothing done in the past 3 months, even though that's objectively not true. I guess that's "conference & travel withdrawal", because I had tone and tons of bigger events in the first half of the year and 3 smaller events since TechEd Amsterdam in July. On the upside, I am pretty relaxed and have certainly reduced my stress-related health risks ;-)

So with winter and its short days coming up, the other half of my life living a 1/3 around the planet until next spring, I can and am going to spend some serious time on a bunch of things:

On the new programming stuff front:
     Catch up on what has been going on in Indigo in recent months, dig deeper into "everything Whidbey", figure out the CLR aspects of SQL 2005 and familiarize myself with VS Team System.

On the existing programming stuff front:
      Consolidate my "e:\development\*"  directory on my harddrive and pull together all my samples and utilities for Enterprise Services, ASP.NET Web Services and other enterprise-development technologies and create a production-quality library from of them for us and our customers to use. Also, because the Indigo team is doing quite a bit of COM/COM+ replumbing recently in order to have that prohgraming model ride on Indigo, I have some hope that I can now file bugs/wishes against COM+ that might have a chance of being addressed. If that happens and a particular showstopper is getting out of the way, I will reopen this project here and will, at the very least, release it as a toy.

On the architectural stuff front:
         Refine our SOA Workshop material, do quite a bit of additional work on the FABRIQ, evolve the Proseware architecture model, and get some pending projects done. In addition to our own SOA workshops (the next English-language workshop is held December 1-3, 2004 in Düsseldorf), there will be a series of invite-only Microsoft events on Service Orientation throughout Europe this fall/winter, and I am very happy that I will be speaking -- mostly on architecture topics -- at the Microsoft Eastern Mediterranean Developer Conference in Amman/Jordan in November and several other locations in the Middle East early next year. 

And even though I hate the effort around writing books, I am seriously considering to write a book about "Services" in the next months. There's a lot of stuff here on the blog that should really be consolidated into a coherent story and there are lots and lots of considerations and motiviations for decisons I made for FABRIQ and Proseware and other services-related work that I should probably write down in one place. One goal of the book would be to write a pragmatic guide on how to design and build services using currently shipping (!) technologies that does focus on how to get stuff done and not on how to craft new, exotic SOAP headers, how to do WSDL trickery, or do other "cool" but not necessarily practical things. So don't expect a 1200 page monster. 

In addition to the "how to" part, I would also like to incorporate and consolidate other architect's good (and bad) practical design and implementation experiences, and write about adoption accelerators and barriers, and some other aspects that are important to get the service idea past the CFO. That's a great pain point for many people thinking about services today. If you would be interested in contributing experiences (named or unnamed), I certainly would like to know about it.

And I also think about a German-to-English translation and a significant (English) update to my German-language Enterprise Services book.....

[And to preempt the question: No, I don't have a publisher for either project, yet.]

It keeps happening to me and some of my good friends and it's getting to a point where something needs to be said:

Dear Clemens,

we are pleased to announce the YaddaYadda 2004 conference that will be held in Overseas City, Farwaway Country on Octember 24th-27th. We know your great presentation skills .. blah, blah ...

We will cover coach class airfare of up to $500 and will reserve you a room in the speaker hotel where we will cover the overnight stay and breakfast. We will also provide you with a free registration to attend all the sessions of YaddaYadda 2004.

YaddaYadda 2004 is a world-class conference with 40 speakers from 10 countries and we expect an audience of architects, developers and IT-managers from great companies so that we will give you a great platform and exposure to demonstrate your expertise.

Please let us know whether you are interested in speaking at YaddaYadda 2004 and submit your presenentations until ... blah, blah

Best Regards,

YaddaYadda Marketing Droid

The short answer is: No. For several reasons. First of all, YaddaYadda conference is one amongst a hundred conferences held each year in Faraway Country. You are not running a Microsoft TechEd or a Microsoft PDC where I meet a lot of my friends, and you are not running a high-profile academic event that would really interest me, you are running just another developer conference. So we have that out of the way now.

You know that I live in Germany, right? Sure you do. You know my name, you invite me, it should be pretty much public knowledge that I don't live in Faraway Country. So how do you expect me to even dare to talk to a travel agent about a ticket to Faraway Country for $500? Well, right, you say that if I book 12 weeks ahead of time on the cheapest possible connection (with a comfortable 8 hour layover in St. Someairport) I could get a flight for that price. True. Care to have a look at my schedule? I am Norway until 2 days before YaddaYadda 2004 and I need to go to South Africa from there. And as things happen, these dates may move. A tourist ticket that's inflexible and invalid unless I use those exact flights is practically worthless for anybody who needs to be as mobile as us guys (and gals) who are helping you guys out with content. And you know what? My travel agent is so good that he's getting a business class fare on the German gray market that's cheaper than any flexible economy fare that you could ever book from Faraway Country; go figure that out. And you know what? If other speakers decide to drive 20hrs to Overseas City, do you force them to come in a Yugo, too?

The free registration to your conference sounds like a nice benefit, but I'd like to decline that offer and rather trade those $1499 for cash. Of course it'd be a bit difficult for me to get to the session room without a badge, but I am sure you'll figure out how that works.

And just because you say that your conference will give me a great platform and exposure to demonstrate your expertise I suspect (no, I am sure) that you are not paying speakers, right? See, there's an immediate benefit to you and that's me and all the other speakers talking there and adding to the value of your conference. No, sorry, we are the value of your conference. I like to trade immediate benefit against immediate benefit and that usually either translates into $$$ or into something that's a bit more painful for you than giving out "exposure" - let's say a booth or an full page ad in one of your magazines plus a token of appreciation for the talk.

Do you want to know what the value of "exposure" is and how it translates into immediate business opportunities for the speaker? If you are lucky, you get a good lead out of one per 500 attendees (and really lucky if your get two or three) and that doesn't even guarantee a deal yet. How many people did you say will you have at your conference? 450? Sorry. Doesn't translate.

There are many reasons to speak at conferences. Some are just plain fun to be at. Some are great for the parties. Some are fantastic for the money (go figure). For speakers there are many motivations that range from "the kick" to speak in front of 800 people to liking themselves being on stage to actually earning their lives by speaking. Some of the speakers I know got so IPO lucky in 1999 that they're doing it just so and it has nothing at all with their business.

So how about some honesty and saying: We're throwing a conference, we're going to have a raving party at a bar at the beach and many of your best buddies are likely coming too. Minibar in the hotel is on us. Sorry, we can't pay you for speaking, because we're poor and need the money, but we can pay for a reasonable flight ticket and hotel and since we have this hotel deal anyways, why don't you just stay 3 days longer, use your air-miles to upgrade and maybe bring along your girlfriend? Now, YaddaYadda 2004, that'd be a lot more honest and if your location is cool enough I'd even come. Just don't try that exposure argument on me, please, Mr. Marketing Droid.

I am back home from San Diego now. About 3 more hours of jet-lag to work on. This will be a very busy two weeks until I make a little excursion to the Pakistan Developer Conference in Karachi and then have another week to do the final preparations for TechEd Europe.

One of the three realy cool talks I'll do at TechEd Europe is called "Building Proseware" and explains the the scenario, architecture, and core implementation techniques of Proseware, an industrial-strength, robust, service-oriented example application that newtelligence has designed and implemented for Microsoft over the past 2 months.

The second talk is one that I have been looking forward to for a long time: Rafal Lukawiecki and myself are going to co-present a session. And if that weren't enough: The moderator of our little on-stage banter about services is nobody else than Pat Helland.

And lastly, I'll likely sign-off on the first public version of the FABRIQ later this week (we had been waiting for WSE 2.0 to come out), which means that Arvindra Sehmi and myself can not only repeat our FABRIQ talk in Amsterdam but have shipping bits to show this time. There will even be a hands-on lab on FABRIQ led by newtelligence instructors Achim Oellers and Jörg Freiberger. The plan is to launch the bits before the show, so watch this space for "when and where".

Overall, and as much as I like meeting all my friends in the U.S. and appreciate the efforts of the TechEd team over there, I think that for the last 4 years TechEd Europe consistently has been and will be again the better of the two TechEd events from a developer perspective. In Europe, we have TechEd and IT Forum, whereby TechEd is more developer focused and IT Forum is for the operations side of the house. Hence, TechEd Europe can go and does go a lot deeper into developer topics than TechEd US.

There's a lot of work ahead so don't be surprised if the blog falls silent again until I unleash the information avalanche on Proseware and FABRIQ.