BizTalk 2004 Naming Conventions

This document covers proposed naming conventions for describing BizTalk artifacts.

One of the primary benefits of the BizTalk Orchestration model is the great transparency you can get when a software implementation is pictorial.

Regardless of how well a developer comments code, there will always be a need to maintain a separate set of artifacts (UML diagrams, Visio diagrams with random shapes of your choosing, prose documents, whiteboard discussions, etc.) that are used to convey what the code is actually doing especially when working with a business audience.  This is true if for no other reason than that a discussion of interesting functionality will often take place at a different level of granularity than raw code can support

Round-trip engineering tools - that attempt to keep code in sync with diagrams - often seem to suffer from a lack of fidelity that renders them ineffective.

With BizTalk Orchestration, the diagram is the implementation (at least at a particular level) of a piece of functionality.  Yes, you can disappear into components and lose sight of what might happen.  Yes, there is a code representation (xlang/s) underneath the orchestration but it seems to be completely isomorphic with the diagram.