In BizTalk (2004/2006) pipelines are really a hybrid artifact. Some artifacts (like orchestrations) are compiled artifacts – meaning that the runtime just uses the compiled type to execute the orchestration. The effect of this is that you can change the code of the compiled artifact and affect the runtime behavior of your application by recompiling, placing the newly built assembly into the GAC and restarting your host (see my post on when you can do this versus having to undeploy and deploy). Pipelines – even though you compile them with Visual Studio into a compiled type are treated differently by BizTalk. The data they contain (which objects you want to run at which pipeline stages) is just really configuration – so the deployment step sucks the data into the configuration database, which makes pipelines really more of a configuration artifact than a compiled artifact.
In BizTalk Server 2004 it is possible to read in this configuration data from the ExplorerOM and modify it (on Receive Locations it is the ReceivePipelineData property and on Send Port’s it is the SendPipelineData property) essentially allowing you to make custom pipelines without having to recompile. This feature is there, but not well documented – and of course required you to write custom code to pull out the XML data for each Receive Location or Send Port you wanted to modify and modify the XML using one of the XML APIs in .NET.
In 2006 – next to each pipeline in the BizTalk Administration Console there is an editor button which brings up a property grid which lists all the properties of all the objects configured in that pipeline. Now you can change the behavior of a pipeline by modifying the properties during configuration (which you could do in 2004 – but only through custom code). This will cut down on the number of pipelines you will have to create for you apps, as well as make it possible to reconfigure a pipeline at runtime much more efficiently.