BizTalk Deployment Framework: Add Reference to Application

I wish I had found this before - I had not previously found a way to script the adding of a reference to another application, and thus used workarounds (like including assemblies from other projects).

http://blogs.sqlxml.org/bryantlikes/archive/2007/07/18/creating-biztalk-application-references-with-nant.aspx

This is particularly useful if you have a separate application defined for a common Exception Handling framework (for instance using the ESB Guidance package: http://www.codeplex.com/esb).

Thanks Bryant!

The Starbuckian Handbook from Hog Blog

For those of us admitted users of a local coffee shop for times we don't need to work at the office but need to get out of the house, someone has drawn up a reasonable code of ethics for the 'Starbuckian'. 

http://www.radicalcareering.com/hogblog/?p=80

So You Want to Learn BizTalk... (Part II)

With the fundamental concepts of BizTalk server under your belt, you are ready to get your hands dirty.

Labs

While especially easy to use if you do not have a development machine setup, these labs provide a relatively superficial demonstration of the core BizTalk features. Can be useful for a quick demo to a non-developer though.

Microsoft Virtual Labs
http://msdn2.microsoft.com/en-us/virtuallabs/aa740373.aspx

Tutorials

What's better are the tutorials that are part of the documentation and SDK. This is where a developer really goes 'aha!' for the first time and starts to see he or she can begin to use BizTalk Server. These are not optional ;)

BizTalk Tutorials:
http://msdn2.microsoft.com/en-us/library/aa560270.aspx

Training

If you or your employer are part of the Microsoft Partner program, you have access to perhaps the most valuable and comprehensive self-training package out there - the Classroom-in-a-Box. It includes training videos and slides, whitepapers, more hands-on labs and a VPC with every possible BizTalk core feature installed and configured. It can be accessed under the Partner Resources in the BizTalk product area:
https://partner.microsoft.com/US/40012176

Books

I don't claim to have read many of the books out there on the product. From experience however I can safely say that this book has proved valuable numerous times both as a first read a reference on projects:
http://www.chapters.indigo.ca/books/item/books-978159059699/0/Pro+Biztalk+2006

You can read my review of it here:
http://asonofmartha.blogspot.com/2006/11/pro-biztalk-2006.html

Additional titles can be found here:
http://btob.barnesandnoble.com/index.asp?sourceID=0041631635&btob=Y

Blogs

With prior versions of BizTalk Server, the best place to get answers to real-world problems was always through blogs. Now, MSDN is typically the authority on the "How-To" and plenty of books exist for the product, however there continue to be scores of bloggers discussing their challenges and successes implementing BizTalk solutions. Too many to list in fact, and so here are some links to discover those blogs:

http://www.squidoo.com/bts06

http://www.biztalkgurus.com/

http://www.biztalkgurus.com/blogs/

My del.icio.us BizTalk links:

http://del.icio.us/zutroyquixote/BizTalk

Newsletters and Publications

BizTalk Gurus offers a periodic newsletter called The BizTalker with useful "news from the front":
http://www.biztalkgurus.com/newsletter/index.aspx

There is also a quarterly publication now on its third release called BizTalk HotRod

Where to next...

At this point, you should be well-armed to assist in new or existing BizTalk projects. However, if you are expected to start or lead a project on your own you will do well to fill out your training with additional reading and possibly formal training (including certification).

Coming Up Next:

Part III: Beyond the basics

Previously:

Part I:

So You Want to Learn BizTalk... (Part I)

Learning a new technology can often be a challenge especially if it is one that requires a different different set of lenses on the world. No better can this thought be applied than to the undertaking of learning BizTalk development. It is not for the faint of heart. Let me make it clear that BizTalk is a very powerful and agile tool - but this in combination with the complexities of the problems it solves gives the tool a steep learning curve.

Experience Prerequisites

• Strong knowledge of the .NET Framework (2.0 or higher)
• Strong familiarity with XML and related tools (XPath, XSLT)
• Understanding of SOAP web services and when to use them
• Use of Visual Studio 2005

I wrote this list then realized an almost identical list comes from the horse's mouth:
http://msdn2.microsoft.com/en-us/library/aa577674.aspx

Experience Nice-To-Haves

• Experience with Integration projects
• Understanding of Message-Oriented development
• Understanding of Service-Oriented Architecture (incl the Tenets of SOA)
  
• Understanding of Enterprise Services Buses

Where to Begin

As with development of any server product, I strongly recommend using a virtual PC on which you can install everything (SQL Server + BIzTalk Server + Visual Studio). Development can be done on a separate machine from the DEV server, but if you are using a VPC having everything on the same box will save time.

Part of the initiation to BizTalk development should most certainly include performing the full BizTalk installation. This will serve to appreciate what is actually under-the-hood. Even if infrastructure and server installation is not your forte, this experience will serve you well in your trials and tribulations ... er, travels.

To start, as with most Microsoft products, the best place is the Microsoft Learning:

Clinic 2954: First Look: Microsoft BizTalk Server 2006 for Developers
https://www.microsoftelearning.com/eLearning/courseDetail.aspx?courseId=51883

With that, you can flesh out the details with this article from the documentation:

Product Documentation: Understanding BizTalk
http://msdn2.microsoft.com/en-us/library/aa546748.aspx

Coming Up Next:

Part II: Tutorials, Labs and Books, Oh My!

Part III: Beyond the basics

CompSci != Software Engineering

Regarding Chris Chapman's article Reviewing Ontario CompSci Schools: Who's Teaching Best Practices? of September 17,2007

I was going to post this as a comment on his blog, but it turned into a posting of my own :)

I definitely appreciate the sentiments Chris has raised and respect the research he has done (even if he says it is a rough assessment). My biggest beef with this analysis, however, is that it completely ignores the fact that as many as half of the schools looked into also offer Computer Engineering with a Software specialization, if not true Software Engineering within the Engineering (not the Science) faculties.

I will insist that this is an important distinction. A Science faculty is going to emphasize research and development, as well as the more hard/pure/abstract aspects of Computer Science. Topics such as best practices in industry, ethics and professionalism are of course going to be elective, as they might be in mathematics or botany programs. I suppose the unfortunate reality is that most Comp Sci grads still go into industry as a developer (for instance) but the industry has made the assumption that such grads are software professionals truly grounded in best practices and methodology.

Software engineering is such an oft-abused word and by no means does a comp-sci grad necessarily have software engineering skills or even understand what software engineering really means. Especially in Ontario (to tow the line of the PEO) it is becoming clear why so many engineering faculties are trying to bring software engineering into their domain - industry is expecting a software developer to have engineering skills! And as you imply, it is to the detriment to us all in the software industry if these issues are not cleared up: people in the industry need to have a grounding in best practices and projects need to completed successfully within time/budget etc.

Having come through the Software Engineering program at UWO, I agree that there is still some bias towards requirements engineering (which for better or worse is still an approach used in the industry) but other methodologies including Agile are gaining more ground. The academic calendar for Western's SE program can be seen on this link:

http://www.westerncalendar.uwo.ca/western/web/2007(new)/Courses_UWO_SE.html

Universities by nature still tend to be slow moving of course and with such a rapidly evolving industry like software, there will likely always be a disparity between what is taught and what is done. That means industry may have to bear the burden of ramping up new grads. So be it - I'm sure this is nothing new to most employers. That said, I am all for academic programs (particularly ones with an industry focus, like engineering) teaching and making mandatory courses on best practices.

The reasons for software project failures are many, not the least of which is people understanding the difference between software and other "hard engineering" projects. I think much of the solution lies in educating industry on where best practices are truly taught (as Chris has helped show) but more importantly actually teaching them to all software graduates (especially those becoming software professionals) and this will likely include the continued migration of teaching software engineering into the engineering schools.