Blog Home  Sign In RSS 2.0 Atom 1.0 CDF  

  def Softwaremaker() :
         return "William Tay", "<Challenging Conventions />"

  knownType_Serialize, about = Softwaremaker()

 Wednesday, August 10, 2005

As timeline nears for Microsoft TechED Asia 2005 in Singapore (24th-26th August 2005), I have managed to firm up my topics. Besides the usual rather cryptic session topics and synopsis (Sessions [1] and [2]), I have added 2 of my own pre-packaged flavours into the mix (Sessions [3] and [4]). I hope the latter 2 sessions will be able to provide a cool new refreshing look at distributed computing (Web Services, ESB, EAI, WS-*) to the audiences and hopefully draw in some good crowds., 4 topics for the Softwaremaker. It is time to get to work on that.

1) Programming Indigo
William introduces Indigo for the first time to the masses in Singapore. He will explain the basis of its design and programming model and looks at the Whys and Whats of it. Indigo is a huge framework and he will bring the audience in for a quick sneak peek of the future of the Windows Communication Foundation and why it is not just another WS-Toolkit.
2) Building Secure Web Services Using Indigo
William introduces Indigo for the first time to the masses in Singapore. He will explain the basis of its design and programming model and looks at the Whys and Whats of it. Indigo is secure-by-default and offers many ways to tap into pre-existing security mechanisms for building connected, un-trusted boundaries. William will also share his thoughts on the interoperability aspects of WS-Security as well as the best way to move forward. William will also explain why WCF != WSE 4.0++. 
3) Transactions in Web Services and WS-OtherThings Developers Love to Hate
The above interesting refreshing Title IS the Synopsis. Enough said.
4) SOA, SOAP, WS-*, BP-1.0, WSE, ESB, EDA, WCF, EAI: Making sense of all the FUD
Tired of being fed the same stuff over and over to you again and yet have no idea what you are eating ? If you know these acronyms all too well but have no idea what they meant and how they fit into the grand scheme of things OR if you ever wonder sometimes if they are just fluff or stuff, this interesting refreshing session will address some of your Fears, Uncertainties and Doubts.
Birds Of A Feather Discussion Session Forum
1) Preparing Indigo
2) Migrating ASMX to Indigo
3) SOA, SOAP, WS-*, BP-1.0, WSE, ESB, EDA, WCF, EAI: Making sense of all the FUD
I am also in the midst of assisting INETA APAC to help co-ordinate a huge joint 3 Usergroups (WHAM BAM BIG BANG) session on one of those TechED nights. Steve Riley from Corp will, as usual, do what he does best and present on a security topic to all 3 Usergroups (Singapore .NET Usergroup, Singapore SQL Server Usergroup, Singapore Windows Usergroup). There will be a great networking event after his presentation. All in all, this should be a great event and will provide some value to those who cannot make it for the TechED day events.
I hope to see you there.
Wednesday, August 10, 2005 7:40:20 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Thursday, July 28, 2005

    The WinFX Runtime Components Beta 1 is available here, and the WinFX SDK is available here.  Also, check out the new Windows Vista Developer Center at

    With this release comes with the official names for many of the technologies that they've been talking with our developers about for several years. In particular, Windows Longhorn is now Windows Vista, Avalon is now the Windows Presentation Foundation, and Indigo is the Windows Communication Foundation.

     “Former” code name

    Official name




    Windows Presentation Foundation


    Windows Communication Foundation


    XML Paper Specification (XPS)

    Least-privileged User Access

    User Account Protection


    WinFX Runtime Components

    Thursday, July 28, 2005 3:23:37 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Wednesday, July 27, 2005

    I had such a fun time speaking in this Ark-Group event. Getting involved in the expert panel discussion led by Neal Ford of ThoughtWorks was a blast. We had a very good ratio of academic researchers and real-world industry and field experts in the audience to work out a very well-balanced discussion.

    As usual, I come from a real-world industry approach and sometimes, I cannot help but take pot-shots at the academics, all in good fun. . As Neal calls me, William the pragmatist.

    I was noted in the event as one who tends to go against convention (and this is not the first time I am doing this). For example, I am not about to get caught up in the SO(A) buzz and I urged the audience not to as well. The design principles of SO(A) such as loose-coupling, etc is something that has been around for years and the branding of all these principles under a new name just doesnt fool me. Of course, I challenged the audience to define the so-loosely-defined term SO(A) and everyone seems to have so many mixed views. It is one of those things that I termed 100 different answers for 50 different people --- depending on the time of day. Service-Orientation is a different thing altogether as it talks about how you should be using certain principles or tenets to design the interfaces and how to go about using them. Now, that I buy !

    This is also one of the few times I spoke out and caution against the use of a ESB or what I prefer to call as a message broker. Especially if the ESB is a productization of a vendor's proprietary technology. As one of the speakers had noted, it is not easy to maintain one, let alone implement it. Patches and fixes come in fast and furious. Someone in the audience has asked about the use of the ESB outside of the E, which I think the entire panel, including me, agreed that this will not happen in a long time to come (if at all).

    As I think I have articulated well enough to the audience, the reason for ESB today (and yes, value can still be derived from it today) is to hook up legacy systems using messages and for them to be using advanced (read: Enterprise) features such as Security, Reliability and Transactions which the broker provides. Of course, it is mostly a pull-thing here because the standards for these specifications are not ratified and matured yet. I am a firm believer that the emphasis is on the message and NOT the endpoints. Once the specifications mature and the Super-platform players introduce them baked into its kernel and core, the dumb nodes around the supposedly smart ESB plumbing suddenly wont seem so dumb after all.

    I have a strong inkling that Indigo will lead the way for that.

    Having said that, I dont think a mass-uptake will happen anytime soon. There is a huge consolidation in the ESB market today with WS-Management and WS-Registry players coming into the mix. I expect even further consolidation when Cisco introduced its appliance-based Application-Oriented Networking into the market.

    Will this be another nail in the coffin for ESB ? I believe it will be - provided the below quote is true.

    There's good news here -- no one interviewed for this piece believes that the Cisco move will spark a new generation of protocols.

    However, one potential issue is whether applications will have to be written specifically to AON and the network in order to take advantage of AON features. Cisco says no, but Randy Heffner, Vice President in Forrester's Application Development & Infrastructure research group, notes that "from the application side, it's going to take a while to figure out the implications of this. The key question is, "do I have to rethink my networking messaging processing?"

    Somehow, I think this will go to some great lengths in addressing the latency constraints of Service-Orientation. I hope so and I like what the market is doing to go all out to embrace the world of XML-Messaging.


    Wednesday, July 27, 2005 2:01:03 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  • Please take a look at the new MSDN site serving as the single content point for current ASP.NET customers to easily make the move to ASP.NET 2.0.

    Upgrade Center:

    Also, check out the new whitepaper that details the lessons learned, best practices, and valuable techniques that will help developers upgrade their apps.

    New Upgrade Paper:

    For general migration (ASP, competitive, etc.) content, you can always refer to the migration center at:

    Tuesday, July 26, 2005 11:58:21 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Tuesday, July 26, 2005

    The much anticipated download of a fully installed & configured Visual Studio 2005 Team System Beta 2 VPC is now available for download to MSDN Universal Subscribers. This is the same VPC that was distributed at TechEd USA and TechEd EMEA and represents a clean install of Windows Server 2003 w/ Visual Studio 2005 Team System Beta 2.

    VPC Contents:

    • Microsoft Windows Server 2003 Standard Edition
    • Microsoft Visual Studio 2005 Team Suite Beta 2 (expires May 1, 2006)
    • Microsoft Visual Studio 2005 Team Foundation Server Beta 2
    • Microsoft .NET Framework 2.0 Redistributable Package Beta 2
    • Microsoft SQL Server 2005 Community Technology Preview
    • Microsoft Office 2003 Standard Edition
    • Microsoft Live Communication Server 2003

    This VPC does not contain any sample projects or sample data.

    Minimum System Requirements:

    • PC with 2.0 gigahertz or faster processor
    • 1.5 GB RAM minimum
    • 10 GB available hard disk space
    • Super VGA (800 x 600) or higher video
    • DVD-ROM drive
    • Microsoft Virtual PC 2004 SP1 software

    If you have some trouble locating this developer-Godsend --- I have done some snopping already and it is here:

    Developer Tools > Visual Studio 2005 > Visual Studio 2005 Beta 2 > English > Visual Studio 2005 Team System Beta 2 VPC


    Tuesday, July 26, 2005 12:35:16 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Friday, July 22, 2005
    You may ... when it went under the moniker called Longhorn
    Friday, July 22, 2005 1:36:34 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Thursday, July 21, 2005
    Wednesday, July 20, 2005 10:38:17 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Friday, July 15, 2005

    As you can see from the comments I left there and I am re-producing it here:

    One of the things I noticed is that the .svc extension is strange if you look at it from a endpoint angle. Having

    is rather unnatural. I had a couple of attendees who actually thought it was a typo in the HOL (the HOLs are full of typos, btw) and changed it to

    Of course that didnt work as well. They had a hard time grappling with the unnatural look and feel of it.

    I would think that receiving client applications would do a double-take on this as well once they look at the actual endpoint address

    Getting rid of the physical file extensions would be a great and welcomed idea! Afterall, it is good convergence with the servlets of J2, Remoting and httpHandlers of .NET, Content Management Servers and others as well.

    If I am not wrong, isnt that how REST Web Service works as well ? Something like or It is a verb thingy. There is really no physical file on the other end.

    To me, its simpler as well as now if I have to change any type information, it will be in the .config file only and nothing more. God forbid customers to deploy multiple physical files as well ... and to some of us who are used to doing inline scripting in these asmx or svc files (for debugging and testing purposes, not for production use), .NET 2.0 already gives us dynamic compilation in App_Code

    To me, the solution is clear: Dump the svc file extensions

    If you have other ideas, opinions or just want to echo my same thoughts, do feel free to drop by Steve's post and let him know !

    Friday, July 15, 2005 9:54:04 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  • To those whom have attended Indigo Ascend and have asked me via emails: What acutally happens in the plumbings of the IsOneWay part of a Indigo Duplex Contract ?

    HTTP/1.1 202 Accepted is the answer. This is the explicit return.

    HTTP/1.1 100 Continue

    HTTP/1.1 202 Accepted
    Date: Fri, 15 Jul 2005 08:56:07 GMT
    Server: Microsoft-IIS/6.0
    MicrosoftOfficeWebServer: 5.0_Pub
    X-Powered-By: ASP.NET
    X-AspNet-Version: 2.0.50215
    Cache-Control: private
    Content-Length: 0

    This, of course, only applies to the HTTP Bindings.

    "The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this.

    The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled."

    Friday, July 15, 2005 9:14:47 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  • According to Don's blog here: Indigo has support for REST since Day 1. In the same breadth, he disclosed that it will explicitly support HTTP PUT/POST/DELETE/GET to please the REST purists out there.

    Like Steve mentioned here, I, too, am not a fan of technology stacks that complete with their own ideologies. To me, technology is there just to get a job done efficiently and effectively. My post here attracted quite a fair bit of hits and same-echo-sentiment emails. It even made to ZiffDavis blog list here.

    As Steve has echoed as well, I am also even more convinced now that Indigo is going to be the platform to beat when it comes to distributed communications. No doubt about it.

    I am really glad that the Indigo team, whom I think comprises some of the brightest minds in the software field, is all united to work towards a common goal of creating a religion and ideology-agnostic product. If this is not innovation, I dont know what is.

    Show me the money, Beta1

    Friday, July 15, 2005 4:40:50 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Thursday, July 14, 2005

    The perennial question: Love or Hate your Project Managers (PM) ?

    Three men: a project manager, a software engineer, and a hardware engineer are in Ft. Lauderdale for a two-week period helping out on a project.

    About midweek they decide to walk up and down the beach during their lunch hour. Halfway up the beach, they stumbled upon a lamp. As they rub the lamp a genie appears and says "Normally I would grant you 3 wishes, but since there are 3 of you, I will grant you each one wish."

    The hardware engineer went first. "I would like to spend the rest of my life living in a huge house in St. Thomas, with no money worries and surrounded by beautiful women who worship me." The genie granted him his wish and sent him on off to St. Thomas.

    The software engineer went next. "I would like to spend the rest of my life living on a huge yacht cruising the Mediterranean, with no money worries and surrounded by beautiful women who worship me." The genie granted him his wish and sent him off to the Mediterranean.

    Last, but not least, it was the project manager's turn. "And what would your wish be?" asked the genie.

    "I want them both back after lunch" replied the project manager."

    • If you get in my way, I'll kill you! - ideal project manager
    • If you get in my way, you'll kill me! - somewhat less than ideal project manager
    • If I get in my way, I'll kill you! - somewhat misguided project manager
    • If I get in your way, I'll kill you! - A tough project manager (eats glass, live cats, etc.)
    • If get kill in will way I you. - dyslexic, functionally illiterate project manager
    • I am the way! Kill me if you can! - messianic project manager
    • Get away, I'll kill us all! - suicidal project manager
    • If you kill me, I'll get in your way. - thoughtful but ineffective project manager
    • If I kill you, I'll get in your way. - project manager who has trouble dealing with the obvious
    • If a you getta ina my way, I gonna breaka you arm. - project manager from New York
    • I am quite confident that there is nothing in the way, so no one will get killed. - project manager who is about to get in big trouble
    • If you kill me, so what? If you get in my way, who cares? - weak, uninspired, lackluster project manager
    • If I kill me, you'll get your way. - pragmatic project manager
    • Kill me, it's the only way. - every project manager to date

    Everyone in the project team (PMs, Engineers, Developers, etc) have a key part to play and therefore a right to exist within a project environment...and the key point is that --- Everyone wants to take care of the customer since they are the ones paying but we take care of them in our own (I know its right) ways and sometimes if anyone wants to go home earlier, it is usually at the expense of another.

    There is no exact science to this. It is mainly art. If it was pure science and everything is so researched, proofed and documentated, we would not have this diagram (which has been in existence for years) still making great jokes and headlines today.

    Thursday, July 14, 2005 5:34:10 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions