Wednesday, August 10, 2005
As timeline nears for Microsoft TechED Asia 2005 in Singapore (24th-26th August 2005), I have managed to firm up my topics. Besides the usual rather cryptic session topics and synopsis (Sessions  and ), I have added 2 of my own pre-packaged flavours into the mix (Sessions  and ). I hope the latter 2 sessions will be able to provide a cool new refreshing look at distributed computing (Web Services, ESB, EAI, WS-*) to the audiences and hopefully draw in some good crowds.
...so, 4 topics for the Softwaremaker. It is time to get to work on that.
1) Programming Indigo
William introduces Indigo for the first time to the masses in Singapore. He will explain the basis of its design and programming model and looks at the Whys and Whats of it. Indigo is a huge framework and he will bring the audience in for a quick sneak peek of the future of the Windows Communication Foundation and why it is not just another WS-Toolkit.
2) Building Secure Web Services Using Indigo
William introduces Indigo for the first time to the masses in Singapore. He will explain the basis of its design and programming model and looks at the Whys and Whats of it. Indigo is secure-by-default and offers many ways to tap into pre-existing security mechanisms for building connected, un-trusted boundaries. William will also share his thoughts on the interoperability aspects of WS-Security as well as the best way to move forward. William will also explain why WCF != WSE 4.0++.
3) Transactions in Web Services and WS-OtherThings Developers Love to Hate
The above interesting refreshing Title IS the Synopsis. Enough said.
4) SOA, SOAP, WS-*, BP-1.0, WSE, ESB, EDA, WCF, EAI: Making sense of all the FUD
Tired of being fed the same stuff over and over to you again and yet have no idea what you are eating ? If you know these acronyms all too well but have no idea what they meant and how they fit into the grand scheme of things OR if you ever wonder sometimes if they are just fluff or stuff, this interesting refreshing session will address some of your Fears, Uncertainties and Doubts.
Birds Of A Feather Discussion Session Forum
1) Preparing Indigo
2) Migrating ASMX to Indigo
3) SOA, SOAP, WS-*, BP-1.0, WSE, ESB, EDA, WCF, EAI: Making sense of all the FUD
I am also in the midst of assisting INETA
APAC to help co-ordinate a huge joint 3 Usergroups (WHAM BAM BIG BANG) session on one of those TechED nights. Steve Riley
from Corp will, as usual, do what he does best and present on a security topic to all 3 Usergroups (Singapore .NET Usergroup
, Singapore SQL Server Usergroup
, Singapore Windows Usergroup
). There will be a great networking event after his presentation. All in all, this should be a great event and will provide some value to those who cannot make it for the TechED day events.
I hope to see you there.
Thursday, July 28, 2005
The WinFX Runtime Components Beta 1 is available here, and the WinFX SDK is available here. Also, check out the new Windows Vista Developer Center at http://msdn.microsoft.com/windowsvista.
With this release comes with the official names for many of the technologies that they've been talking with our developers about for several years. In particular, Windows Longhorn is now Windows Vista, Avalon is now the Windows Presentation Foundation, and Indigo is the Windows Communication Foundation.
“Former” code name
Windows Presentation Foundation
Windows Communication Foundation
XML Paper Specification (XPS)
Least-privileged User Access
User Account Protection
WinFX Runtime Components
Wednesday, July 27, 2005
I had such a fun time speaking in this Ark-Group event. Getting involved in the expert panel discussion led by Neal Ford of ThoughtWorks was a blast. We had a very good ratio of academic researchers and real-world industry and field experts in the audience to work out a very well-balanced discussion.
As usual, I come from a real-world industry approach and sometimes, I cannot help but take pot-shots at the academics, all in good fun. . As Neal calls me, William the pragmatist.
I was noted in the event as one who tends to go against convention (and this is not the first time I am doing this). For example, I am not about to get caught up in the SO(A) buzz and I urged the audience not to as well. The design principles of SO(A) such as loose-coupling, etc is something that has been around for years and the branding of all these principles under a new name just doesnt fool me. Of course, I challenged the audience to define the so-loosely-defined term SO(A) and everyone seems to have so many mixed views. It is one of those things that I termed 100 different answers for 50 different people --- depending on the time of day. Service-Orientation is a different thing altogether as it talks about how you should be using certain principles or tenets to design the interfaces and how to go about using them. Now, that I buy !
This is also one of the few times I spoke out and caution against the use of a ESB or what I prefer to call as a message broker. Especially if the ESB is a productization of a vendor's proprietary technology. As one of the speakers had noted, it is not easy to maintain one, let alone implement it. Patches and fixes come in fast and furious. Someone in the audience has asked about the use of the ESB outside of the E, which I think the entire panel, including me, agreed that this will not happen in a long time to come (if at all).
As I think I have articulated well enough to the audience, the reason for ESB today (and yes, value can still be derived from it today) is to hook up legacy systems using messages and for them to be using advanced (read: Enterprise) features such as Security, Reliability and Transactions which the broker provides. Of course, it is mostly a pull-thing here because the standards for these specifications are not ratified and matured yet. I am a firm believer that the emphasis is on the message and NOT the endpoints. Once the specifications mature and the Super-platform players introduce them baked into its kernel and core, the dumb nodes around the supposedly smart ESB plumbing suddenly wont seem so dumb after all.
I have a strong inkling that Indigo will lead the way for that.
Having said that, I dont think a mass-uptake will happen anytime soon. There is a huge consolidation in the ESB market today with WS-Management and WS-Registry players coming into the mix. I expect even further consolidation when Cisco introduced its appliance-based Application-Oriented Networking into the market.
Will this be another nail in the coffin for ESB ? I believe it will be - provided the below quote is true.
There's good news here -- no one interviewed for this piece believes that the Cisco move will spark a new generation of protocols.
However, one potential issue is whether applications will have to be written specifically to AON and the network in order to take advantage of AON features. Cisco says no, but Randy Heffner, Vice President in Forrester's Application Development & Infrastructure research group, notes that "from the application side, it's going to take a while to figure out the implications of this. The key question is, "do I have to rethink my networking messaging processing?"
Somehow, I think this will go to some great lengths in addressing the latency constraints of Service-Orientation. I hope so and I like what the market is doing to go all out to embrace the world of XML-Messaging.
Tuesday, July 26, 2005
The much anticipated download of a fully installed & configured Visual Studio 2005 Team System Beta 2 VPC is now available for download to MSDN Universal Subscribers. This is the same VPC that was distributed at TechEd USA and TechEd EMEA and represents a clean install of Windows Server 2003 w/ Visual Studio 2005 Team System Beta 2.
This VPC does not contain any sample projects or sample data.
Minimum System Requirements:
If you have some trouble locating this developer-Godsend --- I have done some snopping already and it is here:
Developer Tools > Visual Studio 2005 > Visual Studio 2005 Beta 2 > English > Visual Studio 2005 Team System Beta 2 VPC
Friday, July 22, 2005
Thursday, July 21, 2005
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 http://abc.com/ep1 or http://abc.com/getSomething. 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 !
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
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."
According to Don's blog here: Indigo has support for REST since Day 1. In the same breadth, he disclosed that it will explicitly support HTTP PUT/POST/DELETE/GET to please the REST purists out there.
Like Steve mentioned here, I, too, am not a fan of technology stacks that complete with their own ideologies. To me, technology is there just to get a job done efficiently and effectively. My post here attracted quite a fair bit of hits and same-echo-sentiment emails. It even made to ZiffDavis blog list here.
As Steve has echoed as well, I am also even more convinced now that Indigo is going to be the platform to beat when it comes to distributed communications. No doubt about it.
I am really glad that the Indigo team, whom I think comprises some of the brightest minds in the software field, is all united to work towards a common goal of creating a religion and ideology-agnostic product. If this is not innovation, I dont know what is.
Show me the money, Beta1
Thursday, July 14, 2005
The perennial question: Love or Hate your Project Managers (PM) ?
Three men: a project manager, a software engineer, and a hardware engineer are in Ft. Lauderdale for a two-week period helping out on a project.
About midweek they decide to walk up and down the beach during their lunch hour. Halfway up the beach, they stumbled upon a lamp. As they rub the lamp a genie appears and says "Normally I would grant you 3 wishes, but since there are 3 of you, I will grant you each one wish."
The hardware engineer went first. "I would like to spend the rest of my life living in a huge house in St. Thomas, with no money worries and surrounded by beautiful women who worship me." The genie granted him his wish and sent him on off to St. Thomas.
The software engineer went next. "I would like to spend the rest of my life living on a huge yacht cruising the Mediterranean, with no money worries and surrounded by beautiful women who worship me." The genie granted him his wish and sent him off to the Mediterranean.
Last, but not least, it was the project manager's turn. "And what would your wish be?" asked the genie.
"I want them both back after lunch" replied the project manager."
- If you get in my way, I'll kill you! - ideal project manager
- If you get in my way, you'll kill me! - somewhat less than ideal project manager
- If I get in my way, I'll kill you! - somewhat misguided project manager
- If I get in your way, I'll kill you! - A tough project manager (eats glass, live cats, etc.)
- If get kill in will way I you. - dyslexic, functionally illiterate project manager
- I am the way! Kill me if you can! - messianic project manager
- Get away, I'll kill us all! - suicidal project manager
- If you kill me, I'll get in your way. - thoughtful but ineffective project manager
- If I kill you, I'll get in your way. - project manager who has trouble dealing with the obvious
- If a you getta ina my way, I gonna breaka you arm. - project manager from New York
- I am quite confident that there is nothing in the way, so no one will get killed. - project manager who is about to get in big trouble
- If you kill me, so what? If you get in my way, who cares? - weak, uninspired, lackluster project manager
- If I kill me, you'll get your way. - pragmatic project manager
- Kill me, it's the only way. - every project manager to date
Everyone in the project team (PMs, Engineers, Developers, etc) have a key part to play and therefore a right to exist within a project environment...and the key point is that --- Everyone wants to take care of the customer since they are the ones paying but we take care of them in our own (I know its right) ways and sometimes if anyone wants to go home earlier, it is usually at the expense of another.
There is no exact science to this. It is mainly art. If it was pure science and everything is so researched, proofed and documentated, we would not have this diagram (which has been in existence for years) still making great jokes and headlines today.