Patterns, patterns, patterns

Today I attended two architecture session at Software Development Event (SDE) from Software Development Network (SDN) in Driebergen (Netherlands). First session by Dennis Doomen was Design Patterns applied in the field (through experience). Perhaps you noticed that our work as a developer today is filled by so-called Design Patterns. Think of patterns such as Model-View-Presenter, Dependency Injection, Fluent Interfaces, Factories and Domain Modeling. Even Microsoft is bringing them up now with ASP.NET MVC, which means Model View Controller. If you want to know more about patterns you can the books of Eric Gamma or Martin Fowler, but chance is that you might fall asleep after the first page. In his session Dennis talks about patterns he uses in his daily job. His PowerPoint and code can be downloaded from his blog. Second session by Pieter de Bruin was around application architecture guidance. Microsoft  launched a new version of Application Architecture Guide in January: a document to use when you are setting up. NET applications. His talk (and the document) focuses on the most common types of applications, partitioning application functionality into layers, components, and services, and walks through their key design characteristics.This guide is a collaborative effort between patterns & practices, product teams, and industry experts. There you go patterns!!! If I think of BizTalk and application or SOA in general there are patterns to. Martin Fowler wrote a book about enterprise integration patterns (and there is a site too) and Thomas Erl recently written a book that is out now called SOA Patterns. Patterns are important and useful in any kind of creating software solution being user interface, service, messaging, database, and so on.

Technorati:software patternssoa design patterns

DTAP Strategy: Pricing and Licensing

To implement BizTalk solutions it is a good practice to have an DTAP environment in place. DTAP stands for Development, Test, Acceptance and Production. Development and test environments are equal (mirrored) and same account for acceptance and production. Deploying DTAP environments is easy, because there are many factors influencing outcome of DTAP. One factor is pricing and licensing costs. BizTalk is available in different editions and since BizTalk depends on operating system and database there are some configuration options to. Here is an overview of possible configurations for DTAP environments, hence there is a nice BizTalk Feature Dependency Matrix.

Besides features, there are non-functional requirements to reckon with like fail-over, availability and scalability. On Microsoft Pricing and Licensing FAQ section of BizTalk I found this on non functional side. In a large BizTalk Server 2006 R2 deployment, two key considerations ensure redundancy in all areas of the architecture and manage significant message volume:

First, on the front end (the machines running the BizTalk Server 2006 R2 services that are actually performing the business document transformation, routing, and business process management work), it is usually best to have two or more computers pulling from the centralized processing queue, so that if one fails, the remaining computers are still processing work. This provides both “scale-out” and “failover” for the BizTalk Server 2006 R2 computers. The BizTalk Server 2006 R2 machines often do not need to use Microsoft Cluster Server (MSCS), as fault tolerance is automatically provided in redundant configurations. BizTalk Server 2006 R2 Enterprise boxes may be clustered using MSCS to enable specific scenarios. If customers choose to cluster (using MSCS) the BizTalk Server 2006 R2 machines, CPU licenses must be purchased for every server, regardless of whether they are clustered as active/active or active/passive mode. Whether customers choose to cluster using MSCS or redundant configuration, BizTalk Server 2006 R2 ENT is the only edition that supports using more than one computer to share a BizTalk Server 2006 R2 load.

Second, on the back end (the computer[s] on which the Microsoft SQL Server processing queue is located, and from which one or more front-end computers are pulling), it is also desirable to have “failover” should the computer running the SQL Server service fail. This is a standard active/passive SQL Server clustering scenario utilizing MSCS and, logically, is completely separate from the BizTalk Server 2006 R2 computer(s) in operation. This is what we are referring to as “failover” clustering. SQL Server Enterprise Edition and Standard Edition offer failover clustering ability. Note that you may use BizTalk Server 2006 R2 Enterprise or Standard with SQL Server Enterprise Edition or Standard Edition for failover capability on the back end. It is also often desirable to “scale-out” the SQL Server installations by providing more than one computer running SQL Server to support multiple message boxes. BizTalk Server 2006 R2 Enterprise is the only edition that offers scale-out ability and multiple message boxes.

This means that there are possibilities in configurations for BizTalk deployments in DTAP (as shown in picture below).

On website of Microsoft I noticed following note.

Note: Many customers who deploy BizTalk Server implement separate development, testing, and production environments for their BizTalk Server 2006 R2 solution. For the development and testing environments, you need a user license for each developer and tester, which can be obtained through either BizTalk Server Developer Edition or an MSDN Premium Subscription. For the production environment, you need a valid processor license of BizTalk Server 2006 R2 Enterprise, Standard, or Branch Edition for each processor on which you install an edition of BizTalk Server 2006 R2.

As you can noticed there is no remark on acceptance environment here. So if one needs to have an equal acceptance and production environment then a valid processor license of BizTalk Server 2006 R2 is required. Let do some math here with license pricing of BizTalk Server.

Lets say three developer editions (not MSDN) of BizTalk (two for development and one for testing), four standard BizTalk Editions will come to an amount of $35493 ($26994 if one uses standard edition of BizTalk from for instance MSDN for acceptance environment). Amount will be different if Enterprise edition is used in Acceptance and Production Environment, depending on if MSDN is used or not. Lets assume again three developer editions (not MSDN) of BizTalk (two for development and one for testing), four enterprise BizTalk Editions will come to an amount of $141493 ($71495 if one uses enterprise editions of BizTalk from for instance MSDN for acceptance environment). These are just prices for BizTalk not Team Foundation Server, Visual Studio 2005 Team Editions, SQL Server, Operating Systems. Through calculations you can learn a lot what the cost in the end will be. To lower the cost MSDN subscriptions might come in handy for Development, Test and Acceptance.

Regarding pricing and licensing I have recently posted a discussion on LinkedIn. In case of a BizTalk DTAP Strategy, which editions are suited for each environment?

One answer which I liked is the following and resembles how I think it should be.

“Buy an MSDN subscription for everyone who touches D, T, and A. That way, you don't need any additional licenses for these environments. Use Enterprise Edition of BTS if you require a multi-server setup, use Standard Edition if you are OK with the risk of a single server setup. Use Standard Edition of SQL if you have one or two SQL Servers. (Two server clustering is available in SQL Standard.) If you need more than two SQL Servers for performance reasons, get Enterprise Edition. Use Branch Edition at the spokes in hub and spoke setups." (Thanks Geoff)

Customers can benefit a lot having multiple MSDN Subscriptions regarding Development, Test and Acceptance. For Production valid processor licenses are required!

So far I have talked about cost factor of BizTalk Server alone in perspective of configuration options. There are more factors concerning a DTAP environment deployment, ‘Pricing and licensing’ is one of them and an very  important one.

Technorati:BizTalk 2006 R2BizTalk Server 2006 R2BizTalk

Social Networking with Twitter/Yammer?

I did some things on Twitter and Yammer (inside my company), but to be honest it does not work for me. Best social networking tool for is and will be LinkedIn. It is professional and adds value with its features. For instance asking questions or start discussion inside groups. I truly like that and it works for me. Yammer account is gone and twitter to (at least I am trying to).

I will try some other time to get rid of it. I know it is an hype this kind of social networking, but not for me. I stick with LinkedIn and Facebook to stay in touch with my Canadian, English, US friends and family.

Technorati:web 2.0

BizTalk Server 2009 Sandbox Installation Part II

In past I build an VPC with trail software from Microsoft to install a BizTalk Server 2009 Beta. This time I will do it again using an Visual Studio® Team System 2008 Team Foundation Server SP1 VPC Image (Trial) from Microsoft that will expire 31 December 2009. This image contains TFS 2008 installed on Windows 2003 Server with SQL Server 2005. First on needs to do is download the image this will take some time (in my case an hour or two ). I then clicked on the self extracting en_visual_studio_team_foundation_server_2008_sp1_december2008_vpc.part0001.exe to extract three files (TFS08SP1-V7.vmc, TFS08SP1-R2.vmc, and TFS08SP1.vhd).

 

 

Next I did following steps in order:

1. Launch the Virtual PC Console using Start|Programs|Microsoft Virtual PC.
2. Click the New button to launch the “New Virtual Machine Wizard”.
3. Navigate to the Options page and select "Add An existing Virtual Machine" radio button.
4. Click the Browse button and navigate to the location you extracted the files to and select the TFS08SP1-V7.vmc file (the TFS08SP1-R2.vmc file is for use with Virtual Server 2005 R2 SP1 Update).
5. Select the “When I click Finish, Open Settings” checkbox and click Finish.
6. On the left pane for the dialog "Settings for TFSRTM08-TFSONLY-V7", select Memory. Then on the right pane, adjust the value of the RAM setting for your computer (You should leave at least 256 MB of free memory).
7. Click OK to close the dialog.
8. Select the new image entry, TFSRTM08-TFSONLY-V7, and click Start.
9. To logon to the machine, click on Action Menu (Shortcut: Right Alt+Del) on the VPC console and use the following credentials:
   Username: TFSSETUP, password: P2ssw0rd (Administrator account)

 

And is what you will see after you login.

This process took me less than 3 hours in total. I now created a share through VPC to location of BizTalk Server 2009 Beta. If you do not have public beta available, it can be downloaded (takes less than 30 minutes). So copy file called BTS09Beta.exe to local C Drive and click on it. Fill in folder to unzip (I choose C:\BizTalk2009Setup).

After unzipping installation you can start by clicking setup.exe in folder BizTalk2009Setup. A cabinet file needs to be downloaded during setup so I configured VPC internet connection by selecting wireless network through Network Settings (also I assigned DNS manually, see this post). I selected the following components (see picture).

 

 

After installation I did start configuring straight away. I installed Excel 2007 (BAM!) first and checked if SharePoint Services 3.0 was installed (which was the case).So this is what is on the machine now:

Last but not least configuration of BizTalk Server 2009 Beta on this VPC. Configuration of SSO, Group, BizTalk Runtime, and Business Rules Engine was pretty straight forward. Configuration of BAM is easy and requires you to do the following.

BAM alerts could not be configured, hence SQL Server 2005 Notification Server was not installed. I created a new website called BAM and assigned port 88 (see this post how to).

 

Before BizTalk Server 2009 will be released you  will be able to play with the bits. BizTalk Server 2009 will be released somewhere in next couple of months (could be May, BizTalk will be RTM end of march). This sandbox installation of BizTalk is a bit different that the one I did in December and took less time. Also I installed more components and configuration was a bit more work. Focus here is on BizTalk Server 2009, OS and database are of previous version (i.e. 2003 OS, 2005 SQL Server).

Technorati:BizTalk Server 2009

Wait for BizTalk 2009? Part II

In my previous post I asked if I should wait for 2009 or deploy an OTAP environment now. I asked this question also in Linked Groups BizTalk, BizTalk Certified Professional Group, BizTalk Professionals, and BizTalk Server Professionals.

Comments where divers, but clear on whether or not to wait for BizTalk 2009.

Moustafa Refaat:

My opinion is not to wait. BizTalk 2006 R2 is a mature platform and already would deliver what you want except 2008 and some 64 bit functionality. So unless you are dependent on these functionalities to run on 64 bit or you can not run in 32 bit then wait for 2009.

Chris Romp:

I would seriously consider BTS 2009, especially if they're using Team Foundation Server to implement ALM. Overall, however, it depends on what features they'll be using, and if any of those have updated in BTS09.
They won't have to wait very long; I would expect to see BTS09 released likely before they go into production.

Leonid Ganeline:

If these projects should be deployed in this Spring use R2. Otherwise use 2009, never mind it is in Beta. It is a pain to use all old stuff with R2 like VS2005, SQL2005, Windows Server 2003. Make sure you are seriously considering the SOA on the WCF + WF + Dublin base.

Christian Siegers:

I had a similar issue some time ago. Wait or deploy. I choose to deploy the current version because looking at the project of the organization there were no new features being used. So waiting for a new version, but not using the new stuff isn't a good thing waiting for.
I think it is not a matter of technique but more of what the business wants. If the customer wants the newest version then wait, if the customer wants to start developing use the current version. I
Though decision, but just hear what the customer wants.

Jone Gudmestad:

The main reasons to wait for BizTalk 2009 are:
* Support for Windows Server 2008/SQL Server 2008
* Support for Visual Studio 2008 and MS Build
* Improved BAM RTA on SQL Server 2008
* Support for virtual servers
* New and improved versions of LOB adapters and ESB guidance will follow
The main reasons to go with BizTalk 2006 R2:
* Can start now and then upgrade to BizTalk 2009 later
My guess is that BizTalk 2009 will RTM pretty soon...

Mike Diiori:

It sounds like you are correct in assuming some analysis needs to be done to determine the best course of action. BTS 2009 seems pretty stable, but you never know the true status of the product until the release date is set and the bits are publicly available.
Some other points that I've had to consider when making a similar decision:
1.) Does the new system need adapters, accelerators or other functionality that is not available with BTS 2006 R2?
2.) Is the project thoroughly scoped to the point where a go live date can be determined accurately +/- a few weeks to a month? Is the go live date within the next few months or later this year or next?
3.) What does the rest of the organization infrastructure look like? Are they running Windows 2008 servers, Windows 2003, etc? Do they have mandates to follow as far as existing Microsoft support agreements that would cause them to be more forward leaning and more likely to wait for BTS 2009?
Since BTS installations wind up being fairly cost intensive for even the most basic installation, it is best to err on the side of caution and make sure the client's needs are fully vetted before making any recommendation.

Sandeep Kesiraju:

depends upon when the deployment date needs to be..
I would strongly recommend 2009, just because there are a lot of improvements within BizTalk as well as the supporting SQL Server 2008 features, as well as support for windows server 2008.
if you are starting your development now, it is a good time to start with BizTalk Server 2009.

Patrick Shirley:

My experience has always taught me to wait until new versions are thoroughly beta tested before taking them on....depends how 'bleeding edge' you want to be?
If your business requirements are dependant on the timely development of the solution I would progress with 2006 R2....all depends how long you can wait!

 

As you can see quite some comments after a couple of days. It also showed me that LinkedIn is a great virtual place to ask experts, fellow professionals questions or start discussion as this. Through blogging I noticed that interactivity is far more less. Only got one comment on the post in same amount of time.

Thiago Almeida:

We're helping at least 2 clients facing the same situation. What helped us decide to go with BizTalk 2009 for one of them is the extra functionality provided by SQL 2008 like reporting services, compression, etc.
The other was a bit easier since the project is estimated to be in production only at the end of the year we decided BT2009 should be used since it will have been a few months since the product RTM'd.
Note that both projects would be "green field" installations of BizTalk...

Not bad to have almost ten valuable answers within five days and things to think about. Thanks everybody for making time to these comments.

Technorati:BizTalk Server 2009

BizTalk OTAP: Wait for BizTalk 2009?

I am facing a new challenge in deploying an OTAP within two organizations or at least a case, where customer is asking itself about which version for an complete OTAP environment. Question here is should a customer wait until BizTalk 2009 is released or deploy an OTAP now based on BizTalk Server 2006 R2. In my opinion it depends on the situation the customer is in. If OTAP is necessary in a certain program, where an OTAP of BizTalk is required to continue for instance an implementation of SOA (dependency on BizTalk where progress needs to be made on complete program). In case of an green field situation or startup of a program one can wait or start with Beta (through TAP). But I also feel that there are just to many factors to determine what the best solution is: wait or deploy now and start developing solutions? Through this post I hope I will receive some comments (commenting can be done anonymous, no authentication is required), what best way to go is :)

Technorati:BizTalk Server 2009