Blog Home  Sign In RSS 2.0 Atom 1.0 CDF  

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

  knownType_Serialize, about = Softwaremaker()
 

 Monday, May 09, 2005

I was recently quoted in the press talking about OSS vs. proprietary platforms and solutions. It appeared in the IT Lifestyle Section (Digital Life) of our national newspaper --- The Straits Times 03 May 2005

I had said, and I quote:

... mutivendor expertise and support may be hard to come by for Linux and OSS. And these can add up to a higher total cost of ownership compared to pre-packaged Windows ...

Please click here to see the exact article in pdf form.

MyQuoteInThePress

Monday, May 09, 2005 9:52:32 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Thursday, May 05, 2005

    Fellow Microsoft Regional Director and a software legend, Rocky Lhotka posted an interesting entry on Message-based WebMethod "overloading" here.

    In it, he recommends (and I quote) that service methods use a request/response or just request method signature: 

       response = f(request)

    or

       f(request)

     "request" and "response" are both messages, defined by a type or schema (with a little "s", not necessarily XSD).

    The actual procedure, f, is then implemented as a Message Router, routing each call to an appropriate handler method depending on the specific type of the request message.

    I couldnt agree more. While easier to comprehend, the practice of passing parameters to a Web Method call often sends the wrong messages across as (W3C) SOAP as just another RPC. Ultimately, if you have no idea and dont even want to grok the innards of the XMLSerializer, you would really think you are passing method parameters across or worse, think that you are ferrying objects across the wire.

    Therefore, I firmly believe that it is for the good of all if you explicity specify that you are expecting a XMLDocument / XMLElement / XMLNode and you will dispatch the same on your endpoint. What you do at your implementation (whether it is serializing from a type to deserializing from one) is placed squarely at the mercy of the tools in your hand or the knowledge in your head.

    With the current state of tools (or lack there-of) today, I sit on the same camp as Aaron Skonnard and Christian Weyer (plus others, I believe) as I believe firmly in the contract-first approach. Good devs should dig what is going on as close to the wire as possible, at least once. Then they can use all the wizards and helpers they want. This will help them understand better what is going on if they should need to troubleshoot later (leaky abstractions) or find other ways to improve performance.

    This is just something that my team and me here have gathered over the years esp when I have got many developers out there working on the same solution offshore in different countries.

    While I agree that not many people out there enjoy or want to grok the angle brackets and that the lack of tools out there is hugely to be blamed, tools make a productive developer but not necessarily a proficient one.

    Until today, I still come across developers that still think Web Services are still about transferring an object across the wire. Having terms like "Web References" and "proxies", even deemed to be more abstract and dev-friendly, does potray the wrong ideas across.

    I have always recommended younger developers who are interested in learning about Web Services / ASMX and SOAP to try out the (just-now-defunct) Microsoft SOAP Toolkit first before moving on. I find that to be a great interesting way to learn about XML SOAP Services as abstractions are kept to a minimum. Another great SOAP Toolkit in the face of Microsoft's non-supporting stance of its own is Simon Fell's PocketSOAP.

    Another fellow Regional Director, Bill Wagner (who authored an very impressive book "Effective C#") posted his solution to Rocky's post here. I have used the same sort of approach that Bill had documented before and it is good and does serve its purpose. However (and please correct me if I am wrong), it bounds the message contracts and datatypes tightly to the WSDL. If I am going to add a third Request / Response pair of classes, it will render my initial WSDL invalid (unless of course, if I am willing to add an additional endpoint)

    I worked on a project before which specify that (newer) datatypes are to be added in phases and therefore, we had to decouple the XSD from the WSDL (which is in accordance with one of the best practice of WSDL Deployments -- modular and the separation of concerns). Oh, by the way, this is practiced in Indigo.

    I don't know if there is a way to decouple the XSDs from the WSDL in VS2003 today. Even if there is, I am guessing it is a difficult hack at best. So, what I did was to create the XSDs for each datatype as they come along and do a XSD import in my WSDL. At my message exchange contract, I used an open content type with xsd:any. Thereafter, I author my own WSDL with the help of Christian's and Thinktecture's WSContractFirst. Since the message and the datatype XSDs are all imported, the wsdl actually has a small footprint now. With the wsdl /server switch, xsd:any becomes an XMLElement type. For abstraction within my service, I changed it to an object in my implementation detail.

    Note: .NET 1.1's WSDL.exe /server switch, in my mind, is still fairly limited and comes with a couple of annoying things I didn't like BUT I will expand this in detail later.

    [System.Xml.Serialization.XmlTypeAttribute([Namespace]:="urn:softwaremaker-n
    et.swmstoreexchangemessages"]> _
    Public Class Response
      Public Result As Result
    End Class

    [System.Xml.Serialization.XmlTypeAttribute([Namespace]:="urn:softwaremaker-n
    et.swmstoreexchangemessages")] _
    Public Class Result
      [System.Xml.Serialization.XmlElement(ElementName:="Book",
    Type:=GetType(BookType),
    Namespace:="urn:softwaremaker-net.swmstoreextendedtypes"), _
      System.Xml.Serialization.XmlElement(ElementName:="CD",
    Type:=GetType(CDType),
    Namespace:="urn:softwaremaker-net.swmstoreextendedtypes"), _
      System.Xml.Serialization.XmlElement(ElementName:="Anything",
    Type:=GetType(AnyType),
    Namespace:="urn:softwaremaker-net.swmstoreextendedtypes")] _
      Public Any As Object
    End Class

      Public Function
    ProcessRequest([System.Xml.Serialization.XmlElementAttribute([Namespace]:="u
    rn:softwaremaker-net.swmstoreexchangemessages")] ByVal Request As Object) As [System.Xml.Serialization.XmlElementAttribute("Response",
    [Namespace]:="urn:softwaremaker-net.swmstoreexchangemessages")] Response
       '...
       End Function

    Once the consumer points to my wsdl (I turned off documentation of asmx by default), all the XSDs are imported by VS2003 as well (and that is a good thing). The xsd:any is still an XMLElement over at their end and we leave it as it is since we cannot control what they do there. The consumer can choose to deal with the raw XML if they want to OR do an xsd.exe imported.xsd /c and let the XMLSerializer do its (limited) magic .

    In this sense, no matter how many more datatypes I add or remove, my wire-contract remains the same. I just let the endpoints serialize / deserialize the open-content xml (xsd:any). In my project I had mentioned earlier, I have one asmx endpoint servicing multiple consumers each sending different messages that conforms to different XSDs (For example, GroupA sends BookType and GroupB sends the CDType as well as a GroupC next time that sends a type that is unknown to me today). The thing I need to take care of is to send the appropriate datatype xsd to the appropriate groups so they can serialize / deserialize into the appropriate types. As you can see from the code snippet above, at my asmx, I will just add any new datatypes that come along.

    While, this may seem like too much compared to Bill's solution above, it was necessary to decouple the datatypes from my wsdl in that project and the XSD Editor (codenamed: daVinci ?) in VS.NET2003 was the best tool I had in hand at that time. Developers are too comfortable with objects. This is obviously natural with the decade-long evolution of Object-Orientation and the power of abstractions the OO tools and languages bring today.

    However, other factors like time, extensibility, standardization make abstractions expensive...and among others, these are all factors that make up the principles of the move towards Service-Orientation. Now, if we have to make and designed services to be explicit, this means that devs need to know they are explicity invoking a service across the wire, how far can the tools go to hide all the plumbings and yet not hide the fact that the service is on the other side and not just a mere shadow copy of a remoting object that seems to reside on the same application domain.

    Will Service-Orientation fail to hit the mainstream because of this ? I dont know. I guess only time will tell.

    Thursday, May 05, 2005 2:22:18 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Wednesday, May 04, 2005

    Ian Yates interviewed me for what turns me on for MSDN Magazine SEA Edition. Read about it here.
    © MSDN Magazine SEA Edition

    Wednesday, May 04, 2005 4:26:50 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Saturday, April 30, 2005

    With reference to my earlier post here, more details on the conference (SDA.NET 2005) are now publicly available here. This is a paid event and it is rarity in Singapore as technological conferences are usually presented free. BUT I am sure attendees can find a lot of value here as top notch speakers from all over the world will be flying over here to share their industry experience and knowledge.

    Who are these speakers, you ask ? There is the famous Ingo Rammer and Clemens Vasters and of course, moi .

    I will be making 2 presentations in the VIP Tracks, namely

  • Demystifying WSDL (26 May 2005 1045 hours)

    While developers rely on the many powerful features of today's IDEs, inner technical plumbings are often ignored and worst yet - misrepresented and misunderstood. This ignorance of inner workings can lead developers to choose the wrong technologies and solutions for solving specific problems. Nevertheless, when it comes to troubleshooting the nooks, crannies and crevices at crunch time with no extra help, nothing beats a dirty pair of hands, a hammer and screwdriver. William Tay attempts to get everyone's hands dirty with a detailed look at WSDL, one of the most core and mature XML service technologies of today.

    Topics to be covered include: what is WSDL, WSDL's critical role in service-orientated architecture (SOA), and WSDL's core elements and definitions. He will also survey WSDL best practices (eg. interoperability, extensibility, versioning, etc.) and the application of WSDL concepts in Indigo. The new features and enhanced functionality incorporated into the upcoming release of WSDL 2.0 are explained and compared with the current WSDL version.

    NOTE: This is a (Level 400) deep technical session that is not for the faint-hearted. However, it will be a angle-bracket fest.

  • SOAP Message-based Security: Today and Tomorrow (26 May 2005 1415 hours)

    One of the three key pillars of critical importance in the adoption of SOAP messaging-based services in an enterprise is security. In fact, the security aspect of standards-based messaging system has been singled out by worldwide CXOs as the most inhibiting factor in the mainstream-wide adoption within an enterprise. The ratification of WS-Security 1.0 by OASIS on 6 April 2004 has gone into great lengths to change that perception. William will show how and what you can do to secure your SOAP messaging-based services today. You will also learn how the same standards-based WS-Security Specifications can be used to secure the next generation of distributed web services with Indigo.

    All 3 of us are presenting on Indigo as well. This will be a good time to catch a preview of Indigo and have a feel of what it is all about. I really hope to see a good turnout there and it will be a good time to catch up with Ingo, Clemens and the rest of the folks.

    See you there.

  • Friday, April 29, 2005 11:20:56 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Wednesday, April 27, 2005
    Tuesday, April 26, 2005 10:28:06 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Tuesday, April 26, 2005

    ...and it is in Longhorn Client with Speech Recognition.

    I have just finished attending Richard's demo and I must say it has convinced me of the future. He was speaking on the "Future of Speech Recognition in Microsoft" in the MSFT Corp APAC Regional MVP Summit 2005 here in Singapore.

    Without going too much into details, he showed many cool demos (what is a Speech Recognition prezzo without demos anyways) where he uses a Wordpad as a prop, then proceeded to do more cool demos by speech-enabling a ASP.NET 2.0 Web Application. One word to describe it all C...O...O...L

    He then proceeded to say "Bring up Windows Media Player" and then said "Play Beethoven Symphony No. 9" before the sweet sound of classical music piped through through his notebook's speakers. I am no classical music fan BUT it sure did sound sweet to my ears. This will sure bring a hot date with a gorgeous babe to second base .

    Everyone was clapping, wooing and wowing at all these demos. However, one thing that I found was very good which I felt was lost on the audience is that when he typed the word "MVP" as part of a long sentence in Wordpad, the client echoed back the letters "M.V.P" instead of the word "mufffp". Now that is cool. . Have I finally seen Computing Intelligence at the personal user level ?

    Now, this is what Computing should be in the future. Bill Gates kept talking about making it simpler and seamless. I think he meant Natural as well. Typing and QWERTY is NOT natural, although it may seem to the endless hordes of graduates and youngER professionals I met over the past few years who can type or SMS at light warp speed. However, they cannot seem to carry on a decent intelligent conversation face-to-face. INK and Speech technologies is making computing revert back to the primitve ways on how man carries on in his commumication patterns (and it is about time) --- and that is to speak and write...and NO ! Typing is not innate to the human being. After almost 4 decades, I still cannot type in a decent way.

    Microsoft has spent a tremendous amount or resources and investment in harvesting these technologies and innovating it to make it easier for the end user. It is not about XML, Web Services, etc. These facets shouldnt just be a blackbox to the end-users. It should be invisible to them. This bodes well for the computing landscape of the future

    By far, the best presentation I have seen in this summit. You can read more about the Longhorn Speech API here and Longhorn managed speech APIs on Windows XP here.

    I am a believer.

     

    Tuesday, April 26, 2005 10:28:34 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Thursday, April 21, 2005

    MSN7DateTime1.JPG

    I am on a roll. Since I tinkered with some client-based programming here as part of a small weekend project, I suddenly get this huge urge to do some more geeky client-GUI stuff.

    I have generally been doing much of my work in the distributed systems area and therefore are known to be much of a server guy or a (W3C) SOAP, XML geek to many. However, like many of people who has ventured into the software development world of Windows, it usually starts at the desktop...and for me, it is VB3 - VB6, including VBA. OK, I risk the MFC, C++, Java, C# people spitting at me here so I better stop.

    Anyways, I have always love the Internet Messenger (IM) and the genre of Presence Technology it brings. To think that if I had those technologies back in the late eighties while I was away in university in Canada, I wouldnt be writing those huge 'costly' paper stacks of letters to my folks back at home every week and I would still have kept in contact with my childhood friends. Hey, what can I say, I was too lazy to write them...

    MSN Messenger is what I have always used as my IM, and then again, I have not used any other. It is currently in Version 7 at the moment and the enhancements that come with each version never seem to amaze me.

    However, one pet peeve I have is the "Turn on What I am listening to" feature which I think, in my opinion, is for people with a narcissistic streak in them. There is nothing that turns me off than to imagine all the contacts in my list displaying the songs they are listening to at that moment. I dont know about you BUT I would be hugely embarrased if I have Britany Spears's I Am Not A Girl, Not Yet A Woman on my playlist.

    So, I thought I do some mucking around with the MSN Messenger Window to see if I could do some Windows SubClassing into its Windows Handle. For all those of you who dont know the essentials of Windows are, I took the liberty to quote Aaron Ballman from his link I have referenced above:

    All GUI applications on Windows are driven by getting messages from the operating system, and translating them into events for the user to handle. So when the mouse moves, a window is given a message telling it that the mouse has moved, and here are its current coordinates. Or when the user presses a key, a different message is generated and a window is alerted. This message dispatching is how all events are fired in REALbasic -- the system lets the framework know something has happened, and the framework passes the information along to you in the form of an event.

    If you are going to try writing a GUI component in REALbasic, you will most likely need a way to hook into this magic function that the OS calls in order to receive notifications of what the user is doing. For example, if you wanted to write a TrayIcon class you might want to be notified when your icon is double-clicked on so that you can fire an action event. Before we get into the details of how to accomplish this, you should be brought up to speed on the terminology and concepts involved.

    If you're coming from the world of C/C++, .NET or even Visual Basic, the magic function being described may be familiar to you. It is traditionally called a WndProc (pronounced 'wind-proc') and it's short for window procedure. You let the system know what WndProc to call by specifying one in a window's class definition (called a WNDCLASS) structure, which is then registered with the system. Every window created with that class definition will have its WndProc called by the system for all messages. The OS knows when to call the WndProc because there's a loop in the application known as the message pump which handles all the message passing. A typical message pump will look something like this (in C):

    I had done some of those Windows programming before back when I had more hair so this is not a foreign concept to me. I dug out my old Win32 API Programming book to get myself acquainted with all the Windows Handles API again. I must say that I really enjoyed that as it did bring a sense of nostalgia to me. All the technical documentation about Windows Handles, Message Pumps, Windows Subclassing, Function and Memory Pointers and \0String Buffers\0 did get me excited for a while.

    Then, I took a couple of nights off from sleeping (Hey, I have a real job...) and started doing some programming work against the .NET Framework...and before you know it, I have cooked up something that I would humbly think is quite respectable. Check out the screenshots on this page. OK, I admit the Application UI is nothing to shout about and I am ashamed to say I have failed Design, Usability and Color-Coordination 101 lessons in school. .

    Basically, I allow the user to feed into the MSN Messenger their current location (I will explain more later...), the host machine's date, time and timezone as well as some user-defined caption. Since there is a clock element involved, I had to add a timer to constantly update MSN Messenger on the current time. The timer frequencies can be set as 1, 5, 10 seconds and 1, 5, 10 minutes. And for those who have some bandwidth restrictions (I believe MSN Messenger sends a packet over the network to inform all your contact list on you next message text), there is a UPDATE ONLY ONCE feature that updates once and then disables the timer.

    As for the location, as I have many contacts on my list who travels frequently and they like to put their current location on my MSN Caption, so I figured this would be a useful feature and I wanted to make it automatic with no user intervention. I then wrote up a simple Where Am I Web Service that returns the Country name and code of your current location based on your IP address. An IP address is pretty accurate in telling your current whereabouts country-wise. Your IP address that you sent to my Where Am I service would be the public-interfacing IP address of your Wide-Area-Network. In this sense, you could be booting up this little application in Japan, Panama, Canada or the US and it would return your current host country automatically.

    (On a more geeky note, I have invoked this Where Am I Web Service asynchronously [not via a duplex channel], so there is no Freeze-Hanging effect once this application is loaded. It really is quite cool to see your host country being reflected in your application once it returns from the service)

    Now, wouldnt it be much more cooler to display all these Location and Time settings on your MSN instead of showing off what you are listening to ? Now, if everyone uses this tool, it would be nice to see everyone on my contact list from all over the different countries from all the (5 ? 6 ? or is it 7 ?) continents in the world.

    I also played around with the system.diagnostics and processes a bit so that ONLY one instance of the application be loaded at only one time. This is really one of those rare times that I have done development work without any considerations for object pooling, scalability, load-balancing and the handling of muliple connections, etc that comes with the domains of distributed systems. Way cool. I like it !!!

    I added some enhacements to it as I figured that there are way more narcissistic people than I think there are. (Oh, btw, I am blogging --- Am I narcissistic then ?) BUT I had to think of something more useful and functional. Then I realized maybe people would want to show what they are currently working on at the moment. This could be done via the Active Window Handle API. You could then show off to your boss that you are currently working on your assignment at the moment. However, do take note, you would be announcing to everyone that you are surfing for Internet Pornography as well so use this feature with care...

    Of course, all these features can be turned on and off with a knob. Anyways, I have tested this with Windows XP and 2003 Server and it works. Other than that, you are on your own. You would also need the Microsoft .NET Framework 1.1 for this. You can get it via your Windows Update or download it here. Since this is freeware, please read the license before downloading and installing it.

    Download it here now. Enjoy !

    TO-DO

    1.  To add more features
      • Someone mentioned to me to show the current available computer memory at the moment. This could be bragging rights for someone with a 2 or 4GB RAM Machine or someone who is willing to contribute their system resources to the SETI @ Home Project. Let me know via comments on this post if you would like this feature.
    2. I dont really know how to remove that irritating headphone icon thingy. Let me know via comments on this post if you know how or could offer any advice.
    3. Hyperlink the text. Again, I dont really know how to do this so I would appreciate any advice and such.

    I hope this serves as some kind of feedback to the MSN team as well so they know what to include for MSN Messenger 8 next time.

    MSN7DateTimeApp.JPG

    Thursday, April 21, 2005 2:51:11 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions