Sunday, February 22, 2004

The only reason I started this blog was so I'd have a forum for editorializing. I already have my web site (www.lhotka.net) for formal information about my books, speaking, CSLA .NET">CSLA .NET framework and so forth. But I didn't have a good place for editorial thoughts (otherwise known as ranting). Thus the blog, and thus this post.

For those who don't know, I'm in the process of writing a C# edition of my Expert One-on-One VB.NET Business Objects book. The C# edition is due out in May 2004. The planned title is Expert One-on-One C# Business Objects.

Before I agreed to write this C# edition, I gave a lot of thought to the project. While there's no doubt that both VB.NET and C# are first-class languages in .NET, the fact is that I've been a strong voice for VB over the past many years. What would people think if I went over to the 'dark side' and actually used C#?

I was worried that the VB community would consider that I'd turned my back on them and/or their chosen language. Heck, I was even a bit worried that I'd fall in love with C# - in which case I might actually abandon VB. I was also worried that the C# community wouldn't accept the book or the CSLA .NET framework because of my long-term association with VB (which presumably makes me and my work contemptible to some strange fringe of the C-style language community).

The process of writing the C# edition of the book starts with the code. I really can't go far in the prose until the code has been ported to C#, tested and so forth. So at this point I've spent a fair amount of time doing C#. Additionally, publicity about the C# edition of the book has started, so some people in both the VB and C# communities know it is coming. Due to this, I have some answers to my questions.

First off, I have not fallen in love with C#. It is an OK language, and I understand why people like it. It is the first C-style language that is nearly as easy to use and understand as VB. Using C# merely confirms my original belief that the .NET platform represents the victory of the VB mindset. In many ways, C# really is just VB with semi-colons.

By way of disclaimer, I've never been a C-style language person. I started with Basic, went to Pascal, wrote a VT100 terminal emulator in C++, did some FORTRAN, some Modula-2, then VAX Basic and finally VB (starting with version 1 on up to VB.NET).

That brief bit of C++ was more than enough to convince me that the C-style world view of the time (this was in 1988 or so) was simply wrong. Managing your own resources is silly, unless you are interacting directly with hardware. C/C++ is simply the wrong tool for business software development.

For the entire life of VB, it has existed in a managed environment, where memory and other resources were taken care of on our behalf. It has also existed in an environment where programmers didn't usually have to worry about the underlying OS, because there was a nice library of components to do the heavy lifting on our behalf.

This is exactly the way .NET works. All that has happened, is that the wonderful world of VB has been extended to the rest of the programming languages out there, so even C-style programmers don't have to deal with all that resource management crap. In many ways, the C-style world has finally been brought into the fold.

So, while I've found my experience with C# to be rewarding, from the perspective of learning a new language, my heart still belongs to VB. At the same time, I do see the attraction of C# for people who've spent their lives using C-style languages. It is a hard thing to switch paradigms, and I fully understand why most C-style developers wouldn't want to stretch themselves to learn a whole new linguistic style. It is the same reason most non-C developers don't want to learn C-style languages, but in reverse.

I'll certainly continue to use C# as well as VB. I anticipate writing a Whidbey edition of the Business Objects books - VB first, followed by C#. I also plan to see if I can get CSLA .NET running on mono at some point. Since the VB compiler is far behind the C# compiler in mono, obviously C# will be the choice for that little side project.

My other primary concern revolves around the publicity of the C# edition and what that would mean. Thus far I've only heard from the VB community. Some people have expressed concern, while most people have expressed strong support. This blog entry is intended partially to address the concerns I've heard from the VB community about me possibly giving up VB for C#... But I'm not going to abandon VB just when it is going to get really cool again (in Whidbey we get edit-and-continue, and the My namespace - very cool stuff!!).

I've also heard from a number of C# developers, and everyone has been supportive. I haven't heard anything from the hard-core fringe groups yet, but I imagine I will once the book is out. That should be entertaining!

But, to reinforce and/or clarify my stance:

  1. .NET really is language neutral. I can't see a serious advantage one would gain by using either VB or C# in a CSLA .NET app. It just doesn't matter from a functional perspective.
     
  2. I, personally, am not language neutral. I prefer VB. I think it is more readable and intuitive, and thus provides better self-documentation and long-term maintenance. It is also more accessible to new developers - imo.
     
  3. I fully understand that other people are likewise not language neutral. Some prefer C#. That's cool - see point #1 above.

The whole point behind writing the C# edition of the book is to provide people who choose (or are forced) to use C# the same level of access to the material as the VB community. Because there's a lot of both VB and C# developers out there, it only makes sense to have editions of the book in both languages. If some third language were to rise to equal dominance (in terms of market share), I'd probably write an edition in that language as well.

In the end, the book is not about language. It is about distributed architecture and how object-oriented concepts can fit into that distributed world. It is about using the really cool features of the .NET framework like serialization and remoting to do things that used to be really hard in a much easier way.

Ultimately it is about having fun architecting, designing and developing .NET applications. Certainly that's what drives me, and I hope it is what drives anyone who reads and uses the book and the CSLA .NET framework.

Code well, have fun!

Sunday, February 22, 2004 2:53:56 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Wednesday, February 11, 2004

Applications or Components?

 

When you create a system with web services, are your web services components or are they standalone applications?

 

While this might seem like a semantic question, it is actually a very big deal, with a lot of implications in terms of your overall application design, as well as the design of the web services themselves.

 

I specifically argue that web services are the ‘user interface’ to a standalone application. Any other view of web services is flawed and will ultimately lead to a seriously flawed application environment.

 

Another, simpler, way to put this is that “a web service is an application, not a tier in an application”.

 

Perhaps the key reason this is such an important thing to realize is that almost anyone can use a web service. It isn’t like we get to pick which other apps will call our web service. Web services are discoverable, and someone, somewhere in our organization (or outside) will discover our web service and will start using it.

 

If we designed the web service as a tier in our application, we would design it to trust our higher level tiers. If the higher level tier did a bunch of calculations or validations, it would be silly to replicate that functionality in a lower level tier.

 

On the other hand, if the web service is a standalone application that merely has an XML interface (as compared to a GUI or HTML interface), it must implement its own calculations and validations. It would be silly for an application not to implement this type of functionality.

 

So let’s get back to the component vs application thing.

 

Components are generally viewed as entities that live within applications. A component provides some functionality that our application can use. But components often have a high degree of trust in the application, and the application certainly has a high degree of trust in the component.

 

Think of Windows Forms controls, ActiveX controls, encryption libraries, data access (like ADO.NET) and so forth. These are all examples of components, and it is pretty clear that there’s a high level of trust between them and their hosting applications.

 

Viewing a web service as a component implies that it is part of an application, rather than actually being an application. This implies a higher level of trust than can be granted to something that is essentially a public API that can be invoked by any application in our organization (or beyond).

 

Applications, on the other hand, don’t trust each other. They trade data, they send messages, but they don’t trust. We’ve probably all be burned (multiple times) by having too much trust between applications, and we know that it is a bad thing.

 

By viewing a web service as an application, we can apply full application design principles to its creation. It has a presentation tier (the XML web service itself), a business tier (hopefully a set of business objects, or at least a business DLL), and a data tier (whatever that might be). It is self-contained, doing its own calculation, validation, authentication and so forth.

 

Other applications can use our web service as a data source, or however they choose. But our web service will be internally consistent and self-protecting.

 

This ultimately means that the web service will be reliable, useful across multiple applications and in the end will be a good investment in terms of development dollars.

Wednesday, February 11, 2004 4:00:44 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Thursday, February 05, 2004

After all the cool WinFX demos at the PDC there's been a lot of speculation about what WinFX and XAML (the XML dialect used to describe forms for WinFX) mean to all of us. One thing I've heard time and time again is that XAML represents a common programming model for Windows and the web.

You can take this concept two ways.

One is to say that there'll be a common model because both web developers and Windows developers will have a cryptic tag language to describe their displays, and will write code behind those tags to drive the UI. And this interpretation appears to be quite accurate - but its not very sexy.

The other is to say that XAML will allow us to write a single client application that can run in either the browser or on a smart client. Somehow the XAML would become HTML for a browser, and would become highly animated Dirext3D code for Windows. I don't buy this view at all, and here's why:

Bridging the gap in capabilities between the terminal-based browser world and the smart client world is a non-trivial exercise.
 
I've been thinking for a long time (years) about what must occur for this to be transparent across Windows and Web clients.
 
On a Windows client all the code behind the form will run right there on the client. Not just the animation stuff, but our UI intelligence and very likely our business logic. In fact, running our business logic (in whole or part) on the client is the whole point of having a smart client, so this point is pretty key. So our UI logic can interact with the full WinFX API. It can also interact with our business objects (or data objects) in a very rich way, since everything is running in a single memory space on the client.
 
At the same time, we want this to degrade all the way back to a terminal-based browser. In this scheme nothing can run on the client. The client is merely a display vehicle - a colorful 3270 terminal. After all, HTML isn't evolving, so web pages and browser rendering in 2007 will be essentially the same as today (which means the web, or at least HTML, is as good as dead, but that's another topic :-) ).
 
So where does all our UI code and/or business logic run in the degraded model? It must, by definition, run on the web server. But our code is written to this super-rich WinFX object model, while the user is seeing a dumbed-down terminal representation. In order to fake out our code, the web server will have to give the illusion to our code that it is running within a full-blown client. That way our code can interact with the same objects in the degraded world as it does in the real world.
 
A web server engine that can translate between a simulated WinFX client (for our UI code) to and from HTML (for the user's terminal) would be really something to see. I very much doubt that something this ambitious is in the works for Longhorn, but it is the only way to provide high-end functionality on Windows with the same code base that could also drive the terminal-based browser experience.
 
If they went this route, they'd probably need to create at least a couple simulators - one for HTML 3.2 and one for IE 6+ capabilities. Maybe more.
 
Following this to the extreme, someone could also create a Flash simulator that translated the WinFX reality into something that could be rendered in shockwave. Of course none of our UI code itself could run in shockwave, because our code would still be in .NET assemblies, so the Flash stuff would be pretty lame compared to real Flash work or compare to our actual WinFX UI... Still, it could probably do a limited subset of the WinFX animations, just without any client-side validation or user interaction code.
 
So while a XMAL->HTML converter could probably be created, that doesn't really solve anything. The real problem is how to make our UI code continue to run when (presumably) the client isn't even running WinFX, or maybe isn't even on the same machine where our UI code is running.

Thursday, February 05, 2004 2:20:56 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Wednesday, February 04, 2004

 Dev Days in Minneapolis.
 VS Live in San Francisco
 VS Connections in Orlando
 VS Live in Toronto

... and more to come. Please go to my presentations page for a full list of topics and locations.

 

Wednesday, February 04, 2004 2:33:09 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 

I've been rather skeptical of the whole blogging thing. However, the technology has been evolving, and blogs are becoming more and more integrated into the fabric of the web and the way we all communicate via the web. Due to this, I've finally decided to create a blog.

I don't anticipate that this will replace my primary Rockford Lhotka web site, which is where I provide continuing information and updates about my books and articles. Instead, I anticipate that I'll use this blog as a way to communicate more general thoughts and ideas over time.

Hopefully as time goes on this will evolve into a useful and interesting site.

Thanks for visiting.

Rocky

 

Wednesday, February 04, 2004 11:35:01 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  |