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.
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
- When to use What
- More Thoughts
- Distributed Security
- 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
After so many years, I have finally activated my first PSS call to Microsoft. All these years, I have been prowling Google and MS user-and-newsgroups rendering help and sometimes receiving help as well. Never had I once need to activate a PSS call. Power to the MVPs
However, I had this pressing problem that couldnt be solved and because of that, I had to skip a few cool demos which kinda sucks.
The problem revolved around the installation of SP1 on top of Windows Server 2003. It just rolls back halfway during the installation process without giving me a reason why. I also noticed that it happens during the installation of this file cladmwiz.dll, which is strange because I am not running any kind of clusters.
It was definitely a long and tedious day with a very helpful person from PSS Microsoft. There were language muckups because the APAC PSS center is based out of Greater China and it takes a good 3 minutes just to make sure we get the Case Reference ID correct. Patience is definitely his middle name.
Finally, we came to the troublespot and found a way to workaround it. The problem were the UDDI Components that was installed on my Windows 2003 Server machine. Apparently, SP1 doesnt like it enough to install itself on top of it.
Here is the workaround:
- Extract this attachment to the target machine.
- Extract the sp1 package with the following command line: [sp1 package file].exe -x
- Run the following command line on the target server: uddisp.exe install [sp1 path]
- Then, uninstall UDDI component through Add/Remove Program
- Install the service pack 1 again.
I hope this helps someone out there as days and days of googling resulted in nothing. This will also save some poor soul from activating the PSS for help.
Now in the first place, why isnt this documented ? It seems that I am the only one in the world who uses UDDI on Windows Server 2003 SP1.
You know what ? Somehow, why am I not surprised ?
Thursday, July 07, 2005
I have been following the exchanges between Savas, Jim Webber, and Michi Henning here and here. There are more links but I will leave it up to the interested reader to use a RESTful approach to refer to those resources from the above 2 links.
To be honest, this has been piped over the newsgroups, forums, conferences, etc for some time now and it is really nothing interesting to debate about, really.
All this noise has led to a lot of FUD in the field and I get a constant barrage of questions in any of the technology conferences I speak in or attend. I work in the fields out there and therefore I tend to approach technology unlike that of academics, trainers or vendors. I do what clients want in the most efficient way (read:cost_and_resource-effective) possible. I have met a few people from academics as well as from the product vendors who entered the field thinking that just because they can point out which exact page number explains the ds:SignedInfo in _WS-Security Specs_, they can convince and conquer the field and have every single customer out there upgrade their existing technological infrastructure every 6 years.
Well, the Mainfraimes, the CICS and the COBOL wonks are still out there. Still making a lot of money for its vendors and service providers. People are still driving Ladas and these legacy will be there for some time, probably a long long time.
We get a lot of younER developers who are very confused with all barrage of technologies out there and sometimes people on the field (which means customers as well) get the short end of the stick when these developers use the wrong technology in the different parts of the technical solution. So, yes, some of the stuff you read in the Daily WTF is not ficticious.
Sometimes, when I come across comments like these here from Savas's blog here:
> Microsoft is betting on SOAP and made it a key part of its distributed computing platform, not DCOM.
Betting on SOAP? Hmmm... .NET remoting does not use SOAP. It uses a binary protocol for performance reasons. So, I'm not sure that Microsoft are "betting on SOAP". They certainly are not for their .NET remoting protocol. And DCOM failed because it could not be made to scale, due to its misguided garbage collection idea. And because DCOM, amazing as that may sound, was even more complex than CORBA.
Somehow, I either feel that I still dont get the picture or that irrationality is clouding good judgement (still).
Of course, .NET Remoting doesnt use SOAP. In fact, it used to and is deprecated for good reasons. It is a distributed object technology which implies implicit method invocation. SOAP is not a distributed object technology. It is all about services, all about standard schemas, being explicit in design and yes, it also means dispatching these XML documents on a "hopeless transport" or the Lada of the network protocol today. You cannot compare them just like you cannot compare the performance of objects and services.
Is this the best we can do ? Of course NOT. Should we all dump our existing heap of scrap metal in our garage and get the shiniest and fastest aluminium today ? Of course. Are we going to empty our bank account, forfeit and compensate on our current loan arrangments to do it ? NO, NOPE, NADA ... This is a just a fact that we have to deal with.
Having said that, to me, both sets of distributed technologies will have its place to stay, regardless of what the vendors say to sell more and the trainers sell to teach more. Each have its place and their merits tend to show up best if used and deployed wisely in the different layers, tiers and boundaries of a decent, usable and viable solution. When I say Solution, I mean an entire composition of different new and old systems that services a business program, initiative and ultimately a goal. Isnt that what we are building systems for in the first place or have I totally lost my mind and lost track of who my paymaster is ? Dont get me wrong, progress is not possible without making full proof and implementations of the latest rocket science or theories. But Progress can be measured in many ways. To most people, progress is measured by how they can make legacy or existing technologies and architetures last and endure given the rapidly evolving set of standards, protocols and environments and how fast they can go home and spend time with their families as age increases and TTL declines.
COM+, DCOM, .NET Remoting is something we use very frequently on the field, and for good reasons too. I am known to be a (W3C) SOAP Wonk BUT I will not give them up easily within the innards of my system and I will use SOAP for the reasons it was designed for. In fact, to me, one of the most important features in SOAP is the @role (@actor) and the @mustUnderstand. Or else, I would just stick with just plain old XML.
Is Microsoft betting on SOAP ? You bet, and so is the entire industry. It is a well known fact that while it is simplistic in design (in fact, this is one of the wierd specification that becomes simpler as the newer iteration evolve. Let hope it remains this way), getting across-the-board agreement is the costly element. In fact, it took 5 years from the original design meeting and prototype to become an “official” specification and it (SOAP 1.1) is still not an official W3C Submission. The cost to each participating organization easily crosses several million USD. The rough estimates to putting the final WS-* specs to bed (if there is such a thing) would easily be more than 20 million USD.
Just like life, in the field of software engineering, compromise is something we need to work with. I once had a straight-through exhaust pipe the circumference of a toilet bowl fitted underneath my car as well as a wide-open air filter underneath the car bonnet. After 3 months, I couldnt deal with the generated noise as well as the (less-dense) hot air the air cone was taking in from all angles so I dumped both of them. While it may take me slightly longer (by a few seconds, perhaps) to reach the market to buy groceries, the brat in the younger me learnt to deal with it.
While, I have my own ideas on the Request/Reply MEP, RPC, Document-Literal Messaging, etc and I like to share my research and thoughts with some of the brightest minds in the industry over a hot cup of Java, it is not something I lose sleep or sweat about. It just serves to keep my sanity in check when I still have to deal with OLE and VB3 issues today and it does make good conversation with some of the most intelligent geeks out there.
Sometimes, I feel the point of technology is lost when people argue over stuff like that. To these people, I recommend a good classic read: Technopoly: The surrender of Culture to Technology by Neil Postman