BizTalk is a fine centralized message broker
with many adapters to 3rd party applications,
but service buses are inherently distributed -
not centralized.
Logical centralization leads to spaghetti.
Mixing logical orchestration and routing
with business logic, data access, and
web services calls is not a good idea
and leads to slow, unmaintainable code.
NServiceBus guides developers away from these
dangerous anti-patterns while still providing
the needed messaging patterns and integration.
The best of both worlds
In many cases you will need to integrate your code with existing systems and legacy applications possibly running on different technologies and proprietary protocols. This is a classical Enterprise Application Integration (EAI) situation and is not what service buses are meant to address.
In these cases, between your high-level business services you would use NServicebus and within the relevant services, behind the service boundary, you'd make use of BizTalk to perform the integration with your existing systems and legacy applications. Here's how it looks:
As you can see, the use of BizTalk behind a service boundary is something of an implementation/integration detail. By keeping the scope of the problem domain small, using BizTalk for a small orchestration to synchronize customer information between Oracle PeopleSoft and SalesForce won't run into either performance or maintainability problems.
Next steps
Sometimes you need a hammer, sometimes you need a screwdriver, and sometimes you need both. While a Swiss army knife may appear to do both, it is a poor choice for any but the most trivial undertakings.
To learn more about dividing up your architecture into high-level business services, see the presentation Udi gave on SOA on this page.
This download from Microsoft dscribes the details of getting NServiceBus and BizTalk to work together. Including a whitepaper, code samples as well as videos - this will get you up and running in no time.
If you haven't downloaded NServiceBus yet, give it a try.
