Scott Seely seems to object to my previous comment on being careful about the defaults used by svcutil.exe. Scott goes on to describe in detail how svcutil figures out what should get written in the default configuration, which is pretty useful.

But, seems to me like Scott may have misunderstood my comment. Yes, I do know how svcutil.exe works and even why it chooses the defaults it chooses. I'm not arguing against it configuring default values (even for all binding properties, as cumbersome as that can be). I'm arguing against the rationale of the default values themselves, as they make little sense for a client side proxy.

Don't get me wrong, I fully agree with Scott's comment that "Bigger defaults would have made it easier to blow up your average WCF endpoint, and that wouldn't have been a good thing", but that's an assertion that makes a lot of sense for a service endpoint. A client side proxy, on the other hand, will rarely require such stringent settings and in fact it constantly gets in the way (only case where this would be significant is in the case of duplex contracts).

In other words, I'm arguing for SvcUtil being slightly more smart about the default values depending on the context. And even more, I'm arguing that the default security constraints configured by default on WCF bindings (SvcUtil or no SvcUtil) are too small. I'm not saying to make them unlimited, but they could benefit from slightly larger values, particularly for WSHttpBinding and friends.

But as long as we're on the topic, let's add one more to the mix: The truth is, that these kind of security constraints are sitting right in no man's land. Developers will very rarely look at them (unless they are already aware of the issue) simply because they test their services in limited environments, where, for example, messages might be small enough to cause no trouble. But then they go blow up in their faces in the production environment. Administrators on the other end, have no clue what this settings are or what they configure (in fact, they have no clue they even exist) and will simply ignore them... until they blow up in their faces as well. This is not a good situation by any means, because you know what people will do? They'll just get used to configure them always to the maximum possible value.

Windows Communication Foundation

My good friend Sam Gentile pointed me to David Pallmann's set of WCF tips. Lots of good stuff in there, and I found myself agreeing with most of the stuff David brought up.

One that particularly resonated with me was Tip #4 on default settings. One of my biggest gripes with svcutil.exe is that it generates a default client-side proxy configuration that is fairly useless, because it initializes all binding properties explicitly with values that are too small to be useful in many cases. What's worse, you may not realize the consequences of this during initial testing and may only notice the problem later on. In particular, message size and encoding quotas have default values that are too small.

Actually, I'll go one step further and say that a lot of these security quota settings make little sense for service consumers. However, you do want to configure them properly for services themselves (though the default values might still be too small for most scenarios), as they can help you protect against denial of service kind of attacks, or simply protect you from handling requests larger than your service can chew.

Windows Communication Foundation

BizTalk Server 2006 R2 Developer edition (RTM) is now (finally!) available on MSDN downloads for MSDN subscribers. Downloading!

BizTalk Server 2006 R2

As I mentioned a couple of weeks ago, I've been doing some Java work here and there. I don't mind it, and I even welcome the chance to get reacquainted with Java every now and then. For now, the tooling I'm using is a mixture of Vim, the command line, and Eclipse. It works OK, but it hasn't been a fully pleasant experience.

First I ran into a bit of trouble getting the Eclipse debugger to work with Tomcat and getting the project system setup just right. Turned out I was using the wrong project type (!) and once I fixed that I was able to work much better. The Eclipse debugger still sucks, particularly if you've been spoiled by the VS debugger, which, even with it's faults and limitations, is still very good and extremely usable compared to some other tools.

The "feature" that I have come to rather dislike about Eclipse, however, is Perspectives. I don't mind the core idea; it makes total sense: Have a way to configure different settings and options in the environment (particularly around window & UI layout and available options) based on a given context.

However, I find that the way Eclipse implements Perspectives gets in the way I work, for a few reasons. The first one is that there are just too many perspectives, some of which don't quite make sense to me. For example, I see very little reason to have completely different perspectives for Java and Java EE; they share to much in common. Also, the choice of which perspectives are easily accessible (that is, through the Window -> Open Perspective menu option) seems pretty arbitrary and doesn't always work out well (not too mention the fact that the contents of said menu depend on what the current perspective is, which doesn't help).

What I found more annoying about perspectives, though, is that switching between perspectives is a manual process most of the time, which seriously reduces their usefulness, as you have to constantly go through the UI to change the perspective back and forth. For example, Visual Studio also has something similar to perspectives, in the sense that the UI can be customized for certain contexts (such as when coding and when debugging), but the fact that those contexts exists is mostly transparent to the user: Visual Studio will switch between them automatically based on actions you make in the UI, such as starting the debugger. Not so with Eclipse. For example, the Debug perspective doesn't [always] activate automatically when you start the debugger, which I've found pretty annoying.

On the other hand, it's possible I'm just using it wrong

Eclipse

After working with Windows Communication Foundation for a while, I've reached the conclusion that the two features in WCF that I like the most are:

1. Generic Service Contracts: That is, the combination of using simple contracts with a single, catch-all operation and untyped data contracts (a.k.a. the System.ServiceModel.Channels.Message class). Particularly for one way, scenarios, these are really powerful and flexible. In other words, stuff like this:

[ServiceContract]
public interface IGenericOneWayService
{
   [OperationContract(Action="*", IsOneWay=true)]
   void Execute(Message msg);
}

2. Custom Bindings: Creating custom bindings by composing arbitrary sets of BindingElements is extremely flexible and a provides an excellent extensibility mechanism, particularly when you introduce custom protocol channels (i.e. above the transport channel) into the mix.

It took a bit of time for these to finally "click" for me, but I know fully realize this is a pretty cool thing to have in the framework. I do wish there was better validation of custom bindings, as well as a way to specify declaratively the requirements and capabilities of binding elements.

Windows Communication Foundation

Jeremy Miller asked about switching from NAnt to MSBuild and if it would be worth it. I've thought about this in the past, and here's what it always comes out for me:

• In raw power and flexibility, I don't think there's a clear winner.
• MSBuild has the advantage of being "built-in" and that as Microsoft itself extends the compilation process (or brings more things into it, as is the case with, say the Workflow Foundation validation targets), it will have some stuff earlier than NAnt.
• NAnt, however, has a fairly extensive (more extensive, I'd say) set of tasks, if only because it has been around earlier and has a good community around it.
• Personally, I prefer NAnt's structure; I find it easier to read and maintain than MSBuild's one. This is pretty significant to me because build scripts can easily get fairly complex. Syntax itself is irrelevant here because both are XML dialects.
• Documentation for NAnt is, I'd say, far better than for MSBuild. In particular, I found MSBuild documentation to be pretty useless in general because what you will usually find documented is the API (raw methods and properties) of the MSBuild task classes, instead of documenting them in a way that more obviously maps to how you would actually use them in a build script.
• It might be wise sometimes not to choose one over the other, but instead have them collaborate.
• If you need multi-targeting support (that is, compiling a single code base against multiple framework targets), then NAnt is the clear winner here. NAnt's framework support is pretty good and it's very easy to create a build-script that can compile a single code based against .NET 1.1, 2.0 and Mono. MSBuild is rather lacking in this area (MSBee can help with .NET 1.1, but it really is a hack and a pain in the neck to use).

In general, I would say that if you're already familiar with NAnt, and can use it effectively and efficiently, there is little compelling reason at this time to switch. But if you're not familiar, then at least trying to get acquainted with MSBuild should be worth it.

NAnt, MSBuild

Ayende has been very vocal about his opinion of SSIS (SQL Server Integration Services) in the past, and, to be fair, he has some good points and indeed working with SSIS can be a pain in the neck many times. However, I've discovered that I despise SQL Server Reporting Services (SSRS) far more than I could ever  SSIS.

Working with Reporting Services is about as much fun as sticking needles under your fingernails. It insists on changing stuff on it's own, like switching report parameters to multi-value after you tell it you want them single-values, reverting a dataset parameter to some weird incorrect value you once typed in (no matter how many times you change it), or just throwing weird errors in your face. And don't even get me started on the joke that is the MDX query designer.

FWIW, I think most of my issues (if not all of them) with SSRS are directly related to the design-time support for authoring reports; I don't think I have many problems with the actual runtime behavior of it (for now).

SQL Server, SSRS, SSIS

Here's another Color Scheme for Visual Studio 2005. This one has a dark (almost black) background, but high contrast, playful colors for the most common uses:

It's also my most complete color scheme yet, as it includes very usable configurations not only for the usual (Code, XML, HTML and CSS) but also for things like XSLT/XSD and MDX (and works very nicely for SQL, as well).

This time, I'm using Damien Guard's Envy Code R Preview 6 for my font, which I've found extremely usable and very nice. It has very distinctive features, and contrary to what I expected from Damien's comments about it being mostly oriented to use at small font sizes, I found it very good at 15pt. And I love his "Visual Studio" special version (which I'm using for this color scheme) that presents "bold" fonts using italics instead! The only thing that I do think could be better is the '#' symbol, which, I think, seems too small.

Download EnvyCodeR_Nightingale.zip. Enjoy!

Update: Download the Visual Studio 2008 version here.

Visual Studio, Color Scheme

I was setting up my Orcas VM again to play a bit with some VS2008 stuff. As part of my usual rituals, one of the first things I'll do is import my old VS2005 settings from a .VSSETTINGS file I keep around. Mostly it works fine, and much better in beta 2 than it used to work on previous builds (though it will still cause a couple of warnings).

That said, I did run into two minor, but annoying things, related to Font and Color settings:

1. Why, ohh why, did the XAML designer guys add yet another complete set of color settings for XAML code? Isn't XAML after all XML? Why couldn't they just use the base XML color settings and maybe add a couple of new options, instead of a complete new set?
   I mean, I appreciate having flexibility, but there's a point after which too much configuration options is just annoying. Many Visual Studio color scheme setting files around (from those that do share it) don't really include the full set of color bindings (for example, many just have the base code options and maybe html/xml settings, but not very often); now if you want to share a quality color scheme for VS2008 you need to configure and test yet another complete set of colors? ouch!
2. The import seems to truncate some of the Fonts and Color settings. In particular, it seems to completely ignore colors for User Types (Enums), User Types (Interfaces), User Types (Value Types) and User Types (Delegates), setting them up with some other color (not sure yet where it picked it from). I guess this is probably a simple bug in the importer, but not sure it's worth reporting (unlikely to be fixed at this stage).

Visual Studio 2008

I've been doing some work this week working on SQL Server 2005 Reporting Services using MDX to query OLAP Cubes. It's the first time I had a serious project (that is, do anything significant) using MDX, and it's been an interesting experience.

After a while, MDX starts to sort of make sense, but I will say that, as far as query languages works, MDX has a pretty strange syntax; it's not very readable [1] and I found it pretty absurd that the facilities in the language to work with parameterized queries were so convoluted!

[1] It's probably more accurate to say that queries can be written in a very readable fashion, which is usually useless because it means using a structure that makes it very hard to introduce query parameters. Silly, if you ask me...

MDX, OLAP

Today was my 30th birthday! Had a great time hanging out with my family at lunch and then later during the evening for dinner and got some cool presents (including some books, which I always love, and a new Wii game!). A good day all around

Walter Michel commented on my recent entry on the BizTalk and WCF Messaging Models and asked if I had some guesses as to what the architecture of a future BizTalk version might look like in regards to WF/WCF integration. I think that, at this point in time, it is anybody's guess what it might look like, as it is just too early to tell.

Honestly, I don't know what it might end up looking like, and I can't even say I can make an educated guess (and there are people with far more criteria for making such educated guesses than me, such as Jon Flanders). Instead, I'll address the question in a different way, by mentioning what I consider a few challenges I see regarding the integration and other things like that.

The Impact of Significant Architecture Changes

One key aspect of the whole integration process between the three technologies is what the impact of significant changes to the core BizTalk architecture. Microsoft already went down that path during the transition between BizTalk 2002 and 2004, and while those of us developing BizTalk solutions are extremely grateful for the benefits that the new architecture brought over, companies with large investments in BizTalk 2000/2002 solutions were not so happy. For most of them, going to BizTalk 2004/2006 meant a complete rewrite of their integration solutions, and that can be very expensive, and though to justify to the business side, not only because of cost, but also because of the associated risks.

With BizTalk 2004/2006, BizTalk brought over not only a significantly revamped platform, but also a new, effective, and very welcome extensibility model that has been tested with time. That's why the current core product architecture has been good for three release cycles already, and the fact that even complex things like WCF could be integrated without significant changes to it is pretty substantial.

A lot of Microsoft clients and partners have made significant investments in that architecture and its not clear how that investment might be preserved (or at least their loss mitigated a bit) if significant architecture changes happen. I'm pretty sure the people at the Connected Systems Division at Microsoft are aware of this, and from my own, outside perspective, I can only say that it seems like a daunting and complex decision to make. Whatever way they decide to go, it's not going to be easy.

So, what happens if the complex changes do become a reality? We can only hope that good migration tools are not left by the side; but even with those migration tools, you'd probably be looking at a complete rewrite scenario again for the most part.

Messaging

In my previous entry, I commented that the current WCF integration in BizTalk 2006 R2 leverages the existing BizTalk messaging extensibility model (the adapter framework) on top of the messaging engine. However, I think that in the long run, keeping both is probably not the best solution. Despite their differences, there's still a lot of common ground and responsibilities between the BizTalk Messaging Engine and the WCF model, and simply keeping both models in place, with their independent extensibility models, would be too expensive (for example, keeping both the BizTalk adapter framework and the WCF transport channel model).

So my best guess is that, at some point in time, one of them would tend to disappear, and needless to say, that would have to be the BizTalk one. Does it mean that the BizTalk Messaging Engine will disappear? Probably not, but it will change and its responsibilities will adjust to that.

For example, assuming that the core message moving responsibilities are absorbed by the WCF stack, then the Messaging Engine would concentrate on it's other tasks: Managing Receive Locations/Ports and Send Ports/Port Groups (assuming those concepts still exists in some fashion), managing port configuration settings at runtime, managing errors and, assuming the Message Box concept remains (or some equivalent centralized routing agent), then submitting and retrieving messages from it.

There are some interesting aspects deriving from this:

• The pipeline model would disappear. Personally, I'm a little saddened by this because I consider the pipeline extensibility model to be simple [1], elegant and very effective; and it's one of the great assets BizTalk has when integrating against legacy and third party systems with peculiarities in the messages they generate/consume. That said, WCF does have a good extensibility story, though the responsibilities of where each things happened are a bit more diluted across the stack, instead of being centralized like in the BizTalk pipeline concept.
• The WCF model has some bias towards XML/SOAP. Certainly, it allows other things as messages, depending on how much work you're willing to invest in it. This is changing a bit, though, in .NET 3.5 with the REST support, and I expect it will change even more in later releases. To be an effective messaging stack for an integration platform, however, this needs to be a non-issue.
• WCF supports a more complex set of interactions (and MEPs) than those supported by BizTalk at this time, and it's not clear how some of those could be used to extend BizTalk. This includes things like composite duplex channels, as well as the durable services/sessions model supported in .NET 3.5 (the current implementation of which makes little sense if the service is backed by a real workflow in WF/BizTalk).

The Message Box

An interesting question that comes up is whether a future BizTalk version might still have the Message Box. Currently, the MessageBox is the cornerstone and heart of the BizTalk architecture, and a key element in supporting BizTalk's highly reliable, loosely-coupled, asynchronous model.

However, I don't discard that, if a major architecture change is done, the MessageBox model isn't reevaluated, because it also is a disadvantage at times. For example, it can impact message throughput and latency in low-latency, synchronous scenarios, and after a certain point, the centralized model doesn't scale all that well without some really heavy-duty DB servers (which is expensive).

I don't think the message box concept will go away soon, but it may change in how it is implemented. I also think (but this is just a wild guess) that we might see some support for more lightweight operation modes were you trade off some of the features of the MessageBox for lower latency for purely synchronous operations (this would be interesting, particularly for some messaging-only scenarios).

The Orchestration Engine

As far as I know (at least from the little tidbits MS has let out), XLANGs is going away to be replaced by a WF-based orchestration engine. At the least, this means that some migration tools would be needed here, possibly with a set of custom WF activities that match more closely to the behavior of the built-in XLANGs shapes in current BizTalk versions.

There are some interesting implications and questions coming from this change:

1. One of the core advantages that WF has over the current BizTalk Orchestration model is that it is extensible through custom Activities. However, as we've already seen, some custom WF hosts will restrict the set of activities that can be used in Workflows executing on them. Whether BizTalk will have an open or closed model here is anybody's guess.
2. WF has one low-level mechanism for getting data into a workflow: Workflow Queues (getting data out of a workflow isn't quite as clear). While the queue model is very flexible, it is also too low-level for what most people are comfortable with. Unfortunately, the current WF releases don't really have a very good higher-level mechanism for this (the HandleExternalEvent and CallExternalMethod activities are woefully inadequate). In other words, the existing Port model in BizTalk is a far better model, which the new WCF integration into WF in .NET 3.5 is sort of related to (at least they are much more similar).
   This is, in a lot of ways, a key point in making WF usable as an XLANGs alternative. The current port model in BizTalk is tied to the BizTalk MessageBox, and it is instrumental in the design of loosely-coupled orchestrations and services, scaling processing to multiple hosts (via the BizTalk Host model and bindings), and versioning complex long-running processes (direct binding is extremely useful when breaking up complex processes into multiple orchestrations and letting each one be versioned independently).
3. A key difference between WF and XLANGs is the fact that XLANGs is message oriented. This means that messages are a first-class language construct, and so message construction, manipulation and the receiving/sending of messages is a clear concept. WF, on the other hand, has no clear of what a message is at all, and execution is not related at all to how data (messages) flows around the process. On one hand, this is an advantage because it opens new possibilities and adds expressiveness to the tool, but it is also a downside because the message-orientated nature of BizTalk and BizTalk orchestrations has been one of BizTalk's strongest points and really aligns it with Service-Oriented Architectures.
   In fact, even in the WCF integration in .NET 3.5, the concept of message isn't directly mentioned; instead we talk about [data]contracts, which are still just CLR objects. If this remains so, then an interesting follow-up question to consider is what happens to the existing BizTalk features that are closely related to its message-oriented nature, like maps and the support for non-XML message formats (including EDI and Flat Files, but not limited to them). There are certainly alternatives for this, and I do doubt we'll see a significant reduction in functionality in this space, though how it is accomplished could change significantly.

Human Workflow

Traditionally, BizTalk hasn't been oriented towards automating processes with heavy user-involvement (the stronghold of more workflow oriented tools like K2.net or Ultimus). With BizTalk 2004, Microsoft made a weak attempt at providing some tools for building these kind of solutions as part of EAI projects with Human Workflow Services (HWS), which were deprecated on BizTalk 2006.

WF has more potential in this arena, although the core WF is too basic to build human workflow solutions out of the box without a large number of extensions. I don't expect a future BizTalk version to incorporate more Human Workflow oriented features; given that Microsoft has said they are investing in positioning Microsoft Office Sharepoint Server as a contender in that space. We might see some more BizTalk to Sharepoint integration tools, though.

Business Rules Engine

Both BizTalk and WF have some business rules functionality. While the BRE in BizTalk is, in general terms, more advanced than WF's, it's not clear exactly what's going to happen. I seem to remember reading that both engines are now owned by the same dev team, so we should certainly be seeing some convergence there.

What is not clear to me is whether there will continue to exist two separate engines (one for the core WF and one for server oriented products like BizTalk). If both continue to exists, then that does mean a bit more confusion for BizTalk developers as it will mean having to choose on a case by case basis which of both engines to use from orchestrations (now WF workflows). If they converge into a single rules engine, then I would expect the WF engine to absorb, one way or another, the extended functionality offered by the BRE.

Conclusion

The only conclusion I can make of this is that I have more questions than answers . It's certainly going to be interesting to see how the core framework evolves and how that impacts the architecture and functionality of BizTalk as a standalone server product, and for us BizTalk developers it will sure have some significant impacts. The best I can say is that learning a bit about WCF and WF and understanding their architecture now sure will help when the time to make the transition comes along.

[1] The only reason writing pipeline components is complex at times is because of the COM-compatible interfaces you need to implement to satisfy the old, internal unmanaged implementation in the Messaging Engine, as well as the need to do streaming as much as possible to minimize the performance impact.

BizTalk, Windows Workflow Foundation, Windows Communication Foundation

I've been doing some little Java work the last few days (and have a bit more coming down the pipeline (nothing big, just a few small changes and additions to existing applications), and decided to look again at Eclipse. It had been a while since I had used it last (and even back then it was pretty decent).

A few thoughts:

• Eclipse is fairly small (as far as IDEs go). I downloaded the J2EE version of the Europa release, and the compressed download is only about 140MB. Obviously, there are quite a few more plug-ins for Eclipse, and I imagine that a multi-language version would be a lot bigger, but even so, it's refreshing to see it compared to the multi-gigabyte beast that is Visual Studio.
• It's also pretty nice that once you decompress the eclipse release, you can just keep it around or copy it to another machine and have a working installation; definitely saves a lot of times (I love apps you can do that with!)
• I remembered what it is that I don't quite like about Eclipse: The UI. Don't get me wrong, it is fairly fast and responsive (heck, it loads a lot faster than VS on my machine), but the interface is extremely cluttered, full of small, unrecognizable icons and with way too many tool windows. It does get the job done, though, but feels a bit oppressive to me (particularly since I got used to running a pretty lean VS environment with very few toolbars and most tool windows (the few I use, anyway) set to auto-hide.
• Navigating the Preferences dialog is a freaking nightmare. The number of options is almost baffling, and a lot of settings are spread over several different pages. For example; just try changing the code window colors and fonts...
• My feelings about the workspace model are mixed:
• Bad: It forces a specific project layout on disk, which doesn't work very well with how I usually structure my project folders (by client).
• Good: Many preferences are saved alongside the workspace folder, meaning if you move your workspace, you take your preferences with you. It also makes it easy to have different preferences for different projects by simply having them on different workspaces (something VS is not good at).
• Bad: Many preferences are saved alongside the workspace folder .

It's interesting to note that even with Eclipse around, I've been doing a lot of work simply editing the code using Vim and compiling using the command line tools .

Eclipse, Java