William,

Independently hosted WSE-based service endpoints listening over HTTP must -
at some level - leverage the hosting APIs. There is a dependency in the WSE
on HTTP context (System.Web.HttpContext), as demonstrated by Anthony in a
previous post (see exception).

The WSE pipeline operates independently of the underlying transport. It may
leveraged to create and/or process SOAP messages without the imposition of
transport. By extension, the resulting SOAP message that's created could be
sent across the wire using any transport-related class found in the .NET
Framework. However, it's not guaranteed to be compliant with its associated
SOAP binding. That stated, you're better off leveraging  what the WSE
provides in the Microsoft.Web.Services2.Messaging namespace. There is a code
example specified in the WSE quickstarts (%ProgramFiles%\Microsoft
WSE\v2.0\Samples\<Language>\QuickStart\PipelineHosting) that demonstrates
how to instantiate the WSE pipeline to create a message in memory.

To answer your question:

The purpose of the WSE pipeline is to process a SOAP message through I/O
filters. Inbound SOAP messages are processed via the ProcessInputMessage
method while outbound SOAP messages are augmented via the
ProcessOutputMessage method. In both cases, the
Microsoft.Web.Services2.SoapEnvelope parameter is what is processed,
independently without the imposition of transport. That stated, once the
message has been processed, you are free to do with it what you like. :-) In
the WSE quickstart example (above), the resulting message is persisted to
and read from disk.

John