March 2005 - Posts

Reaching a blogging milestone
Thu, Mar 24 2005 8:41 AM

One year and two week after Dennis talked me into blogging, I'm now writing my 100th post!! It's now that I realize what a dynamic and interesting year I had with my new employer. And with Indigo and Avalon ahead, Whidbey nearby and IBF and EntLib on my attention right now, the next year won't be different.

Doing cool things with the Business Rules engine in BizTalk
Thu, Mar 24 2005 8:35 AM

When I learned BizTalk 2004 over a year ago now, I also took a day to play with the Business Rules Engine. That day always left me with the feeling that you could do really cool things with that, but not a single occassion last year allowed me to put this engine to test.

Now Microsoft published an interesting article about complex business rule processing up on MSDN. That's the kind of rules I thought about. Haven't got the time to test it though.

The webpart story between SharePoint and ASP.NET 2.0
Tue, Mar 22 2005 9:47 AM

SharePoint (WSS) and ASP.NET 2.0 both support the concept of webparts. Problem is, their not based on the same technology and not interchangeable. This raises the question which direction you should take when building WebParts.

Mike Fitzmaurice answers this question on his blog. Along the way some notes are made about WSS/ASP.NET 2.0 interoperability (ASP.NET 2.0 and WSS on the same box after WSS SP2 is applied!) and WSS direction for the next release.

Longhorn current release schedule + much more about Longhorn
Fri, Mar 18 2005 8:00 AM

Paul Thurrot writes about the current view on Longhorn's release. Interesting stuff.

[via Mike Taulty]

by Carlo Poli | with no comments
Filed under:
Playing with EntLib, part 2: configuration revisited and building a custom Application Block
Thu, Mar 17 2005 7:54 PM

Yesterday I posted about the fun I have with EntLib and my initial reservations towards the Configuration Block and its support in the Console. Since then I spoke to Edward and Pascal and mailed with Dennis Mulder and they all didn't share my view on the uselessness of it. A good reason to revisit the problem, since I greatly respect their opinions.

Turns out they are more right then I thought. Although I'm still not a big fan of the Configuration Console (I felt like I had to build all settings twice, once for the data and once for the node properties), I now am a big fan of the Application Block model and it's configuration support.

Basically I made three mistakes when I played around with it. Yeah right, three mistakes. I'm getting too old for this software development, the time I could write a significant piece of code that compiled the first time seems lightyears away. Anyway, my mistakes where: 

1) I build my testproject mainly around the designer, which is what you normally wouldn't do and made it harder to see the advantages. An understandable mistake to make, since it was the designer I was interested in.

2) I looked too much at the HelloWorld project, which is more complicated than simple projects need, because of the use of factories and providers. Also not a very bad mistake, they didn't write the sample to bypass it.

3) I saw my appblock as a settingscontainer instead of a piece of functionality. My biggest mistake.  An Application Block is supposed to deliver functionality, how could I ever think about it as something that just stored my settings. As soon as I sorted that one out, I got the hang of it.

The example I used over and over again when I talked about configsettings was storing an FTP username and password securely for building an FTP session. I now realise that I should not only store the settings but build an appblock that hides all the complexity of building FTP connections. My demo FTP Application Block project was born.

An application block should have an easy to use API, in my case a GetFile and a PutFile that both accept a FTPLocationName as a parameter. This name maps to a location configured in the configuration file, with all the details like hostname, port, folder, username/password, etc. These settings are encrypted by the Configuration Block and stored securely. I had the skeleton running and configurable through the console in about 3 hours. So, I must admit, Edward, Dennis and Pascal are right, the configuration stuff in EntLib is cool, you should just use in the proper way.

BTW, to anybody interested in the FTP Application Block, I'm sorry to tell that I didn't implement the real functionality and the existing code contains numerous bugs, so you have to build your own I think.

Playing around with Enterprise Library
Wed, Mar 16 2005 4:35 PM

A couple of weeks ago I was evaluating the different options a software developer has to instrument his application. I did this because I'm writing application guidelines for applications that are supposed to be hosted on a generic .NET platform and we wanted to standardize monitoring and logging to ease maintenance of all those applications.

As part of that I evaluated the Logging and Instrumentation Application Block of Enterprise Library. In fact, EntLib delivers almost everything I needed, so I now favor EntLib in my guidelines. One the biggest pro's of EntLib is the configuration console which allows for on-the-fly reconfiguration of the Instrumentation in a pretty intuitive way with a nice UI. No more editing of complex XML-files, so less change on breaking an application by typos.

While at it, I thought EntLib could also tackle another concern for my guidelines, which is secure storage of configuration settings. Here's where the trouble started. Although it only took me minutes to produce an application that could read and write configuration settings and have them encrypted, I couldn't edit them through the configuration console. This is a big issue, because one of the nice 'features' of encrypted settings is that you can't edit them through notepad. Without the ability to use configuration console you're stuck to writing a configuration application to configure your application or extend your application with a configuration function (which probably is a bigger risk to your application than storing unencrypted settings). Both approaches make me unhappy.

There is light in the darkness though, but it isn't very bright. If you do want to configure your settings through the configuration console you can extend the console. The only serious way to do that I found so far (I'm no expert yet, so I might miss something) is by providing a custom application block. I've played around with that the last few days and it's certainly doable, but it didn't make me happy either. It's a whole lot of work to be able to store and manage sensitive settings like a FTP username and password.

Another light comes from former college and brilliant developer, mister Conijn. He has also spotted this weakness and started a development project that allows you to provide an XSD to the configuration console to manage arbitrary settings. I think he started himself a rough but honorable job. Untill he's done or EntLib 2.0 fixes it (I hope), I think I manage my configuration settings in another way. How do you manage your settings?

My article is published in the latest .NET Magazine (issue 8)
Tue, Mar 8 2005 9:28 AM
Last year I decided to write an article about BAM in BizTalk. Microsoft published it in it's latest .NET Magazine (it's dutch). Let me know how you experienced the article, I'm very interested.
VSTS Performance Analyzer Tool on Channel 9
Tue, Mar 8 2005 9:23 AM
Channel 9 has a video on the Performance Profiling tools in VSTS. Looks very cool. One funny note, the demo project he uses is called Rational ;-).
The truth about large message support in BizTalk 2004
Tue, Mar 1 2005 12:07 PM

When BizTalk 2004 was launched, Microsoft announced that it supported large messages (into GB's). It was important to them because they broke the 4 MB limit that previous versions had.

What wasn't very clear, is that this statement is mainly about the fact that they use streaming to handle incoming messages. Which also means that scenario's that can't be solved by streaming still might (or will) have issues. The BizTalk Core Engine Team therefore published an very informational article about scenario's that might not work with large messages, with details about the reasons for these problems. A must read for any BizTalker that expects to do large message handling someday.

Main takeway for me: when a customer asked me if BizTalk 2004 supports large messages I would answer "Yes", now I will answer "No, unless you keep the message handling simple or invest time in tuning the solution". Because I think that is the reality of BizTalks support for large messages.

The end of the source code file?
Tue, Mar 1 2005 10:47 AM
Oron Novotny of Goldman Sachs writes in his article “Next Generation Tools for Object-Oriented Development” (published on MSDN) why he thinks development tools should no longer use source code files. In fact, he also has some statement about making development language-independent. Interesting approach to ending the VB.NET vs C# debate, I think ;-). But seriously, I think his arguments for abandoning the source code file are very good.