Need a better name for “Messaging”

As DevHawk/Harry Pierson pointed out in comments to my "I’m going to DisneyWorld" post, I need to massage the title of my messaging talk a bit so as not to confuse the masses at TechEd who think "messaging" means "email/Exchange". Any suggestions?

Hani’s biling again….

Hani’s at it again, talking up (in his inimitable style) talking up TheServerSide Symposium next month. He must’ve been running low on the creative juice, because when he gets around to my name , the best he can come up with is:

    Bill Berk will no doubt tell us how great JBoss is (I hear he’s been practising his umms, hmms and errrs). Gregor Hohpe will STILL be trying to sell more copies of his book (possibly giving Jason Hunter a run for his money in the best-dead-horse-flogging-via-a-book category), while Ted Neward will drop names and refer to Microsoft celebrities by their first name (that really must wow the girls) and somehow try to convince us that .net is relevant for java people. Rod Johnson will have completed his transformation from mild mannered intelligent British guy to freaky mad glint in the eye Spring zealot and ejbhater (possibly with a bigger posse in tow that his six pitiful acolytes last year).

Oh, come on, Hani, you can do better than this. How about

    , while Ted Neward will try vainly to convince us that EJB is still somehow relevant and thus try to sell a few more copies of his lame-ass book


    , while Ted Neward will attempt to inject into his talks something that passes for humor in his eyes by insulting the attendeees


    , while Ted Neward will once again try to hog as much camera time as he can and this time, instead of moderating a panel, he’ll just run the entire panel himself, from asking the questions to answering them and getting into a fight onstage with himself

I mean, really, Hani, you are so much better than this! 😉

EEJ’s first 1-star review

… and the author of the review, Don R. Hanson II, it’s a legitimate beef:

    I feel kind of lonely here; everyone else seemed to love this book. Looking at the table of contents, I was very excited when I started reading the book. However, while reading it cover to cover I slowly became more and more dis-illusioned with it.

    The book is divided up into a number of recommendations, called items, in a manor similar to Effective C++ and Practical Java. The problem is that most of the items appear to fall into one of a few general catagories:

        Intro level generalities of good design for the web. e.g.
            pass data in bulk – multiple asynchronous calls out of process are more expensive than one big call
            make deployment as simple as possible – exactly what it says!
            use HttpSession sparingly – this is web application design 101
            always validate user input – my personal favorite; who today is not validating user input received from the web?
        Using a pair of items to represent a classic design best practice. e.g.
            Lazy-load infrequently used data & Eager-load frequently used data
            Consider using optimistic concurrency for better scalability
            Consider using pessimistic concurrency for explicit concurrency control
        Re-statements of some of the principals of secure coding e.g.
            Security is a process, not a product
            Remember that security is not just prevention, aka "fail securely"
            Assume insecurity, aka "grant minimal trust necessary"
            Establish a threat model

    My copy of this book has long been in the trash. Save your money. Here are a couple of free online articles to get you started:

        Secure coding:
        Article on stopping SQL injection:

Well, I can’t really deny his implied criticism that the book is too basic for his taste: much like its predecessors, the book is designed to cater to people who’ve not seen many of these ideas before, ideas which long-time architects and developers are probably already familiar with. As a matter of fact, I even make reference in the prologue to the idea that many of these items will likely elicit a "no duh!" reaction from seasoned veterans. But, in fact, the same was true of Effective C++ and Effective Java (the latter, in fact, elicited some of the same response from me when I first read it, then realized over time that this was because I had already stumbled across a lot of the items in person, and so wasn’t illuminated by it as much as I had been by Effective C++).

In response to some of your comments, such as "who today is not validating user input received from the web?", all I can say is that the OWASP Top Ten security vulnerabilities list pretty much answers that question, in that XSS attacks, command injection attacks, buffer overrun attacks and others all stem from improperly validated input from the user, so apparently the basic answer is, a lot of people.

But to address the basic issue, I formally call to anyone who thinks EEJ is too basic to email me the kind of items they’d like to see for a "More Effective Enterprise Java", in case A-W and I decide to produce said follow-up volume.

You don’t miss something until it’s gone…

If you’ve tried to reach the weblog and failed recently, it’s not your fault; we’ve been having some "issues" with our ISP here at the house, and as a result, the server (which is sitting under my desk) seems offline at times. I promise, the server is still running, it’s just that you can’t reach it. 🙂

This is one of those decisions that I’m not really looking forward to: when we make the Big Move Up North, do I continue hosting this domain on my server in my house, and be somewhat hostage to the support infrastructure of my local ISP provider, or do I co-lo the box (or just let somebody else’s box host the Web and EMail services) with a more reliable ISP that will be a bit more proactive in finding and shooting down the problems? Any suggestions or experiences?

Needing recommendations on good domain providers

I just noticed that was available, so I purchased the domain and will probably start moving the "professional" side of my life over there so as to have both a "personal" presence (here) and a "work" presence (there). This then raises an interesting question: assuming I want to host the domain on an ISP’s machine, does the blogosphere have any good/bad comments about various providers? I’d be looking for:

    Unlimited email accounts, or at least a fairly high (>100) number before additional charges kick in. I want to be able to try and keep spam to a minimum by using "tracker" email accounts when registering for downloads and stuff.
    Either an ASP.NET or Servlet/JSP engine capability, though database backing isn’t necessarily required. Obviously I want to be able to host a weblog on the domain.
    High or unlimited bandwidth. Though I don’t expect people to come flocking to my domain, I don’t want to get nailed with unbelievable surcharges the one time I get SlashDotted.
    Fairly high (>500MB) file capacity allotment. I want to be able to put seminar demos, examples, and other such things, on the server for people to get hold of.

I know there’s some strong opinions out there, so….

“What the hell…?”

I know. I said exactly the same thing.

Some of you reading my weblog or visiting the site probably wondered if I’d fallen off the face of the planet–I had no weblog, I had no site, I didn’t even have any kind of email connectivity, and if you’re part of my messenger buddy list, you didn’t even see me online that much. Some people tried to call, and got nothing but voice mail the entire week. A few people even expressed downright concern–was everything OK? Was I moving early? Was I burned out and just wanted to get away from it all for a while…?

No, Ted just discovered first-hand how addicting a broadband connection can be, and how dangerous hosting your own email and web server from that broadband connection can be when that connection goes down while you’re 8,000 miles away.

I left for London on Saturday (to teach a Web Services .NET class, for the record), and by the time I landed at Heathrow on Sunday, my site was down, more or less permanently, until Thursday. We’d been having some flakiness with it already before I left, but it was a sporadic thing; we had SBC come and look at the line, but the line looked fine. The DSL modem might have been suspect, or the router, but major power spikes aside, it’s hard to imagine what might have killed a piece of electronic equipment that has zero moving parts. My router was doing some strange things on Thursday (at one point it went into its best imitation of a blue screen, going into continuous reboot cycle until I powered it off and on again), but it was again pretty sporadic and I just chalked it up to some random static.

By Monday, it was pretty apparent it wasn’t static.

Here’s where things get fun: as an exercise to the reader (which is the ubiquitous catch-phrase of authors meaning "I don’t want to figure it out myself, so YOU do the work and I’ll claim the credit for having posed such a cool problem to you"), debug, from an airport 8,000 miles and 8 hours time zone differential away, a flaky Internet connection. You can’t Telnet into the box, you can’t VNC into the box, you can’t even ping the box (because you shut ping down at the firewall for security reasons).

Monday, Tuesday and Wednesday were spent more or less round-robining between the local ISP and Southwestern Bell (SBC), trying to each selectively determine why it was the other guys’ fault. Finally, the local ISP, Omsoft, took it upon themselves to come inside the house and have a look at the DSL modem (which they replaced), then a second time (to replace the DSL modem that burned out after one day), then finally a third time (to discover it was my router, after which point they just plugged the server into the DSL modem directly). By Friday, the server was alive, even though it wasn’t accepting HTTP requests. (Somewhere in all the wackiness the Web service got stopped.)

Needless to say, I’ve learned my lesson–, my new "professional" domain and future home of the technical weblog (so this can remain a more personal one, though it may still talk about technology at some levels, since that’s so much a part of my life), will be professionally hosted, so that outages become THEIR problem and not mine. Hopefully they won’t go on vacation to London anytime soon….

Oh, and class was great, thanks. 😉

Next technology, I want it to be about something OTHER than reuse

I was reading an article by Aaron Skonnard (of Pluralsight) in MSDN Magazine while on a break teaching last week, this one on SOA and a sort of general introduction to what SOA was supposed to be. No offense to Aaron, but I was struck by how the opening paragraphs of his article sounded suspiciously familiar–no, he wasn’t plagiarizing anybody, but it was those catch-phrases, the ones we’re all so painfully familiar with, that really leapt out at me. SOA was supposed to foster better modularization and encapsulation, enable re-use, and so on.

I’m curious: just how many technologies are created that DON’T foster re-use at some level?

A quick Google search reveals that "Enable reuse" turns up 2M hits, and the top two links?

    Catalogs. Catalogs enable reuse and create efficiency. Automation modules are composed of objects, which are derived from catalogs. (From, whatever that is.)

Wow. Catalogs enable reuse. AND create efficiency. Gotta get me some of that!

The next link I found even better:

    … "The key to value-added custodial servicing in this market is to enable re-use of existing market standards and practices – particularly by those buy-side …

was from a site labeled as SWIFT. Custodial servicing. Enabling re-useof existing market standards and practices. Custodial servicing.

Is there anything in this world that doesn’t enable reuse? The remaining top ten links cite "Web services", "Tests and Testing Methodologies", "Web Parts" (from MSDN), "Want to service-enable your enterprise? Model first!" (from TechTarget), "— provides effective solutions that enable people reuse structured content across networks", "Enable code reuse" (through .NET Reflection), and of course, lest we leave THEM out of the picture, "Migrating CORBA 2.x applications to CCM", which tells us that "… CCM based applications will enable "Reuse" and "Assembly" that will be the key to productivity enhancement, software longevity and cost reductions." Across 10 hits, we stretched across 5 or 6 different technology platforms. And the only reason we didn’t fall as far back as C or COBOL links is because those are "dead" languages, despite having more lines of code written in them then Java and .NET combined.

Are we starting to get a clue yet? If the problems with our industry were all about enabling reuse, then either we’re all collectively pretty stupid, or else the problem isn’t about enabling reuse. Or modularization, or strong typing or weak typing or strong coupling or weak coupling or….

Do I know what the problems that plague our industry are? Nope. Or rather, I guess I can list the symptoms off as well as the next guy, but that doesn’t mean I have any deep insights as to what solves the problem. But just to try something new, the very next application I write, I’m going to forget about "enabling reuse" and see how far I get.

Who knows? Somebody else might find the approach useful.

Speaking schedule for the next month or two

More than a few people have asked me already what shows I’m speaking at this coming year, and the short answer is that there is no short answer. 🙂

First stop on the 2005 speaking circuit for me is TheServerSide Java Symposium 2005 March 3-5 in Las Vegas, where I’m doing two talks ("Effective Enterprise Java", of course, and "WS-Peril: The Perils of Web Services"). I’m looking forward to hanging out with my former gang from TheServerSide, and seeing how TechTarget is treating them these days. Of course, I’m also looking forward to seeing Rod, Gregor, Jason and Adrian again, as one of the great benefits of the TSSJS show (at least, based on my impressions from last year) is that they do a great job bringing together some of the best thinkers in the Java space into one place. Some of the hallway conversations at last year’s TSSJS were just phenomenal; I in particular remember one with Rod Johnson over Spring’s role in the Grand Scheme of Things, and Rod’s frank admittal that they weren’t trying to completely replace EJB, just provide something other than bazookas to kill roaches (my words, not his). 🙂

Almost as soon as I get to Vegas, I’m off to Milwaukee for the first of this year’s No Fluff Just Stuff shows, which promises to be another whirlwind ride. I’ve tentatively committed to doing every(!) NFJS show on the schedule this year, which should be an interesting ride. Of more interest to most readers of this weblog is that this year marks a significant change to the NFJS format: we’ve added a .NET track, shepherded by yours truly, which will include talks from myself, some of the existing NFJS speakers (Justin Gehtland and Venkat Subramian, to name two), and two new NFJS players: Cathi Gero and Rocky Lhotka. It should make the NFJS speaker panels that much more interesting, since .NET brings a different perspective on architecture than the traditional Java viewpoint, and Rocky in particular has been on a tear to talk about architectural models for a while now. As for me, I’m talking about Effective Enterprise Java again, but also some new .NET taks on Indigo and C-Omega, among others. I’m looking forward to both a lot, particularly C-omega, since I think XML and relational integration into the language is the Next Big Thing for programming languages; should draw some interesting comparisons to Groovy.

Then, life gets doubled up for a bit as both the patterns and practices Summit West and SD West 2005 are held in the same week in roughly the same location, in Mountain View. I’m speaking at both: I’m doing a half-day Effective Enterprise Java tutorial and a 90-minute "Web Services without the bleeding edge" talk at SD West, then a "Communication Design Patterns" talk at the Summit along with a "Patterns Workshop" with Gregor Hohpe and Ward Cunningham, which has got me all tingly–we’re going to workshop a pattern and add it to PatternShare, the online patterns repository that Ward’s championed at Microsoft. (How much do I love this job? How often do you get a chance to workshop a pattern with two of the Big Patterns Guys? Wow.) Coupled with a Birds-of-a-Feather session on Web services with Michele Bustamente and Elliott Rusty Harold at SD West, the week should be chock-full of all kinds of opportunities for me to get brought up short on all kinds of things. 🙂

And that’s just March. 🙂

Christian starts chatting up Indigo

OK, so Indigo is officially out of the closet…. somewhat. And Christian Weyer, who’s been a part of the Indigo SDR team for about as long as I have (perhaps longer, dating back to TechEd of last year), has started commenting on the Indigo programming approach, starting with the explicitness of Indigo’s contract model. In it, he says:

    What really annoys me is that nearly everybody seems to ignore the interoperability aspect of services (and Web Services…) nowadays. If you (try to) do serious interop in your daily work, you won’t even bother starting with C# or VB or Java… and yes: I know that you might want to see C# interfaces and some square-bracketed attributes as one valid way to write down your service’s interface description.

As he points out (quoting Steve Vinoski as he does), going at an interoperability problem from the perspective of a programming language inevitably leads to failure, because few programmers have the discipline to ignore the trap that Steve mentions:

    When you start with the code rather than the contract, you are almost certainly going to slip up and allow style or notions or idioms particular to that programming language into your service contract. You might not notice it, or you might notice it but not care. However, the guy on the other side trying to consume your service from a different implementation language for which your style or notions or idioms don’t work so well will care.

But unfortunately, it gets worse.

I’ve come to recognize that we’re still looking to XSD and WSDL to be a sort of "IDL for interoperability", and the problem is that both Schema and WSDL allow for things to be defined that don’t fit our existing programming languages. Facets on schema types, in particular, create a particular brand of Hell for the Schema-to-class automatic translators, and fact is, most tools (xsd.exe and all of the Java-based toolkits I’ve tried thus far) basically punt on them. Which leads us to a nasty discipline problem all over again: Not only do you have to be disciplined enough to avoid the styles or notions or idioms of a particular programming language into your service, but you have to be disciplined enough to avoid the styles or notions or idioms of the wire-level representation, as well, or the consumers of the message on both sides will find it awkward to work with.

How do we avoid this? At the moment, there’s less concern for the latter than the former, but as people start to go with a more "contract-first" approach, we either have to bury the angle brackets behind a subset of what schema can offer (and thereby piss off the angle-brackety crowd), or else we have to just publish mounds of texts and patterns [1] to describe to people what to avoid and when.

Neither one sounds truly appealing, which leaves a third option, one far more radical but infinitely more satisfying: just ratify and stamp with approval the current programming practices, and introduce XML and schema types as first-class citizens into our programming languages.

[1] I categorically refuse to use the term ‘best practices’ because THERE ARE NO SUCH THINGS! Anyone who talks about ‘best practices’ is basically saying they’ve never considered the alternatives or why a particular approach is good or bad. A given solution never has all-good or all-bad consequences, but a mix of both, and how can you judge which consequences are good or bad when you take the solution out of the context of a problem that needs to be solved? DEATH TO BEST PRACTICES!


Dare points out the object-hierarchical impedance mismatch

No sooner do I finish ranting about the discipline required in going with a contract-first approach, than I start going through my RSS feeds and find that Dare has already done so. He also points out (which I think is *truly* significant):

    This isn’t theoretical, more than once while I was the program manager for XML Schema technologies in the .NET Framework I had to take conference calls with customers who’d been converted to the ‘contract first’ religion only to find out that toolkits simply couldn’t handle a lot of the constructs they were putting in their schemas.Those conversations were never easy.

Having done a few of those contract-first conversions of customers myself, I can attest to the uneasy conversation. You know that this is by far the best approach to Real Interop between platforms, but you still feel somewhat slimy: "Doing this yields the best interoperability, but you gotta be careful not to do this… or this… or this… and for God’s sake, don’t do that… or that… or this, either… Oh, and when we codegen all this, all the schema rules we put into place will probably be stripped off by the code-generating utilities we run the schema through, so we’ll probably need to do some validation by hand…." I’m always worried that a client is going to look me in the eye and ask if I’m just trying to create more work for them so they have to keep me around longer as a consultant. Ouch.

    The main thing people fail to realize when they go down the ‘contract first’ route is that it is quite likely that they have also gone down the ‘XML first’ route which most of them don’t actually want to take. Folks like Tim Ewald don’t mind the fact that sometimes going ‘contract first’ may mean they can’t use traditional XML Web Service toolkits but instead have to resort to SAX, DOM and XSLT. However for many XML Web Service developers this is actually a problem instead of a solution.

Now, I’m not sure I agree 100% with Dare that this is a problem instead of a solution–I think this is a challenge, to be met with the right tools for the job, and again, that tool being the integration of XML into our programming languages. If XML becomes a first-class construct in the language(s), then it becomes MUCH more approachable to take a XML-in/XML-out approach to doing this whole Web service (or whatever we’re going to call it in five years, because I’m pretty sure "Web services" as a term is done) thing.