Diving Into BizTalk 2004

Towards the end of 2005 our company decided that we were churning some old applications, some legacy applications were digging in, and some new business functionality was being implemented. Throw into this a few third party vendors, and we decided that we should really take a look at SOA.

We went out bought some books, talked to the industry folks at Forester, sent some people to conferences, joined some Yahoo lists and began to see if this SOA thing would work for our mid-sized enterprise.

We dug into the UDDI repository and quickly forgot that as an option. We are still looking for a reasonably priced web service, windows system events, and email monitoring, escalation, and notification product. If you folks know of any send me an email.

One of the things that became clear was that we were most likely to be successful with SOA if we adopted a Business Process Manager (BPM). Well since we are a mostly Microsoft shop, we took a look at BizTalk 2006 and really liked what we saw, except for the ship date. We decided to reduce risk on the implementation by going with a released version of the product, but purchase the 2006 version. That way we could implement BizTalk Server 2004 (BTS) and have it in production around July, then have a smaller effort to migrate the 2004 code to 2006.

To make sure BTS04 was easily upgradeable we are doing some behind the scenes testing of upgrading the code to the latest versions of BTS06. We will limit the types of things we do in BTS04 and really get the messages flowing, but maybe stay a little behind with how we use HAT and HWS.

We installed BTS04 Standard after some nudging in our development environment, as it turns out BTS04 does not like it if you install BTS04 on a Windows 2003 SP1 environment, and then place all of the databases on a separate SQL 2000 SP4 server that used to be a SQL 6.5 box, and had been upgraded all the way. This dev environment was also a NT4 box that was upgraded to Windows 2000 Advanced, and had been patched to the latest service packs. To make the situation a bit dicier, the SQL instance was clustered and the failover side of the cluster was a clean Windows 2000 Advanced, SQL 2000 SP4 install. With a call to Microsoft support, they solved the issue.

Which brings me to this weekend... On Friday I called around until I found a copy of BizTalk Server 2004 Unleashed at MicroCenter. We packed up the family and headed out for dinner and a book. I read the reviews of this book, and I'm not sure I agree completely. If you are used to reading developer instructions for how to do something this book makes me feel right at home. The examples outline how to do certain things but leave out key elements, which have you turning back a chapter to figure stuff out or sometimes going to the index and looking up where some key part of the sample code was glossed over, but covered in a future chapter.

I went to bed on Friday night after reading the first chapter and thought this book was going to be an excellent read. I woke up on Saturday morning, read through the examples

I must say I woke yesterday morning with a more complete idea of how BTS should work in an environment. I wanted to learn more about how BTS works with web services, and how best to use BTS in our environment.

So let me set the context here. I’m new to this company. A fulltime employee and the person defining the role of enterprise architect here. Historically I’ve been a technical architect / developer. For this BTS project I recommended somebody I knew to come into our company and help us put together a BizTalk solution that would work for us.

We had 3 weeks to get the environment setup and take a message from a message queue and call either 1 or 2 web services depending on the payload of the message. It's been 5 weeks and our company is looking to mitigate risk in this area. I've been encouraged to do what it takes to see that we get to where we need to be by the end of week 6. So I am doing what I know best and digging-in.

I spent the rest of Saturday going through the book, extending the sample scenario from chapter 2 of the book, and continue working it until it met my real business requirements. Then I went and took a look at the code written by Bob, my consultant friend. Let's just say that Bob's code didn't look like anything I had written, I really couldn't figure out where the code was coming and going. To make matters worse, I had asked Bob to check-in his code on Friday so I could take a look at it this weekend. You guessed it. Bob did not check-in the code.

Okay at this point I’m not so happy with Bob. But I’ve seen Bob’s work products in the past, and still have high hopes for what Bob is producing. So I take a look at what Bob put together.

As it turns out there are four ways of connecting web services to BTS.
1. Use BTS and add a web reference in your orchestration
2. Use the BTS SOAP adapter
3. Use the WSE 2.0 adapter
4. Create your own proxy object

So Microsoft and the book I read on Saturday took approach number one and used BTS the way they had built it for. The last company I was at, we used BTS with standard web services, but had to remove and re-add the web service every time the WSDL for the web service changed. It turns out that using the SOAP adapter can be problematic in heavy usage scenarios, and the since we don’t write WSE 2.0 web services, option 3 was out as well.

So that pretty much leaves us with options 1 and 4.

With option 1 we use basic BTS04 and run into issues when we need to change WSDL. With option 2 we create our own proxy objects, but now we need to GAC the web service proxies into the BTS server.

Well off I go to figure out how I want this BTS proxy stuff can work.