Blog Home  Sign In RSS 2.0 Atom 1.0 CDF  

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

  knownType_Serialize, about = Softwaremaker()

 Friday, February 24, 2006

Microsoft-Google ?

Cannot help but retrieve the above image from a long forum entry found here. It is either someone over-estimates MSFT Corp or under-estimates Google Inc.

Friday, February 24, 2006 8:59:45 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Wednesday, February 15, 2006

    In an article on eweek, John deVadoss, director, architecture strategy at MSFT Corp made the following quotes:


    Moreover, deVadoss said the edge consists of a provider and consumer model—a provider edge and a consumer edge.

    The consumer edge is the peer-to-peer, Web 2.0 world and the enterprise edge is the SOA, ESB (enterprise service bus) model. In addition, the consumer edge is an asynchronous communications model based on the REST (Representational State Transfer) scheme, and the enterprise edge is based on the Simple Object Access Protocol scheme.

     "REST is a dominant model on the consumer side, and SOAP is the model on the enterprise side," deVadoss said

    I know many people would probably shake their heads now as to the confusion that has arose with this quote. Actually, while I couldnt quite fully agree with everything said above - the nugget to dig here is that one resides on the edge of the enterprise (or the high-end processing machines out there) and the other resides at the side of the consumer.

    In reality though, what ultimately serves the consumer are the enterprises, in some way or another. It is the consumer who pays - no ? Therefore it would be safe to assume that there is a mixture of both schemes in any enterprise.

    While SOAP is probably familiar to many, REST shouldnt be a stranger to many more. It is nothing but how the World Wide Web has been working. It just has a new label OR should I say be saying that the label is stickier now ? SOAP and all the XML acronyms has just emphasized it more. While you may not need to know the URIs, URLs and the way resource locators work or how it came about - you may need to know the word POX (Plain Old XML).

    In simplistic terms - POX is just XML that doesnt really have a defined structure. In contextual terms, POX is XML that is not SOAP.

    Makes more sense now ?


    Tuesday, February 14, 2006 4:35:44 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Tuesday, February 14, 2006

    I love the American Press News and Humour. I am here in Washington listening to and you would never see "See Dick Shoot" or "American VP blows his friend away" as the news tagline in Singapore.

    It would probably go something like "American Vice-President Richard Cheney shoots his friend accidentally" or something boring to the taste.

    Tuesday, February 14, 2006 7:16:24 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

  •  Sunday, January 29, 2006
    Saturday, January 28, 2006 11:54:04 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Friday, January 27, 2006

    Dont get me wrong. I love my new PocketPC Phone on Windows Mobile 5. Some great reviews can be found here, here, here and here.

    If you read all those reviews, it is with no doubt that everyone has their thumbs-up for this beauty and the common underlying praise is its Performance with a Samsung 400 MHZ Processor, which some suggests runs with the same cyclical power of a Intel 570 MHZ Processor, BUT outperforms even that of the Intel 624 MHZ that the Dell AXIM x50 has.

    This is the only PocketPC Phone that I have test-driven successfully with Skype. And if you know how the architecture of Skype works, if it can run Skype, it can run everything. In fact, I have chatted with many people over Skype using this phone ... No-one knows that I am chatting with them via a PocketPC Phone ... and it really makes me wonder about why would anyone bother with these types ?

    Anyways, while playing around with some of the softwares in there, I noticed a couple of boo-boos like those shown below

    Giggles aside and it is a great conversation starter amongst geeks, I have always preferred functionality over aesthetics - Who really cares how the food and the cook looks when it tastes good (the food, that is ...)

    I also fnid it fsacinatnig that the human brian is so cabaple of knowing and dceiphering the meaning, the intent, the samentics of these words, even though it is spelt wrognly.

    Is this an exercise of the brain or is it just simply to carry on the great legacy of software typos ?

    Thursday, January 26, 2006 9:00:34 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions