I had the recent pleasure of meeting up with active blogger Mitch Denny who is one of the Microsoft Indigo Ascend attendees which I conducted last week in Sydney, Australia.

He spent some time blogging about what was learnt during the 3-day session. A very good read here, here and here for all who is interested in knowing the color of Indigo.

What a cool dude. You rock, Mitch !

I really wish I was there to hear Steve Jobs deliver this in person.

In more ways than one, I have always tended (and tried) to live my life and my career path as the way he does. It is a pity there are so many people I know today that have this huge dose of pragmatism built in, whether it is in-bred, cultivated or through an accumulation of bad experiences, that prevents them from achieving the best they can because tangible$ gets in the way.

...which explains why there are only a few Steve Jobs-types in this world. It is only when you realize how close to death you are then you find out how to live life.

The thing that bugs me the most is that those overbearing "guardians" do tend to blanket these theoretical by-the-book advice on the younger ones in the industry who are born so full of curiosity and enthusiasm. By doing so repeatedly, they kill those creative elements in these people.

Chaos breed creativity.

People who live life making a few mistakes (which could be the cause of circumstantial instances and therefore through no fault of theirs) tend to keep an orderly, on the right-side of the road perspective of life. While this is not wrong, they should not be telling people on the other side of the road that they are travelling wrong if they cannot even tell where the traffic is coming from a few years down the road.

A lot of people put a value on the tangible$ to define the end goals in life. What they are essentially doing is putting a buffer on the money coffers to add a false sense of security (or some say, happiness) in life.

To me, as cliche as it may sound, the journey is the reward and the justification of that is the end goal. While I am the last person to say that tangible$ are the least important thing in life because I sure need it to pay the bills and feed the mouths, I make it a point not to be greedy.

Like what Jobs had said --- "Stay Hungry. Stay Foolish." I am making sure my son learns that, in the right way and right context, of course.

A magazine recently ran a "Dilbert quotes" contest. They were looking for people to submit quotes from their real-life dilbert-type managers.

Winning quote from Fred Dales, MS Corp Redmond

"As of tomorrow, employees will only be able to access the building using individual security cards. Pictures will be taken next Wednesday and employees will receive their cards in two weeks."

Could this be the reason why Longhorn is delayed. Except that it is in years instead of weeks.

WS-MetadataExchange is used and enabled by default in Indigo and it comes with WS-Policy as well.

This is one specification that I find really useful because the current convention of using http-get to get the metadata from asmx?WSDL is still a very .NET sort of convention. For my projects, I usually like to put the metadata in a physical file and deploy it as *.wsdl. Other people and toolkits will also have their own naming conventions.

While using http-get is a very useful convention of retrieving metadata, we cannot assume that all services will support HTTP. In Indigo, it’s common to expose an endpoint that only listens over IPC or SOAP-over-TCP.

At its current Beta 1 drop, only http / https will be supported. I do forsee that tcp will be supported in the next major drop.

In Indigo, the WS-MetadataExchange endpoints are added to the (http) service by default at the container-baseAddress/containee-endpointAddress as a mex suffix. You can also choose to define your own custom mex endpoints. Another wonderful thing it supports is that it allows the specifying of a custom metadata file (which I know I will be definitely be using). In other words, instead of getting Indigo to automatically generate the metadata, it will send the requestor to the uri location of the metadata file I specify.

If you have done some UDDI work before, you would be accustomed to the convention of sending standardized (W3C) SOAP Request messages for querying purposes. WS-MetadataExchange uses the same sort of principles, albeit with different querying implementations.

Here is how it works. There is no better way to illustrate this than to get really friendly with the wire-layer plumbings. I have a tool here that will give you a good view of the exchange.

You need to send a standard SOAP request to the listening mex endpoint that goes like this (Replace the square brackets with angle ones)

  [s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing"]
    [s:Header]
      [a:Action s:mustUnderstand="1"]http://schemas.xmlsoap.org/ws/2004/09/mex/GetMetadata/Request[/a:Action]
      [a:MessageID]uuid:f22ee227-3eeb-460d-9352-1a34e97bf911;id=0[/a:MessageID]
      [a:To s:mustUnderstand="1"]http://localhost/servicemodelsamples/service.svc/mex[/a:To]
      [a:ReplyTo]
        [a:Address]http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous[/a:Address]
      [/a:ReplyTo]
    [/s:Header]
    [s:Body]
      [GetMetadata xmlns="http://schemas.xmlsoap.org/ws/2004/09/mex" /]
    [/s:Body]
    [!-- OR an Empty SOAP Body will do just as fine --]
    [!-- s:Body /--]
  [/s:Envelope]

In the tool I had build, you need to put the a:Action value (in bold above) into the SOAPAction textbox as this has to be propagated up to the HTTP-Headers as a SOAPAction header. This is one of the sticklers of using http to query for any SOAP Web Service. Once you clicked post, you will see a good-looking response with all the metadata of WSDL and WS-Policy in the SOAP body. I took out a lot of details in the constraints of space. You should be able to get the point.

  [s:Envelope xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:s="http://www.w3.org/2003/05/soap-envelope"]
    [s:Header]
      [a:Action s:mustUnderstand="1"]http://schemas.xmlsoap.org/ws/2004/09/mex/GetMetadata/Response[/a:Action]
      [a:RelatesTo]uuid:f22ee227-3eeb-460d-9352-1a34e97bf911;id=0[/a:RelatesTo]
      [a:To s:mustUnderstand="1"]http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous[/a:To]
      [ActivityId xmlns="http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics"]uuid:a55fa135-e1b9-4557-a7c3-39cbf042f85d[/ActivityId]
    [/s:Header]
    [s:Body]
      [wsx:Metadata xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex"]
        [wsx:MetadataSection Dialect="http://schemas.xmlsoap.org/wsdl/" Identifier="http://tempuri.org/"]
          [wsdl:definitions]
            [!--WSDL and XSD GUNK--]
            [!--XSD GUNK--]
            [!--WS-Policy GUNK--]
          [/wsdl:definitions]
        [/wsx:MetadataSection]
      [/wsx:Metadata]
    [/s:Body]
  [/s:Envelope]

You will be able to load endpoints, bindings and types dynamically at runtime with such information.

Do take note that Indigo is extremely strict about the mediaTypes headers and you need to set the contentType of the Http-Headers to application/soap+xml. This can be done in the configuration file.

Do download it and try it.

If you think this is a cool new feature in the Microsoft technology space, it is not.

Web Services Enhancements (WSE) 2.0 also had it. All you need is to send in a "http://schemas.microsoft.com/wse/2003/06/RequestDescription" in the Action of a SOAP Message request to a listening WSE 2.0 service and you will be presented with the WSDL as well. This is what WseWsdl2.exe does you switch in a TCP address.

This is a stress ball I will be giving out during an Indigo training seminar / presentation.

Sometimes, I wonder the significance of giving out stress balls for training events like these. What are they trying to say? What does it say about the product you are selling? If you use this, you may need this stress ball to squeeze and to whack against the wall instead of pulling your hair out when things dont work as smoothly as they are supposed to? Yes, it will cause you that much stress.

Why can't they ask me to give out a cold beer or hot coffee or something ? It can convey the message that if you use our product, you can have your cold beer before it gets warm or sip our hot coffee before it turns cold.

My opinions, strictly.

I will be delivering Indigo Ascend in Asia Pacific in the coming months on behalf of the Indigo and Ascend team in MSFT Corp, Redmond, US.

It will start in Sydney, Australia later this month, then move upwards (northwards) to my own local backyard, Singapore. There are a few more countries Microsoft and I are interested to look at bringing this event as well.

This will be a good time for me to meet up with real customers from the enterprises who are using Microsoft distributed technologies or are planning to look into using it in the future. Drop me an email here if you would like to engage me for a discussion.

If you are reading this blog post and you work for an ISV or an enterprise that does a fair bit of distributed computing technology and you are interested in attending this Indigo Ascend in Singapore (I think we are a little bit late in nominations for Australia), do drop me a mail here and I will see what I can do to hook you up for this 3 day event.

If you are from anywhere else besides Australia or Singapore (in APAC) and would love to attend an event like this, do drop me an email as well and I will see what I can do to bring Indigo Ascend to your country.

I have been invited to deliver a few Ascends before such as Visual Studio 2005 and such. However, I have always turned it down because I dont consider myself to be a "professional" trainer since I have always been on the field working on real projects with real problems in distributed technologies for some time (and not some simulated fanciful classroom labs scenarios) ...

... BUT...

Indigo is an Ascend which I am proud and excited to deliver because it is a future facet of Windows Server 2003 that I have spent quite some time on and I believe it is something that real customers need in the field to solve real-world problems today.

There is really nothing quite like it out there at the moment or in the immediate future outside of Microsoft. It is really one of Microsoft's innovation at its best.

I have recently flashed some performance graphs between Java 1.5 and the .NET counterparts version 1.1 and 2.0 Beta2. This is where I got the statistics from.

You will see the outright disparity in performance gains when .NET 2.0 Beta2 is put through the same tests with its poorer 1.1 brother and its distant cousin Java 1.5.

...And we are still talking about .NET 2.0 BETA 2 ... Let us see what happens when we get to November 7 2005

I have been receiving business and technical content on CDs / DVDs for years and I have always taken for granted that CDs / DVDs are very durable media types. I mean, have you ever tried breaking a CD ? It is not easy and cannot happen just "accidentally".

I was wrong.

I received this (See below pictures) in my mail (by a reputable courier) 2 weeks ago. It was packaged in a plastic envelope and not in a hard box and was damaged in transit ... The damage is actually much worse than it seems in the pictures. Lessons learnt:

1. Ship CD / DVD out in a hardbox, even if it is a single piece
2. Dont play at the edge. If you are expecting the content to come in a day or two before you need to use it, you are playing with fire. Get it way way way in advance before you need it. You may need a re-send again if get the below.
3. Shit happens.

Web Services Enhancements (WSE) 3.0 CTP is released.

Here it is. The runtime is here. The notes for the CTP are here. The HOLs are here and here. Go geek out !

My own little test utility tool - Manual SOAP Post has been seeing a fair number of downloads and I have received some good compliments on it as well as good feedback.

Actually, it is really nothing to shout about. It is one of those tool things that people have been using under the hood and therefore taken for granted. Since I have been doing a fair amount of work in terms of wire-interoperability, I figured that an abstraction (or proxy)-neutral tool would be good from a common point. So, I am being explicit in crafting out a message (bypassing the various abstractions that SOAPHttpClientProtocol, WebServicesClientProtocol,