Virtual PC Optimizations

Tags: Virtual PC, Virtual Server
A coworker recently sent me a link to an excellent document describing the difference between VPC and Virtual Server and how to squeeze the most performance from it. I'm not going to reproduce the entire document here for brevity but I do want to describe the settings made within the virtual system to improve performance (because I know I'll want to do this on every new VPC I start working on). You can grab the whole document here: http://blogs.msdn.com/nolansax/attachment/700992.ashx.

Configure performance settings on the Microsoft Windows XP or Microsoft Windows Server 2003 virtual machine

1. Start Virtual PC 2004, and then start the Windows XP or Windows Server 2003 virtual machine that you want to configure.
2. Click Start, click Run, type sysdm.cpl, and then click OK.
3. On the Advanced tab, click Settings under Performance.
4. On the Advanced tab, click Programs under Processor scheduling, and then click OK.
   ** Note Before you modify this setting, you must verify that the host is not running critical services in the background.
5. On the Hardware tab, click Device Manager.
6. Expand Disk Drives, right-click the drive that you want, and then click Properties.
7. On the Policies tab, click to clear the Enable write-caching on the disk check box, and then click OK.
8. On the File menu, click Exit to close Device Manager.
9. Click Start, click Run, type desk.cpl, and then click OK.
10. On the Settings tab, click Advanced.
11. On the Troubleshoot tab, move the Hardware acceleration slider to Full, and then click OK two times.
12. Click Start, click Run, type regedit.exe, and then click OK.
13. Locate and then click the following registry subkey:
    My Computer\HKEY_CURRENT_USER\Control Panel\Desktop
14. In the right pane, right-click MenuShowDelay, click Modify, type 400 in the Value data box, and then click OK.
15. Quit Registry Editor.

Dropdown Engineering

Tags: BizTalk, Dropdown Engineering, Software Development

In my work I do a lot of development within products or frameworks. The best example is BizTalk but others are K2.net or BIE (Bryante Integration Server). Creating business solutions within these frameworks requires a different approach to software development. How is it different? Well...

The first thing you need to do as a developer is embrace the features. Only by doing this do you fully leverage the power of the framework Why even use the product if you intend to hand roll everything? I often see new BizTalk developers concocting long and involved code in Orchestration Expression Shapes (think: code snippets). Naturally, they are complaining the whole time about how the shape dialog doesn't have intellisense or other useful coding features. I try to gently remind them that they are missing the point; expression shapes shouldn't really need more than a few lines of code. Anything more and you are likely doing something that could be done better in another way. (If the built-in features of BTS don't do what you want then at least write a helper class to encapsulate your valuable business logic). The point is that the framework gives you the flexibility to write your own code but that doesn't mean you should (or need to).

The second thing you need comes from experience with the framework (usually after 2-3 projects) and that is to know the pitfalls. Every framework has strengths and weaknesses. Part of what makes a superior Dropdown Engineer is understanding this and knowing where to invest work to shore up the weaknesses. This may be one of the single biggest advantages of using experienced engineers.

I sometimes lament the loss of creative freedom when using product frameworks but I take solace in the fact that they allow me to develop solutions faster, more reliably, and with greater feature-sets than I would be able to do on my own. In essence they (the good ones, anyway) allow me to concentrate on business value without investing heavily in the foundational work. That's a good thing, right?

Microsoft SOA and BPM Conference: Day 4

Tags: Windows Communication Foundation, BizTalk, Microsoft, SOA

Last week was the conference, this week it's back to work and wow am I ever paying for spending the week away from the office. Nonetheless, the blogging must go on...

What is Federation?
During an interesting discussion about integration design patterns by an architect from Software Architects, inc. something interesting came up. He asked the audience to define 'Federation' and a couple of answers flew back but most people had trouble defining it. He provided what I believe is a very succinct definition that I will be happy to borrow and use from now on. Thanks, Mr. Architect! :)

Federation is the unification of self governing entities.

The new WCF Adapter
With the release of BizTalk 2006 R2 (tentatively scheduled for mid 2007) there will be direct support for the new Windows Communication Framework (part of .NET 3.0). From the looks of things this adapter will rapidly become our most commonly used adapter. This to me is yet more proof that WCF will have a dramatic impact on how we build applications.

WCF adapter features

• Transactional message send/receive


• Uses ws-* headers for routing/processing


• Numerous security scenarios


• In-proc hosting of non-http (netTCP, netNamedPipes, netMSMQ) endpoints

Business Rules
A very interesting seminar was held discussing business rules within your enterprise. Where to store them and how to express them. There was lots of good stuff with the usual justifications for separating business logic from code. I thought there were a couple of points in particular that were worth recording.

Deciding factors on where to keep rules

• Volatility


• Ownership

Reasons to manage Business Rules separately

• Accessibility


• Flexibility


• Manageability

Web Services Software Factory
On a final note, there was a great seminar presented by the Patterns and Practices team which showed us some of the great work they are doing around standardizing Web Services application development. I strongly encourage everyone to go and check it out at the Web Service Software Factory Community page.

Benefits of using a software factory

• Quality


• Consistency


• Performance

That's it for the conference reporting. It was a great educational experience and I feel privileged to have attended. Hopefully, next year we have the opportunity to go again!

Microsoft SOA and BPM Conference: Day 3

Tags: BizTalk, Microsoft, SOA

Here we are in the home stretch of the conference and the gems keep on popping up.

A replacement for the SQL Adapter?
I asked my annual question about whether they will be re-writing the SQL adapter and the short anser is "no" but... a surprise during the adapter presentation was the revelation that there will be a new Oracle adapter in R2. It turns out that the new Oracle adapter is a complete rewrite based on ADO.NET. Furthermore, it was suggested that since it's based on ADO.NET that it could also include support for SQL Server. It may be the case that we see a new 'database' adapter that supports Oracle and SQL server. Let's keep our fingers crossed!

Large Messages
A common challenge with BizTalk solutions is handling large messages. A large message is defined as anything over 1-2 megabytes. A persuasive demo showed us how dramatic the performance hit can be if you do not handle large messages carefully. The general approach is to avoid pumping huge messages into the message box. Instead, store the large part of the message in a file or database and then tag the message with a reference to the storage location. This would happen in the incoming pipeline. When messages leave BizTalk an outgoing pipeline reconstructs the message by retrieving the large bit and joining back to the message.
A very impressive solution was demonstrated that actually examined the incoming message for large elements, pulled them out (and replaced them with a reference id), stored them in the database, and then reconstructed the message on the way out. The performance improvement of this approach was huge. Something like a 60% improvement.
The presenter has a blog that's a good place to seek out more information on large message handling. It can be found here: http://blogs.digineer.com/blogs/tabraham/default.aspx

Microsoft SOA and BPM Conference: Day 2

Today's presentations were more technical than yesterday and hit on a number of interesting topics.

My favorite presentations were about Windows Communication Foundation (WCF). First off, WCF looks like the answer to many of our solutions. Being able to implement a variety of communication transports with run time configuration is awesome. It's also going to be great to bring the WS-* protocols into the mainstream with direct support for BizTalk ports.

I picked up a few best practices that we'll have to be sure to follow:

• Don’t plan on migrating to WCF. Plan on engineering new applications. The value of migrating is limited since existing applications ‘work’ and moving web services projects to WCF web services doesn’t really gain much.
• When validating messages avoid ‘schema validation’ as it can be costly. Validating Data Contracts is preferable.
• Protocols
• BasicHTTP is for all HTTP and web services type communication except for if you need WS-*
• WSHTTP is for WS-* web services communications
• NetTCP is for fast, efficient communication (and is best for machine-to-machine within your .NET solution)
• NetNamedPipes (I think it’s called) is best for service calls within the same machine
• Add Fault Operations to the WSDL contracts

Lastly, I picked up a couple of answers to my standing questions around SOAP Faults and NULL parameter validation. On the SOAP Fault front the good news is that the WCF WSDL tools will support SOAP Faults which is a huge improvement over the current tools. With NULL parameter validation the answer seems to be to use a new group of .NET 2.0 data types within the System.Nullable namespace. These are effectively a bunch of value types that can be NULL which should bypass the fun behavior of .NET where it assigns default values for NULL parameters.

Microsoft SOA and BPM Conference: Day 1

Another year passes and here I am at the BPM conference in Redmond again.

Last year the conference was very focused on the impending release of BTS 2006 and the impact of the recently unveiled WinFX (since renamed to .Net 3.0). This year BTS seems to be taking a lesser role and is being presented more as a supporting technology for the - currently fashionable - Services Oriented Architecture (SOA). In fact, if the first day is any indicator SOA is the central theme of the conference with technologies used to support Services Oriented (SO) architectures presented as precisely that, technologies to enable SOA.

Why is SOA the focus of the conference this year?

SOA is certainly nothing new. As my colleague pointed out, 'distributed computing' has been around for many years and was an early attempt to distribute 'services'. Dave Chappelle explained in his keynote that the reason SOA is now so hot is because the communication protocol to communicate services has finally been decided. The Simple Object Access Protocol (SOAP) allows diverse computing environments to communicate in a consistent way which effectively lowers previously near-impenetrable barriers. Chappelle also pointed out that the last time this happened was with TCP/IP when it assumed the mantel of dominant networking protocol and effectively enabled the Internet to be realized by opening up all of the diverse networks and allowing them to communicate with each other. So, it seems that SOA is the focus this year because the technology has reached a critical mass.

What benefit does SOA provide?

Normally, when I explain the benefits to a customer I describe three main benefits but in a couple of the presentations yesterday I came to realize a nagging suspicion about one of the ‘benefits’ that has moved me to officially remove it from my list of SOA benefits. Here are the benefits:
1. Abstraction
2. Accessibility
3. Reusability
For a while, I’ve suspected that my argument for reusability was a bit weak and after hearing others question it yesterday I’ve come to the conclusion that it is very weak. I can think of very few real-world examples where a service has been re-used to the point where it can reasonably be described as a benefit. Usually, a service is too specialized for a business case to be shared by other processes. Other times, the owner of that service has a vested interest (i.e. data ownership) in preventing access by other parties. In fact, the only example that immediately comes to mind of successfully reusing services is with simple ones like GetActiveDirectoryProperty which is a simple service that returns a property value given an account and property name. I think this was successfully reused because the business case was very precise and the AD values were not particularly proprietary.

Anyway, more on the conference to follow…

SOAPException class as WSDL SOAP Fault?

Recently I embarked on a seemingly simple mission. I wanted to explictly define a SOAP Fault to return a .NET SoapException. This turns out to be not so simple. In fact, after a few hours of experimentation, searching, and consultation I have still to come up with a decent answer. The search continues...

.NET and WSDL SOAP Faults

Recently I was working with a customer that wanted to explicitly define the SOAP Fault related to a failed web method call. I thought this would be simple since tools like WSDL.exe would provide the mechanism to handle the faults. Boy, was I wrong. It turns out that none of the 'mainstream' .NET WSDL tools handle SOAP Faults at all. If you generate a service from a WSDL file using "WSDL /server" it clears out all of the Fault references. So much for automation.

A guide to good naming

A question that I often get is "what should I name it?"

The best advice I can give is to take off your 'developer' hat and put on your 'business' hat. The most meaningful names reflect the purpose of the artifact. I have found that most often the purpose is best defined in business terms.

For example, we have a component that notifies a user of a new task. We could call this componet "SendEmail" or "SMTPOut" but it is much more meaningful to call it something like "SendTaskNotification".

It's almost never appropriate to name things based on the technology used. My favourite example of this is to name your XmlDocument variable "xmldoc". Could this name be any less descriptive? Surely, if we are going through all the trouble to instantiate/use this variable it must have some purpose. When naming we need to highlight this purpose and ideally put it in terms of the task at hand without focusing on the technical. It would be much more descriptive to call this variable "PurchaseOrder" or something like that (if that it what it was being used for). It is obvious from the code that it's an XmlDocument so we don't need to name it that.

A big win for good naming is the massive reduction in the need to write comments to describe what the variable is for. Good name swill take you a long way to self-commenting code.

BizTalk 2006 Documenter has been released

Recently, the super handy UK SDC BizTalk 2006 Documenter utility (think NDoc for BTS) was released. I can tell you that after making the mistake (once) of retrofitting a 2006 project onto a 2004 machine so that I could run the documenter (the old version didn't support 2006) I'm really happy to see this update.

You can grab it here along with some other handy-looking BizTalk tools: BizTalk server 2006 Scripts: Home

Developing Business Process and Integration Solutions by Using Microsoft BizTalk Server 2006

I found out this week that I passed the BizTalk 2006 beta exam. I suppose this makes me a certified BizTalk Engineer. Woohoo!

The test was quite long (almost 90 questions) and was broken into the following sections:

1. Plan a BizTalk Application
2. Develop and Debug an Integration Application
3. Develop and Debug a Business Process Application
4. Implement Business Rules
5. Enable Business Activity Monitoring
6. Deploy a BizTalk Application

Those of you who know me will not be surprised in any way that the deployment section was my worst. It's hard to delegate deployment to someone else on a test! :)

Consultant's Rules of Engagement

I was chatting with a colleague a while back and we were discussing ways to make our consultants feel more comfortable when they are dropped into a customer site. The biggest factor in their comfort-level seems to be how prepared they feel they are.

This totally makes sense to me as I realize now that the nature of the engagement is always one of the first things that I start investigating when I know I will soon be working with a customer. Ideally, the investigation yields enough details that I can begin establishing some expectation that focus on preparation appropriately. So what sort of expectations should I be looking for to maximize my preparedness?

That's where the Rules of Engagement come in. Here at Visiphor Consulting Services (VCS) we often use a military metaphor for our engagements. We are 'air-dropped' in, we are 'marines' who build the objective and move on, or we 'establish a beach head'. So, given the military context the concept of defining Rules of Engagement for our consultants seems natural. I know this term is not 'new' to consulting (as a quick Google search shows) but it very applicable to our consulting work.

Consultant's Rules of Engagement

1. Objectives
   
   
   1. What is the vision or 'big picture' of the engagement?
   
   
   2. What are the shared goals that constitute a successful conclusion?


2. Expectations
   
   
   1. What are the customer's expectations?
   
   
   2. What are our expectations?


3. Technical
   
   
   1. What are the skills required to achieve the objectives?
   
   
   2. What are the technologies involved?


4. Diplomatic


1. What is the political climate?


2. Who is the project sponsor?


3. What are the profiles of key players in the engagement?

A consultant provided with these Rules of Engagement should be armed with enough information to maximize their potential for success.

Team Foundation Server Administration Tool

This tool looks very helpful for configuring security within Team System. There are three different applications that need to by 'synchronized' (Team Foundation Server, SQL Reporting Services, and SharePoint) and this tool helps by administering all three simultaneously.

Team Foundation Server Administration Tool

Team System Software Topology

There are two important divisions in the Team System software universe:

1. Client
2. Server

The server product is called Team Foundation Server and provides the backbone of the Team System. An example of what it provides would be Source Control.

The client products are different flavours of Visual Studio 2005 based on roles
within the project team.

1. Team System Explorer
• This tool is bundled along with Team Foundation Server and is
  intended for non-techies to access things like work items.
2. Visual Studio Team Suite
• The uber-product that contains everything for all roles
3. Visual Studio for Architects
• Intended for Architects but really just seems to be a weaker version
  of Team Suite (which is what all the Architects will want).
4. Visual Studio for Developers
• Intended for Developers with a decent range of features for
  developing software within Team System.
5. Visual Studio for Testers
• Intended for Testers with some interesting testing features.
6. Visual Studio for Database Professionals
• Intended for Database Developers with some special features within
  the IDE specific to databases. Still no T-SQL intellisense,
  though

There you have it! We are hoping to get a hold of Team Suite for our evaluation but we may have to settle for Developer since that's all we can get a hold of. The DVD trial ordering site on ms.com says Team Suite is back-ordered and there is no download offered.

Investigating Team System - Licensing FAQ

We've been looking at this new beast called Team System for some time now and the time has come to jump in and start working with it. Due to the complexity and 'newness' of Team System we've decided to evaluate it by using it to develop an internal application. Also, since we are planning on using the 6-month demonstration version of Team Foundation Server we thought it was best not to undertake a customer engagement and run the danger of our demo expiring before we delivered!

But, perhaps I'm jumping ahead of myself. My goal with this blog over the next few weeks is to record the trials and tribulations of our Team System evaluation. Perhaps it will be useful to readers but more likely it will be a record of our discoveries for posterity.

There seem to be a couple of big challenges when starting a Team System evaluation. These are (1) Licensing, and (2) Application Topology.

Team System Licensing FAQ
Well, you know this is a bit complicated when MS has to release a 'white paper' describing how Team System (TS) licensing works! Here's a licensing FAQ based on what I've translated.

Q: Where do I get information regarding Team System Licensing?
A: Check out the Microsoft® Visual Studio® 2005Team System Licensing White Paper.

Q: I have MSDN Universal, surely I get Team System with it?
A: Short answer: 'not all of it'. Long answer: You do get Microsoft® Visual Studio® 2005 Team Edition for Software Developers and Microsoft® Visual Studio® 2005 Team Foundation Server Workgroup Edition. Unfortunately, these two products are really only suitable for small development shops and leverage only part of the Team System feature set. You need MSDN Premium to access more of Team System.

Q: Can I upgrade MSDN Universal to MSDN Premium in order to score Team System?
A: Short answer: "yes". Long answer: There are some options for upgrading your current MSDN subscription. Check them out here. Note: It looks like the best promotion ends on June 30th, 2006.

Q: What do I need to buy to use Team System?
A: You need one or more client licenses (Visual Studio), a Team Foundation Server License, sufficient CALs to support your user base (one for each user), and a non-MSDN Windows 2003 Server license. The client licenses come in a variety of flavours based on the 'role' of the team member. The best one is Team Suite since it covers all of the others but you can also get a Developer, Tester, Architect, or Database version.

That covers the main questions I had. Hopefully this helps!

I'll talk about Team System Application Topology in a future post.

When is InfoPath the correct technology?

Lately, we've (the very talented Developer Group at my company) have been discussing when to use InfoPath instead of something more traditional like ASP.net. Here is the synthesized result of our conclusions based on past experience. Hopefully, it aids you in making the correct choice in your projects.

InfoPath is suitable for:

• Simple to medium ‘form’ applications
• Applications based on data-entry. i.e. validate/submit
• Applications based on xml data
• Applications that follow a pattern supported by the out-of-the-box GUI. This reduces custom-code considerably.
• Applications requiring offline data entry/saving
• Scenarios benefiting from a consistent Application environment – No cross-browser Issues
• “No installation” simple applications – for simple data entry forms

InfoPath is not suitable for:

• Applications based on data-management. i.e. download/upload/validate of existing data sets
• Complex forms where significant work is needed to optimize performance by working around InfoPath’s foibles
• Applications that have no need for the concept of ‘client-side’ data entry. i.e. reports
• Time-sensitive form initialization – complex forms can be slow to load
• Applications with a large user base. i.e. licensing issues – purchase 1000 copies of Office Premium
• Non-Windows environments – Office Premium must be installed
• "No installation” complex applications – complex forms require security certificates or installers