Blog Home  Sign In RSS 2.0 Atom 1.0 CDF  

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

  knownType_Serialize, about = Softwaremaker()

 Tuesday, May 05, 2009
Tuesday, May 05, 2009 2:16:00 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Monday, May 04, 2009

    Both references are good reads and would propbably be a good debate topic for many but lets not do the religious cult thing:

    Abstraction, Componentization, Reusability, etc. They have all changed the world the developers live and breathe in, havent they ? No, I dont want to sauter transistors on a motherboard anymore. Give me a PC anytime. Give me solutions.

    My personal opinion is that there is no end and you cannot find a answer that fits all. Question one has to ask is:

    • Are you looking for a brick builder/manufacturer
    • ... Or are you just interested in building a wall/house ?

    Make no mistake, I think there is a market for both. However, chances are, no one single good person will fit both bills. 

    Monday, May 04, 2009 3:40:46 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Friday, April 24, 2009

    This is a good tip for all who are who are running Windows 64-bit:

    To be able to host a Silverlight 3.0 in a frame in a Windows Presentation Foundation (WPF) Application on 64-bit Windows, you may hit some obstacles your WPF application will load the 64 bit version of IE – which cannot load Silverlight currently.

    Now, IE is really an x86 application, even when running in Windows x64. So, the actual real issue is mshtml. mshtml comes in both 32- and 64-bit flavors.  Since by default the WPF application is compiled as processor agnostic (bingo!), it floats to x64 and gets the 64-bit version of mshtml.

    Therefore, try this to resolve: Compile the WPF application as 32-bit.  The project’s “Configuration Manager” in Visual Studio should be able to help with this.

    Friday, April 24, 2009 1:34:44 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Friday, October 24, 2008

    Ahhh ... it has been a while, hasnt it ?

    My life is just torn between working with bits of 2, beats of 4 and nucleotides of 4. But while challenging, it has been really fun. As spoken to a friend today, my passions in life seeks out to expand the comfort boundaries of gray matter, which we called the mind and to constantly challenge and stimulate the brain to learn and absorb new things that one would never think of learning if one boxed themself in a virtual space, which techies like me would call "typecast".

    One example that I highlighted to my friend today, which I respectfully pointed out to them that he falls under, is when he said: "But we tech people are not good at talking to people and engaging them in meaningful conversations ..."

    Typecast alert !

    I ended up talking with him (not to him) for a good 20 minutes and told him we just had a meaningful conversation and that he could hold one really well. I told him that he himself set up this virtual boundary to box himself in. No one did and that he could easily remove this barrier and elevate himself to do and more importantly, to learn new things and behaviors. Instead of having new curiousities about old things, have new questions, passions and interests towards new things.

    Anyways, I wont be talking about my new-found passions here but I will be briefly touching on a topic that many people knew I have passions for (and I still do) - and that is the innards and the plumbings of software technologies.

    I came across types of this type of questions a lot in emails, forum questions and usergroup events:

    openquotes.png I have this WSDL file that looks something like this:

    <?xml version='1.0' encoding='UTF-8'?>

    <definitions name="someCustomer" targetNamespace="urn:someCustomer" xmlns:typens="urn:someCustomer" xmlns:xsd="" xmlns:soap="" xmlns:soapenc="" xmlns:wsdl="" xmlns="">
          <message name="add_someCustomer">
                <part name="resId" type="xsd:string"/>
                <part name="cPortable" type="xsd:string"/>
          <message name="add_someCustomerResponse">
                <part name="add_someCustomerReturn" type="xsd:string"/>
          <portType name="someCustomerPortType">
                <operation name="add_someCustomer">
                      <input message="typens:add_someCustomer"/>
                      <output message="typens:add_someCustomerResponse"/>
          <binding name="someCustomerBinding" type="typens:someCustomerPortType">
                <soap:binding style="rpc" transport=""/>
                <operation name="add_someCustomer">
                      <soap:operation soapAction="urn:someCustomerAction"/>
                            <soap:body namespace="urn:someCustomer" use="encoded" encodingStyle=""/>
                            <soap:body namespace="urn:someCustomer" use="encoded" encodingStyle=""/>
          <service name="someCustomerService">
                <port name="someCustomerPort" binding="typens:someCustomerBinding">
                      <soap:address location="http://foo/bar/someCustomer.php"/>

    However, I need to change the add_someCustomerReturn  type from xsd:string to a complex type.

    I’ve made several tests variants around trying to add a complex type, like the following:

          <message name="add_someCustomerResponse">
                <xsd:complexType name="respType" >
                            <xsd:element name="someStatus" type="xsd:boolean" />
                            <xsd:element name="someResult" type="xsd:boolean" />
                <part name="add_someCustomerReturn" type="typens:respType"/>

    However I always end up having an error like:

    Custom tool error: Unable to import WebService/Schema. Unable to import binding 'customerBinding' from namespace 'urn:customer'. Unable to import operation 'add_customer'. The datatype 'urn:customer:respType' is missing. closequotes.png

    One thing to note is the above "web service" is using: soap:binding style="rpc". While I am not advocating one over another (document/literal), I personally think that if you stripped the religious and philisophical debates, one can certainly build a RPC-style web service using doc/literal encoding.

    The above exceptions funs afoul of what many techies called: Section 5 Encoding

    For the above to be resolved, you need to define a complexType reference by wsdl:part “add_someCustomerReturn” in the schema.
    To do this, you MUST define wsdl:types and add the schema to the WSDL that defines the complex and change the type=”xsd:string” (of the wsdl:part) to the identifying complexType in the schema (encoded in wsdl:types)

    While this is an old article written by Tim, the same principles apply. Do check it out of you need to stimulate your brain: The Argument against SOAP Encoding

    Friday, October 24, 2008 12:58:46 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Saturday, October 13, 2007

    I know I havent been posting deep technical stuff that I used to do. Contrary to what people think my current role entails, keeping abreast of the technology landscape is what I am supposed to do and what I enjoy and so when colleagues joked with me when was the last time I booted up Visual Studio, for example, I enjoyed seeing their shocked faces when I told them: "oh - just last night. why you asked ?" .

    I dont dwell deep like I used to but I still code up decent projects which I implement within my own developmental testing environment (yes, I have one running latest versions of Active Directory, SharePoint, Exchange and all the other goodies), driving the houshold crazy when I think of new and different ways to document expenses, publish a Book or CD library, home automation projects using all sorts of different technologies (yes, that includes Ruby-on-Rails) or in my new Windows Mobile 6 Device. Of course, I admit I dont post topics deep like I used to. It is not so much the content but more so, the limiting factor of time.

    Recently, I was involved in some internal technical discussions with regards to the issue of scale comparisions between Windows Communication Foundation (WCF, previously - Indigo) and ASMX. Below are some discussions:

    If you have a web service that is going to be IO bound, you would definitely want it to be scalable and almost every resource in the world tells you to implement ASP.NET asynchronous pattern (BeginSomething/EndSomething, etc) on it so to go easy on the thread pool. ASP.NET uses an IAsyncHttpHandler to handle the request, which means the worker threads are not blocked while the IO-bound operation executes somewhere else. Sounds good so far.

    If you make a WCF version of it with webHttpBinding (which actually means you can invoked it AJAX-style) following the same async pattern for the methods, you may find that each invocation of the WCF service eats up two threads – one for its ASP.NET HttpModule.ProcessRequest and the other for the actual IO. Ouch! You may think that this means your WCF implementation may end up eating all threads reserved for ASP.NET, which would indeed scale down the server

    Is this true OR are we missing the complete picture ?

    While the scenarios explained above are reasonable observations, it doesnt paint the complete picture. WCF does perform better scalability than ASMX.

    • Threading:
      For ASMX, when a request comes in, it would be queued up immediately for async ASMX. So the thread is released for that request and a new thread will pick up the work item later.

    For WCF, when a request comes in, we queue it up in WCF and let an IO thread handle the request. At the same time, the request thread-pool thread is held to wait for the request to complete.

    Yes, WCF uses more threads than async ASMX. But there is a reason for this. Using asynchronous ASMX is dangerous and not really a good practice (and I have hinted at this many times in the many Web Service/ASMX presentations I have done over the past few years). While it does well at what it is supposed to do, it does trick the developer into a "false sense of security". Essentially, if you dont know how the ASP.NET blackbox works, you may find yourself thrown against the car wall when you take a hidden, unsuspecting corner at high speeds. It does not provide enough throttling for client loads. Basically the server takes all items and queue them up for later processing. The server does not have a good throttling mechanism to control the number of work items. To everyone else, it seems that the server is quite friendly to all clients. However, if the number of clients is unbounded, this is really bad. First of all, the server working set would grow unlimited due to unlimited requests queued up. Secondly, many client requests would become obsolete when it’s picked up by the server from the queue. The latter accounts for a a good set of problematic scenarios I have come across in my past consulting gigs with regards to high-load and high-transactional ASMX asynchronous implementations before I joined the borg.

    Think of it as a side of the brain (that tells you that you are about to be full) not functioning properly when you sit down at a buffet table. You eat and eat and eat without knowning when to stop and then your ingestion/digestion system starts kicking in, you actually hit the wall. Hard. Literally.

    • Server Throughput
      When you measure scalability, the most important measurement is the server throughput. That is, how many requests the server can handle per time unit? For async ASMX, it would be pretty fast at the initial phase. However, like the ingestion/digestion analogy I was referring to above - Once the server is in a steady phase (as when CPU is fully loaded), the throughput will go down because the server capacity has reached. You can compare the data between async ASMX and sync ASMX over the long run to see what I mean.

    Also you would see higher memory usage of the async approach.

    • ASP.NET Throttling
      That said, ASP.NET does have a throttling mechanism that is used for sync ASMX, which is the threadpool thread limit. The number of threads used to handle requests are bounded ( WCF uses this fact to throttle incoming requests. You can always change the configuration settings to increase number of threads to be used to allow more work items to be queued up.

    The max number of threads follows the following formula:
    MaxWorkerThreads x #CPU – MinFreeThreads
    This is 12 by default on a single-proc machine.

    • Two-level Throttling for WCF
      WCF leverages the ASP.NET threadpool throttling to throttle client requests. At the same time, WCF has its own item queue throttling. The former is throttled by the setting mentioned in the immediate above point, while the latter is controlled by WCF throttling settings (maxConcurrentCalls etc). ASP.NET can automatically adjust threads based on CPU loads so that you would always get full load of the server.

    In this way, you may experience client failures because the requests are rejected at ASP.NET layer beforehand. So you can increase the ASP.NET throttling to get better experience. But eventually you would still be bounded by the physical server capacity, no matter whether you use async ASMX, sync ASMX, or WCF as mentioned above.

    There is improvement work done in .NET 3.0 SP1 and of course, .NET 3.5 (beta 2 here), with the use of prioritized item queues. Do expect even-better WCF performance even in some of the common scenarios. Fine tuning minWorkerThreads will even give us even better results.

    Thanks to Wenlong for helping out with the guidance and explanation. The complete scenario and the design principles for it will be published in greater detail in a MSDN whitepaper later. Do watch out for it.

    Friday, October 12, 2007 10:40:28 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Monday, June 25, 2007

    Microsoft Office SharePoint Server (MOSS) has the term "Portal" dropped for a reason. Unfortunately, just like everything else, we have to carry our legacy along and that means that customers today still view MOSS as a portal product play.

    While I would not disagree with that, portal functionality is but one of the collaborative features that comes along with MOSS. I usually encourage people to view SharePoint as a platform. An application development platform to enable and extend collaborative, unified communicative, interative and intuitive solutions. Because SharePoint comes with rather rich features and functionalities out-of-the-box (ootb) and because the underlying platform is on Microsoft .NET 2.0, customizing and extending SharePoint is easy.

    One of the things that people tend to look past in SharePoint, besides its inherent features and functionalities such as Search, Document Management, Personalization, etc are some of the elements of Social Computing that comes with it or that can be extended with it. 

    Of course, there are the blogs, wikis features that are out-of-the-box. I see many compare with the blogs or wikis-specific application engines out there and argue that MOSS is rather short at times. Again, I point to the fact that MOSS is an application platform. It is made to reach its potential throught customization. While this can be done manually, there are many many many 3rd party best-of-breed solutions out there on top of SharePoint today that can really transform SharePoint. I mean, who really would know SharePoint is powering sites like this and this? These solutions can be found commercially via the many Microsoft partners out there as well as via the communities such as Codeplex, SourceForge.NET, and other online communities such as here, here and here, just to name a few.

    To further enhance its social computing features, you can just simply just use a few lines of very simple AJAX scripts on ASP.NET 2.0 to transform SharePoint to enable cross-community collaboration such as with, flickr, digg, snap, soapbox, etc.

    Of course, Microsoft is quick to extend its ootb features with the release of its online business toolkit which further enhances the Web 2.0 capabilities of SharePoint. Read more about it here.

    I recently came across a request to be able to extend the ootb RSS Viewer Web Part to refresh itself (without any entire page reloading) after a configured period of time. This is so that the users would be able to see an updated view of the latest breaking news by subscribing to the RSS feeds of their favourite news service providers without pressing the Refresh F5 button many times.

    It took me exactly 15 minutes to code up a new web part to do just that using ASP.NET 2.0 and Visual Studio 2005. Actually, it just took 5-6 lines of Javascript code and I am able to have my own auto-refresh RSS web part, bearing in mind that web parts in MOSS are rendered as nothing but the <DIV> HTML tag.

      var _q = rndString(3);
      xmlhttp = new XMLHttpRequest();"GET", "" + "?" + _q, true); // so that the browser wont read from its cache

      xmlhttp.onreadystatechange=function() {
        if(xmlhttp.readyState == 4) {
           var outputXHTML = xmlhttp.responseXML.transformNode(_yourXSLTransformHere_);
           document.getElementById('myAutoWebPartDIV').innerHTML= outputXHTML


    var t;

    I will leave out the inheritance of WebParts plumblings for the reader to try out on their own on how to build and customize your own web part. Scott Guthrie provides some very good starting resource on how to do so va his blog post here.

    As you can gather from here, with the right mix of .NET 2.0 code and Javascript, the possibilities of having Web 2.0 capabilities in SharePoint is really only limited by your imagination. All you really need to do is just to get your hands dirty and try.

    Monday, June 25, 2007 12:05:54 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Saturday, September 09, 2006

    One of the topics presented during the Architecture Track in the just-concluded Microsoft TechED South East Asia 2006 was done by IASA.

    It was done via a very interactive session with the floor questioning the panel from the IASA Malaysian chapter about the value of being an architect and topics of the like.

    One of the questions from the floor was: "Do you believe that architects should be writing code ?"

    It seems that 3/4 of the panel members agree. Some even going on bragging that he is still doing it in assembly, C++ language. hmmm ... In the interest of keeping the session on time so that that the attendees can get home on time amidst the KL jams - I kept my mouth shut.

    Let me open them now.

    Architects shouldnt code. Period. My thoughts. Period. To prevent myself from rambling, which is what I always do when I have a strong opinion on something, let me list them in point forms.

    The term "architect" is a very nebulous term. The hype around it with all the wannabees printing it in bold font on their cards out there (I know a couple of them in Singapore who does them with no shame), who have no idea what is the difference between horizontal and vertical scaling, doesnt make it any better. For better or worse, I only believe in one type - and that is the all-emcompassing solution architect.

    Afterall, aint what all customers want is a solution ? Do you think they really care what is underneath the solution more than that this solution works well, is kept within their budget, perform effectively and efficiently within the constraints of their environment ? Therefore, in this context, I will speak in the context of Solution Architects.


    • In the past, code influenced architecture. The limitations of written-code in a chosen-platform in a defined-era is the damning evidence of the limitation of the architecture. VB3 anyone ?


    • Biasedness based on preference. A solution architect that has a decade long experience in writing code is usually one that doesnt see the other side of the fence, doesnt know that there are better solutions and worst - refuse to want to see it. Most of the people in this category are usually skilled in one platform over the other and it is very hard for people like that to sit down and analyze a problem without a pre-conceived notion in mind in a very neutral manner. Because of this, the likely solution they are going to propose will have the same limitations of the platform they have been so comfortable with. I dont question the depth. Where is the breadth ? These guys should remain what they are good in and be experts in their domains and probably be paid better than a solution architect. For those who argue that they are equally well-versed in both sides of the fence - Good for you. Stay there. It is very likely you are drawing a lot more than an architect. If you are not, you just need to sell yourself better.


    • It is all about the business. Solution Architects bridge the gap between (the returns of) the business with the (returns of) technology. So, yes, they should be just as apt with the Finanical Calculator as much as an Integrated Development Environment or a Installation Panel or Console. They understand the entire depreciation cycle of an enterprise solution much better than the differences between a thread and a process. So yes, the higher the level the language they used to code in (I am talking about 4GL), the better. Bragging how much you still do your work today in First or Second Level Programming Lanaguages doesnt do you any good. In fact, it makes you look bad. It shows the lack of touch you have with your business, how it is run, what are the constraints and the entire business and revenue model. Writing performance drivers, assemblers, kernels, runtimes has nothing to do with a company's business model in a world where Moore's Law still rules.

    It is all about the business, still.


    Saturday, September 09, 2006 3:18:43 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Sunday, September 03, 2006

    Apache Axis2/C version 0.93 is released. This should please the REST camp and highlights the momentum of how REST can be implemented in Web Services. If you are in KL next week, I will be briefly touching base on the REST-vs-SOAP style of implementing Web Services.

    Key Features

    1. AXIOM, an XML object model optimized for SOAP 1.1/1.2 Messages.
      This has complete XML infoset support.
    2. Support for one-way messaging (In-Only) and request response
      messaging (In-Out)
    3. Description hierarchy (configuration, service groups, services,
      operations and messages)
    4. Directory based deployment model
    5. Archive based deployment model
    6. Context hierarchy (corresponding contexts to map to each level of
      description hierarchy)
    7. Raw XML message receiver
    8. Module architecture, mechanism to extend the SOAP processing model
    9. Module version support
    10. Transports supports: HTTP\
      1. Both simple axis server and Apache2 httpd module for server side
      2. Client transport with ability to enable SSL support
    11. Service client and operation client APIs
    12. REST support (HTTP POST case)
    13. WS-Addressing, both the submission (2004/08) and final (2005/08) versions
    14. MTOM/XOP support
    15. Code generation tool for stub and skeleton generation for a given
      WSDL (based on Java tool)
      1. Axis Data Binding (ADB) support
    16. Security module with UsernameToken support
    17. REST support (HTTP GET case) - New
    18. Dynamic invocation support (based on XML schema and WSDL
      implementations) - New

    Major Changes Since Last Release

    1. REST support for HTTP GET case
    2. XML Schema implementation
    3. Woden/C implementation that supports both WSDL 1.1 and WSDL 2.0
    4. Dynamic client invocation (given a WSDL, consume services dynamically)
    5. Numerous improvements to API and API documentation
    6. Many bug fixes, especially, many paths of execution previously untouched were tested along with Sandesha2/C implementation

    Download the above release here.

    Sunday, September 03, 2006 8:41:45 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Saturday, July 08, 2006

    I cannot help but grin when I found out the next Crypto API (CAPI) - or termed - Crypto NextGen (CNG) and the suite it encompasses will be all included in Microsoft Windows Vista.

    This article says it all. Elliptical Curves Cryptography (ECC) should definitely be there (and is) when the Base Smart Card Cryptographic Service Provider (Base CSP) is there as well.

    It will be a long post to explain why the industry is adopting ECC and slowly adopting it and making it the cryptographic algorithm of choice. If you do understand the key concepts of prime factoring behind the concepts of Public-Private (or Asymmetric) Key Cryptography and the constraints of it moving forward into the future and the proliferation of mobile embedded devices, these 2 diagrams should suffice.



    Doesnt that give you a hint of where we are going with computing processing power and where it may be next time ?

    Saturday, July 08, 2006 6:13:10 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Friday, July 07, 2006

    This popped into my inbox a while ago ...


    Contests like this are just great. Not only are you receiving money (if you win... Who cares, even if you dont, a digital mutation of your idea may still evolve to a sellable one), you are competing with the best to generate a innovative, marketable, secured and (hopefully) usable product. The byproduct derived from the entire process would be similar to a mini-version of an RFC. Bad and unsecured ones would have been shot down and the good ones could be made better with a few ingenious tweaks.

    Now only if I can find 25.5 hours in any given day ...

    Friday, July 07, 2006 6:45:38 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  • Blasphemy ...

    It is finally published. After many, many, and I mean, many months of paying the process tax for this piece, it is finally LIVE !

    I started this piece with the first ever March 2005 CTP of Windows Communication Foundation (WCF, previously - Indigo) and I went through so many port demos and edit document cycles its so unbelievably painful ...

    But it is really good to see this in online form and shape.

    I started with this idea even though MSFT Corp has explicity stated that it will not support any form of interoperability between WSE 2.0 and WCF, even though it is "theoretically possible to develop Web services using WSE 2.0 in such a way that they can interoperate with WSE 3.0 (and WCF) by using only a reduced set of specifications"

    More importantly, the main reason for the motivation to write such a piece is written in the article itself and I quote:


    ...WSE 2.0 has seen 3 service pack releases since its official launch in 2004. It implemented the OASIS Web Services Security 1.0 specification which was the widely accepted interoperability standard protocols between secured web services as well as the implementations of WS-Addressing, WS-SecureConversation and WS-Trust. It was integrated very nicely into Visual Studio 2003. Even BizTalk Server 2004 carries with it a WSE 2.0 adapter for securing of Web Services. Thus, it would be fair to assume that there is more than its fair share of implementations in the market today.


    Depending on timing, budget, complexity and a whole host of other requirements, some of these applications will need to be moved and migrated to WSE3.0 and some to WCF. Aaron Skonnard has provided a great resource in his “Service Station” column on MSDN on a brief overview on the migration of WSE 2.0 applications to WSE 3.0 ones. However, as stated in his article, there are some major changes in the programming model and architecture in WSE 3.0 and migrating them from WSE 2.0 may not be trivial.

    Another very important factor to take note is while WinFX, and therefore WCF, is available downstream from Windows Vista to Windows 2003 and Windows XP. That is as far down as it goes. There still exists a huge installed base of Windows 2000 Servers out there running on server and data farms and if you need to implement the advanced Web Services stacks on those servers, WSE is still a very important strategy you cannot ignore.

    As noted in the above guidelines, even though Microsoft will not guarantee interoperability between WSE 2.0 and WCF, the good news is that there are a few WSE 2.0 common scenarios, which can allow wire-interoperability with WCF. I will illustrate them in the next section...



    So, this article will outlined WHAT that reduced set of specifications are and HOW to go about using them.

    Many Special Thanks go to Kirill, the Interop PM on WCF, who gave me a couple of tips to get over the port-over humps I had thoughout this piece since last year. And of course, I cannot forget Clemens, who is the catalyst to making this publication happen when he came onboard.

    I hope this helps at least someone out there. Enjoy !

    Friday, July 07, 2006 6:11:57 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Saturday, May 27, 2006

    Here I am - proud to announce that I will be doing a MSDN Redmond-hosted Webcast right from the other side of the hemisphere in Singapore.

    I will be speaking on concepts of Reliability in Soap:Web Services, why its needed, as well as the context of it in Windows Communication Foundation (WCF, previously - Indigo).

    More importantly, a 40GB Creative (another homegrown Singaporean product) ZEN MP3 player is at stake here waiting to be won. So, do sign up quickly for a chance to win this. Rules here.

    If you are one of those insomniacs in Asia-Pacific, do try to tune-in. I hope this blazes a trail for the other community leaders in Asia-Pacific to follow suit and show that we are right on par there with the best in technology.

    Click here for more details on this webcast.

    Saturday, May 27, 2006 6:03:37 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Tuesday, May 16, 2006

    Apache Axis2/C version 0.91 has been released via here:

    Key Features

    1. AXIOM, an XML object model optimized for SOAP 1.1/1.2 messages with complete XML Infoset support
    2. Support for One-Way Messaging (In-Only) and Request Response Messaging (In-Out)
    3. Module architecture, mechanism to extend the SOAP processing model
    4. Context hierarchy
    5. Directory based deployment model
    6. Raw XML providers
    7. WS-Addressing, both the submission (2004/08) and final (2005/08) versions
    8. Transports: HTTP * Both simple axis server and Apache2 httpd module and * SSL client transport - New
    9. Service Groups - New
    10. Service client and operation client APIs - New
    11. REST support (POST case) - New
    12. Module version support - New
    13. MTOM support - New

    Other notes

    1. Interoperability tested with Axis2/Java for XML in/out client and services
    2. Addressing 1.0 interoperability

    Major changes since last release

    1. Full Addressing 1.0 support
    2. Improved fault handling model
    3. SSL client transport
    4. MTOM implementation
    5. Implementation of easy to use service client and operation client APIs for client side programming
    6. REST support (POST case)
    7. Module version support
    8. Service groups
    9. Numerous bug fixes since last release

    Un-Implemented Architecture Features (TBD in 1.0)

    1. Sessions scoping for application, SOAP, transport and request levels
    2. Different character encoding support
    3. Dynamic invocation
    4. Archive based deployment Model

    Un-Implemented Architecture Features (TBD post 1.0)

    1. WSDL code generation tool for stub and skeletons (based on Java tool)
    2. Security module
    3. REST (REpresentational State Transfer) support (GET case)
    4. Web Services policy support
    5. Axis2 Web application (Web App)
    Tuesday, May 16, 2006 5:59:18 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Monday, May 08, 2006

    One of the common questions I came across my Windows Workflow Foundation (WF) and Windows Communication Foundation (WCF, previously - Indigo) consultancy tour is how do we logically use WF inside a WCF-hosted service.

    I had spent some time talking about how we can host a WF in a WCF:ServiceHost and how we can create a channel to invoke a workflow inside a WCF Service.

    Of course, we can always bring up a Workflow runtime and create a new workflow instance within the ServiceHost. However, some of us may prefer a more non-intrusive mode of a workflow invocation style.

    There are actually many extensible points at the Service Dispatcher which you can hook into that is part of a service behavior. There is the IServiceBehavior, IOperationBehavior and one of my favourite extensible behavior points I like to hook into is at the IEndpointBehavior.

    For instance, you may want to inspect a message in its raw glory and depending on its headers or the request properties, you may choose to invoke an appropriate action or workflow. You would need to implement the ApplyDispatchBehavior routine which gives you acccess to an EndpointDispatcher, which in turn, gives you a chance to implement a IDispatchMessageInspector. The IDispatchMessageInspector exposes some very useful routines which allows you to hook into the request message just after it has been received as well as before sending the reply message back.

    I would probably inspect the messages at this point and invoke the appropriate workflow and send the appropriate values into the ExternalDataEventArgs of the workflow based on the message values.

    Of course, this is not a hard and fast rule. How and when you do it is totally up to you. You may want to do it at the IOperationBehaviour and have the message dispatched to another entirely different operation if you want to (or if you dont agree with how WCF dispatches its messages).

    Below are some snippets that will help you along. I will be going more in-depth into these details in TechED Asia 2006 in Malaysia where I will show some really cool never-seen-before demos that is a mixture of WF and WCF. If you havent planned to be be there at TechED Asia 2006, do so now !

    Namespace Softwaremaker.NET.Wcf.Demos
    Public Class WcfMessageInspectorWorkflowInvoker : Implements IDispatchMessageInspector

    Public Sub New()
    End Sub

    Public Function AfterReceiveRequest(ByRef request As Message, ByVal channel As IClientChannel, ByVal instanceContext As InstanceContext) As Object Implements IDispatchMessageInspector.AfterReceiveRequest
    'Inspecting Message Request ...
    'Invoking appropriate Workflows based on values found in request message
    Catch e As Exception
    Throw New FaultException(e.Message)
    End Try
    Return Nothing
    End Function

    Public Sub BeforeSendReply(ByRef reply As Message, ByVal correlationState As Object) Implements IDispatchMessageInspector.BeforeSendReply
    'Inspecting Message Reply ...
    'Invoking appropriate Workflows based on values found in reply message
    Catch e As Exception
    Throw New FaultException(e.Message)
    End Try
    End Sub
    End Class

    Public Class WcfMessageInspectorWorkflowInvokerBehavior : Implements IEndpointBehavior


    Public Sub ApplyDispatchBehavior(ByVal serviceEndpoint As ServiceEndpoint, ByVal endpointDispatcher As EndpointDispatcher) Implements IEndpointBehavior.ApplyDispatchBehavior
    endpointDispatcher.DispatchRuntime.MessageInspectors.Add(New WcfMessageInspectorWorkflowInvoker)
    End Sub

    End Class

    What I have described above is a good way to abstract how and when you invoke a workflow away from your WCF-Hosting or business code. How do I add this behavior into my serviceHost ? Easy. Just call the below before your serviceHost.Open

    serviceHost.Description.Endpoints(0).Behaviors.Add(New Softwaremaker.NET.Wcf.Demos.WcfMessageInspectorWorkflowInvokerBehavior)

    Now, if you decide that the above code sentence intrudes into your hosting code and you would like it to be configured in your config file for flexibility as well, I will show in a later blog post how to add your own custom-defined behaviorExtension into your configuration file. Think: BehaviorExtensionSection.

    ... OR you can always go to TechED Asia 2006 in Malaysia where you sure would derive more value than a single non-interactive blog post.


    Monday, May 08, 2006 5:12:54 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Wednesday, March 15, 2006

    Ar - Arguments...It does make us move forward at times.

    Richard Grimes has managed to kick up a storm again with his article here, again. While, I would not go very far in saying a kernel Operating System should be written in managed-code. God knows I will not use one if it is and you shouldnt to. As far as I can tell, .NET was not created for writing operating systems?  It sits on top of the operating system and thats that

    It is, however, very important to note, the investments MSFT Corp have on managed code. Instead of giving you the usual bullets and docs. How about this ?

    Lines of Managed Code

    And lets not forget that Microsoft CRM is the first Enterprise Business Solutions that is written on managed code from Microsoft. Read: Dogfood

    And YES - Windows Communication Foundation (WCF, previously - Indigo) is written in C# as well.

    Case Closed. <EOM>


    Tuesday, March 14, 2006 11:44:31 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Tuesday, March 07, 2006

    Now if XML-RPC aint enough (I had blogged about this here and here), now we can add REST-RPC into the mix. The main difference would be the use of HTTP to provide application semantics via its verbs. This would mean that there would hardly be any XML or Request payload of any kind.

    Tuesday, March 07, 2006 1:01:34 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Wednesday, February 08, 2006

    What a way to start off a new category on my blog called "Interoperability".
    I recently came across an interesting post in the forums that goes something like this:


    Currently I'm working with Visual Studio 2003 in order to generate xmldsig signature. I'm using the class signedxml  to create the xmldsig signature and I get somthing like this:

      [Signature xmlns=""]
    Algorithm="" /]

    But I need the signature to be in a namespace that should be identified by
    the dsig prefix:

    [dsig:Signature xmlns:dsig=""]

    I really didnt think anything of this. At first glance, I thought the problem lies not in the code BUT the processor / validator that was used to read this.

    The dsig or any prefix, for that matter, doesn't indicate whether they 2 use different namespaces. Check
    the [default] namespaces and compare.

    Strictly speaking -

    • [ds:Signature xmlns:ds="" /]
    • [dsig:Signature xmlns:dsig="" /]
    • [Signature xmlns=" /]

    are isomorphically the same. If the end processor / validator reads it and treats differently, I believe that it should be a design flaw at the other end as it is really poor design to rely on namespace prefix.

    If you look at the XML-Digital Signature Specifications, Section 1.3 states that:

    This namespace is also used as the prefix for algorithm identifiers used by this specification. While applications MUST support XML and XML namespaces, the use of internal entities [XML] or our "dsig" XML namespace prefix and defaulting/scoping conventions are OPTIONAL; we use these facilities to provide compact and readable examples.

    Therefore, it is NOT necessarily to have a prefix to it as long as it points to the same namespace.

    However, I spoke too fast. Further explanations by the other party has made me put my thinking cap on. He provided 2 reasons being:

    1. Compatibility with our existing signer.
    2. We are planning to extend the signature to XML Advanced Electronic Signatures (XAdES) format. In that case the prefix is mandatory.

    I am surprised [which kinda shows how much I know, or dont know ???]. I spent some minutes digging into the XML Advanced Electronic Signatures (XAdES) specifications and true enough, it declares:

    The XML schema definition in clause 5 Qualifying properties syntax defines the prefix "ds" for all the XML elements already defined in [XMLDSIG], and states that the default namespace is the one defined for the present document. In consequence, in the examples of this clause, the elements already defined in [XMLDSIG] appear with the prefix "ds", whereas the new XML elements defined in the present document appear without prefix.

    <ds:Signature ID?>- - - - - - - - -+- - - - -+
      <ds:SignedInfo>                  |         |
        <ds:CanonicalizationMethod/>   |         |
        <ds:SignatureMethod/>          |         |
        (<ds:Reference URI? >          |         |
          (<ds:Transforms>)?           |         |
          <ds:DigestMethod>            |         |
          <ds:DigestValue>             |         |
        </ds:Reference>)+              |         |
      </ds:SignedInfo>                 |         |
      <ds:SignatureValue>              |         |
      (<ds:KeyInfo>)?- - - - - - - - - +         |
      <ds:Object>                                |
        <QualifyingProperties>                   |
          <SignedProperties>                     |
            <SignedSignatureProperties>          |
              (SigningTime)                      |
              (SigningCertificate)               |
              (SignaturePolicyIdentifier)        |
              (SignatureProductionPlace)?        |
              (SignerRole)?                      |
            </SignedSignatureProperties>         |
            <SignedDataObjectProperties>         |
              (DataObjectFormat)*                |
              (CommitmentTypeIndication)*        |
              (AllDataObjectsTimeStamp)*         |
              (IndividualDataObjectsTimeStamp)*  |
            </SignedDataObjectProperties>        |
          </SignedProperties>                    |
          <UnsignedProperties>                   |
            <UnsignedSignatureProperties>        |
              (CounterSignature)*                |
            </UnsignedSignatureProperties>       |
          </UnsignedProperties>                  |
        </QualifyingProperties>                  |
      </ds:Object>                               |
    </ds:Signature>- - - - - - - - - - - - - - - +
    Readers must take into account that the XAdES forms build up on the[XMLDSIG] by adding new XML elements containing qualifying information within the shown [XMLDSIG]ds:Object element, according to the rules defined in the present document. This ds:Object element will act as a bag for the whole set of qualifying properties defined in the present document, conveniently grouped.

    So, there are 2 questions to answer here:

    1. Is there a way to handle the Digital Signature prefix in the SignedXML Class in .NET Framework 1.1
    2. If so - How ? If not - How ?

    I decided to spend some time on this and after much disassembling some of the System.Security.Crytography.XML binaries, I found out to my dismay that the answer to Question [1] is NO. This is because the constants and the URIs of the XML Digital Signature functions in the System.Security.Crytography.XML space are found in the XMLSignature class and that class is declared as an internal class .

    Therefore, the answer to Question [2] would be to build our own customized Digital Signature stack. This may actually sound harder than it is. Truth is:- With Reflector and work done behind the MONO-Project and published on, I hacked a workaround in a few hours time. That actually means that I didnt really do much testing on it and so I disclaim myself from any liabilities, including, but not limited to, mistakes, injuries, deaths, etc caused if you choose to use it.

    You would use this assembly just like you would with System.Security.Cryptography.Xml. The namespace would be Softwaremaker.NET.Security.Cryptography.Xml.PfDsigInterop.

    Do take note that I has ONLY implemented the XML Digital Signature in this assembly.

    Imports System
    Imports System.IO
    Imports System.Security.Cryptography
    Imports System.Xml
    Imports System.text
    Imports Mono.Xml
    Imports System.Text.UTF8Encoding
    Imports Softwaremaker.NET.Security.Cryptography.Xml.PfDsigInterop

    myRSA = New RSACryptoServiceProvider

    Dim doc As XmlDocument = New XmlDocument
    doc.PreserveWhitespace = False
    doc.Load(New XmlTextReader("..."))

    Dim mySignedXML As SignedXml = New SignedXml(doc)
    mySignedXML.SigningKey = myRSA

    ' Create a data object to hold the data to sign.
    Dim dataObject As New DataObject
    dataObject.Data = doc.ChildNodes
    dataObject.Id = "someSWMId"

    ' Add the data object to the signature.

    Dim ref As New Reference
    ref.Uri = "#someSWMId"


    Dim xmldg As XmlElement = mySignedXML.GetXml
    ' Append the element to the XML document.
    doc.DocumentElement.AppendChild(doc.ImportNode(xmldg, True))

    ' Save the signed XML document to a file
    Dim xmltw As New XmlTextWriter("...", New UTF8Encoding(False))

    To verify the signed XML, we would just have to use back the System.Security.Cryptography.Xml found in the .NET Framework. At least, the .NET stack got the design of the namespaces and the prefixes right.

    ' Create a new XML document.
    Dim xmlDocument As New XmlDocument

    ' Load the passedXML file into the document.

    ' Create a new original SignedXml object and pass it the XML document class.
    Dim signedXml As New System.Security.Cryptography.Xml.SignedXml

    ' Find the "Signature" node and create a new XmlNodeList object.
    Dim xmlnsmgr As New XmlNamespaceManager(xmlDocument.NameTable)
    xmlnsmgr.AddNamespace("SWM", "")

    Dim nodeList As XmlNodeList = xmlDocument.SelectNodes("//SWM:Signature", xmlnsmgr)
    signedXml.LoadXml(CType(nodeList(0), XmlElement))

    myRSA = New RSACryptoServiceProvider

    Return signedXml.CheckSignature(myRSA)

    You can download my [prefixed-XMLDSIG] custom assembly here. Do let me know if you have any comments or feedback. Enjoy !!!


    I have spoken to a few experts [on the standards body] about this and it seems that the concensus is that the prefix is NOT needed at all.

    The XAdES specifications did not EXPLICITLY state that the prefix is needed so I don't see how the conclusions are drawn that prefixes are fixed. Maybe I am missing something.

    It looked to me like all the spec was saying was that the *examples* used those prefixes.

    It strikes me as surprising that any specification worth its salt would specify a *fixed prefix*. It would have been too restrictive and not something that many vendors would agree and abide.

    I have advised the other party to check with the other parties/vendors for this. In the meantime, I will pull this assembly offline until I get better clarifications.


    Wednesday, February 08, 2006 1:18:02 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  • Now-Now Scott, I think we both agree on my thoughts (below) since Day 1, but I wouldnt go as far as you. .

    ... Some issues that I have come across are the use of Datasets (a NO ! NO ! in distributed designs -- > Interop is a big problem and Datasets are TOO verbose), the inclusions of Data Schemas at the wire level when traversing network calls, etc. ...

    My Evil trophy would (have) go(ne) to "Add Web Reference". Why the past tense in that ? It is rectified.

    Wednesday, February 08, 2006 12:42:35 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Friday, February 03, 2006

    Not quite as complicated as it may sound.

    Web Services Enhancements (WSE) 3.0 allows that re-usability element aspect. Say I am writing a ASMX 2.0 service with an intent to host it in another [internal ?] process via another transport (TCP, SMTP, MSMQ), I can easily do so.

    The *.asmx file that contains

    <%@ WebService Class="SomeSWMNamespace.SomeSWMService"%> is equivalent to WSE 3.0's

    Protected Overrides Sub OnStart(ByVal args() As String)
        Dim address As Uri = New Uri("soap.tcp://swm/someSWMwindowsservice")
        SoapReceivers.Add(New EndpointReference(address), GetType(SomeSWMStockService))
    End Sub

    that is hosted via a Windows Service Process. Of course, the architecture of ASP.NET and IIS specifies the vDir and the physical *.asmx file as the physical endpoint address while you get to specify your own if you host it via another process.

    In other words, the IHTTPHandler class for asmx endpoints and the Winows Service are different processes accessible via different transports (Http and Tcp) but hosting the same codebase. Incidentally, this codebase is a .NET Class Library with all the fanciful attribute decorations:

    <WebServiceBinding(Name:="SomeSWMService", _
       Namespace:="", _
       ConformsTo:=WsiProfiles.BasicProfile1_1, EmitConformanceClaims:=True)> ...

    <WebService(Namespace:="")> _
    <Policy("SWMTracePolicy")> ...

    Friday, February 03, 2006 10:29:59 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Wednesday, January 18, 2006

    Two of my favourite features out of many in Visual Studio 2005.

    1) Finally - A Correction of what was wrong for some time - There is a Add Service Reference now. This is essentially what svcutil.exe does for you. Awesome. Now we know we are speaking services and messages ... No more calls please.

    2) A simple IDE enhancement but yet one that can generate lots of productivity. VS.NET will launch any project (of a solution) that my cursor is residing on. No more booting up of Class Libraries or Service Components by mistake anymore, (esp. in-front of an audience)

    Wednesday, January 18, 2006 3:08:43 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Monday, December 26, 2005

    One of the things that I thought <Input TYPE=radio> had always lacked is that it only allows it to be specified as part of only ONE group - which is dictated by the NAME attribute.

    Therefore, with this code

    <INPUT TYPE=radio NAME=names VALUE=1>William Tay
    <INPUT TYPE=radio NAME=names VALUE=2>William Gates
    <INPUT TYPE=radio NAME=names VALUE=3>William Tell 
    I can do this: William Tay William Gates William Tell

    However, if I wanted something with a 2-dimensional twist to it such as something like this:

    Please Vote your Favourite Topics via a Preference Gauge

      Order of Preferences
    Topic 1 1 2 3
    Topic 2 1 2 3
    Topic 3 1 2 3

    I will be stuck somewhere in between because while I can select my order of Preferences (in terms of 1, 2, 3) for any of those topics, I cannot prevent other uses from selecting a Preference 1 for more than 1 topic. This kinda distorts the voting statistics as someone may vote a Preference 1 for all topics which is not meant for business functionality intent.

    While, there are a few ways to do this, such as using a combination and tweaking of dropdownlists and other <input type>, I had some trouble searching for the same function to be served via a more intuitive Radio Input Type.

    So, I decided to write a small javascript snippet to be implemented via the onclick event-handler of the <Input TYPE=radio>. The parameters to be passed into the javascript function are all the same for all the radio buttons so it will be very easy to do this programmatically in your favourite language.

    The trick would be to manipuate the VALUE attribute to slot in a second Radio Group name and thereafter, have some javascript code manipuate the other radio buttons. Here is my documentation including the parameters to be passed into the javascript function:

    <INPUT TYPE=radio NAME=n1 VALUE=1_1 onclick="javascript:ClickAnotherRadioGroup(this.value,">

    The Value of the Input Type=Radio must be a delimited string
    The Value to the left of the pre-defined delimiter is the name of the Second Group Name
    This means that while NAME signifies a Radio Group, the x of VALUE=x_actualvalue signifies the Second Radio Group
    (a) - <INPUT TYPE=radio NAME=n1 VALUE=g1_1 onclick="javascript:ClickAnotherRadioGroup(this.value,">
    (b) - <INPUT TYPE=radio NAME=n1 VALUE=g2_2 onclick="javascript:ClickAnotherRadioGroup(this.value,">
    belong to the same Radio Group (n1)
    - <INPUT TYPE=radio NAME=n2 VALUE=g1_1 onclick="javascript:ClickAnotherRadioGroup(this.value,">
    (d) - <INPUT TYPE=radio NAME=n2 VALUE=g2_2 onclick="javascript:ClickAnotherRadioGroup(this.value,">
    belong to the same (but different from above) Radio Group (n2)
    However, (a) and (c) belong to the same radio group as well (g1) WHILE (b) and (d) belong to another group (g2)
    The Value to the right of the pre-defined delimiter is the ACTUAL VALUE of the Input Type=Radio
    Note that if the ACTUAL VALUE of the Input Type=Radio uses the same delimiter, we can change our own delimiter in this function

    Now try this with the Javascript implementation:

    function ClickAnotherRadioGroup(v,n)
     var f = document.forms(0);
     var n2 = v.split("_")[0]; // Retrieving the second grouped value
     for(var i=0; i<f.length; i++)
     if ((f.elements[i].type == "radio") && (f.elements[i].checked) && (f.elements[i].value.split("_")[0] == n2))
       var c1 = f.elements[i].value; var c2 =  f.elements[i].name;
       if ((v == c1) && (n == c2)) {} else
        f.elements[i].checked = false;
    Try this now:

    Please Vote your Favourite Topics via a Preference Gauge

      Order of Preferences
    Topic 1 1 2 3
    Topic 2 1 2 3
    Topic 3 1 2 3

    I hope this snippet will help someone as much as it has helped me.

    Monday, December 26, 2005 3:59:59 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Tuesday, October 18, 2005

    Fellow Singaporean Microsoft MVP, Aaron Seet has a very interesting take on the above subject. It is a definite read.

    Tuesday, October 18, 2005 9:21:11 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Friday, September 23, 2005

    The British Computer Society came up with this very interesting piece which I recommend a STRONG read.

    A couple of points which I find very interesting (and many people may not know and how true it is) and I take the liberty to quote from the above-referenced article here:

    "... In most industrialized nations, intellectual property (IP) generated by an employee through the course of his or her employment legally belongs to the employer. In the UK, this is embodied in the Patents Act 1977 and the Copyright, Designs & Patents Act 1988. Of course, if you are employed as a janitor and happen to write software in your spare time, you could argue that the IP that you are generating is entirely unconnected with your normal duties as an employee and therefore belongs to you. However, when it comes to software professionals, there is no such argument. Any software that they write, irrespective of whether it is during or outside normal working hours, legally belongs to their employer. Self-employed and contract software engineers are not usually bound by employer's IP rights but are unlikely to be strongly motivated to write OSS code unless they can earn a living from doing so, and the unpaid volunteer nature of OSS development tends to rule out this possibility ..."

    "... There are uncomfortable similarities between the OSS development process and the situation that arose in the computer games industry in the early 1980s, where legions of 'bedroom programmers' produced video console games of such poor quality that, despite selling in tens of thousands, they nearly destroyed the industry. The games industry learned a valuable lesson from this experience and is now arguably the most highly trained and disciplined software development community in the world. This professionalism in software development is cited as a major contributory factor to the explosive growth that the computer games industry has enjoyed over the last 10 years. The open source movement, with its hacker ethic, doesn't promote professionalism ..."

    I did spend some time pondering over the member's remark:

    "... Without prompt action, my fear is that a further move towards OSS could result in the nightmare scenario of OSS at one extreme and Microsoft at the other with nothing else in between. Where would our freedom of choice be then? ..."

    Friday, September 23, 2005 1:04:37 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Tuesday, September 20, 2005

    I remember while I was chatting about one of the article I was working on for MSDN with some folks from MSFT Corp during lunch at and I said that most of my code snippets are written in Visual Basic and for once ever, no-one sniggered and laughed. That moment was priceless.

    This was because we just came off a fantastic talk on Visual Basic 9: Future Directions in Language Innovations. In fact, someone echoed how cool Visual Basic 9 IS now. I dont know how long was it when "Cool" and "Visual Basic" got along together until today. WOW ! What can I say ? It is standing proud.

    There is a piece here that gives a brief overview on Visual Basic 9. What do I love most ? Its built-in deep XML Support. I cannot wait. Give it to me now !!!

    It was a great day.

    Tuesday, September 20, 2005 6:23:25 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Wednesday, July 27, 2005

    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

  •  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

  •  Wednesday, July 13, 2005

    I have been invited by the Ark Group to speak in one of their major technology management conferences in Singapore on the 27th July 2005.

    This conference is themed around Planning and Implementing Service-Oriented Architecture : Developing SOA to Reduce the Cost of Integration, Leverage Legacy Systems and Improve Business Agility.

    My 45-min presentation is titled:

    Design and Security Notes from the Field

    • Distributed Computing
      • Thoughts
      • When to use What
      • More Thoughts
    • Distributed Security
      • Thoughts
      • When to use What
      • More Thoughts

    As usual to my presentation style, I tend to keep my topics interesting and a refreshing experience. The conferences in this field has always been dominated by the academics, researchers and technology vendors who sometimes lose touch of whats happening on the ground. I will go against this bias and inject some field experience in there. It should be an interesting conference for attendees and delegates. I think it will even be much more interesting when I sit down with them for networking lunch.

    I hope to see you there.

    Tuesday, July 12, 2005 10:11:01 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Saturday, June 18, 2005

    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.

    Getting an mcdba certification is not a problem if you have done cisco training as well as other security training programs like mcp but there is no replacement of microsoft training.

    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="" xmlns:a=""]
          [a:Action s:mustUnderstand="1"][/a:Action]
          [a:To s:mustUnderstand="1"]http://localhost/servicemodelsamples/service.svc/mex[/a:To]
          [GetMetadata xmlns="" /]
        [!-- OR an Empty SOAP Body will do just as fine --]
        [!-- s:Body /--]

    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="" xmlns:s=""]
          [a:Action s:mustUnderstand="1"][/a:Action]
          [a:To s:mustUnderstand="1"][/a:To]
          [ActivityId xmlns=""]uuid:a55fa135-e1b9-4557-a7c3-39cbf042f85d[/ActivityId]
          [wsx:Metadata xmlns:wsx=""]
            [wsx:MetadataSection Dialect="" Identifier=""]
                [!--WSDL and XSD GUNK--]
                [!--XSD GUNK--]
                [!--WS-Policy GUNK--]

    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 "" 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.

    Saturday, June 18, 2005 5:08:50 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Saturday, June 04, 2005
    Courtesy of Aaron, a technically-brillant dude and a ASP.NET MVP of our Singapore Community.

    With cheap web hosting, you can save more on domain name registration and spend more on the web design as well as the seo services, particularly when you work at home.

    Saturday, June 04, 2005 7:58:14 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Wednesday, June 01, 2005

    First Survey of U.S. Corporate Application Server and Scripting Deployments Reveals Microsoft® Ahead of Competing Web Platforms.

    Not really a surprise to me but good to know nonetheless.

    Wednesday, June 01, 2005 2:13:11 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Saturday, May 28, 2005

    This will be interesting ...

    I think I will reserve my comments on this for now.

    Friday, May 27, 2005 11:23:39 PM (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)



     "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.

    et.swmstoreexchangemessages"]> _
    Public Class Response
      Public Result As Result
    End Class

    et.swmstoreexchangemessages")] _
    Public Class Result
    Namespace:="urn:softwaremaker-net.swmstoreextendedtypes"), _
    Namespace:="urn:softwaremaker-net.swmstoreextendedtypes"), _
    Namespace:="urn:softwaremaker-net.swmstoreextendedtypes")] _
      Public Any As Object
    End Class

      Public Function
    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

  •  Thursday, April 21, 2005


    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 !


    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.


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

  •  Wednesday, March 16, 2005

    People who know me knows that I generally dislike the the unproductivity of the development of Web Applications. Clients are asking for more and more complex (== intuitive) user interfaces today which is forcing the developers to handle the complexity of the plumbings of the protocols and other legacy (== it works) innards (== javascript) instead of focusing on solving the business problems. ASP.NET goes a long way in simplifying that technology process. However, the baggage of the protocol (synchronous request-response, state, etc) leaves a lot to be desired by the clients (== users) and the developers.

    The developers at Google are using what people are calling 'Ajax.' Jesse James Garrett at Adaptive Path consulting in San Francisco explains it this way via his blog:

    "Google Suggest and Google Maps are two examples of a new approach to web applications that we at Adaptive Path have been calling Ajax. The name is shorthand for Asynchronous JavaScript + XML, and it represents a fundamental shift in what’s possible on the Web."

    Basically Ajax is about using Javascript and the XmlHttpRequest object to do processing on the server after the page loads on the client. You can read about the process in this article.

    The possibilities with this are potentially amazing. "The real challenge here is not figuring out how to make the code work but thinking of interesting ways in which it can be utilized."

    Google Suggest and Google Maps did shake the earth for some people at how Web Applications can be viewed and re-invented using oldER technologies. My fear is that clients will start calling and ask for these interfaces when there are still no clear designing tools around. It seems like, in today's world, everyone is not focusing on staring at angle-brackets, choosing to let the toolkits and toolsets do the walking and talking for them.

    With the above said, now unless Visual Studio comes up with a designer for Web Applications close to that or can Eclipse of the J2EE world step up to the plate to be a tough challenger (and credit must be given to them for achieving tremendous strides over the past few years in catching up with the intuitiveness, productivity and the richness of VS.NET),  it will still remain out of reach to most mainstream commercial developers.

    Now until that happens, and not forgetting Flash gaining huge popularity (Check out this amazing Flash Application that does a one-screen registration with no effects of the http synchronous request-response showing through), does this spell the end of Smart Clients ?

    Only time will tell...

    Tuesday, March 15, 2005 9:32:01 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Sunday, February 27, 2005

    (W3C) SOAP is very like to XML-RPC and not the other way around.

    It works by marshaling procedure calls over HTTP as XML documents. However, one major difference is that SOAP allows the documents to be treated literally as --- well, Documents.

    As you will be able to see from the angle-brackets snippets below -- you will notice some major differences between SOAP and XML-RPC. One major difference you will notice right away is that XML-RPC doesnt have any of the XML Namespaces, doesnt support XML Schemas and has a very definite set of types and primitives. One of the major improvements of SOAP 1.2 over its preceding version is the removal of Section 5 Encoding, which, just like XML-RPC, is to improve the room for interoperablity by allowing people and parties to agree by having lesser opportunities for people to disagree (tm). I wont go much into details here. Eric Kidd has built up a fantastic repository about XML-RPC here.

    As I have mentioned before, I had done some work before revolving around XML-RPC. In fact, I still see major operations out there still communicating via XML-RPC. While I love SOAP, XML-RPC still does get the job done if you wanted simplicity and faster interoperability. I am however, willing to bet that, as distributed computing really pushes the realm of distribution and enterprise requirements of Security, Transactions and Reliability becomes more deeply rooted in the message, SOAP will become the defacto standard in message transmission. In the same tone of distribution, I do still remember that while doing XML-RPC, while some people and companies will argue that it is a loose-coupled concept, it sure doesnt apply to the parties involved in the transactions and invocations. We spent unproductive hours on the phone and meeting tables arguing what should be sent over and many more over what it is supposed to look like on the wire. If weapons were allowed then, I am sure we would have reached an agreement faster. Of course, the weapons I meant here were things like the Colt .45 Pistol and the S&W .460 Magnum. Because, tools were more primitive then, we actually had to write every single element out before it goes onto the wire. Serialization was unheard of then.

    I have built 3 simple Service Operations which is then broken into SOAP and XML-RPC Formats. The 3 methods and their I/Os are simple but they should be able to illustrate the different signatures and return types.

    Function HelloWorld() As String...

    Function SumAndDiff(ByVal x As Integer, ByVal y As Integer) As SumAndDiffStruc...

    Function RetSoftwareDevelopers() As SoftwareDeveloper()...

    These functions are then decorated with [XmlRpcMethod()] and [SoapMethod()] to distinguish themselves to their operation and binding approaches.

    Let us see how each of them is represented differently on the wire. I will show the XML-RPC format first then followed by SOAP:

      <params />
            <string>Hello World</string>
      <params />
                        <string>William Tay</string>
                              <string>Microsoft .NET Technologies</string>
                        <string>ABC DEF GHI</string>
                              <string>Microsoft .NET Technologies</string>

    Below are the respective SOAP Representations:

    <soap:Envelope xmlns:soap="..." xmlns:xsi="..." xmlns:xsd="...">
        <HelloWorld xmlns="..." />
    <soap:Envelope xmlns:soap="..." xmlns:xsi="..." xmlns:xsd="...">
        <HelloWorldResponse xmlns="...">
          <HelloWorldResult>Hello World</HelloWorldResult>
    <soap:Envelope xmlns:soap="..." xmlns:xsi="..." xmlns:xsd="...">
        <SumAndDiff xmlns="...">
    <soap:Envelope xmlns:soap="..." xmlns:xsi="..." xmlns:xsd="...">
        <SumAndDiffResponse xmlns="...">
    <soap:Envelope xmlns:soap="..." xmlns:xsi="..." xmlns:xsd="...">
        <RetSoftwareDevelopers xmlns="..." />
    <soap:Envelope xmlns:soap="..." xmlns:xsi="..." xmlns:xsd="...">
        <RetSoftwareDevelopersResponse xmlns="...">
              <Name>William Tay</Name>
                <Plaform>Microsoft .NET Technologies</Plaform>
              <Name>ABC DEF GHI</Name>
                <Plaform>Microsoft .NET Technologies</Plaform>

    As you would have noticed by now, XML-RPC has a fixed set of types and abstractions such as methodCall, methodName, params, value, struct, etc and of course, its response member-name-value pair. Like its name suggests, the param elements do represent each a parameter and the encapsulating structure does look like an object-instance representation. SOAP, on the other hand, makes heavy use of XML Namespaces and Schemas to validate how and what the message should look like.

    We are, however, moving away from this RPC behaviour of transmission. This is a good thing as SOAP, while requiring much more engineering complexity, does offer much more extensibility in terms of message exchange patterns and extensible headers. Even the RPC-Encoding RPC-ish style messages that are generated by the SOAP toolkits of a couple of years back is making way for Document-Literal as the default style today. You take the messages "AS-IS" and how you mapped them into your platform native language and what you do with them is left to the implementation details of each platform. The XML schemas act as a way for you to tell what is legal or illegal as IO to your service.

    Please note that I am using Charles Cook's fantastic XML-RPC .NET for my XML-RPC implementation here. Another way for you NOT to re-invent the wheel is to use Simon Fell's PocketXMLRPC. I am a huge fan of Simon Fell's SOAP Tools and I am sure this is a winner as well.

    Sunday, February 27, 2005 1:18:01 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Tuesday, February 22, 2005

    In my recent tour of the local university campuses giving talks and presentations, I noticed that most of the students find my talks hard to digest and understand. This is not surprising since I have always been known to be a server guy and not much of a tools person. Actually I used to be a client-tools person BUT have since spent the last year or so dabbling in distributed computing protocols.

    This is not just associated with students, BUT some of the younger folks that I had a chance to engage as well. This goes really far to show how old I am. It is very hard to extol the benefits of XML/SOAP and Services if the younger folks dont understand and appreciate the history of COM, MTS. Pretty soon, when Indigo matures from the wild, technologies like COM+ and .NET Remoting will become legacy as well.

    Everyone who grew up in the .NET era never knew about DLL Hell in deployment. Those things I need to do at 12 midnight when everyone is asleep and I am given the safe-clear command to do a regsvr32 for a 10KB Win32 COM DLL and then reboot the servers after...and I have not even mentioned about those nightmarish versioning problems when someone else's DLL is installed over mine....

    Well, it is good for those folks just like it was good for me not to have gone through Yourdon's Structured Programming era. Now thinking about it made me realize that maybe I would have appreciated object-abstractions better if I had.

    Anyways, since I was very focused on distributed computing protocos and XML SOAP Services in my talks and since the audience were mainly younger students who had no professional experience, I tend not to dabble too deep into BEST PRACTICES in Deployments, Versioning and Interoperability scenarios. I am sure most of them would rather poke a needle into their eye than to watch me write angle brackets, do some xsd typing, and then import namespaces before binding them all together in a WSDL file. Therefore, I usually give a more general broader overview of the industry, how come we have what we have today and what are we getting tomorrow. The history part usually sits well with them and so most of the questions that came up usually relates to that.

    Since most of their curriculum and labworks never went back to technologies that were more than 2 years old, I do find it useful sometimes to show them how COM, MTS and DCOM was done last time. That usually catches their attention although I think it was more of an amusement to them more than anything else.

    "Now, see this black thingy, we call them vinyl in our days and we put this needle-like shaped thing on it so that music can be piped out from this trumpet-like thingy...and we have to put it carefully on the edges so that it starts from the first tune...and if we want to repeat the same tune again, we have to sit up, go back to the machine, lift the needle up, squint our eyes on the vinyl so we can pick out the correct sequence of the groove on the vinyl that the song starts on and put it carkefully and slowly on that groove and VOILA, we have replay....What ? Oh, we have to do that everytime we want to replay that song...Whats that ? Shuffle, Random --- What's that ?"

    So, running DCOMCNFG.EXE and OLEView is not something I would do too often just to get a chuckle from the student audience

    However, I promise some of them I would blog about XML-RPC in relation to (W3C) SOAP and that is what I intend to do. There are still more than a few implementations out there in the real-world that are happily humming along with XML-RPC. I had done a couple of them before using MS SOAP Toolkit to XML-RPC with an apache server. I dont see them clamouring after SOAP so soon as those functionality are pretty straight-forward Request-Response endpoint invocations. In fact, the banner hanging in their server room reads: "NO SOAP, NO Problems" which I thought was quite cool even though I am a big fan of SOAP.

    Anyways, how can a Web Service history lesson be complete without XML-RPC. Dave Winer, who came up with XML-RPC amongst other things is still one of the key guys today, in my mind, who has shaped the landscape of distributed computing today. There is no doubt that SOAP has its roots in XML-RPC. XML-RPC is sort of an early generation of Web Services and it went a long way to define one of the principles of Service-Orientation which is to create as little shared abstractions as possible. In fact, there are so few primitives and types in XML-RPC that there is so little to agree and disagree on which, in turn, sets a positive tone in integration and interoperability. Incidentally, that was one of the reasons why SOAP 1.1 Section 5 Encoding was taken out in SOAP 1.2.

    I would try to see what I can come up with to write some XML-RPC scripts on .NET, just for the fun of it. I dont see any scenarios that I could use it unless one needs to write a .NET client to connect to a UNIX XML-RPC Server. Extensibility could be an issue as I could not route those messages, at least, not easily. On the other hand, because XML-RPC is slightly simpler (XML-RPC = SOAP++), it may pose less of an interop hazard.

    Tuesday, February 22, 2005 7:56:28 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Saturday, January 29, 2005

    This guy is killing me. Another excellent post from him here on how to extact a RSA Public Key from a Signed Assembly.

    Nice work, William.

    Saturday, January 29, 2005 1:47:59 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  • Finally, after months of waiting, Microsoft's Enterprise Library is available for download. This is essentially Avanade's famous ACA.NET version 4 which now has a official Microsoft alignment.
    Saturday, January 29, 2005 12:59:58 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Friday, January 28, 2005

    Some of the folks in the Spore DotNet Usergroup got together one night to run a practical project. The idea behind the link is to build a bridge to access Visual SourceSafe over the internet. It was built successfully with the help of SCCBridge.

    Incidentally, SCCBridge relies heavily on SOAP and DIME for its purpose and it is therefore no surprise that Web Services Enhancements (WSE) 2.0 was heavily involved in use here.

    "Both the server and the client are written in C# in Microsoft Visual Studio .NET. In the project is used library SharpZipLib created by Mike Krueger (for more info see ). The algorithm for text files comparing was taken from The Code Porject site, and was written by Shankar Pratap."

    Friday, January 28, 2005 3:28:07 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  • This has been floating around for some time BUT MSFT Corp has released an official statement here

    Since XQuery is expected to reach W3C recommendation only in 2006, it won't be shipped in the upcoming .NET Framework 2.0

    I guess people like me will have to live with XSLT and XPATH for now.

    Friday, January 28, 2005 12:02:47 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Monday, January 03, 2005

    A very interesting blog about Why Microsoft can blow off with C# and an even more amazing response after that.

    Sunday, January 02, 2005 9:25:14 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Sunday, December 19, 2004

    Having been developing for a number of years since the late 80s, I have been very used to the programming practice of using hungarian notation. I not only used it in variables, but in the database naming as well. Yes, I used tbl and fld prefixes for my Tablenames and Fieldnames respectively.

    Of course, recent recommendations is to dump hungarian notation in your programming style and opt to use meaningfull, descriptive words instead. I have also been poked fun at for using hungarian notation while doing some testing work for Paladin by its author.

    So there I decided to adopt a new developing and programming lifestyle and was happily humming along when I got hit face-first by a (JET Engine) ADO.NET Exception Syntax error in UPDATE  (0x80040E14). Having been doing the same UPDATE statement style and using the same Data Access Layer blocks for so long, the ego-monster in me looked for a system bug right away. Running this same query within MS Access itself would be fine but if I used JET as the Data Provider, the same exception would occur. Try as I have to google'd it, I cannot seem to find out what was wrong. Most of them poined to the use of JET's keywords such as [PASSWORD] which I have learnt from previous experience to just use PWD. Here is my “post-hungarian notation” UPDATE Statement:

    "UPDATE LibraryItems SET Title = '" & psTitle & _
    "', AuthorArtist = '" & psAuthorArtist & "' , ItemTypeID = " & piItemTypeID & _
    " , GenreID = " & piItemTypeID & " , ContentFormatID = " & piContentFormatID & _
    " , Qty = " & piQty & " , DateBought = #" & pdDateBought & "# , PriceBought = " & _
    pcPriceBought & " , DateSold = #" & pdDateSold & "# , PriceSold = " & _
    pcPriceSold & " , StatusID = " & piStatusID & " , References = '" & psReferences & _
    "' , Remarks = '" & psRemarks & "' WHERE ID = " & CommonUtil.ValidateSQLSafeString(mRecID)

    Can you spot my mistake ? I didnt until I stumbled across this MS Support article about JET's reserved keywords...

    AARRGH !!! So, REFERENCES is a JET's reserved keyword as well. In the past, I would have used fldReferences and therefore would NOT have encountered such an exception.

    The FIX: Wrap Square brackets around the column name [References]. In fact, I recommend to wrap it around all column names, not just suspect ones. OR just use the CommandBuilder QuotePrefix and QuoteSuffix command to bypass the reserved keyword error.

    • CommandBuilder.QuotePrefix = "["
    • CommandBuilder.QuoteSuffix = "]"
    Saturday, December 18, 2004 11:50:06 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions