Blog Home  Sign In RSS 2.0 Atom 1.0 CDF  

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

  knownType_Serialize, about = Softwaremaker()
 

 Monday, February 28, 2005

I was just alerted by Julie about the availability of WSE 2.0 SP3. I must say, she has got her eyes and ears on the ground. Any new releases in some hidden corner, bet on her to find it first.

However, I am going to give this a pass. I believe it is just a version with bug fixes and patches and probably, better documentation. Microsoft BizTalk Server 2004 is keeping me fairly busy for the moment so I will just sit tight and wait for WSE 3.0 followed by Indigo

[AUTHOR UPDATE]: The ReadMe for WSE2SP3 is found here. It is a very targeted fix covering stress, security and perf issues

Monday, February 28, 2005 2:36:51 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  • What is happening to our PROFESSIONAL tagline in our Singapore Professional DotNet Usergroup ?

    We are getting very strange new languages asking for help and even worse (?), people like these feel so natural about it and some others do not hesitate to defend and ask everyone else to try to find time to understand it as it is the way to go (?)

    I take the liberty to Ctrl-C and Ctrl-V some snippets here. I hope Douglas Adams of the Hitch Hiker's Guide to the Galaxy (Wierd Science - The Babel Fish) get me a Babel Fish soon.

    hi every 1
    i am new to sql server and i dint noe how to let the server start to run on my PC
    can some 1 direct mi how to do that
    another qn i had is how to set data i wanted to the database similar to using microsoft access database
    can some1 direct mi too
    thanz alot

     
    =============================================

    Anyone here tot/dream of  a 'Tech/IT' startup or already doin it?
    anyone wanna discuss issues pertaining to these?

    Eg
    1) idea
    wat kinda of business wud u be interested in?
    wat business do u think has potential?
    wat do u think is hot currently ? or wil be hot in the next few yrs ?

    well... mayb not jus local .. consider goin global as well..
    anything under the sun on tech startups....

    ok...let me start....1st....
    since im currently preparing for a possible startup...

    well...i feel one critical issue is...
    finding/assembling the core team of people...why?
    a) its hard to find partner who is willing to commit, has simliar goals n willing to sacrifice
    i believe nothing great can b achieved wo sacrifice.. eg personal life, lower income or
     no income for sometime, etc etc

    haa... im also like tat... working at irregular hours...
    all my past jobs r flexi hours.... or rather...
    my past bosses had accept flexi hours arrangement w me...
    always late to reach office...n work til late at night...when everyone had left...

    i like ur component based idea... i guess... one way is to properly architect a certain
    project, n sub-out/assign the different modules/components to freelancers/subcontracters..
    however... i guess it also depends on the nature of the project as eg hw-sw linked
    projects r difficult to 'componentised'..

    hmm... n i guess.. theres also the integration difficulty n answerables n expertise in architect...
    i can guess why most coy avoid these since
    a) they can make a subcontractor answer more easily to whole project than a component
    b) let the subcontractors handle integration issues
    c) perhaps the coy do not hav enuf expertise in architecting complex projects n so
    sub out whole project n let sub contractors do the designing...

    however , if a coy has its own architect n intergation engineers...
    component-based contracts wud b viable..

    agree... complementing skills r hard to find indeed...
    n one thing i feel abt knowing people thru networks...is tt u dunno them enuf...
    ...unlik frens or former colleagues...
    well... there is certainly some risk + give n take...
    we all know or hav heard how political things can get in any startup bussines...
    even w frens...it may b tricky at times...
    perhaps its all parts n parcels...of running a bussines...n learning...

    i feel killer app n business acumen is not enuf...
    or rather.. its the beginning....
    the execution is when core team players come in...
    need diff skillsets... such as marketing/sales, tech skills, managment, etc etc...
    even tech skills alone.. alreadi need diff skillsets if it involves diff disciplines...

    cash flow problem....hia....tats where investros come in...
    but i guess... in startups... theres lots of 'make do' situations n compromising....
    eg using free/cheap tools instead of full-fledge ones...

    how abt ideas on bussiness?

    infact... im jus interested to hear the pt of views from IT people...
    as im from embedded sw background... really know nuts abt  IT industry...
    my ideas r often related to hardware products...

    for eg... rite now... i see opportunities in
    -providing middlewares
    -providing reference designs
    -designing products
    based on some in 'Emerging Technology/area'

    Eg of emerging tech/area
    -wifi-n, wimax, zigbee, wireless usb
    -homenetwork, homeautomation
    -securities industry : eg survillence, biometrics
    (i see tat video survillience is under goin a 'generation' change stage... which is an opportunity...jus lik 2G->3G)
    -n even dsp areas...(theres been lots of developement lately in the industry)
    -n voip etc etc...

    yeah... n the problem w emerging tech is tat... u need to hit the market at the rite time
    - too early n u hav to b able to sustain cash flow...
     thou u hav more time to 'maturiese' ur ip n market ur expertise...
    - too late u wil hav less chances...

    moreover... i feel there w be more 'convergence' betw embedded n IT services...
    eg video-on-demand...etc etc... im sure there wil b more to b discovered...

    how abt IT side??? really dunno much abt IT...

    hahaa...
    i tot the short hand i use r alreadi the common ones...unlik other local forums...really

    well... if there is another person who complain abt my short hand... than i wil try harder...
    cos i had found it natural n quick to write in this way...

    if my grammer n vocab incorrect... its due to my poor command of the language...
    so pls pardon me on tat... cos i use too much machine langauges...haa...jus joking...

    =============================================

    ah..the 'weight thing'.... well personally im not so concern over such things in forum...
    but thx...i wil take note of tt...

    apologies for giving u guys dazy eyes

    Monday, February 28, 2005 12:55:30 AM (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:

    <methodCall>
      <methodName>HelloWorld</methodName>
      <params />
    </methodCall>
    <methodResponse>
      <params>
        <param>
          <value>
            <string>Hello World</string>
          </value>
        </param>
      </params>
    </methodResponse>
    <methodCall>
      <methodName>SumAndDiff</methodName>
      <params>
        <param>
          <value>
            <i4>15</i4>
          </value>
        </param>
        <param>
          <value>
            <i4>10</i4>
          </value>
        </param>
      </params>
    </methodCall>
    <methodResponse>
      <params>
        <param>
          <value>
            <struct>
              <member>
                <name>sum</name>
                <value>
                  <i4>25</i4>
                </value>
              </member>
              <member>
                <name>diff</name>
                <value>
                  <i4>5</i4>
                </value>
              </member>
            </struct>
          </value>
        </param>
      </params>
    </methodResponse>
    <methodCall>
      <methodName>RetSoftwareDevelopers</methodName>
      <params />
    </methodCall>
    <methodResponse>
      <params>
        <param>
          <value>
            <array>
              <data>
                <value>
                  <struct>
                    <member>
                      <name>Name</name>
                      <value>
                        <string>William Tay</string>
                      </value>
                    </member>
                    <member>
                      <name>Age</name>
                      <value>
                        <i4>30</i4>
                      </value>
                    </member>
                    <member>
                      <name>Profile</name>
                      <value>
                        <struct>
                          <member>
                            <name>Experience</name>
                            <value>
                              <i4>10</i4>
                            </value>
                          </member>
                          <member>
                            <name>Plaform</name>
                            <value>
                              <string>Microsoft .NET Technologies</string>
                            </value>
                          </member>
                        </struct>
                      </value>
                    </member>
                  </struct>
                </value>
                <value>
                  <struct>
                    <member>
                      <name>Name</name>
                      <value>
                        <string>ABC DEF GHI</string>
                      </value>
                    </member>
                    <member>
                      <name>Age</name>
                      <value>
                        <i4>50</i4>
                      </value>
                    </member>
                    <member>
                      <name>Profile</name>
                      <value>
                        <struct>
                          <member>
                            <name>Experience</name>
                            <value>
                              <i4>10</i4>
                            </value>
                          </member>
                          <member>
                            <name>Plaform</name>
                            <value>
                              <string>Microsoft .NET Technologies</string>
                            </value>
                          </member>
                        </struct>
                      </value>
                    </member>
                  </struct>
                </value>
              </data>
            </array>
          </value>
        </param>
      </params>
    </methodResponse>

    Below are the respective SOAP Representations:

    <soap:Envelope xmlns:soap="..." xmlns:xsi="..." xmlns:xsd="...">
      <soap:Body>
        <HelloWorld xmlns="..." />
      </soap:Body>
    </soap:Envelope>
    <soap:Envelope xmlns:soap="..." xmlns:xsi="..." xmlns:xsd="...">
      <soap:Body>
        <HelloWorldResponse xmlns="...">
          <HelloWorldResult>Hello World</HelloWorldResult>
        </HelloWorldResponse>
      </soap:Body>
    </soap:Envelope>
    <soap:Envelope xmlns:soap="..." xmlns:xsi="..." xmlns:xsd="...">
      <soap:Body>
        <SumAndDiff xmlns="...">
          <x>15</x>
          <y>10</y>
        </SumAndDiff>
      </soap:Body>
    </soap:Envelope>
    <soap:Envelope xmlns:soap="..." xmlns:xsi="..." xmlns:xsd="...">
      <soap:Body>
        <SumAndDiffResponse xmlns="...">
          <SumAndDiffResult>
            <sum>25</sum>
            <diff>5</diff>
          </SumAndDiffResult>
        </SumAndDiffResponse>
      </soap:Body>
    </soap:Envelope>
    <soap:Envelope xmlns:soap="..." xmlns:xsi="..." xmlns:xsd="...">
      <soap:Body>
        <RetSoftwareDevelopers xmlns="..." />
      </soap:Body>
    </soap:Envelope>
    <soap:Envelope xmlns:soap="..." xmlns:xsi="..." xmlns:xsd="...">
      <soap:Body>
        <RetSoftwareDevelopersResponse xmlns="...">
          <RetSoftwareDevelopersResult>
            <SoftwareDeveloper>
              <Name>William Tay</Name>
              <Age>30</Age>
              <Profile>
                <Experience>10</Experience>
                <Plaform>Microsoft .NET Technologies</Plaform>
              </Profile>
            </SoftwareDeveloper>
            <SoftwareDeveloper>
              <Name>ABC DEF GHI</Name>
              <Age>50</Age>
              <Profile>
                <Experience>10</Experience>
                <Plaform>Microsoft .NET Technologies</Plaform>
              </Profile>
            </SoftwareDeveloper>
          </RetSoftwareDevelopersResult>
        </RetSoftwareDevelopersResponse>
      </soap:Body>
    </soap:Envelope>

    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

  •  Saturday, February 26, 2005

    If you built it well and right, you only have to built it once tm

    Saturday, February 26, 2005 1:49:10 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Friday, February 25, 2005

    Had a great session today with Robert McDowell, Vice President at MSFT Corp of the Information Worker Group. It was stated in his bio that he has 35 years of IT experience.

    WOW ! I didnt even know IT is that old...He also started the Microsoft Consultancy Services, which I think, is a great feat in itself.

    He gave the managed partners a great candid insight into what Microsoft can do and will do in the upcoming future wrt to business productivity esp in the area of the Information Worker. He is a great presenter and is one of those guys who can speak insightfully for 60 mins without a single powerpoint slide.

    He then handed out autographed copies of his book "In Search of Business Value" after the presentation. Excellent...I cannot wait to read his book.

    Thursday, February 24, 2005 9:29:17 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

  •  Friday, February 18, 2005
    Friday, February 18, 2005 2:06:32 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  • I am presenting on a topic on the 22nd February 2005 to the undergraduates at our own National University of Singapore (NUS). Next week will be the Computing Week and the theme focus is, of course, on .NET

    TOPIC: Services in the Object-Oriented Programming Paradigm

    SYNOPSIS: William will give an overview of objects in the OOP paradigm world and the costs of it in the real world of distributed computing and programming. He will then introduce the concepts of services and how it may be the industry's responses to these lessons. He will then compare the differences between objects and services and explore some of the principles and concepts of Service-Orientation and how the world is moving forward to embrace the concepts of service architecture and programming. If there is time, William will also give a very brief 40,000 foot view of what is upcoming in Indigo

    I will be making more of these academic presentations as I go along. There are a few deep technical ones I will be preparing as well and I hope to aim them at the NUS or Nayang Technological University (NTU) Alumni Community Executive Commitee to get a good clout and to ensure a good meeting of the minds.

    Friday, February 18, 2005 2:03:42 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  • Benjamin points to a great tool from MSFT Corp Research in Cambridge that acts as a security diagnosis tool for WSE2 policy files...

    Worth trying and looking into even though it is unsupported...Since when is a product or tool that rolls out from Research supported in the commercial production world anyways...

    Another +1 for Microsoft for the raising awareness in security, esp in the realms of XML SOAP Services.

    Friday, February 18, 2005 12:43:51 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Thursday, February 17, 2005

    MD4, MD5, SHA-0, and now SHA1.

    I believe the MD series has known collisions as well...

    Well, I had blogged about these days before.

    Thursday, February 17, 2005 2:44:36 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Wednesday, February 16, 2005

    In some of my recent XML SOAP Services demos and presentations, I found myself needing to manually post a SOAP message to a listening (W3C) SOAP Services on http and also on the tcp transport protocol.

    While doing that, I can also change the SOAP Message on the fly and post it instead of having to change the way VS.NET XMLSerializer serializes the types and then recompiling and running it again. Besides saving time, it does add an element of oommph as well as there is no break in momentum and more importantly, audiences really do see and can appreciate what is going onto the wire real-time.

    Being able to change the messages on the fly as well also lets you see very quickly and clearly what the receiving endpoints can or cannot do. In this sense, with just a few tweaks of the angle brackets, I can generate SOAP Faults at will and it gives the audience great examples for learning how and when SOAP Faults are generated. For example, changing the element names OR re-ordering the elements of a SOAP Message and see what and how the receiving endpoint reacts. I will leave this as an exercise to the reader.

    I have written a small tool to help me do that. Recently, I have just added an ability to the application to allow it to post SOAP messages over the TCP Transport channel to a listening Web Services Enhancements (WSE)-enabled SOAP Service.

    Granted, most people will still need to manually pre-compose a SOAP Message before-hand. Do this as part of your pre-presentation work and save the messages for posting to the receiving endpoints later. Of course, if you are an angle bracket freak like me or Tim or Radovan, then you should all feel comfortable typing them into the textbox.

    Seriously though, this tool allows you to save your SOAP message scripts as part of your preparation work. You can either post these as files (via the OpenFile Dialog button) or copy-n-paste those scripts into the textbox.

    I believe that this can serve some basic purpose scenarios. Do note that besides doing presentation work with this, I think this is a great tool for developers who need to further test their SOAP Services to make sure it is able to generate the exact SOAP Responses (SOAP Faults and all) with every single differing SOAP Request.

    For example, users testing their WSE-Enabled SOAP Services can change the wsu:Timestamp element to test the service timeouts or play around with the wsse:Security elements of _WS-Security Specs_.

    [Pre-requisites]:

    [Notes]:

    • This will only work for the Request-Response MEP for WSE-Enabled SOAP Services

    [Upcoming Plans]:

    • Incorporate the ability to listen for incoming SOAP Messages as well. So it will work for truly asynchronous, duplex type SOAP Services as well
    • ...

    I have made it available for download here. I plan to make the source codes available once I incorporate most of the features the market wants.

    Please feel free to leave your comments and feedback in this post so I know how to better improve it.

    Wednesday, February 16, 2005 12:03:56 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  • I know this BizTalk tip will come in handy one day.

    Wednesday, February 16, 2005 12:01:52 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Monday, February 14, 2005

    Tim and Dare had some great exchanges here where they discussed on the importance and significance of staring at angle brackets and service reach.

    Tim hit on a sweet spot which I can definitely identify with when he wrote this:

    "Is it an issue in companies doing lots of legacy integration work?"

    I guess we all come from and work in different IT surrounding environments. I work in a fairly large Systems Integrator where loads of our work revolves around integration and maintainence of legacy systems in vertical Line-Of-Businesses. Since it is also a free business environment, we also have to integrate with work done by other SIs, systems and technology vendors as well. This is a fairly tough proposition and if we are not involved in sitting around tables discussing how to integrate data formats and semantics, we are usually thrown a stack of documents describing the data schemas of other companies and people doing previous work with other technology systems.

    Now, XML-Schema is usually (Thank God for that) the agreed-upon format for describing these data formats and that is all we have. Nothing more. Most of the time, we are just given documents with table formats and we have to markup those table formats in XSD ourselves.

    So, the XSD-Editor in Visual Studio is definitely a God-sent (Geek-speak, of course) to generate the schema. I was left to my own barehands and notepad to create the WSDL.

    No, other WSDL toolkits were not an option, cost-wise. Thinktecture's WSCF definitely gave us a huge productivity boost in terms of generation of those WSDL files. By that time, our brains are so well-tuned to angle brackets that we could just hand-author the resultant WSDL to produce the exact result we want. Examples include having multiple service elements and soap:location address attributes for the same SOAP Binding, importing of re-usable data schemas and the separation of abstact and concrete defintions in the WSDL File. By doing all that, we built extensibility, versioing and interoperability as well...and we went in there with our eyes wide open. Troubleshooting is relatively a breeze now, one look at the SOAP Request and the WSDL; we know where and how the SOAP Fault happens.

    Is that a problem with primitive tooling that can be solved down the road ? Maybe and I truly hope so. In this instance, I hope that tool utility developer companies can strive for that goal. I am, however, sceptical that a holy grail can be achieved so soon.

    I still think, with all things status quo, that developers need to know explicity what goes onto the wire. This has got nothing to do with what is the "native" or real contract or the the canonical forms used to describe the messages. The problem is that when someone gives us these contracts or schemas described in canonical forms, it is the only thing we have that we best understood what is to be sent on the wire so that the other end of the pipe can intepret, understand and process these messages.

    ...Therefore, I have no choice to not just stare at angle brackets BUT understand what it is trying to convey as well.

    p/s: One of my favourite article that exhorts the virtues of the Contract-First Approach

    Monday, February 14, 2005 2:56:25 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Sunday, February 13, 2005

    I have spent some time preparing on a topic on WSDL and I will present this in our March 2005 SgDotNet gathering.

    Synopsis:

    With all the power of abstractions that most major IDEs to today offer, inner technical plumbings are often ignored and worst - Misrepresented and Misunderstood. This can lead to choosing the wrong technologies and solutions to solving specific problems. When it comes down to troubleshooting the nooks, crannies and crevices at crunch time with no extra help, nothing beats a dirty pair of hands, a hammer and a screwdriver. William attempts to get everyone's hands dirty with a detailed look at what transcends within one of the most core and matured XML Service Technologies of today.

    Some of the things that will be covered:

    1. What is WSDL
    2. Critical role in Service-Orientation
    3. Core Elements and Definitions
    4. Discovery Views
    5. Best Practices (Interoperability, Extensibility, Versioning)
    6. Coming soon to a parser near you: WSDL 1.2 ? …or is it… WSDL 2.0 ? >>> If we have time
    7. RPC-Encoding Vs Doc-Literal WSDL Concepts in Indigo >>> If we have time

    If you are available or around the area on the 10th of March 2005, why not drop by Microsoft Singapore and sit in ?

    The difference between this presentation and the ones I had done before for our own usergroup is that I am representing INETA APAC in this event. Thus I will be speaking in the context of a speaker from the INETA APAC Speaker Bureau. I really hope that INETA APAC can sort out some of their administrative details in time and be able to subsidize some of the pizza money for the food we intend to have. Heck, this is the only way I know how to keep some of them awake while staring at the monotonous angle brackets...

    Register yourself here.

    Saturday, February 12, 2005 11:41:40 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Saturday, February 12, 2005

    Can anyone be surprised with Cisco's decision to enter the XML Messaging market ? With the rapid propagation of XML into the mainstream market esp in the areas of XML Messaging (aka XML SOAP Services), Middleware, Brokering, Intermediaries, it is about time customers get more choices and exposure in this arena.

    With Cisco in this segment of the market, I do expect more alternatives and choices in XML Boxes to be had by customers and them paying lesser as well.

    I still remember very clearly it was only less than 2 years back when I brought up the idea of introducing an XML Firewall into a client's environment by then Flamenco Networks (which is now acquired by Digital Evolution) and being pooed-pooed right in my face on how a text-based representation can be used for messaging and how the contents of this representation can be inspected at wire-speed at the hardware level.

    Well, Moore's Law has made it so that the price and speed of high-powered specialized processing such as XML-Encryption and XML-Digital Signature besides just plain inspecting and routing of SOAP packets can be made available to the grasp of the general masses. This will also bring forward the concept of Application-Oriented Networking into the market. I dunno BUT are we seeing another layer of abstraction into the mix now ?

    Too bad this client is not around anymore for me to say "I told you so..."

    I am very interested to see how this whole affair pans out with the middleware app-server companies such as Big Blue

     

    Saturday, February 12, 2005 8:28:11 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Friday, February 11, 2005

    I have been a very interested observer in the recent debate between Tim and Clemens on their definition of the contract in the context of XSD/WSDL/Policy. Aaron has this to share as well which I read with great interest.

    I have done a fair amount of work in preparing to give some prezzos and talks about XSD/WSDL/Policy this year. This is the feedback I had gathered over past few months when developers questioned the reach of interoperability of XML SOAP Services...and most of the time, they have no idea what is going on with the XMLSerializer and the WSDL Generator.

    Although I am on Clemen's side when he states that:

    "Staring at WSDL is about as interesting as looking at the output of “midl /Oicf”."

    I do stand on different ground as him when I believe that developers still need to know what is going on in the deeper plumbings of things. Semantics discovery is still a distance away. While the RAD approach of VS.NET and Indigo is great in churning out developer and business productivity, the real world of the enterprise is rather different. Working in a fairly large SI give me an in-depth look at how disparate systems MUST BE made to integrate and work with each other. Introducing newer, better systems such as Indigo is not even an option at this point in time.

    WSDL-generating tools are still very primtive today. There is no easy way to really extend or version my XML SOAP Services without mucking around with the brackets of WSDL today. If you implement some kind of a proxy-middleware layer approach as a messaging layer (known as the Enterprise Service or Message Bus to some), it is highly likely that it is doing things to your XSD or WSDL to attain its advertised benefits. The point is --- You cannot run away from having to muck around with it and we are not even talking about interoperability yet.

    Clemens, however, did state his point is only valid "if you’ll be sticking to Indigo". Unfortunately, I dont have that luxury to work in an environment with a single homogeneous platform and I really doubt that will change in the real world for many years to come. So besides having to know what the wire-format looks like, it is equally important to agree to that format first and this is where XSD/WSDL/Policy comes in.

    I think Aaron hit the point in his post when he did a comparison of roles between IDL and XSD/WSDL/Policy plays in the definition of a contract. However, I would read WSDL than IDL anytime of the day.

    I believe that the WSDL generated by default (*.asmx?WSDL) from VS.NET is difficult to read and understand before it is not in-line with proper practices. Modularity, Re-usability and Separation of concerns are not being diligently practiced. That is fine, and like what Clemens say, as it is not meant to be read by many humans...but by not treating it as an official contract is totally different thing altogether.

    I think WSDL is the indispensable API and is poised to be the universal contract design view. I am a great fan of the contract-first approach and Thinktecture's WSCF, currently in the 4th rendition, is a huge step in the right direction to realize that design implementation. It does a great job in separating the data types from the message types. I cannot wait for it to go one step further in version 5 where it will generate interfaces to host the service implementation regardless of where the implementation may be, amongst other things. Thanks Christian for listening to my pleas.

    And if you are not debating the fact that WSDL is the contract but it is the readability you are having an issue with, there are a couple of ways to make a WSDL easier to read. If you are having trouble with the brackets, then why not try the {curly} ones instead. I used CapeClear's Simplified WSDL Stylesheet to bend the angles into curls.

    And of course, some people from the other camp do share the same views as well.

    Barring any further whopping from Rich Salz on WSDL 2.0, I think some of the recommendations of WSDL 2.0 does make it slightly flatter and therefore easier on the eyes. Examples include:

    1. Removal of Message Constructs -- It is more or less redundant now with Doc/Literal in wide acceptance now and is rightfully placed in the section.
    2. Renaming of PortTypes to Interfaces and Port to Endpoint can give a Software / XML SOAP Service geek orgasms.
    3. Introducing XML Schema model XSD-type enhancements such as wsdl:import and wsdl:include does bring about certain principles of modularity, re-usability and separation of concerns.
    4. ...

     

    Friday, February 11, 2005 2:56:39 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Monday, February 07, 2005

    Michael Liebow, VP of Web Services at IBM Global Services has a great entry on his weblog where he asked if "Customers really want an SOA". This is really a great post and I couldnt agree more.

    He stated that Service Oriented Modeling and Architecture (SOMA) provides an approach to building an SOA that aligns to the business goals. It helps customers tie business processes to underlying applications to help the business realize benefits more rapidly. However, the key differentiator for SOMA is where the discussion starts. It's with the business problem.

    He makes a few quoteworthy notes worth repeating:

    1. "...businesses need better visibility into their business processes. Breaking the business down into component view -- from a discrete process or the business processes supporting the entire enterprise -- is critical to achieving business improvement and growth..."
    2. "...Business process modeling will map out a companies' business processes and help determine which business processes provide strategic differentiation over competitors, what processes are core and what business processes may not be considered strategic..."
    3. "...Once the business process change or enhancement aimed at growth has been identified, the technology conversation can now begin..."
    4. "...Customers need to approach building an SOA based on the needs of the business. A detailed identification and prioritization of services that a business needs to develop or expose to support improved business processes must be developed..."
    5. "...Evolving an SOA across the enterprise frees up IT resources and helps to ensure that investments in technology are focused on core capabilities aimed at growing the business..."
    6. "...An SOA is a roadmap. It's a means to an end. What they are demanding is flexibility..."

    Like what I have always been saying in my presentation and consulting rounds, and many-a-times conflicting to what a lot of people believe, when what they all want is just to implement XML and SOAP Services OR to be seen jumping on the SO(A) bandwagon so to look and seen to be in-tune with the times. Sometimes, people think they are implementing a SO(A) when all they are doing is just implement a SOAP interface to their data-element-layer. In other words, this isn't any different from implementing an n-tier architecture.

    --- The goal of every business should be to build an agile business system framework to better adapt itself to its ever-changing business environments; And like what Mike mentioned in point [6] above, an SO(A) is the current best approach to build that agility.

    Monday, February 07, 2005 3:51:27 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  • OASIS ratifies UDDI version 3 as Standard here
    Monday, February 07, 2005 2:45:35 PM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions

  •  Sunday, February 06, 2005

    SDA-Asia has recently published one of my articles online. In this article, I talked about how Web Services Enhancements (WSE) can be used to solve Real-World business problems with some proper thought and design processes.

    This is not as technical an article comparred to the ones I have written before, however, I feel it gives a good overview and insight to what the advanced XML services are and how to make use of some of them to solve some of the business problems of today...and needless to say, WSE 2.0 is THE tool to do that today in .NET

    I have spent a fair amount of time writing up a REAL technical article (on WSE, of course) recently which I hope will get published soon enough. Will update all once it goes live. Enjoy.

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

  •  Friday, February 04, 2005

    Bill Gates talks about Microsoft's commitment to interop

    Any questions ?
    Friday, February 04, 2005 12:43:49 AM (Malay Peninsula Standard Time, UTC+08:00)  #    Disclaimer 
  • Blog reactions