As I have already mentioned, I am involved in a project that uses BizTalk 2009. With this beast, you have to develop on the machine that has BizTalk installed and configured. This is vey unfortunate, especially when so many things can go wrong. From my experience in the past I have decided to work in virtual machine. Boy that paid off back so quick. While working on a custom adaptor, something went wrong during deployment and BizTalk 2009 was not responsive anymore. But I had nothing to worry about – I had a snapshot I could go back to.

I am starting a project that involves a lot BizTalk 2009. Since this is a completely new territory for myself, I decided to blog about it. There a lot of resources available out there, especially from MSDN.

First thing I decided to look at was a Custom pipeline. Two types of pipeline exist – sending and receiving. To understand better pipelines, I read BizTalk 2004: A Message Engine Overview on MSDN. It provides more information than just pipelines that is very useful for general BizTalk understanding (which I find a vital if you plan to develop for BizTalk).

One picture is worth a thousand words :)

I really liked this presentation. Highly recommended.

Today I was trying to solve a simple technical problem. Given a specific XML, needed to clean it up by removing any elements of a particular type.

More than a year ago, I have posted a blog entry related to what I was trying to implement in one of the projects. Unfortunately, not my team could understand what I was trying to do, neither I was able to make myself clear. Either way, I ended up closing the blog with a question “can code be too loosely (coupled), or your code is so coupled, that anything else is difficult to digest?”. Now I can answer my own question question.

ASMX web services were a breakthrough when appeared on .NET platform. A lot of services were created to take advantage of web services technology.

Now, that WCF is replacing legacy web services, we still have a lot of legacy web services running and being used. Connecting to legacy web services from WCF can be achieved either by leveraging Visual Studio .NET auto-generated proxies, or by creating dynamic channel I talked about before. Creating dynamic channel looks like a cleaner solution, but there are a few caveats:

There was a lot of noise generated by a blog “The Duct Tape Programmer”. There were lots of responses as well (link, link, link, link, link, link, link, link…). The last one I read was from Oren, where he puts it plain – just don’t do it.

I have my reasons to disagree with the statement(s) Joel wrote in his blog, but probably the most important one is about testing. Probably the reason for that is because I was developing without TDD for quiet a while, and I saw the difference. To me tests are design, and if you drop them, well, hell with design. A good project has to have a good design, and design starts from code, expressed first in tests, and after that in production code.

Our new system is entirely based of services (SOA solution). From the day one we had an issue with Visual Studio auto-magically generated proxies and management of those as system grew. Solution at that time was to create clients of the services dynamically, but the knowledge of WCF we had was a minimal. Now, 6+ months later, we finally getting to the point where I am comfortable and pleased with the solution. The interesting part is that WCF had that option all the time, we were not just educated enough to see it. Now we are.