BizTalk Server 2009 (2006 R2) Utilities

BizTalk Server 2009 was released end of April 2009. This tends to lead to  a natural  review of our internal handbooks and the utilities that complement our processes.

When approaching all BizTalk engagements we  initially consider the SOA Roadmap and development methodologies and test frameworks that support these approaches. The majority of the utilities/extensions mentioned here are available as open source, or free trial download, but rarely do I see these utilities combined. It is assumed that these are applied to the traditional base build of Windows, SQL Server, optional WSS and BizTalk.

WCF LOB Adapter SDK SP2 (http://www.microsoft.com/downloads/details.aspx?FamilyID=47AB6F21-0D8B-4C90-A8B9-E8647281B164&displaylang=en )

The LOB adapter pack has now been extended to support SQL Server and is worth considering when looking at using WCF bindings.

BizTalk Adapter Pack 2.0 (http://www.microsoft.com/downloads/details.aspx?FamilyID=76736ba7-3c05-4436-9353-1c33f9005194&displaylang=en ).

This is a 120 day evaluation extending the WCF LOB Adapter SDK, to enable the auto generation of schemas and ports for the additional new bindings. There is an additional cost for this pack, depending on the licence model of your client.

Nunit 2.5  (http://www.nunit.org/index.php?p=download ).

Still popular with clients and used  to manage BizUnit test cases. The more traditional option is mstest, but useful to include for completeness.

BizUnit 2.3  (http://bizunit.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=9001#DownloadId=23581 )  or 3.0 (http://bizunit.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=20013)

BizUnit is an excellent declarative test framework for managing test cases and for generation of automated regression test packs. The newer release 3.0.x.x has additional feature support. Some clients like to make use of the excellent BizUnit Designer, which provides a UI for test case generation over editing raw XML. This is useful for early adopters, helping with understanding of what features are initially available in the framework.

Microsoft BizTalk LoadGen 2007 (http://www.microsoft.com/downloads/details.aspx?FamilyID=c8af583f-7044-48db-b7b9-969072df1689&DisplayLang=en)

An additional tool to coordinate the execution of performance and stress tests.

BizUnit Designer 1.4 (http://bud.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=12968#DownloadId=33409) used with BizUnit 2.3

 A useful tool providing a UI to assist with the initial creation of test cases.

BizTalk Deployment Framework  (http://biztalkdeployment.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=17826#DownloadId=54972 )

This is a must for any development team. Having used the older framework extensively, the new features support msbuild projects over nant. This is a real time saver when managing complex build and deploys.

HTMLHelp.exe ( http://www.microsoft.com/downloads/details.aspx?FamilyID=00535334-c8a6-452f-9aa0-d597d16580cc&displaylang=en )

A Pre-requisite for the HTML output of the following orchestration profiler/documentor

BizTalk Orchestration Profiler 1.1.1 ( http://biztalkorcprofiler.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=6375#DownloadId=17235 )

An excellent tool for verification of code coverage of orchestrations in BizTalk. Generation of a help file analysing orchestration performance. Used during test cycles for verification of regression test packs coverage.

BizTalk Documentor v3.2 (http://biztalkdocumenter.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=8689  )

A useful tool for documenting the configuration of a BizTalk implementation. Useful to include in the deployment and release cycles for configuration management issues and to share with support teams, to verify configurations.

BizTalk Server Best Practices Analyzer v1.2 ( http://www.microsoft.com/downloads/details.aspx?FamilyID=93d432fe-1370-4b6d-aaa8-a0c43c30f5ab&displaylang=en)

An essential tool for all client deployments to generate and understand compliance reports. The latest version supports BTS2006, 2006R2 and 2009.

MessageBoxViewer ( http://blogs.technet.com/jpierauc/pages/msgboxviewer.aspx)

An invaluable tool for querying and analysing system configurations, especially for warnings of potential performance issues. This is more of a dynamic analysis than best practices analyser.

 Each of the downloads provides excellent detail on how to use the individual utilities. These are the utilities that we use to support our SOA Development Methodology when implementing and supporting BizTalk Server implementations. They provide the basis for development, test and deployment frameworks.

 

Enterprise Architecture and SOA

A few months ago I attended the Enterprise Architecture conference in London.  As we Enterprise Architects aren’t exactly a dime a dozen, I found it very stimulating to be able to participate in conversations with like-minded people.

Overall, I found the conference very positive as it reinforced my own belief that for Enterprise Architecture to add value to your organisation, it must be oriented towards the business community, and it can’t be just an IT-led initiative.

However, what became apparent as the conference progressed, was that two recurring themes were emerging: firstly, a lot of people do not understand what Enterprise Architecture is; and secondly, Enterprise Architecture is not Service Oriented Architecture (SOA). Unfortunately, some presenters seemed to miss the second point.

SOA is first and foremost an application and technology architecture pattern for defining reusable, technology-agnostic composite applications.  Used correctly, SOA will deliver value to your company’s IT estate.  But there are some essential facets of architecture that SOA does not address, the most important of which is the business architecture.

The common catchphrase of SOA is that it “aligns business and IT” – but how?  Everyone knows that this is facilitated by the services that you define, and these should be “business oriented”.  But there is more to business architecture than just service definitions.  For business architecture to be truly worthwhile it must encompass an holistic view of how your organisation is defined, what are its long-term goals and objectives, what its marketing and product strategy is, and how it interacts with its customers.  And how IT is used to deliver this.

This is why you need Enterprise Architecture.  Not only does it allow you to define your architecture within consistent, reusable models and artefacts that be shared across both the IT and business communities, but by separating these artefacts into separate architectural domains (e.g. business, information, application and technology), it allows your organisation to identify the inter-dependencies between these domains (for example, between your service catalogue and your information model), so that your architecture becomes truly sustainable and the benefits apparent to IT’s customers – the business community.

This is the message that was getting lost at the conference and within the industry in general, and unfortunately, some of the worst culprits are the SOA vendors.  SOA isn’t just something you can buy out of the box – architecture is something that your organisation must invest in, to define and build the resources that empower your enterprise.  As John Zachman so succinctly put it, beware of the enterprise silver bullet that some vendors will try to convince you is the answer to everything.

We’re fortunate at Smart421.  We use our Enterprise Architecture framework to deliver SOA (in fact, EA can be used to deliver any architecture).  Maybe you can find it useful too…

 

SOA is not just Web Services

This point has been explained in many other places, but still seems to need reiterating for some audiences:

SOA means Service Oriented Architecture

The most important word in that phrase could be ‘Architecture’, not the ‘Services Oriented’ piece – that just applies a modifier for the type of architecture; it does not mean that SOA is just the use of Web Services. Those are a technical interface mechanism and related standards that are indeed prevalent in any SOA environment, but that is only a part of it.

I, and my colleagues, often come up against a technical-biased viewpoint that implementing SOA is just a matter of using Web Services, SOAP, XML and WSDL for application integration. Maybe this comes about from the frequent over-use of the ‘Technical Architect’ job title, but that would be a different discussion with no real ending in sight.

In this context, an architecture implies a framework that is used within an organisation, whether it applies to business, information, application software or technology infrastructure. An architecture should include some form of blueprint and an associated set of principles to be applied to projects or solutions that fit within that architectural domain.

For SOA, a blueprint is an absolute prerequisite for any implementations to go into that environment (actually, for design and even project feasibility). Along with the blueprint should be a set of standards and principles that can be used to ensure the strategic SOA vision can be met. Tactical solutions may deviate from the strategic aims, but only if they can be shown to have strong justification for breaking the defined rules, and even then should have further plans to bring the solution into line for future strategic use.

The process of defining and applying SOA standards is that of governance, which is a form of quality control that applies to a greater level than is commonly seen in technical development projects where design and code reviews tend to take a project-specific view.

For SOA implementations to be successful, services should be designed to support business needs, so that they can be reused by multiple processes and applications, and using common approaches for interface definitions, data models, error handling and security. If these are not defined up front, as part of the architecture, it is highly likely that each set of services introduced into the SOA platform will be inconsistent, requiring additional effort for integration into any composite applications or services. Some of these points, especially that of security, can be very hard to ‘retro-fit’ if a standard is defined after the implementation of a number of service-based solutions. The same problems arise for any other standards that may be defined ‘after the fact’.

Hopefully these comments give a flavour of how SOA requires a broader level of thinking for application and solution design. There is a huge difference between a set of ad-hoc Web Services exposed in an ESB product and that of an architected design using SOA principles for compatible, consistent and reliable service-based developments.

If you are embarking on an SOA implementation, you really do need to form this holistic view of applications, services and business processes, with an architecture governance programme to ensure that the defined principles are applied. Of course, this is where the full ‘Enterprise Architecture’ approach comes in to play, with SOA being a subset of EA.

To those organisations, or more likely, development teams, that are just extending their EJB or COM components with a SOAP interface on an ESB, you should refrain from calling this approach a Service Oriented Architecture, as it most probably is not. It is quite likely to be just another bunch of incoherent application interfaces that will form a birds nest (or can of worms) with connections crossing all manner of boundaries. Well, that is my opinion of what I have seen happen, at least. Oh, one other whinge on common errors, it is ‘Oriented’, not ‘Orientated’. Shoot me if I use the wrong phrase!

SOA isn’t trivial, but if applied properly it can be a much better way of developing solutions within and across and organisation. So don’t be put off by the apparent overhead – doing SOA ‘properly’ is a good idea and should ideally be undertaken as part of a new approach to IT solutions that are using best practices in all possible areas.

I hope you now agree, that SOA is not just about exposing and using Web Services, and that if you are one of those committing the ‘crime’ of misusing or abusing the SOA moniker, please think again and take a step up to the greater view of architected solutions.