This is seriously groundbreaking: Clemens (also here) just finished an example of a Metro client accessing Microsoft's BizTalk Services (aka Internet Service Bus). "Well", you might ask, "what is so groundbreaking about this? Isn't this what this whole web services thingy was supposed to achieve? Interoperability?!"

Yes, indeed. However, this is the first time ever (to my knowledge) that Microsoft is releasing JEE code, built with Metro within NetBeans, as part of an SDK. Getting there took quite a while, and was largely enabled by Sun and Microsoft working very closely together in a series of interop-plugfests. The latest installment of these got (especially) WS-Trust interoperability to a point where you can now use the client implementation in Metro to access the STS provided by the .NET Framework.

Congrats to Clemens, but also the Metro team (namely Jiandong and Harold).

tag: Interoperability, WS-Trust, Metro, BizTalk Services

Microsoft made the ruling of the Court of First Instance in Europe available on their web site... this condenses 5 years of my work life into a single document.

tag: Microsoft

Electronic health record are a very touchy subject, since these affect some of the most personal data. While a usable and reliable system for such electronic records would certainly save a lot of money and also prevent even more health-care related mistakes, the Microsoft HealthVault solution is probably the very worst way of trying to solve these problems.

Do not get me wrong - I do applaud Microsoft for trying to push this effort ahead, so that we (as a society) can make progress towards a reasonable solution. But a centralized (one is tempted to say: totalitarian), Passport-like data sink for my most personal data does not even sound bad to me^[1]. Here are a couple of questions that came to my mind immediately after reading the announcement:

• Why would I trust an unrelated and (health records wise) completely unexperienced company trust with my health records?

• What happens in case of a data breach?

• Why should I consent to having my data shipped to *any* other country?

• Why is Microsoft only worried about third party "Program" provider satisfying *their* Privacy Policy needs and not mine.

• What happens if health related surfing habits are harvested not through the HealthVault web site, but through the *required* Microsoft Passport account?

The list could go on and on after reading the boiler plate privacy policy. I just cannot understand why Microsoft is pressing forward into this area without taking much more caution to prevent security breaches (ha: they are using SSL and strong passwords!!) and limit liability. In this area (particularly when dealing with super personal data like real-time live sign data) there is no "get it right the third time".

Paul Madsen made a very good point of this area of application being ideally suited for Liberty technologies. I think that data as sensitive as medical records should be regulated to only be kept in federations: without my explicit consent data should not move from one silo (doctor A) to any other (doctor B or insurance). In fact, the way the (ineffective, but privacy preserving) way health care works today is a federation model.

tag: healthvault

[1] I am really in a Pauli mood today.

Dare Obasanjo offers a very balanced view on the recent announcement by Microsoft to release the .NET 3.5 source under a highly restrictive license. He writes:

This is one of those announcements I find hard to get excited about. Any developer who’s been frustrated by the weird behavior of a .NET Framework class and has wanted to look at it’s code, should already know about Lutz Roeder’s Reflector which is well known in the .NET devoper community. So I’m not sure who this anouncement is actually intended to benefit.

The Microsoft Reference License says:

"Reference use" means use of the software within your company as a reference, in read only form, for the sole purposes of debugging your products, maintaining your products, or enhancing the interoperability of your products with the software, and specifically excludes the right to distribute the software outside of your company.

So, if you look at the source code for .NET you better stop working on *any* plumbing or infrastructure code, because you might get tainted. Why are they doing this? I'd rather see the .NET code going under a GPL license, or even a BSD derivative.

Microsoft R-L is NOT open source - it is not even closed source Or, to use a Wolfgang Pauli expression: "This is so bad, it is not even wrong."

tag: opensource, .NET, Microsoft

Mike Jones has blogged about Microsoft's latest OSP covered specification. Large chunks of the InfoCard protocols that appeared on Kim's blog over time are now in this refatored version of the spec. I did not have the time yet to go through this in detail, but I am quite interested to figure out if I can build a managed card provider and consumer based solely on this spec. Mike assures me that this works, so I hope to report back about this soon ...

BTW: Thanks for all your work, Mike (and Kim, of course).

tag: Identity, Microsoft, InfoCard

Here is a nice short article by Scott Hanselman on what is currently happening in .NET land - especially at MIX07. I find his graphic on the evolution of the various .NET technologies quite interesting and helpful. A couple of interesting take aways and comments:

- Silverlight 1.1 alpha, along with the "CoreCLR" will be interesting to disect. According to Scott, there is nothing "micro or tiny" about this runtime, only sane refactoring. That might be so, but the Base Class Library amounts to somthing of a Micro/Mobile edition ...?!

- The Dynamic Language Runtime is interesting - but I am not quite so optimistic to believe that the Microsoft Permissve License will really win the "hearts and minds" of the hardcore open source community...

- The JavaScript/CLR (in process?) integration sound *really* interesting.

Ultimately, the success of Silverlight and the CoreCLR program will probably depends on platform support. And as Sun has learned very painfully, sufficent platform support can only be achieved with truely open source software.

Here is an interesting move by some .NET developers: they are pleading with Microsoft to open up .NET and - at least - support it on multiple platforms, if not outright open source it. Now that would be interesting.

tag: Microsoft, Open Source, .NET

WPF/E (Windows Communication Foundation/Everywhere) is now called "Microsoft Silverlight" and available as a beta here. I think it will be really interesting to see if Microsoft goes beyond Windows and Mac and will start supporting other OSes (like Solaris or Linux) as well... and also *continue* to support this for the future.

Interesting news from the Compact Framework group: They are planning on releasing a subset of WCF on the Compact Framework (i.e. their mobile edition). This is quite interesting, not the least because a lot of their mobile devices are frequently used in a disconnected mode and only updated at scheduled times. One solution to the problems that arise with this mode of operation is the use of SMTP as a transport protocol for SOAP.

Here is my mail to Mike Jones on the OSP:

Hello Mike - 

First of all this is most excellent news - and I am looking forward to
seeing those protocols being implemented by a large number of market
participants. 

However, I do have a few questions that you might be able to clarify: 

1. For the purposes of OSIS, there are some components in the WCS that
do no seem to be covered, in particular the InfoCard specifications,
including schema and the visual components for the card selector UI.
Will this be covered by a separate covenant?

2. Also, the language of the OSP mentions that only Necessary Claims,
i.e. those REQUIRED in the specs are covered. What about OPTIONAL, etc.
portions of the specs?

Thanks a lot, 

Gerald Beuchelt 

At this point I would like to thank Mike and also Kim for their work on getting the WS-* protocolsl into the OSP and - hopefully - all the other specifications that will follow

Here you can find the OSIS response to the OSP.

I think that this reposonse is - particularly in the context of OSIS and related efforts - quite appropriate. The obvious issues with the covenant, as also pointed out by quite a few of my colleagues (see e.g. Eve or Simon) are addressed, including the concern that Microsoft is not the only stake holder in the WS-* space.

... and what is this RALLY thing, anyways?

RALLY is an architecture and a set of specs form Microsoft that describes how to create devices that will easily configure themselves into a Microsoft centric network, with a heavy focus on home networking at this time. Here is their overview site:

http://www.microsoft.com/whdc/rally/default.mspx

A couple of important technologies include:

• PnP-X Plug and Play Extensions - This will allow external devices on the network to link themselves into the Windows OS and appear to the OS as Windows devices.
  
• LLTD Link Layer Topology Discovery - the name says it all ...
• Web Services Profile for Devices - I sense a candidate for another round of OSP.. or maybe not?

Now the question at hand is, how this program will possibly integrate with J2ME, Jini and JXTA. Any ideas anybody?

I just installed Windows Vista RC1 (Build 5600) and had some serious problems getting Windows Update to work from behind my proxy server. The error I got was 8024402C, along with the recommendation to try the Automatic Proxy configuration. Needless to say that this did not work ...

Here is how to get rolling with this issue:

1. Get the WinHTTP system proxy settings right

When configuring IE in Vista, you DO NOT configure the system HTTP proxy settings. In former versions of Windows you would use the proxycfg.exe command for doing this. In Vista, you will have to use the netsh.exe. (Does anybody know of a UI way to do this?) Do this:

netsh> winhttp

netsh winhttp> set proxy myproxy.company.tld:80

You have to do this in a CMD.EXE windows with administrative privileges (right click CMD.EXE in Accessories and select 'Run as Administrator').

2. Delete old setting for Windows update

- Stop the Windows Update service (e.g. through the Services MMC plug-in or through net stop wuauserv).

- Delete C:\WINDOWS\SoftwareDistribution (again, with administrator privileges)

- Start the Windows Update service

It should work now.

Microsoft today announced their "Open Specifications Promise", essentially a non-assertion covenant for a huge chunk of WS-* protocols. This OSP means (as fas as I can tell - and I am NOT a lawyer ) that people can start implementing WS-* specifications without having to fear any action from Microsoft, as long as they do not sue Microsoft over these specs - duh!

This is quite good news for a number of reasons:

1. All existing implementations of WS-* technology are safe from any legal harassment from Microsoft. Not that they would do this necessarily, but this covenant gives peace of mind.
   
2. Since pretty much all security specs are out, OSIS and Higgins are now in a much better position to implement a WCS compatible InfoCard selector.
3. The best thing about this is the fundamental mindshift at Microsoft. A couple of years ago this would have been unthinkable. Now it is real. This is really major change in the way Microsoft deals with the open source community. It can be hoped that this OSP is just the beginning of a much more open discussion with Microsoft.
   

Here is a suggestion for the dasBlog folks:

After our corporate blog host (http://blogs.sun.com/) was upgraded to Roller 3.0 (which - by the way - has a couple of really nice improvements), my cross-poring would no longer work. Since this is quite annoying is went to figure out why this is so. It turns out that the Roller folks (at least at Sun) were thinking ahead and made sure that all calls the XMLRPC endpoints get redirected to a protected HTTPS handler. Makes sense.

Unfortunately, this break the posting mechanism for dasBlog, as well as a lot of other blog clients out there. While the Roller admins are now fixing this, I came up with a small idea how to get dasBlog to post to HTTPS endpoints as well. Since it uses the Cook Computing XML-RPC library, this fix is actually very straight forward:

You will need to fix just a very few items:

• The CrosspostSite class in the newtelligence.dasBlog.Runtime namespace. Here you should add a propety like String transportProtocoll = "http" or similar. Also the schema for the siteConfig file file to accomodate this additional attribute.
  
• The UI to allow proper configuration (duh!).
  
• The HandleCrosspost() method in newtelligence.dasBlog.Runtime.DasBlogDataServiceGFactory.BlogDataServiceXml.CrosspostJob. This UriBuilder should be reconfigured to something like:
  UriBuilder uriBuilder = new UriBuilder
                                  (ci.Site.transportProtocol,
                                   ci.Site.HostName,
                                   ci.Site.Port,
                                   ci.Site.Endpoint);

And this should be it.

Obviously, for the long run I would love to see an ATOM protocol based mechanism, but so far this is a dream (I guess?!). Here is the URL for the Bug I submitted on SF.NET.

This is a interesting research project at Microsoft: Phoenix is the framework for all upcoming compiler and JITer optimizations for the Microsofts platforms. Their goal is to unify opmizations and execuction imrpovements for both managed (i.e. .NET) and unmanaged (i.e. Win32) code. Conceptually it uses a three stage optimization and code generation process, with the Phoenix C2.EXE C++ back end compiler being the centerpiece:

A very nice effect of this research program is that it will allow developers to come up with their very own development language and still use the platform optimizations provided by Phoenix.

The research development kit can be found here.

Microsoft Live has a STS for Windows Live ID (aka Passport) running here. Now this is really interesting, particularly in the context of Microsoft's recent move to get the Infocard selector to many platforms. So what is the rationale behind this? Here is my take on this:

ADFS will be the Microsoft implementation of the Enterprise STS. If it advertises iteself now as a ADFS Federation Partner (i.e. a 'trustable' resource for your enterprise AD), you will be able to provide SSO for your customers to log into your extranet. Now the really interesting question is: will Microsoft allow the Passport STS (by explicit business contract) to trust ADFS deployments (maybe for really large cutomers only), thus enabling your enterprise users to SSO into Passport sites?

Microsoft's Atlas framework for AJaX got some harsh comments from Microsoft's partner Wintellect about the lack of cross-browser interoperability. At the end of the day, AJaX really came up because tht different component frameworks and client capabilities are so disjoints, that for a long time there was no way you could build a rich Web UI. With Atlas only supporting IE (for the interesteing parts, at the very least), the benefits of AJaX go away.

So if Microsoft is truley serious about making Atlas a usable AJaX framework, they will have to support Firefox and Safari, at the very least.

David Chappell made some interesting remarks on Java and NetFX during his TechEd session and on his blog. He compares the creation of SCA by IBM, BEA and some others to the creation of the .NET Framework in 2000.

I would put this somewhat differently: .NET in 2000 was a (somewhat late) reaction to the success of the Java platform. As .NET evolved, itwent - essentially - through the same issues as Java: 1.0 was essentially unusuable, 1.1 kinda worked, and 2.0 (or 1.2 in Java) is/was the first truely usable platform. In this sense, SCA is comparable to the announcement of the Longhorn pillars, at best.

In his TechEd session this morning, David was trying to compare SCA with WCF. He noted that while WCF is in its final beta stages, SCA is just starting with the definition. This is certainly true. However, there are other simplifying APIs (such as EJB3, JBI/OpenESB, WSIT) that have a similar architectural scope as WCF and are in final beta as well. I strongly recommend reading the comment section of David's blog article as well, since it contains a lot of interesting pointers.

Finally - the confusion is complete: WinFX is now NetFX. Huh?

The (likely) final name for the collection of .NET APIs formerly know as WinFX 3.0 (aka Avalon, Indigo and Workflow, but NOT WinFS) have a new name and community portal: They are now called NetFX and hosted at http://netfx3.com/, with Indigo/WCF being located at http://wcf.netfx3.com/.

After J#, X# and some more abberations, Microsoft is now fiddeling with the idea of Script#. This is a code generation tool for JavaScript - you start with a C# class, run the ssc.exe compiler and get JavaScript from the C# source, instead of IL. He also has some integration with Visual Studio working at this point. The obvious target for Script# is the AJaX world.

I haven't quite made up my mind if I like this approach or not. It definitively seems intriguing for developers that do not (yet) have a solid understanding of UI-side development.

Here is a nice little tweak for Visual Studio 2005:

In a debug session with the default settings, you can only see "External Code" in the call stack for the Windows/.NET code base. If you go to Tools -> Options... -> Debugging -> General, and unselect "Enable Just My Code", you can then see the entire call stack.

There is one caveat however: if you enable this option, VS gets a lot dumber about stepping into your code, so you have to set breakpoints very extensively.

At this time, most of you have probably heard about the Web Services Interoperability Toolkit for Java (a.k.a. Project Tango), which enables maximal interoperability between the upcoming Windows Communication Foundation on .NET and the Java world. If not, go see http://wsit.dev.java.net/ ASAP.

WSIT will be tightly integrated with the Glassfish Sun Application Server, which also features full FastInoset support. In fact, Glassfish will - based on the HTTP header content type - automatically switch between text+xml and application/fastinfoset.

Now, with the WCF integration that FIFI will deliver, you will be able to configure an Indigo client at deploy time (or even after) to use the by far more efficient FI encoding. And this (re)configuration will only take a change in a single line in the .config file of that client (assuming that you are using a CustomBinding in the first place ).

So, at the end of the day, you can start you deployment of SOAP and RESTful Web Services with angle brackets and as soon as you need a more efficient encoding, you switch to FI by simply setting the right config parameter in the WCF client. Can it be less painful?

Finally, with a lot of help from sgen.exe and a number of very talented inidividuals, I got the complex types to work this morning. The biggest issue was the way WCF compares Strings:
Java does sttring interning, .NET does not do this by default (this is why (object) string1 == (object) string2 is without further consideration a bad idea). Within the XML serialization framework however, WCF uses a NameTable to "atomize" (i.e. intern) strings. The Reader must return interned versions of the name, localName, namespace, etc. or the string comparisons in the generated classes will fail. Here is a sample from the generated code:

while (Reader.NodeType != System.Xml.XmlNodeType.EndElement &&
        Reader.NodeType != System.Xml.XmlNodeType.None) {

    if (Reader.NodeType == System.Xml.XmlNodeType.Element) {
        if (!paramsRead[0] && ((object) Reader.LocalName ==  (object)id4_agedHelloResponse &&
                (object) Reader.NamespaceURI == (object)id2_Item)) {
            o.@agedHelloResponse = Read4_agedHelloResponse(false, true);
            paramsRead[0] = true;
        }
        else {
            UnknownNode((object)o, @":agedHelloResponse");
        }
    }
    else {
        UnknownNode((object)o, @":agedHelloResponse");
    }
}

After fixing the Properties on XmlFiReader, it can now deserialize complex objects, and - as such - also use doc/lit in addition to rpc.

Well, I really do not have any big secrets to uncover, but I wanted to point you WCF developers to an extremely useful tool: sgen.exe.

In itself the tool is quite handy, since you can pre-generate and compile serialization code that would otherwise be generated and compiled by WCF during runtime. The cost for doing this (while only during startup) is quite significant, so using sgen.exe, you can avoid this penalty.

The by far best part of sgen.exe is, however, the '/keep' switch. If you turn this on, WCF keeps the source code for the custom IXmlSerializable implementation, and you can tweak, adjust or - in my case - debug - your serialization process.

There is the obvious question on why FastInfoset and - more importantly for me at this time - why on Indigo (WCF)?

A lot of customers - particularly in the financial industry - have expressed their concern about XML and its 'bloatiness': it is simply to verbose to be useful in 10M, 100M or even Gigabyte sized transactions. This makes a lot of sense and thus, FastInfoset (and similar efficent XML initiatives) were born out of this need.

Sun has been behind FastInfoset from its inception and the current JWSDP and the Glassfish application server fully support FI. It has been a clearly stated goal that we see FI as our strategic binary Infoset representation scheme and we would like to achieve ubiquity.

To achieve such ubiquity, it is mandatory to cover as much server and client platforms as possible. With FI being available for the Java platform - supported and open source - this goal is actually achievable. But in order to be truely successful, it is also necessary to enable non-Java platforms to exchange messages in FI. FIFI aims at just that: to enable FI processing for .NET 2.0 and FI message exchange for WCF.

Reminder: the FIFI BOF at JavaONE is tomorrow, May 17, at 9:30pm in Hall E.

My final project for this quarter's Stanford course (MS&E 201: Dynamic Systems) is going to be quite interesting. We will try to understand the dynamics behind open source adoption and the challenges it brings for Microsoft.

XML and Web services are loosely coupled, right? And loosely coupled and object references do usually not play nice together...

This is quite interesting: It looks like you can preserve object references and pass them along when setting the preserveObjectReference flag to true in a new DataContractSerializer.

I will play around with this and see how this looks on the wire ... stay tuned.

It is interesting to see what Microsoft has done with Windows Mobile so far, and where they plan on going. This presentation give a good overview and also a fairly good lookout on what is coming and when.

Some highlights:

• Windows Mobile 5.0 - released
• MSMQ support
• SQL Server 2005 mobile
• .NET 2.0 compact
  
• 'Crossbow' Release in late 2006, to hit the market by mid-2007
• 'Photon' Release in late 2007, to hit the market by mid-2008
• New kernel
  

It seems that they are now switching to releasing a new version of the mobile OS every year or so.

Interestingly enough, they seem to have cut the roadmap slides in the above version (or am I missing something?), but you can still see the full slide deck using Google's cache.

Fresh from Washington state: Indigo to support POX in TextEncoder

Combine this with Marc Hadley's adventures with REST in JAX-WS, and you might actually get something interoperable ..

In an earlier article, I showed how to make a system dual-boot Windows Vista and Debian Linux through GRUB. This was fairly straightforward, even with the new boot loader (BCD) that ships with the latest Vista builds. All of that happened in a reasonably simple environment - I used Microsoft Virtual PC 2004 SP1 to run Vista build 5342 and Debian.

This time, things are bound to get a little bit more interesting: I am installing Vista build 5342 on a Sun Ultra 40 AMD workstation. The other OS is - obviously - Solaris 10 01/06 (Update 1).

The overall procedure is very similar to what I have described before:

1. Install Windows Vista

2. Install Solaris and edit /boot/grub/menu.lst as described here.

STOP: Solaris is not quite as smart about the boot loaders as GRUB and does some strange things to the MBR - OR - Vista x64 has a different behavior about writing its boot records. At this point, I could start Solaris by default. Vista did NOT boot for me - it was complaining about \Windows\System32\Winload.exe missing.

As such, I ran the System Recovery option from the Vista boot DVD, which reinstalled the Vista boot loaders. To be sure, I ran the bootsect.exe with switch /nt60 on the SYS volume.

For the restore options it is very important that you decline to have the boot problems fixed automatically .Just say "No" and click "Next" and you will be taken to a menu where you can get a full Windows shell - this is MUCH better than the recovery console.

3. Reboot into the Windows shell on the Vista Install DVD.

4. bcdedit /set {default} device partition=c:

5. bcdedit /set {default} osdevice partition=c:

6. Run d:\boot\bootsect /nt60 c:

You should be all set.

If you screw up GRUB

Now back into booting Solaris by throwing the Solaris install DVD into the drive, going to the command prompt of grub and specifying

	root (hd0,1,a)
        kernel /platform/i86pc/multiboot
        module /platform/i86pc/boot_archive

Great. Solaris boots. Now run installgrub(1M) with the following arguments:

installgrub /boot/grub/stage1 -m /boot/grub/stage2 /dev/rdsk/(this is the char device for your root slice)

NOTE: After you re-install GRUB, you will need to go back to the Vista Recovery console.

Here is a help page from Microsoft on BCDEDIT.EXE. Note that you must run COMMAND.EXE as administrator, otherwise BCDEDIT.EXE is not in your search path and will not execute.

Here is a discussion on how to use BCDEDIT in some more situations.