The .NET Sweatshop

Working day and night to help .NET users get the most out of programming the coolest platform on the planet.

Thursday, February 12, 2004

We've been getting a lot of feedback lately about the simplicity of our blocks (or lack thereof). The Data Access application block (DAAB) has been a hit, but some people (myself included) think that while it was cool, the scope was small enough to limit the impact it's had on my coding behavior. But that's the beauty of it for most people. Two classes (one a supporting class, really) and a small series of straightforward methods. You can never look at the CHM file and have great success with the DAAB. The Exception Management block offered more flexibility and configurability and that made lots of people happy, but some were confused by the options. "Just tell me what to do--I don't need options" is what one person once told me. And then there's UIP + Asynch Invocation. Both would be hugely useful if people could understand them. We recently did a webcast on UIP and the turnout doubled the the turnout of all the other webcasts we've had--mostly people who really wanted to functionality and were trying to make heads or tails of it. So what's the solution? Is the the DAAB's simplicity, the EMAB's flexibility, or UIP's thoroughness? I lean toward EMAB myself, but I think we are always going to do what we think the situation calls for. While I will advocate erring on the side of simplicity, I don't think UIP could have been as simple as the DAAB and still have been useful. But that doesn't mean that more easily consummable classes and improved QuickStarts can't help save the day. There's your real solution--keep it useful but give them the clear on-ramp. That's the QuickStart dream. Now we just have to give the Quick Start a new name so that all the baggage associated with it goes away...

Wednesday, February 04, 2004

Several weeks ago, I did another webcast--this time as a "guest appearance" with Ron Jacobs. Yes, my life has been reduced to a series of cameos in our webcasts. As the speakers get better, I step back and just orchestrate. Still, I like to participate and I've got no problem playing second banana. Ron was doing his presentation on Shadowfax, the upcoming reference architecture from PAG. This has the potential to be wicked cool. It's a long time in coming from us (we've been meaning to do one of these for years) and has the potential to be something extremely useful for customers. But, of course, the big three letters come out to play on this one: S-O-A. Aaah!!! Hide the children!!! I tend to think SOA is a little like community--everybody's got an opinion on what it means and what it entails. I think many people believe MSFT's message is that everything in the world should be a web service. Well, what would be so wrong about that. :) OK, that might be a LITTLE unrealistic. Still, implementing an SOA does not require web services, SOAP, WSDL, or any other four-letter acronym (nice to see we've evolved from TLAs). To really have an opinion on what SOA is, you need to know what a service is in the context of SOA (i.e., what are we "orienting" on?). I like Andrew Layman's description of a service best. In Keith Ballinger's book (I swear I am not trying to shill for that book, but it does come in handy) ".NET Web Services", he described a web service as "application logic that is accessible through Internet standards". I like that definition. Notice that it doesn't mean only the XML/SOAP/WSDL/UDDI stack. However, if you want maximum flexibility for the long-term, it's hard to beat XML. It's this eternal battle for programmers between not wanting to ditch old apps (the "if it ain't broke" syndrome) vs. wanting to embrace the future (the "bells & whistles" syndrome). I remember someone asking me if web services was the next CORBA--great intentions, good implementation, and doomed to failure due to incompatability and lack of vendor support & standardization. I'd like to think efforts like WS-I are built to avoid that. That's why Shadowfax is built to support multiple communications mechanisms. Web Services are still the best method for many (most?) cases, but if you want to stay away from the XML, we got your back. Service-Oriented Architectures without web services? What'll they think of next?