MSDN has taken to organizing a week of webcasts on ASP.NET. Last year it was their most popular event, and probably will be again this year.

As part of the event I am presenting a webcast on implementation of custom authentication and authorization in ASP.NET.

Click here to register for the event.

A couple people appreciated me mentioning Vernor Vinge's books in a previous post, so I thought I'd toss out another author I've been enjoying quite a lot lately: Alastair Reynolds.

His books are reasonably hard science-fiction, meaning that he sticks (mostly) to hard science. The exceptions are granted based on extrapolations from today's knowledge of nanotechnology and various theories of physics floating around out there.

The books are also relatively dark, painting a very cool but not entirely comfortable picture of the future. Somewhat like cyberpunk meets hard SF in outer space.

The books are:

• Revalation Space
• Chasm City
• Redemption Ark
• Absolution Gap

Three of the books form a trilogy. Chasm City is a related book in the same universe, but isn't part of the trilogy. However, it is probably best to read them in the order listed above, since Chasm City tends to make some of Redemption Ark more meaningful.

Unlike Vinge's books, I wouldn't say that these provide any great insight into SOA :)  They are however, a very good read.

I'm also nearly done with Neal Stephenson's Quicksilver, the first book in his new trilogy. The other two are out as well. These are prequels to Cryptonomicon, which I still think is the best book I've ever read.

If you have any interest in the history and origins of modern scientific thought, the conflict between Catholicism, early Protestant churches, Islam and all the related politics of kings then Quicksilver is your cup of tea. How can you beat a book that uses Isaac Newton and his contemporaries as major characters?

My one warning – Cryptonomicon and its prequels are dense. Stephenson makes wonderful, even masterful use of the English language in his writing. But the density of information means that I haven’t whipped through any of these books like I do with most other books. There’s no skimming over paragraphs of description to get to the action, since Stephenson’s descriptions are as meaningful and interesting as any conflict or dialog.

You should also be aware that, from a literary perspective, these are cyberpunk books. While none of them have cyber, and precious little punk, the literary form of the books follows the typical cyberpunk approach of telling multiple, vaguely interrelated tales that all collapse together into a single thread in the last few pages. Not everyone likes this style, but I personally love it.

It seems that TheServerSide.net has a debate going this week about O/R Mapping. As part of the discussion, one of the invited debaters made the following comment about CSLA .NET:

“…everyone just "loves" CSLA, afterall its got every feature imaginable, was created by one of the best "experts", is the subject of books and user groups -- and yes there are code gen templates for it. Now don't get me wrong, I think Rocky is a great speaker and teacher (and great in person too -- I have met him), but I think he would agree that CSLA is an example for teaching how to do something and should not really be the expected to be perfect out-of-the-box -- and its not. I've personally seen a project spend way too much time and effort doing things because they chose this route -- they had to constantly go and add/remove/modify pieces to their chosen framework -- and I've heard many others that have similar problems.” (link)

- Paul Wilson

It is not the most professionally phrased comment, but this gentleman has previously made similar comments in other forums as well, so I thought I should provide an answer.

I think it is important to note up front that Mr. Wilson sells an O/R Mapper tool, and so has some bias. It is also important to note that I have written numerous books on distributed object-oriented architecture, and so I have some bias.

CSLA .NET is intended to be a learning or teaching vehicle. It is often also useful in its own right as a development framework.

Different people write different types of books. For instance, Martin Fowler’s excellent Patterns of Enterprise Application Architecture came out at about the same time as my .NET Business Objects book. In many ways he and I are targeting the same demographic, but in different ways. Fowler’s book stays at a more abstract, conceptual level and teaches from there. My book is more pragmatic and applied, teaching from there.

As an aside, I find it wonderful how some of the patterns in Fowler’s book can be found in CSLA .NET. I think this goes to show the power of the design pattern concept – how patterns emerge in the wild and are documented to help provide a more common language we can all use in future discussions.

But back to books. We need books that give us broad theory and concepts. We also need reference-oriented books that give us basic usage of .NET, C# and VB. And we need books that try to span the gulf between the two. This is where I’ve tried to live for the most part – between the theory and reference content. To do this is challenging, and requires that the theory be distilled down into something concrete, but yet rich enough that it isn’t just more reference material.

The way I’ve chosen to do this is to pick a way of creating distributed object-oriented applications. Are there other ways? Oh yeah, tons. Are some of them good? Absolutely! Are some of them bad? Again, absolutely. Is CSLA .NET good? It depends.

Certainly I think CSLA .NET and the rest of the content in my business objects books are good for learning how to apply a lot of theory into a complex problem space. I think that many readers use ideas and concepts from my books in conjunction with ideas from Fowler’s books, the GoF book and lots of other sources.

A side-effect of writing a book on applied theory is that the theory does actually get applied. This means that the book includes a pretty functional framework that can help build distributed object-oriented applications. This framework, CSLA .NET, can be useful as-is in some scenarios. There’s a vibrant online forum for discussion of my books and CSLA .NET where you can find numerous examples where people have applied the framework to help solve their problems.

Many of those people have also modified the framework to better suit their needs or requirements. This is nothing but good. In several cases, modifications made by readers of the books have been applied back into the framework, which is why the framework is currently at version 1.4, where the book described version 1.0.

Does CSLA .NET fit every need? Of course not. No tool meets every need.

It is particularly good at creating performant, scalable line-of-business systems that involve a lot of data entry and business rules and relationships. It supports people who build a good object-oriented business entity model, because it provides for virtually unlimited flexibility in translating the object data to arbitrary (relational and/or non-relational) persistence targets (databases, etc).

It is not particularly good at creating reporting systems, large batch processing systems or systems that are very data-centric and have little business logic. There’s also a cost to the data mapping flexibility I mentioned as a benefit – because with that flexibility comes more work on the developer. If you have either a non-complex data source or you are willing to tie your object model to your data model then CSLA .NET isn’t ideal because it requires that you do more work. If you want your object model to mirror your data model then use a DataSet, that’s what it is designed for.

But the real thing to keep in mind, above all else, is this: there is a set of functionality that must exist to build distributed object-oriented enterprise applications. This includes data persistence, UI design support, business logic, organization of layers and tiers, state management and more.

The issues that I address in my business objects books and CSLA .NET are addressed in every enterprise application. Whether formally or informally, whether through reusable or ad-hoc implementations – everything I address happens in every enterprise app. (And a whole lot more things I don't address are in every enterprise app!!)

The idea that CSLA .NET has “got every feature imaginable” seems to imply that it has extra stuff you don’t need. The fact is that you will address every issue it covers one way or another, plus numerous other issues. You might address them differently that I did, and that’s great. But you will address them.

You can address them in an ad-hoc manner in each app you write. You can address them through a framework, or you can address them through tools. You might address them through a combination of the above.

But I’ll say this: the ad-hoc approach is poor. You should opt for a solution that provides reuse and consistency. There are numerous ways to do this, CSLA .NET is one and I imagine that Mr. Wilson’s O/R mapper tool is another. And there are various commercial frameworks and other O/R mappers out there as well. You have a lot of choices – which is indicative that this is a healthy segment of our industry.

The fact is that at some point you need to make hard decisions within your organization that move from the theory of design patterns and architecture down to the practical and pragmatic level of code, and you only want to do that once. It is expensive, and it does nothing to solve your actual business needs. All this code that does data persistence, layering, tiering, data binding and whatever else is just plumbing. It is necessary, it is costly, it is time-consuming, and it provides no direct business value.

And be warned – if you buy or otherwise acquire a framework or tool set (CSLA .NET, O/R mappers, whatever) you will almost certainly need to modify, extend, add or remove bits and pieces to make it fit your needs. If you do this by buying a black-box component of any sort, you’ll end up extending or modifying around the component, while if you acquire one that includes code you may opt to make the changes inside or outside the component.

Obviously you can acquire a component that does less work for you – something targeted at a narrow task. In that case you might not need to modify it, but you must face up to the fact that you will need to write all the other stuff that it doesn’t do. It isn’t like you can escape the requirement for all this functionality. Every app has it, whether you do it in a reusable form or not is up to you!

So when it comes to frameworks, O/R mappers and all this other plumbing: do it once – build it, buy it, cobble together products to do it. Whatever suits your fancy.

Then get on with building business apps and providing actual value to your organization.

I work for Magenic Technologies. Magenic is one of the nation’s leading software development and consulting companies focused on Microsoft technology, and I feel comfortable saying that we employ some of the best consultants in the industry.

Today Magenic announced that they acquired Empowered Software Solutions (ESS) in Chicago.

Personally I'm very excited about this event. I've known Keith, Tammy and Norm (the founders of ESS) for many years and it is very exciting to get to work with them and all the Chicago-based consultants. ESS has a great (and well-deserved) reputation in Chicago. That reputation will help spread Magenic's national presence into the Chicago area.

There’s a lot of talk about Service-Oriented Architecture (SOA), and Service-Oriented Programming-related constructs like web services and SOAP. There’s even a bit of talk about Service-Oriented Analysis. But where’s the discussion of Service-Oriented Design?

I am quite convinced that service-orientation (SO) is no less of a force than object-orientation (OO). For over 30 years our understanding OO has been evolving and slowly, ever so slowly, gaining mindshare in the industry. I think we can apply a (slightly modified) Grady Booch OO quote to SO as well:

“Let there be no doubt that service-oriented design is fundamentally different than traditional structured or object-oriented design approaches: it requires a different way of thinking about decomposition, and it produces software architectures that are largely outside the realm of the structure or object-oriented design culture.”

The bits in bold are my alterations/additions to this famous quote.

OO includes architecture, analysis, design and programming. Understanding and use of all these components is required to make effective use of OO in an enterprise. Precious few organizations ever pull this off. It requires a major culture and skill shift, which is one key reason why OO is still a popular sideline approach rather than the mainstream approach. (The other key reason is lack of tool support for OO design and programming, but that’s another topic.)

If SO is as big a thing as OO, and I suspect it is, then SO has decades ahead of it on the way to becoming a popular sideline approach for software development. Maybe in that time OO will have become mainstream, but I’m not holding my breath…

As an aside, I very much hope that OOA/D/P do become mainstream at some point. After all, we will need to create services, and a service is just an application with an XML interface (vs HTML or GUI). Creating services requires programming in a more conventional sense, and we’ll end up choosing between data-centric and OO just like today. Personally I really want to see more OO, because I believe it is far superior. But I’m pragmatic enough to know that it is far more likely that services will be created using the same data-centric (Recordset, DataSet, XML document) mindsets that are prevalent today in Windows and Web applications…

In my wilder dreams I envision a new programming language that is specifically geared around the creation of services. It might be neither data-centric nor OO, but rather would directly include language constructs to represent service-oriented concepts. I know Microsoft is grafting some of these concepts into VB and C# through the WSE and Indigo technologies, but that’s like prototyping for something that should come later. Perhaps S#? A language with natural expressions for the ideas inherent in SOA/D/P?

In any case, I am convinced that over the next many years we’ll need to develop SO architecture, analysis, design and programming as disciplines. Processes, techniques and tools will need to be created around all these areas. Perhaps we can do a better job with SO than we did with OO, but that remains to be seen.

But the focus of my question today is this: where is service-oriented design? There’s lots of talk and debate about service-oriented architecture. There’s lots of movement around the creation of technologies (like web services, SOAP and the WS-* stuff) to support service-oriented programming. There’s tiny bits and pieces of discussion about service-oriented analysis. But I have yet to see any serious discussion of service-oriented design.

Service-oriented design is critical. Doing service-oriented programming without service-oriented design is sure to lead to all sorts of unfortunate and unproductive results. Any modern developer knows that you need to translate your architecture into a tactical design for the architecture to be useful. You also know that programming without a design is a sure-fire way to end up with lots of rework and wasted effort.

Service-oriented design isn’t about the enterprise messaging standards, or about the transport protocols (HTTP, MSMQ, Biztalk, etc.). Nor is it about the application of WS-this or WS-that.

Service-oriented design is about the design of service-based applications. It is philosophy. It includes the design of services, service clients and other service-related software constructs. It must focus on concepts like

• relationships
• encapsulation
• message structures
• data flow
• process flow
• coupling
• cohesion
• decomposition
• functional grouping
• abstraction
• the service interface
• the service implementation
• granularity
• shared context
• and more…

Click here for an interesting discussion of procedural vs OO design. I think we need to have a similar discussion around SO design. What is it that makes SO unique and different from procedural/structured and OO design? Intuitively I tend to think that it is unique, but at this point it hasn’t been fleshed out and so we can’t have intelligent or objective discussions about how or when it is different.

In the end, I think that SO will require a comparable culture and skill shift to OO. In other words, moving to SO from either the procedural/structured or OO worlds will require major cultural and philosophical changes, and substantial retraining and relearning.

Does this mean OOA/D/P are dead? Not on your life. Neither are procedural/structured design or programming. Most software today is built using procedural techniques, mixed with half-hearted OO code. As we move (over the next 30 years) toward SO, you can bet that procedural and OO will be along for the ride as well.

As I noted in a previous entry, I rarely read computer books. However, there are exceptions.

People often ask me to suggest good books on object-oriented design. I struggle with this. I have a whole shelf of what I consider to be pretty crappy OO design books. Sure, each of them has a tidbit here and there, but on the whole I wasted a lot of money building a collection of books that sits there gathering dust.

The one book I’ve consistently recommended is David Taylor’s “Object Technology: A Manager’s Guide”. This is an absolute must-read for anyone hoping for success with OO design or programming. Yes, I know it has the dread word “manager” in the title, but don’t let that scare you off. Go buy and read the book. It is not only a delightful read (which is saying a lot for a computer book), but it is full of great ideas and information and ways of thinking.

I just got a new book that I expect will be a favorite. I’m only a bit into it, but I’m so enthused that I’m blogging now rather than waiting for the (sure to be climactic) end of the book.

The book is Object Thinking by David West. Many years ago Mr. West taught college here in Minnesota, and we brought him in to do a multi-day OO design class at the consulting company where I worked. While all of us in the class agreed that his ideas were a bit flakey, the class was absolutely full of great ideas, concepts and approaches.

This book promises to be the same as that class. Mr. West doesn’t pull any punches. He really believes in what he’s presenting, and presents it in a clear and easy to read manner. Sure, the ideas push the limits of what most people consider practical, but they are truly great ideas and deserve serious consideration.

The book reflects a lot of what I talk about in my speaking around the world. This isn’t surprising, since that class years ago certainly influenced my thinking in some very fundamental ways.

This includes ideas like anthropomorphism – where you endow objects with human-like qualities. I do this all the time in my work, and those that have heard me speak know that I do it all the time with objects, computers, networks and all sorts of things. There is tremendous value in giving inanimate entities a voice of their own, as long as you listen to what they say!

And this is the thing. My last statement there sounds flakey. Heck, it is flakey. Mr. West is full of this sort of thing. Don’t let it put you off. I mean it. I’m not much for flakey stuff, but it turns out that some of the flakey-sounding ideas he puts forward are directly useful – at least of you want to do actual object-oriented design.

On a bit of a tangent, Mr. West also tends to use the English language well. This includes using complex words and expressing complex concepts. I love this stuff. My absolute favorite author is Neal Stephenson, mostly because of his absolute mastery of language and imagery. Most computer books (including mine) get edited so they’ll be easier to translate to various other human languages – thus gaining a larger market. While that makes economic sense, it is a truly unfortunate thing, because it guts our ability to use deep language constructs and vocabulary to accurately and viscerally express the concepts we’re discussing.

I am always saying that objects are about behavior, not data. Mr. West has written a book that’s all about understanding that fundamental truth. Get this idea, internalize it, become one with it and you’ll be well on your way to really doing OO design.

My son’s 6^th grade class recently did an exercise where they voted on the US presidential candidates based entirely on the issues and positions set forth by each candidate. But it was a blind poll – the kids didn’t know who was who. The results were surprising! Click here for my wife’s write-up of the event and the parental reaction.

But it got me thinking. What would happen if you did the same thing with a room full of computer geeks, comparing the features put forth by different tools and technologies. Some ideas:

• Java vs .NET
• VB vs C#
• Web services vs Remoting
• Web services vs DCOM

And the list goes on…

But seriously. It would be very interesting to see how people “voted” for a technology based purely on its stated feature set rather than on the largely subjective criteria we use in most cases.

By largely subjective I mean, for instance, that most pro-.NET people choose it because it comes from Microsoft. Most Java people choose Java because it doesn’t come from Microsoft. But if you did a blind poll, which would be chosen? I don’t know, but I think it would be an interesting exercise!

I read a lot of science fiction. I travel a lot (which you can tell from my list of speaking engagements) and I find it very hard to work on a plane. You might think I’d read computer books, but I regard computer books as reference material, so I very rarely actually read a computer book, as much as skim it or use the index to find answers to specific questions… Besides, they are all so darn big, and it gets heavy carrying them around airports :)

So what’s the point of this post? I recently read a very excellent book that I believe has a great deal of meaning for the computer industry. Sure, it is science fiction, but it is also paints a picture of what computing could look like if today’s service-oriented concepts come to true fruition.

The book is Vernor Vinge’s A Deepness in the Sky, which is a prequel to A Fire Upon the Deep. Fire is an excellent novel, and was written first. I highly recommend it. However, Deepness is the book to which I’m referring when I talk about the links to the computer industry.

I doubt the links are accidental. Vernor Vinge is a retired professor of Computer Science in San Diego, and obviously has some pretty serious understanding of computer science and related issues.

I should point out that what follows could give away key points in the story. The story is awesome, so if you are worried about having it lose some of its impact then STOP READING NOW. Seriously. Take my word for it, go buy and read the book, then come back.

The technology used by the Qeng Ho (the protagonist race, pronounced “cheng ho”) in the book is based on two core concepts: aggregate systems and the wrapping/abstraction of older subsystems.

First is the idea that all the systems are aggregates of smaller systems, which are aggregates of smaller systems and so forth. This is service-orientation incarnate. If you know the protocol/interface to a system, you can incorporate it into another system, thus creating a new system that is an aggregate of both. Extending this into something as complex as a starship or a fleet of starships gives you the effect Vinge describes in the book.

And this is a compelling vision. I have been in a bit of a funk over the past few months. It seems like our industry is lost in the same kind of rabid fanaticism that dominates the US political scene, and that is very depressing. You are either Java or .NET. You are either VB or C#. That gets very old, very fast.

But Vinge has reminded me why I got into computers in the first place. My original vision – way back when – was to actually link two Asteroids arcade games together so multiple people could play together. It may sound corny, but I have been all about distributed systems since before such things existed.

And Vinge’s vision of a future where massively complex systems are constructed by enabling communication between autonomous distributed systems is exactly what gets me excited! It is like object-oriented design meets distributed architecture in a truly productive and awesome manner. If this really is the future of service-orientation then sign me up!

The second main theme is the idea that most systems wrap older sub-systems. Rather than rewriting or enhancing a subsystem, it is just wrapped by a newer and more useful system. Often the new system is more abstract, leaving hidden functionality available to those who know how to tap directly into the older subsystem directly.

This second theme enables the first. Unless systems (and subsystems) are viewed as autonomous entities, it is impossible to envision a scenario where service-oriented architecture is a dominant idea. For better or worse, this includes dealing with the fact that you may not like the way a system works. You just deal with it, because it is autonomous.

To digress a bit, what we’ve been trying to do for decades now is get computers to model real life. We tried with procedures, then objects, then components. They all miss the boat, because the real world is full of unpredictable behavior that we all just deal with.

We deal with the jerks that use the shoulder as an illegal turn lane. We deal with the fact that our federal tax cuts just get redirected so we can pay local taxes and school levies. We deal with the fact that some lady is so busy on the cell phone that she rear-ends you at 40 mph when you are stopped at a red light. We deal with the fact that the networks run R rated movie commercials during primetime when our kids are watching TV.

The point is that people and all our real world systems and devices and machines are autonomous. All our interactions in the real world are done through a set of protocols and we just hope to high heaven that the other autonomous entities around us react appropriately.

Service-oriented architecture/design/programming is the same thing. It has the potential to be the most accurate model of real life yet. But this won’t be painless, because any software we write must be ready to deal with the autonomous nature of all the other entities in the virtual setting. Those other autonomous entities are likely to do the direct equivalent of using the shoulder as a turn lane – they’ll break the law for personal advantage and from time to time they’ll cause an accident and every now and then they’ll kill someone. This is true in the real world, and it is the future of software in the service-oriented universe.

To bring this back to Vinge’s Deepness, the various combatants in the book make full use of both the distributed autonomous nature of their computer systems, and of the fact that the systems are wrapping old – even ancient – subsystems with hidden features. It isn't understanding a computer language that counts, it is understanding of ancient, lost features of deeply buried subsystems that gives you power.

We are given a vision of a future where systems and subsystems are swapped and tweaked and changed and the overall big system just keeps on working. At most, there’s adaptation to some new protocol or interface, but thanks to autonomy and abstraction the overall system keeps working.

It is perfect? Absolutely not. In fact I never saw the big twist coming – nor did the protagonists or antagonists in the book. The overall system was too complex, too autonomous. There was no way they could have anticipated or monitored what eventually occurred. Very cool (if a bit scary). But I don’t want to spoil it entirely, so I’ll leave it there.

Go read the book, hopefully it will inspire some of the same excitement I got by reading it. It certainly gave me an appreciation for the cool (and scary) aspects of a truly service-oriented world-view!

Some people are still trying to have browser wars. Now it is apparently between Firefox and IE. What a misguided concept.

Star Trek covered the issue years ago in an episode titled “Let that be Your Last Battlefield” (which is probably the only good episode in all of season 3). In this episode there are two characters. One, named Lokei, has black skin on the left side and white skin on the right. Another, Bele, has black on the right and white on the left.

The point of the episode is to illustrate just how inane the concept of racism really is. But the lesson is easily extended to any scenario where meaningless differences are used as a divisive technique. This is true of the silly arguments between VB and C#, Ford and Chevy, and is equally true of the so-called “browser wars” of today.

When two things are identical except for superficial differences then it is a massive waste of time and energy to get worked up over who picks which thing. People who consider themselves “superior” for picking on set of superficial differences are simply (not to pull any punches) idiots.

Years ago when I was a DEC VAX guy we used DEC branded VT terminals (VT52, then VT100 and VT220).

Another company, Wyse, had VT terminals that were cheaper so we switched to them. These terminals also had a couple odd features we didn't use – after all, we still had lots of DEC terminals, so we stuck with the common (standard) ESC sequences.

Browsers are the same thing. Since HTML has stagnated (or was that standardized?), it doesn't really matter what browser you use. Who cares? Virtually all web sites out there use HTML 3.2, because that’s the de facto standard that works reasonably well on all terminals – oops, I mean browsers.

The difference between having tabs or not, the specific icons on the toolbar, or how favorites are organized are immaterial. In the end, all the current browsers pretty much understand the same ESC sequences (except now those sequences are HTML – whoop de doo).

Sure, some people are foolish enough to use the browser as a programming platform (as in using client-side script to do a rich UI). Those poor people are stuck with IE (or whatever browser they targeted), but that is a poor strategy anyway. Note the total lack of development tools support for client-side programming. There's not a vendor out there who is encouraging or enabling client-side programming. It is a total dead-end wasted investment in the long run.

No reputable Internet company is foolish enough to go down the client-side script road. Only misguided IT shops are doing this, and they are going to get burned over time...

If you want a rich client, use Windows or GNOME or KDE. That’s what these technologies were designed for!!!! Don’t bastardize a terminal/browser into doing something way beyond its design parameters. That’s like using a duck as a pack animal when there are perfectly good mules and horses standing right there.

In the end, when you look at IE or Firefox, either switch, or don't switch. I honestly don't see where it matters. This is fundamentally the same debate as whether to switch from VT terminal vendor X to vendor Y - only now the price for both products is zero.

IE is black on the left side, and Firefox is black on the right. Other than superficial differences they are the same damn thing.

In the Star Trek episode the two “races” had fought so long and hard that they’d literally destroyed their planet. Lokei and Bele were the only members of their world left alive. Thankfully the “browser war” is unlikely to decimate Earth or even the IT industry, but it certainly does have the potential to waste more time and energy than free products can possibly be worth…