I just finished watching Eric Rudder’s keynote on Indigo at VS Live in San Francisco. As with all keynotes, it had glitz and glamour and gave a high-level view of what Microsoft is thinking.

(for those who don’t know, Eric is the Microsoft VP in charge of developer-related stuff including Indigo)

Among the various things discussed was the migration roadmap from today’s communication technologies to Indigo. I thought it was instructive.

From asmx web services the proposed changes are minor. Just a couple lines of code change and away you go. Very nice.

From WSE to Indigo is harder, since you end up removing lots of WSE code and replacing it with an attribute or two. The end result is nice because your code is much shorter, but it is more work to migrate.

From Enterprise Services (COM+, ServicedComponent) the changes are minor – just a couple lines of changed code. But the semantic differences are substantial because you can now mark methods as transactional rather than the whole class. Very nice!

From System.Messaging (MSMQ) to Indigo the changes are comparable in scope to the WSE change. You remove lots of code and replace it with an attribute or two. Again the results are very nice because you save lots of code, but the migration involves some work.

From .NET Remoting to Indigo the changes are comparable to the asmx migration. Only a couple lines of code need to change and away you go. This does assume you listened to advice from people like Ingo Rammer, Richard Turner and myself and avoided creating custom sinks, custom formatters or custom channels. If you ignored all this good advice then you’ll get what you deserve I guess

As Eric pointed out however, Indigo is designed for the loosely coupled web service/SOA mindset, not necessarily for the more tightly coupled n-tier client/server mindset. He suggested that many users of Remoting may not migrate to Indigo – directly implying that Remoting may remain the better n-tier client/server technology.

I doubt he is right. Regardless of what Indigo is designed for, it is clear to me that it offers substantial benefits to the n-tier client/server world. These benefits include security, reliable messaging, simplified 2-phase transactions and so forth. The fact that Indigo can be used for n-tier client/server even if it is a bit awkward or not really its target usage won’t stop people. And from today’s keynote I must say that it looks totally realistic to (mis)use Indigo for n-tier client/server work.

One last post on SOA from my coffee-buzzed, Chicago-traffic-addled mind.

Can a Service have Tiers?

Certainly a Service can have layers. Any good software will have layers. In the case of a Service these layers will likely be:

1.      Interface

2.      Business

3.      Data access

4.      Data management

This only makes sense. You’ll organize your message-parsing and XML handling code into the interface layer, which will invoke the business layer to do actual work. The business layer may invoke the Data access layer to get/save data into the Data management (database) layer.

But layers are logical constructs. They are just a way of organizing code so it is maintainable, readable and reusable. Layers say nothing about how the code is deployed – that is the realm of tiers.

So the question remains, can a Service be divided into tiers?

I’ll argue yes.

You deploy layers onto different tiers in an effort to get a good trade-off between performance, scalability, fault-tolerance and security. More tiers mean worse performance, but may result in better scalability or security.

If I create a service, I may very well need to deploy it such that I can provide high levels of scalability or security. To do this, I may need to deploy some of my service’s layers onto different tiers.

This is no different – absolutely no different – than what we do with web applications. This shouldn’t be a surprise, since a web service is nothing more than a web application that spits out XML instead of HTML. It seems pretty obvious that the rules are the same.

And there are cases where a web application needs to have tiers to scale or to be secure. It follows then that the same is true for web services.

Thus, services can be deployed into multiple tiers.

Yet the SOA purists would argue that any tier boundary should really be a service boundary. And this is where things get nuts. Because a service boundary implies lack of trust, while a layer boundary implies complete trust. Tiers are merely deployments of layers, so tiers imply complete trust too.

(By trust here I am not talking about security – I’m talking about data trust. A service must treat any caller – even another service – as an untrusted entity. It must assume that any inbound data breaks rules. If a service does extend trust then it instantly becomes unmaintainable in the long run and you just gave up the primary benefit of SOA.)

So if a tier is really a service boundary, then we’re saying that we have multiple services, one calling the next. But services pretty much always have those four layers I mentioned earlier, so now each “was-tier-now-is-service” will have those layers.

Obviously this is a lot more code to write, and a lot of overhead, since the lower-level service (that would have been a tier) can’t trust the higher level one and must replicate much of its validation and possibly other business logic.

To me, at this point, it is patently obvious that the idea of entirely discarding tiers in favor of services is absurd. Rather, a far better view is to suggest that services can have tiers – private, trusting communications between layers, even across the network between the web server hosting the service interface and the application server hosting the data access code.

And of course this ties right back into my previous post for today on remoting. Because it is quite realistic to expect that you’ll use DCOM/ES/COM+ or remoting to do the communication between the web server and application server for this private communication.

While DCOM might appear very attractive (and is in many cases), it is often not ideal if there’s a firewall between the web server and application server. While it is technically possible to get DCOM to go through a firewall, I gotta say that this one issue is a major driver for people to move to remoting or web services.

And web services might be very attractive (and is in many cases), it is not ideal if you want to use distributed OO concepts in the implementation of your service.

And there we are back at remoting once again as being a perfectly viable option.

Of course there’s a whole other discussion we could have about whether there’s any value to using any OO design concepts when implementing a service – but that can be a topic for another time.

I am afraid that I'm rapidly becoming more convinced than even Ted that SOA == web services == RPC with angle brackets.

The more people I talk to, the more I realize that virtually no one is actually talking about service-oriented analysis, architecture or design. They are using SOA as a synonym for web services, and they are using web services as a replacement for DCOM, RMI, remoting or whatever RPC protocol they used before.

I think the battle is lost, if battle there was. The idea of a loosely-coupled, message-based architecture where autonomous entities interact with each other over policy-based connections is a really cool idea, but it doesn’t resonate with typical development teams.

The typical development team is building line-of-business systems and just needs a high performance, reliable and feature-rich RPC protocol. Sometimes web services fits that bill, and even if it doesn’t it is the currently fad so it tends to win by default.

People are running around creating web services that do not follow a message-based design. What would a message-based design look like you ask? Like this:

result = procedure(request)

Where ‘procedure’ is the method/procedure name, ‘request’ is the idempotent message containing the request from the caller and ‘result’ is the idempotent message containing the result of the procedure.

Then if you want to be a real purist, you’d make this asynchronous, so the design would actually be:

procedure(request)

And any result message would be returned as a service call from ‘procedure’. But that really goes out of bounds for almost everyone, because then you are truly doing distributed parallel processing and that’s just plain hard to grok.

So in our pragmatic universe, we’re talking about the

result = procedure(request)

form and that’s enough. But that isn’t what most people are doing. Most people are creating services as though they were components. Creating methods/procedures that accept parameters rather than messages. Stuff like this:

customerList = GetCustomerData(firstName As String, lastName As String)

Where ‘customerList’ is a DataSet containing the results of any matches.

There’s not a message, idempotent or not, to be found here. This is components-on-the-web. This is COM-on-the-web or CORBA-on-the-web. This is not SOA, this is just RPC redux.

And that’s OK. I have no problem with that necessarily. But since this is the norm, I am pretty much ready to concede that the “Battle of SOA” is lost. SOA has already become just another acronym in the long list of RPC acronyms we’ve left behind over the decades.

Too bad really, because I found the distributed parallel, loosely coupled, message-based concepts to be extremely interesting and challenging. Hard, and impractical for normal business development, but really ranking high on the geek-cool chart.

I’ve hashed and rehashed this topic numerous times. In particular, read this and this. But the debate rages on, paralyzing otherwise perfectly normal development teams in a frenzy of analysis paralysis over something that is basically not all that critical in a good architecture.

I mean really. If you do a decent job of architecting, it really doesn’t matter a whole hell of a lot which RPC protocol you use, because you can always switch away to another one when required.

And while web services a pretty obvious choice for SOA, the reality is that if you are debating between remoting, web services and DCOM/ES/COM+ then you are looking for an RPC protocol – end of story.

If you were looking to do service-oriented stuff you’d reject remoting and DCOM/ES/COM+ out of hand because they are closed, proprietary, limited technologies that just plain don’t fit the SO mindset.

In an effort to summarize to the finest point possible, I’ll try once again to clarify my view on this topic. In particular, I am going to focus on why you might use remoting and how to use it if you decide to. Specifically I am focusing on the scenario where remoting works better than either of its competitors.

First, the scenario that remoting does that web services and ES/COM+/DCOM don’t do (without hacking them):

1.      You want to pass rich .NET types between AppDomains, Processes or Machines (we’re talking Hashtables, true business objects, etc.)

2.      You are communicating between layers of an application that are deployed in different tiers (We’re not talking services here, we’re talking layers of a single application. We’re talking client-server, n-tier, etc.)

3.      You want no-touch deployment on the client

If you meet the above criteria then remoting is the best option going today. If you only care about 1 and 2 then ES/COM+/DCOM is fine – all you lose is no-touch deployment (well, and a few hours/days in configuring DCOM, but that’s just life ).

If you don’t care about 1 then web services is fine. In this case you are willing to live within the confines of the XmlSerializer and should have no pretense of being object-oriented or anything silly like that. Welcome to the world of data-centric programming. Perfectly acceptable, but not my personal cup of tea.  To be fair, it is possible to hack web services to handle number 1, and it isn't hard. So if you feel that you must avoid remoting but need 1, then you aren't totally out of luck.

But in general, assuming you want to do 1, 2 and 3 then you should use remoting. If so, how should you use remoting?

1.      Host in IIS

2.      Use the BinaryFormatter

3.      Don’t create custom sinks or formatters, just use what Microsoft gave you

4.      Feel free to use SSL if you need a secure line

5.      Wrap your use of the RPC protocol in abstraction objects (like my DataPortal or Fowler’s Gateway pattern)

Hosting in IIS gives you a well-tested and robust process model in which your code can run. If it is good enough for www.microsoft.com and www.msn.com it sure should be good enough for you.

Using the BinaryFormatter gives you optimum performance and avoids the to-be-deprecated SoapFormatter.

By not creating custom sinks or formatters you are helping ensure that you’ll have a relatively smooth upgrade path to Indigo. Indigo, after all, wraps in the core functionality of remoting. They aren’t guaranteeing that internal stuff like custom sinks will upgrade smoothly, but they have been very clear that Indigo will support distributed OO scenarios like remoting does today. And that is what we’re talking about here.

If you need a secure link, use SSL. Sure WSE 2.0 gives you an alternative in the web service space, but there’s no guarantee it will be compatible with WSE 3.0, much less Indigo. SSL is pretty darn stable comparatively speaking, and we’ve already covered the fact that web services doesn’t do distributed OO without some hacking.

Finally, regardless of whether you use remoting, web services or ES/COM+/DCOM make sure – absolutely sure – that you wrap your RPC code in an abstraction layer. This is simple good architecture. Defensive design against a fluid area of technology.

I can’t stress this enough. If your business or UI code is calling web services, remoting or DCOM directly you are vulnerable and I would consider your design to be flawed.

This is why this whole debate is relatively silly. If you are looking for an n-tier RPC solution, just pick one. Wrap it in an abstraction layer and be happy. Then when Indigo comes out you can easily switch. Then when Indigo++ comes out you can easily upgrade. Then when Indigo++# comes out you are still happy.

I just upgraded this blog to the newest version of dasBlog. I upgraded my personal blog a few days ago and it has been trouble-free, so I thought it safe to upgrade this one. The only serious change you may see is when posting comments, as this new version requires that you type in a code from a graphic to help defeat posting bots. Kind of a pain, but worth it I suppose.

Of course I'm doing this just before leaving town for two weeks - first to Chicago and then to San Francisco for VS Live. Always a good time to upgrade

The Chicago trip is primarily focused around working with a Magenic client, but I'll be having some evening dinner meetings with various groups as well, including my first real foray into this fun new trend: a Nerd Dinner.

Sahil has some interesting thoughts on the web service/DataSet question as well.

He spends some time discussing whether “business objects” should be sent via a web service. His definition of “business object” doesn’t match mine, and is closer to Fowler’s data transfer object (DTO) I think.

It is important to remember that web services only move boring data. No semantic meaning is included. At best (assuming avoidance of xsd:any) you get some limited syntactic meaning along with the data.

When we talk about moving anything via a web service, we’re really just talking about data.

When talking about moving a “business object”, most people think of something that can be serialized by web services – meaning by the XmlSerializer. Due to the limitations of the XmlSerializer this means that the objects will have all their fields exposed as public fields or read-write properties.

What this means in short, is that the “business objects” can not follow good OO design principles. Basically, they are not “business objects”, but rather they are a way of defining the message schema for the web service. They are, at best, data transfer objects.

In my business objects books and framework I talk about moving actual business objects across the wire using remoting. Of course the reality here is that only the data moves – but the code must exist on both ends. The effective result is that the object is cloned across the network, and retains both its data and the semantic meaning (the business logic in the object).

You can do this with web services too, but not in a “web service friendly” way. Cloning an object implies that you get all the data in the object. And to do this while still allowing for encapsulation means that the serialization must get private, friend/internal and protected fields as well as public ones. This is accomplished via the BinaryFormatter. The BinaryFormatter generates and consumes streams, which can be thought of as byte arrays. Thus, you end up creating a web service that moves byte arrays around. Totally practical, but the data is not human-readable XML – it is Base64 encoded binary data. I discuss how to do this in CSLA .NET on my web site.

Now we are talking about moving business objects. Real live, OO designed business objects.

Of course this approach is purely for n-tier scenarios. It is totally antithetical to any service-oriented model!

For an SO model you need to have clearly defined schemas for your web service messages, and those should be independent from your internal implementation (business objects, DataSets or whatever). I discuss this in Chapter 10 of my business objects books.

OK, so Shawn has some good points about the use of a DataSet for the purpose of establishing a formal contract for your web service messages. This is in response to my previous entry about not using DataSets across web services.

The really big distinction between using web services for SO vs n-tier remains.

If you are doing SO, you need to clearly define your message schema, and that schema must be independent from your internal data structures or representations. This independence is critical for encapsulation and is a core part of the SO philosophy. Your service interface must be independent from your service implementation.

What technology you use to define your schema is really up to you. Shawn’s entry points out that you can use strongly typed DataSet objects to generate the schema – something I suppose I knew subconsciously but didn’t really connect until he brought it up. Thank you Shawn!

Any tool that generates an XSD will work to define your schema, and from there you can define proxy classes (or apparently use DataSet objects as proxies). Alternately you can create your “schema” in VB or C# code and get the XSD from the code using the wsdl.exe tool from the .NET SDK (though you have less control over the XSD this way).

But my core point remains, that this is all about defining your interface, and should not be confused with defining your implementation. Using a DataSet for a proxy is (according to Shawn) a great thing, and I’ll roll with that.

But to use that same DataSet all the way down into your business and data code is dangerous and fragile. That directly breaks encapsulation and makes you subject to horrific versioning issues.

And versioning is the big bugaboo hiding in web services. Web services have no decent versioning story. At the service API level the story is the same as it was for COM and DCOM – which was really bad and I believe ultimately helped drive the success of Java and .NET.

At the schema level the versioning story is better. It is possible to have your service accept different variations on your XML schema, and you can adapt to the various versions. But this implies that your service (or a pre-filter/adapter) isn’t tightly coupled to some specific implementation. I fear that DataSets offer a poor answer in this case.

And in any case, if you to create maintainable code you must be able to alter your internal implementation and data representation independently from your external contract. The XSD that all your clients rely on can’t change easily, and you must be able to change your internal structures more rapidly to accommodate changing requirements over time.

Again, I’m talking about SO here. If you are using web services for n-tier then the rules are all different.

In the n-tier world, your tiers are tightly coupled to start with. They are merely physical deployments of layers, and layers trust each other implicitly because they are just a logical organization of the code inside your single application. While there are still some real-world versioning issues involved, the fact is that they aren’t remotely comparable to the issues faced in the SO world.

Every now and then the question comes up about whether to pass DataSet or DataTable objects through a web service.

I agree with Ted Neward that the short answer is NO!!

However, nothing is ever black and white…

For the remainder of this discussion remember that a DataSet is just a collection of DataTable objects. There’s no real difference between a DataTable and DataSet in the context of this discussion, so I’m just going to use the term DataSet to mean 1..n DataTables.

There are two “types” of DataSet – default and strongly typed.

Default DataSet objects can be converted to relatively generic XML. They don’t do this by default of course. So you must choose to either pass a DataSet in a form that is pretty much only useful to .NET code, or to force it into more generic XML that is useful by anyone.

To make this decision you need to ask yourself why you are using web services to start with. They are designed, after all, for the purpose of interop/integration. If you are using them for that intended purpose then you want the generic XML solution.

On the other hand, if you are misusing web services for something other than interop/integration then you are already on thin ice and can do any darn thing you want. Seriously, you are on your own anyway, so go for broke.

Strongly typed DataSet objects are a different animal. To use them, both ends of the connection need the .NET assembly that contains the strongly typed code for the object. Obviously interop/integration isn’t your goal here, so you are implicitly misusing web services for something else already, so again you are on your own and might as well go for broke.

Personally my recommendation is to avoid passing DataSet objects of any sort via web services. Create explicit schema for your web service messages, then generate proxy classes in VB or C# or whatever language based on that schema. Then use the proxy objects in your web service code.

Your web service (asmx) code should be considered the same as any other UI code. It should translate between the “user” presentation (XML based on your schema/proxy classes) and your internal implementation (DataSet, business objects or whatever).

I discuss this in Chapter 10 of my Business Objects books, but the concepts apply directly to data-centric programming just as they do to OO programming.

When I first got involved with Microsoft it was around 1990 or ’91. The world of the time was dominated by IBM, with DEC a close second. If you wanted to network PCs you used Novell or Banyan. All PC programs were DOS programs. “Windows” was just one of many graphical libraries being used by software to handle drawing on the screen. And if you wanted to do real work you used a mainframe or minicomputer.

At the time, Microsoft was an underdog.

Personally I wouldn’t have anything to do with them. Novell was the obvious PC networking choice, and PCs in general were so incredibly limited compared to my beautiful VAX computers that I couldn’t understand why anyone would bother to use them. If you were going to use a PC-like computer, the Amiga was the way to go. It was far closer to a real computer than the PC!

Of course the open source community of the time hated the VAX, Novell and anything commercial. At the time the open source world was tied into Unix, even though it wasn’t open source either. But they hated us VAX people who could use the “search” command to search rather than using “grep”. (if you don’t believe me, use google or the wayback machine to look at the newsgroup flame wars of the time)

In any case, the manufacturing company I worked for kept bringing in more and more PCs to do more and more things. And we needed a way to make the PC software accessible to our end users. On the VAX I had a very nice bit of menu software that did personalization, authorization and so forth. We investigated the lame-ass equivalents that existed for DOS, but the PC world had no concept of centralized management and so we adopted none of them.

Finally, out of a busy field of competitors, Microsoft’s Windows product showed up. It was pretty lame too, but at least we were able to use it as a meaningful launch platform for software. This allowed our end users to actually find and use the software we had installed on our Novell server. It also forced us to hire another helpdesk/PC support person… Windows was not cheap, but it was obvious that the world was moving that direction and so we did too.

I should point out that none of the Windows competitors were cheap either. All of them used the highly cantankerous PC as a platform and anything we chose would have required that we hire at least one more PC support person… Compared to our VAXen (with their 99.995% uptime) the PC was just plain terrible. This was true of Windows, our Novell server – all of it.

Personally, I tried to keep at arm’s length from the whole debacle. My boss however, felt that my career would be enhanced if I got involved, so I ended up as the Novell administrator. That included making Windows work with Novell, and eventually with that VAX (because we installed software on the VAX to make it look like a Novell server to the PCs).

The only part of this that was fun was the VAX-as-Novell-server bit. Using that technology we were able to use gawk (open source awk, a text processing tool) to transform our massive manufacturing reports into tab-delimited “spreadsheet” files that could be used in Lotus 123, Quattro Pro or that lame excuse for a spreadsheet, Excel.

Even with Windows, Microsoft was still the underdog. Heck, this was the time that OS2 was supposed to take over the world. Unfortunately IBM forgot that people (end users) don’t give a rip about operating systems. They only care about the programs they use. OS2 didn’t have any software (compared to DOS, and thus Windows – which was still just a graphical shell on DOS). This was the problem with the Amiga too. A superior piece of work in almost every way, but there was no software for it. Not on the level of the stuff for DOS (Windows) or the Mac.

Then in the early 1990’s Microsoft came out with Windows NT. The core of NT is the same as that of OpenVMS (the VAX operating system). That was enough for me to start looking seriously at the PC. I even bought one so I could be part of the Windows NT beta program. It sat next to my Amiga and limped along as best it could.

It is worth noting that the VAX operating system was originally named VMS. DEC changed the name to OpenVMS in response to the open source/unix community’s unceasing assaults and criticisms. Today’s attacks on Microsoft are just the latest version of a decades-old pattern of abusive behavior on the part of the open source community. Before DEC it was IBM and before that there were no computers to speak of.

I know that the open source “community” can’t be represented by any one person or one group any more than Christians can be represented by Evangelicals or Catholics. But after listening to the same tired rants from what must be clones of the same people for 20 years it does seem like there’s a cohesive voice of the open source community… At the very least there’s a consistent dogma.

I started to find out about Windows programming at this time. I had never programmed for Windows itself (or DOS), but I figured that since NT was, at its core, like OpenVMS. I assumed that I could program it in comparable fashion. Not so. The most trivial program took pages of code. There was more code involved to interact with the OS than to do actual business work. So we just kept working on the VAX where we could get real work done.

Then came Visual Basic 1.0. It had a whole host of competitors, and wasn’t necessarily the best of the bunch. But it provided the most direct access to Windows programming of all the options. It allowed us to write Windows programs where most of our code was actual business code. Where we didn’t need pages of code just to draw a window or other silliness.

With the advent of Windows NT 4 Microsoft finally also provided an option to Novell. It was realistic to use NT 4 as a production server, and so we switched from Novell to NT somewhere in there. That was a powerful change, because now our server was programmable.

Yes, I know it was technically possible to program a Novell server. But you have to be kidding. That was really unlike a productive programming experience – especially for someone coming from a VAX! You need to understand that I have never had to deal with all the  memory segmentation issues. The VAX, the Amiga and Windows NT all provide a flat memory model. To this day I fail to understand why anyone voluntarily chose to program on a PC in DOS or Windows…

Around this time it was clear that DEC was dying, and Microsoft was no longer an underdog. Windows NT and Visual Basic propelled Microsoft into a space where they were accepted as a primary option. For small and mid-size business they were often the primary option in fact.

It also helped that through the early 1990’s the “spreadsheet wars” between Lotus, Quattro Pro and Excel eventually settled out. As we all know, the victor was Excel. But that was not a foregone conclusion. During that whole time, Microsoft was the underdog. Quattro Pro was easiest to use and Lotus was the most powerful (and had the backing of existing users). But Lotus never got easy to use, and Quattro never got powerful. Excel got easier to use and more powerful until it was easy enough and powerful enough to displace the other two.

There are lessons to be learned here. Lotus could have made themselves easier to use and they would have won hands down. Quattro had the harder job, but they could have made themselves more powerful and maybe could have won. But the odd man out, the underdog Microsoft was the one who managed to strike the balance that won the war.

I imagine there are similar stories around Word and WordPerfect, but I never witnessed that conflict.

By the mid-1990’s the dust had settled and Microsoft was a major player in corporate and home computing, and I left the manufacturing company for consulting. Why? So I could focus all my energies on programming PCs and not be distracted by the dying VAX.

Quite a turnaround for someone who wouldn’t touch a PC with a 10 foot pole

A while ago TheServerSide.net published an article with Jeff Richter’s thoughts on the future of .NET assembly versioning.

If you read the article you’ll find that the Longhorn OS will seriously change the way that .NET itself is versioned. In fact, it turns out that to a serious degree the whole idea of installing “side-by-side” versions of .NET itself will go away when Longhorn shows up.

Oh sure, they have plans for a complex scheme by which assemblies can be categorized into different dependency levels. Some levels can be versioned more easily, while others can only be versioned with the OS itself.

What this really means is that .NET is losing its independence from the OS. In the end, we’ll only get new versions of .NET when we get new versions of the OS – and we all know how often that happens…

I’d say that this was inevitable, but frankly it was not. Java hasn’t fallen into this trap, and .NET doesn’t need to either. Not that it will be easy to avoid, but the end result of the current train of thought portrayed by Richter is devastating.

Fortunately there’s the mono project. As .NET becomes more brittle and stagnant due to its binding with Longhorn, we might find that mono on Windows becomes a very compelling story. mono will be able to innovate, change and adapt much faster than the .NET that inspired it. Better still, mono will remain unbound from the underlying OS (like .NET was originally) and thus will be able to run side-by-side in cases where .NET becomes crippled.

Hopefully Microsoft will realize what they are doing to themselves before all this comes to pass. Otherwise, I foresee a bright future for mono on Windows.

On the PeerCast website there is an FAQ in which they recommend turning off the Windows XP Firewall:

I got everything right with my broadcast, but no matter what I do, my stream can't get through. Should I get lost?
You are probably behind a firewall, if it is a personal firewall installed on your local PC, try turning it off. (Windows XP Pro for example..)

No wonder open-source is “more secure”, when they are actively running around telling people to disable the primary safety mechanism provided on Windows.

(to be fair, their blanket statement would apply to Linux firewalls too, but their example is Windows, which leads one to believe they prefer having lots of unprotected Windows machines on the Internet or something...)

Sabotage or just stupid advice?

If open-source people are as smart as they claim, they should be telling people to open only those ports required for the software, not to turn off all defenses and let anything through!!

Google has released a 20 year timeline of usenet newsgroup history, highlighting notable events along the way.

I find it very interesting to see the history of the “world's largest BBS“.

Personally I got involved in usenet in 1989 or 1990. I was working for a bio-medical manufacturing company, and managed to convince a local defense contractor to allow us to tap a usenet feed off them. The feed came through our 1200 baud modem, with us dialing into their system to transfer the data. Later they also allowed us to route email through their system over our much faster 2400 baud modems. Ahh, those were the days!

Why'd they do this you ask? Because we were both DEC VAX shops, and there was a hacker-metality brotherhood amongst VAX admins. (that's hacker in the good sense, not the dark sense) I don't think much of that mentality still exists in our industry, and that is a sad loss. I suppose it is the price of “progress“.

Prior to getting the usenet feed, I was a Citadel user. That was a Commodore 64 BBS that worked in a manner similar to usenet. It might have run on the Amiga too, but I don't recall for certain. Anyway, Citadel was a store-and-forward relay system like usenet (at the time), and so I was able to interact with people from all across North America via a local phone call. Someone in the area obviously made long-distance calls as a gateway, and my thanks go to that unknown benefactor!

To bring it back to the usenet timeline though, I think this timeline is interesting by itself. But it also should help us remember that the Web is just one thread in the much richer tapestry that is the Internet proper.

1. Less choice leads to better results.
2. Higher level languages and frameworks restrict choice.
3. Thus, higher level languages and frameworks should lead to better results.

The “less choice” statement flows from this article entitled Choice Cuts. Ignore the politics and focus on the research beneath the statement. That’s what is valuable in this context.

It is obvious that higher level languages and frameworks restrict choice, so I’m not going to cite a bunch of references for that. While many of these languages and frameworks provide a way to drop out to a lower level, in and of themselves they restrict choice. Just look at Visual Basic versions 1-6. Very productive, but often restrictive.

Whether the conclusion that higher level languages and frameworks will lead to better results is true or not is unknown.

Certainly there are examples where better results have been gained. This train of thought is lurking somewhere behind the software factories movement, and does seem quite compelling. Certainly many people using CSLA .NET with code generators have found radically increased productivity – and the combination of the two does restrict choice.

Yet there are countless examples (especially from the era of CASE tools) where the results were totally counter-productive. Where restriction of choice forced intricate workarounds that decreased productivity and made things worse.

Charles Simonyi contributed to an article on The Edge, essentially noting that there still is a software crisis and that low-level languages aren’t solving the problem. He argues in fact, that low-level languages like C#, VB and Java are a dead-end. That we must move to higher-level language concepts in order to adequately represent the real world through software.

This is the view of the software factories people and the domain-specific language movement. And it is rather hard to argue the point. There are many days when I feel like I’m writing the same code I wrote 15 years ago – except now its in a GUI instead of on a VT100 terminal. But the business code just hasn’t changed all that terribly much…

To look at it a different way, a software architect’s job is to restrict choice. Our job in this role is to look at the wide array of choices and narrow them down to a specific set that our organization can use. Why? Because having each developer or project lead do all that filtering would seriously cut into productivity.

Companies employ architects specifically to limit choice. To set standards and policies that narrow the technology focus to a limited set of options. The rest of the organization then lives within those artificial boundaries. There are many reasons for this, including licensing costs, training and so forth. I doubt that many people have considered the direct (presumably positive) impact of the reduction of choice however.

I’ve been working on an idea I’ve dubbed an Entity Description Language (EDL). My original motivation was to reduce the amount of plumbing code we write. Look at a typical Java, C# or VB class and you’ll find that less than 4% of the actual lines in the class perform tangible business functions. Most of the lines are just language syntax or pure plumbing activities like opening a database connection.

In working on EDL though, I’ve discovered that it is virtually impossible – and perhaps undesirable – to replicate the capabilities of C# or VB in their entirety. There are reasons why these languages use such a verbose syntax. They require verbosity in order to provide flexibility, or choice. Virtually unlimited choice.

If we now consider that limited choice is better, then perhaps the fact that something like EDL restricts choice is only good…