Indigo is Microsoft’s code name for the technology that will bring together the functionality in today’s .NET Remoting, Enterprise Services, Web services (including WSE) and MSMQ. Of course knowing what it is doesn’t necessarily tell us whether it is cool, compelling and exciting … or rather boring.

Ultimately beauty is in the eye of the beholder. Certainly the Indigo team feels a great deal of pride in their work and they paint this as a very big and compelling technology.

Many technology experts I’ve talked to outside of Microsoft are less convinced that it is worth getting all excited.

Personally, I must confess that I find Indigo to be a bit frustrating. While it should provide some absolutely critical benefits, in my view it is merely laying the groundwork for the potential of something actually exciting to follow a few years later.

Why do I say this?

Well, consider what Indigo is again. It is a technology that brings together a set of existing technologies. It provides a unified API model on top of a bunch of concepts and tools we already have. To put it another way, it lets us do what we can already do, but in a slightly more standardized manner.

If you are a WSE user, Indigo will save you tons of code. But that’s because WSE is experimental stuff and isn’t refined to the degree Remoting, Enterprise Services or Web services are. If you are using any of those technologies, Indigo won’t save you much (if any) code – it will just subtly alter the way you do the things you already do.

Looking at it this way, it doesn’t sound all that compelling really does it?

But consider this. Today’s technologies are a mess. We have at least five different technologies for distributed communication (Remoting, ES, Web services, MSMQ and WSE). Each technology shines in different ways, so each is appropriate in different scenarios. This means that to be a competent .NET architect/designer you must know all five reasonably well. You need to know the strengths and weaknesses of each, and you must know how easy or hard they are to use and to potentially extend.

Worse, you can’t expect to easily switch between them. Several of these options are mutually exclusive.

But the final straw (in my mind) is this: the technology you pick locks you into a single architectural world-view. If you pick Web services or WSE you are accepting the SOA world view. Sure you can hack around that to do n-tier or client/server, but it is ugly and dangerous. Similarly, if you pick Enterprise Services you get a nice set of client/server functionality, but you lose a lot of flexibility. And so forth.

Since the architectural decisions are so directly and irrevocably tied to the technology, we can’t actually discuss architecture. We are limited to discussing our systems in terms of the technology itself, rather than the architectural concepts and goals we’re trying to achieve. And that is very sad.

By merging these technologies into a single API, Indigo may allow us to elevate the level of dialog. Rather than having inane debates between Web services and Remoting, we can have intelligent discussions about the pros and cons of n-tier vs SOA. We can apply rational thought as to how each distributed architecture concept applies to the various parts of our application.

We might even find that some parts of our application are n-tier, while others require SOA concepts. Due to the unified API, Indigo should allow us to actually do both where appropriate. Without irrational debates over protocol, since Indigo natively supports concepts for both n-tier and SOA.

Now this is compelling!

As compelling as it is to think that we can start having more intelligent and productive architectural discussions, that isn’t the whole of it. I am hopeful that Indigo represents the groundwork for greater things.

There are a lot of very hard problems to solve in distributed computing. Unfortunately our underlying communications protocols never seem to stay in place long enough for anyone to really address the more interesting problems. Instead, for many years now we’ve just watched as vendors reinvent the concept of remote procedure calls over and over again: RPC, IIOP, DCOM, RMI, Remoting, Web services, Indigo.

That is frustrating. It is frustrating because we never really move beyond RPC. While there’s no doubt that Indigo is much easier to use and more clear than any previous RPC scheme, it is also quite true that Indigo merely lets us do what we could already do.

What I’m hoping (perhaps foolishly) is that Indigo will be the end. That we’ll finally have an RPC technology that is stable and flexible enough that it won’t need to be replaced so rapidly. And being stable and flexible, it will allow the pursuit of solutions to the harder problems.

What are those problems? They are many, and they include semantic meaning of messages and data. They include distributed synchronization primitives and concepts. They include standardization and simplification of background processing – making it as easy and natural as synchronous processing is today. They include identity and security issues, management of long-running processes, simplification of compensating transactions and many other issues.

Maybe Indigo represents the platform on which solutions to these and other problems can finally be built. Perhaps in another 5 years we can look back and say that Indigo was the turning point that finally allowed us to really make distributed computing a first-class concept.

I just spent three days getting inundated with the details of Indigo as it stands today (in its pre-beta state). For those that don’t know, Indigo is the combined next generation of .NET Remoting, Enterprise Services, Web services (asmx and WSE) and MSMQ all rolled into one big ball.

I also had some conversations about Avalon, though not nearly in so much detail. For those that don’t know, Avalon is the next generation display technology that uses full 3D rendering and should allow us to (finally) escape the clutches of GDI. Avalon is the display technology related to XAML. XAML is an XML markup language to describe Avalon interfaces.

My interest in these technologies spans quite a range of concerns, but top on my list is how they might impact my Business Objects books and the related CSLA .NET framework.

It turns out that the news is pretty good. Seriously good actually. In fact, it looks like people using CSLA .NET today are going to be very happy over the next few years.

Within the context of CSLA .NET, Indigo is essentially a drop-in replacement for Remoting. I will have to change the DataPortal to use Indigo, but that change should have no impact on an application’s UI, business logic or data access code. In other words (cross your fingers), a business application based on CSLA .NET should move to Indigo with essentially no code changes.

[Disclaimer: Indigo isn’t even in beta, so anything and everything could change. My statements here are based on what I’ve seen and heard, and thus may change over time as well.]

One of my primary goals for CSLA .NET 2.0 is to alter the DataPortal to make it easier to adapt it to various transports. In the short term this means Remoting, asmx, WSE and Enterprise Services (DCOM). But it also means I’ll be able to add Indigo support with relative ease once Indigo actually exists.

Avalon is a different story. Avalon is a new UI technology, which means that moving to Avalon means tossing out your existing UI and building a new one. But if you are using Windows Forms today, with CSLA .NET business objects for your logic and databinding to connect the two together your life will be better than most. It appears that Avalon will also support databinding against objects just like (hopefully better than) Windows Forms.

Since a well-written CSLA-based Windows Forms application doesn’t have any business logic (not even validation) in the UI itself, switching to Avalon should merely be a rip-and-replace of the UI, with little to no impact on the underlying business or data access layers. I keep telling people that the “UI is expendable”, and here’s the proof

I just thought I’d share these observations. Indigo and Avalon (together under the label of WinFX) won’t show up for quite a long time, so none of this is of immediate interest. Still it is nice to know that when it does show up sometime in the future that CSLA .NET will have helped people to move their applications more easily to the new technologies.

Cross-pollination is one of the benefits of regular interaction with fellow speakers and authors. For instance, Juval Lowy was just showing me this cool and rather obscure feature where you can just make method calls “disappear”. Now I am not convinced that this is a good thing, as the effect is not at all explicit or obvious – but it is cool nonetheless.

The idea is that you can write a method:

Public Sub Foo()

End Sub

Then you can call this method elsewhere in your code. Perhaps even many places in your code:

Public Sub Client()

  Foo()

End Sub

So far so good. But now apply this attribute to the Foo method:

<Conditional("MyFlag")> _

Public Sub Foo()

End Sub

When you now compile your project, Foo is compiled, but the call to Foo in the Client method is not included in the result. Yes, that’s right – all calls to Foo everywhere in your code disappear without a trace. They aren’t in the CIL, and thus are just poof, gone.

To get those calls to Foo back, you need to define a compiler symbol:

#Const MyFlag = True

Now mystically, the calls to Foo will reappear in the compiled code.

This is a form of conditional compilation, similar to checking for a debug condition or something. But it is not explicit, and the caller will have no idea that they aren’t calling the method any more. Nor will the developer, since there’s no way for the caller to even know that the method is marked for disappearance.

Seems like a feature that should remain obscure, but from a purely geeky perspective it is pretty interesting.

I am a proud signatory of the petition to save IDL. Some may consider such petitions to be foolhardy, even absurd, but I think it is important to put forth some effort to save endangered technologies such as IDL. To see something this important, this transformative and this intuitive simply fade away into obscurity would be a terrible fate.

Wait! What the hell am I saying? I hate IDL! Hey, how do I unsign that damn petition anyhow? Damn! Now like numerous VB6 developers, I have signer’s remorse… Woe to me!

I was recently asked what I thought about proprietary vs “open” programming languages.

First off, I am not convinced that there is such a thing as an “open” language. Perhaps C and C++ (through the existence of things like GCC). But really the question is whether a language is standards based or not. “Open” is far less important in this regard than being based on a published standard.

The only mainstream languages today that are standards based are C++ and C#. Both VB and Java are proprietary, though of the two Java is arguably more "open".

My concern has never been about whether a language was proprietary or not, but rather whether it was well-supported by both vendors and a community. It is longevity that is important, not openness. Companies build software using languages, and they want to have some confidence that the language will exist longer than their software.

No successful language (proprietary or not) changes frequently/radically and lives long. Similarly, no language that fails to evolve over time lives long. These things are not a function of openness, but rather are a function of support from vendors and community.

VB, for instance, is proprietary, but is the most widely used language in the world. There are more lines of VB out there than of COBOL (which was the previous "king"). It enjoys strong vendor and community support. Witness the incredible effort (and pain) involved in the language’s evolution to the .NET platform. The level of vendor commitment required to make this huge change is not to be underestimated.

C++ is a standards-based language, which means that each vendor comes somewhat close to implementing the standard. There are (to my knowledge) no C++ compilers that entirely meet all standards requirements. But in striving for compliance, there is a high degree of consistency between C++ compilers and for some types of code that can be valuable. Certainly there is strong vendor and community support for C++ since the current mainstream operating systems are written in this language.

C# is also standards-based. Microsoft presumably implements the standard directly, while mono goes beyond it by already adding non-standard features coming in .NET 2.0. One would hope that the C# standard will change to include things like generics, but at present Microsoft is going to be making their C# non-standard in .NET 2.0. Regardless, there is strong vendor and community support for C# both inside and outside Microsoft.

Java is proprietary, with some arguable elements of being "open". Regardless of anyone’s personal or political views on Java, it is clear that it enjoys substantial vendor and community support. It continues to evolve through both open source and vendor initiatives and is a widely used language in many fields.

Each of these four languages has strengths and weaknesses. Features that are missing or sub-par and features that are really cool.

But most important is that all four languages have substantial vendor support and investment. It is clear that none of them will be abandoned by their vendors in the foreseeable future (even C++, which has faded dramatically due to pressure from Java and C#).

Similarly, it is clear that all four of them have vibrant and active community support. You can easily find paying work, code repositories, open-source projects, tools, user groups, conferences and other forms of activity for any of these four languages. If you are more business-focused, there’s a lot of Java work out there, and there’s a lot of .NET work (roughly split 50/50 between VB and C# at present). If you are more hardware-focused there’s still a lot of C++ work to be had. While it is thankfully fading from the business world, C++ remains the dominant language in use by computer engineers and operating system developers.

Of course even with all this, widely used languages never really “die”. This is why there’s a workable market for commercial .NET versions of things like COBOL and FORTRAN. This is why you can still find active development in FoxPro, and why there’ll be active work in VB6 for many years to come. I wrote earlier with some thoughts on the longevity of “dead” technology.