I highly recommend reading Vittorio's most excellent and illuminating blog entry for how to use the new features we've added to BizTalk Identity Services for allowing you to use 3rd Party Managed Cards.

A flock of pigs has been doing aerobatics high up over Microsoft Campus in Redmond in the past three weeks. Neither City of Redmond nor Microsoft spokespeople returned calls requesting comments in time for this article. An Microsoft worker who requested anonymity and has seen the pigs flying overhead commented that "they are as good as the Blue Angels at Seafair, just funnier" and "they seem to circle over building 42 a lot, but I wouldn't know why".

In related news ...

We wrapped up the BizTalk Services "R11" CTP this last Thursday and put the latest SDK release up on http://labs.biztalk.net/. As you may or may not know, "BizTalk Services" is the codename for Microsoft's cloud-based Identity and Connectivity services - with a significant set of further services in the pipeline. The R11 release is a major milestone for the data center side of BizTalk Services, but we've also added several new client-facing features, especially on the Identity services. You can now authenticate using a certificate in addition to username and CardSpace authentication, we have enabled support for 3rd party managed CardSpace cards, and there is extended support for claims based authorization.

Now the surprising bit:

Only about an hour before we locked down the SDK on Thursday, we checked a sample into the samples tree that has a rather unusual set of prerequisites for something coming out of Microsoft:

Runtime: Java EE 5 on Sun Glassfish v2 + Sun WSIT/Metro (JAX-WS extensions), Tool: Netbeans 6.0 IDE.

The sample shows how to use the BizTalk Services Identity Security Token Service (STS) to secure the communication between a Java client and a Java service providing federated authentication and claims-based authorization.

The sample, which you can find in ./Samples/OtherPlatforms/StandaloneAccessControl/JavaEE5 once you installed the SDK, is a pure Java sample not requiring any of our bits on either the service or client side. The interaction with our services is purely happening on the wire.

If you are a "Javahead", it might seem odd that we're shipping this sample inside a Windows-only MSI installer and I will agree that that's odd. It's simply a function of timing and the point in time when we knew that we could get it done (some more on that below). For the next BizTalk Services SDK release I expect there to be an additional .jar file for the Java samples.

It's important to note that this isn't just a thing we did as a one-time thing and because we could. We have done a significant amount of work on the backend protocol implementations to start opening up a very broad set of scenarios on the BizTalk Services Connectivity services for platforms other than .NET. We already have a set of additional Java EE samples lined up for when we enable that functionality on the backend. However, since getting security and identity working is a prerequisite for making all other services work, that's where we started. There'll be more and there'll be more platform and language choice than Java down the road.

Just to be perfectly clear: Around here we strongly believe that .NET and the Windows Communication Foundation in particular is the most advanced platform to build services, irrespective of whether they are of the WS-* or REST variety. If you care about my personal opinion, I'll say that several months of research into the capabilities of other platforms has only reaffirmed that belief for me and I don't even need to put a Microsoft hat on to say that.

But we recognize and respect that there are a great variety of individual reasons why people might not be using .NET and WCF. The obvious one is "platform". If you run on Linux or Unix and/or if your deployment target is a Java Application Server, then your platform is very likely not .NET. It's something else. If that's your world, we still think that our services are something that's useful for your applications and we want to show you why. And it is absolutely not enough for us to say "here is the wire protocol documentation; go party!". Only Code is Truth.

I'm also writing "Only Code is Truth" also because we've found - perhaps not too surprisingly - that there is a significant difference between reading and implementing the WS-* specs and having things actually work. And here I get to the point where a round of public "Thank You" is due:

The Metro team over at Sun Microsystems has made a very significant contribution to making this all work. Before we started making changes to accommodate Java, there would have been very little hope for anyone to get this seemingly simple scenario to work. We had to make quite a few changes even though our service did follow the specs.

While we were adjusting our backend STS accordingly, the Sun Metro team worked on a set of issues that we identified on their end (with fantastic turnaround times) and worked those into their public nightly builds. The Sun team also 'promoted' a nightly build of Metro 1.2 to a semi-permanent download location (the first 1.2 build that got that treatment), because it is the build tested to successfully interop with our SDK release, even though that build is known to have some regressions for some of their other test scenarios. As they work towards wrapping up their 1.2 release and fix those other bugs, we’ll continue to test and talk to help that the interop scenarios keep working.

As a result of this collaboration, Metro 1.2 is going to be a better and more interoperable release for the Sun's customers and the greater Java community and BizTalk Services as well as our future identity products will be better and more interoperable, too. Win-Win. Thank you, Sun.

As a goodie, I put some code into the Java sample that might be useful even if you don't even care about our services. Since configuring the Java certificate stores for standalone applications can be really painful, I added some simple code that's using a week-old feature of the latest Metro 1.2 bits that allows configuring the Truststores/Keystores dynamically and pull the stores from the client's .jar at runtime. The code also has an authorization utility class that shows how to get and evaluate claims on the service side by pulling the SAML token out of the context and pulling the correct attributes from the token.

Have fun.

[By the way, this is not an April Fool's joke, in case you were wondering]

Reading Techmeme I'm seeing that Yahoo! went the way of laying off in the order of a thousand heads by salary ranges rather than experience level. 

Look, Seattle's reuptation for weather may be well deserved, but - on the upside - we actually have weather. You know - rain, snow, wind, freezing - all that stuff that reminds you that you are alive - PLUS 5 months of glorious spring/summer weather where it never gets too hot and never too cold. And we've got the water and the mountains. It's gorgeous here.

Oh, and, we're really not that evil here. I'm having great fun working here all day. My boss looks or acts nowhere near like Darth Vader (he's actually a former Silicon Valley dude who's still adjusting to the climate). I'm learning from people smarter than me every day. I even get to write code on platforms and runtime I've never thought I'd ever touch; and I'm not talking about VB6 or Fortran.

So if you are up for a challenge and want to extend the reach of the .NET Framework into the "cloud" like we're doing here at http://labs.biztalk.net (bigger, bigger stuff ahead), I'll stick my head out - you can write me email at clemensv@microsoft.com with your resume and I will connect you to the right folks.  

And for the long-time readers of my blog: You can write me too. If you want to make an big impact in the industry, now's the time. Oh, and, FWIW, you'll likely get to work with me, but you should rather look forward to work with the gusy I work with.

2007 I've posted some 30 entries on my blog. That's what some of the "Whoa, listen to me, I am so awesome!" blogging crowd of today typically does in a day or two. 2008 promises to be so interesting that it would be a shame not to be blogging, and hence I do. There'll be lots of things going on in tech and in the world. 

Over the past year I've been very deeply involved in the still rather stealthy project 'Oslo' about which we'll talk about in MUCH more detail throughout this year than we have at the recent conferences. When you are in a project with tight disclosure constraints there's really nothing of any substance to talk or blog about. Hence I didn't.

However, since Wednesday I have a new job. I'm now getting my hands dirty by writing code for our Internet Service Bus infrastructure that's currently code-named 'BizTalk Services'. Here, the rules of the game are very different. We're actually building most of the stuff out in the open and are inviting people to play with it. That's really more in the spirit of how I've been working with the community in the past and therefore I'm looking forward to the fun that's to be had in this new team.

Beware; since I gather that I've lost about 95% of my readership of my main at http://vasters.com/clemensv blog due to my inactivity I will use the opportunity to adjust the agenda and make it a "everything that I find interesting" place. Expect political opinion. My MSDN blog at http://blogs.msdn.com/clemensv will get mirrored copies of the tech topics as I've done that since I work here at MSFT. If you just care about the tech stuff read the MSDN mirror. 

Having an Internet Service Bus up in the cloud is not very entertaining unless there are services in the bus. Therefore, I built one (and already showed some of the code basics) that’s hopefully fun to play with and will soon share the first version with you after some scrubbing and pending a few updates to the ISB that will optimize the authentication process. It’s a 0.1 version and an experiment. The code download should be ready in the next two weeks, including those adjustments. But you can actually play with parts of it today without compiling or installing anything. The info is at the bottom of this post.

To make matters really interesting, this sample not only shows how to plug a service into the cloud and call it from some Console app, but is a combo of two rather unusual hosts for WCF services: A Windows Live Messenger Add-In that acts as the server, and a Windows Vista Sidebar gadget that acts as the client.

Since the Silicon Valley scene is currently all over Twitter and clones of Twitter are apparently popping up somewhere every day, I thought I could easily provide fodder to the proponents of the alleged Microsoft tradition of purely relying on copying other’s ideas and clone them as well   Well, no, maybe not. This is a bit different.

TweetieBot is an example of a simple personal service. If you choose to host it, you own it, you run it, you control it. The data is held nowhere but on your personal machine and it’s using the BizTalk Services ISB to stick its head up into the cloud and at a stable endpoint so that its easily reachable for a circle of friends, bridging the common obstacles of dynamic IPs, firewalls and NAT. No need to use UPnP or open up ports on your router. If you choose to do so, you can encrypt traffic so that there’s no chance that anyone looking at our ISB nor anyone else can see the what’s actually going across the wire.

Right now, lots of the Web 2.0 world lives on the assumption that everything needs to live at central places and that community forms around ad-driven hubs. The mainframe folks had a similar stance in the 70s and 80s and then Personal Computers came along. The pendulum is always swinging and I have little doubt that it will swing back to “personal” once more and that the federation of personal services will seriously challenge the hub model once more.

So what does the sample do? As indicated, TweetieBot is a bot that plugs into a Windows Live Messenger using a simple Add-In. Bart De Smet has a brilliant summary for how to build such Add-Ins. When the Add-In is active and someone chats the bot, it answers politely and remembers the chat line, time and sender. The bird has a leaky long term memory, though. It forgets everything past the last 40 lines.

Where it gets interesting is that the Add-In can stick three endpoints into the BizTalk Services ISB:

• A Request/Response Web Service that allows retrieving the list of the last 40 (or less) “tweets” and also allows client to submit tweets programmatically.
• An RSS service that allows (right now) anyone to peek in to the chat log of the last 40 tweets.
• An Event service that allows subscribers to get real-time notifications whenever a new tweet is recorded.

The accompanying Sidebar Gadget, which is implemented using WPF, is a client for two of these services.

 When you drop the Gadget on the Sidebar, it will prompt for the IM address of the TweetieBot service you’d like to subscribe to. Once you’ve authenticated at the relay using your registered Information Card, the gadget will pull and show the current list of Tweets and subscribe to the Events service for real-time updates. And whenever someone chats the bot, the Sidebar gadget will immediately show the new entry. So even though the Gadget lives on some client machine that’s hidden between several layers of firewalls and behind NAT, it can actually get push-style event notifications through the cloud!

“How do I send events to clients?” must be one of the most frequent questions that I’ve been asked about Web Services in the past several years. Well, this is your answer right here.

While I’m still toying around with the code and the guys on the 1st floor in my building are doing some tweaks on the ISB infrastructure to make multi-endpoint authentication simpler, you can already play with the bot and help me a bit:

Using Windows Live Messenger you can chat (click here) tweetiebot@hotmail.com now. Drop a few lines. If the bot is online (which means that I’m not tinkering with it) it will reply. Then look at this RSS feed [1] and you can see what you and everyone else have been telling the bot recently. Enjoy.

[1] http://connect.biztalk.net/services/tweetiebot/tweetiebot%40hotmail.com/rss

Steve Maine explains what's in the newest revision of the BizTalk Services SDK, including quite a few (standalone-) surprises for WCF and WF developers. In case you haven't noticed, we've dropped a new and substantially expanded build of the SDK just a week after we published the first SDK.

Stop. Don't leave yet. Before you say "What do I care about BizTalk?", you should know that while BizTalk has been more or less associated with the BizTalk Server 200x product line in the past few years, (Codename-) BizTalk Services is a complementary set of functionality that's not only interesting to BizTalk Server customers, but really to all .NET developers.

Weird? Flip flopping? Confusing? No. The fact that BizTalk is not only BizTalk Server isn't really new. When BizTalk came out back in 2000 and I was very closely looking at what's going on (get it used for $2), the definition read like this in the press release:

The BizTalk Initiative represents the collective set of investments that Microsoft is making to facilitate business process integration within and between organizations using Internet-standard protocols and formats. It includes the BizTalk Framework, the BizTalk.org community and business document library, as well as BizTalk Server 2000, a business process orchestration server and tools for developing, executing and managing distributed business processes. These investments are being made in conjunction with industry standards groups, technology and service providers, as well as key global organizations.

While the envisioned schema exchange BizTalk.org fell flat since industry-wide message-level-schema standardization for "everything" more or less didn't happen in the way people initially expected, what came out of this initiative as a significant element was that the set of specifications then known as the BizTalk Framework 2.0 that acted as a foundation for quite a few of the WS-* specifications and the BizTalk Server product which evolved into a very successful and leading SOA/BPM suite that's soon seeing its next release, BizTalk Server 2006 R2. Fast forward, read Steven Martin's blog entry where he writes:

[...] We see BizTalk Services as a complement to "traditional" BizTalk Server uses on premise. As you need to coordinate SOA on a broader scale beyond the organization, we see the introduction of hosted services as one way to help support federation of business process, messaging, and identity across boundaries. Over time, we want to ensure that BizTalk Server customers will be able to easily use the cloud services in conjunction with their premise technology. [...]

So all in all, a very sane way to think about BizTalk is that the software and services we publish under that name are providing functionality for messaging, process management and connectivity that go beyond the capability of the core .NET Framework.

I wrote a slightly Twitter-inspired, fun app over the weekend that's using the BizTalk Services Connectivity service and relay. In the spirit of Software+Services I'm going to give you half of it [for now]    You must have the BizTalk Services SDK installed to run the sample.

The server app, which I'm keeping to myself for the next few days as part of the experiment, is an extension (add-in) to Windows Live Messenger. The Messenger add-in monitors all chats with tweetiebot@hotmail.com and keeps circular buffer with the last 40 incoming messages. Using the client (which is in the attached archive), you can get a list of "Tweets" and add a new one (same as chatting)

[ServiceContract(Name = "TweetieBot", Namespace = http://samples.vasters.com/2007/05/tweetiebot)]
public interface ITweetieBot
{
  [OperationContract]
  IList<Tweet> GetTweets(DateTime? since);
  [OperationContract]
  void Tweet(string nickname, string text);
}

or you can subscribe to new tweets and get them as they arrive

[ServiceContract(Name = "TweetieEvents", Namespace = http://samples.vasters.com/2007/05/tweetiebot)]
public interface ITweetieEvents
{
  [OperationContract(IsOneWay=true)]
  void OnTweet(Tweet tweet);
}

The client application hooks up to the client (that lives right on my desktop machine) through the BizTalk Services ISB and the server fires events back through the ISB relay into the client as new tweets arrive. So when you run the attached client app, you'll find that it starts with a dump of the current log of the bot and then keeps spitting out events as they arrive.

The client is actually pretty simple. The EventsClient is the subscriber for the pub/sub service (ConnectionMode.RelayMulticast) that writes out the received events to the console. The rest all happens in Main (parsing an validating the command line argument) and in Run.

    class Program
    {
        class EventsClient : ITweetieEvents
        {
            public void OnTweet(Tweet tweet)
            {
                Console.WriteLine("[{0}] {1}:{2}", tweet.Time, tweet.User, tweet.Text);
            }
        }

        static void Main(string[] args)
        {
            string usageMessage = "Usage: IMBotClient <messenger-email-address>";
            if (args.Length == 0)
            {
                Console.WriteLine(usageMessage);
            }
            else
            {
                if (!Regex.IsMatch(args[0], @"^([\w\-\.]+)@((\[([0-9]{1,3}\.){3}[0-9]{1,3}\])|(([\w\-]+\.)+)([a-zA-Z]{2,4}))$"))
                {
                    Console.WriteLine(usageMessage);
                    Console.WriteLine("'{0}' is not a valid email address");
                }
                else
                {
                    Run(args[0]);
                }
            }
        }

        private static void Run(string emailAddress)
        {
            EndpointAddress serviceAddress =
                new EndpointAddress(String.Format(String.Format("sb://{0}/services/tweetiebot/{1}/service", 
                                    RelayBinding.DefaultRelayHostName, Uri.EscapeDataString(emailAddress))));
            EndpointAddress eventsAddress =
                new EndpointAddress(String.Format(String.Format("sb://{0}/services/tweetiebot/{1}/events",
                                    RelayBinding.DefaultRelayHostName, Uri.EscapeDataString(emailAddress))));

The URI scheme for services that hook into the ISB is "sb:" and the default address of the relay is encoded in the SDK assemblies. We set up two endpoints here. One for the client channel to fetch the initial list and one for the event subscriber. 

            RelayBinding relayBinding = new RelayBinding();
     
            ServiceHost eventsHost = new ServiceHost(typeof(EventsClient));
            RelayBinding eventBinding = new RelayBinding(RelayConnectionMode.RelayedMulticast);
            eventsHost.AddServiceEndpoint(typeof(ITweetieEvents), eventBinding, eventsAddress.ToString());
            eventsHost.Open();

            ChannelFactory<TweetieBotChannel> channelFactory = new ChannelFactory<TweetieBotChannel>(relayBinding, serviceAddress);
            TweetieBotChannel channel = channelFactory.CreateChannel();
            channel.Open();

The two *.Open() calls will each prompt for a CardSpace authentication, so you will have to be registered to run the sample. Once you have opened the channels (and my service is running), you'll be able to pull the list of current tweets. Meanwhile, whenever a new event pops up, the EventsClient above will write out a new line.

            IList<Tweet> tweets = channel.GetTweets(lastTime);
            foreach (Tweet tweet in tweets)
            {
                Console.WriteLine("[{0}] {1}:{2}", tweet.Time, tweet.User, tweet.Text);
            }

            Console.WriteLine("Press ENTER to quit at any time");
            Console.ReadLine();

            eventsHost.Close();
            channel.Close();
            channelFactory.Close();
        }