Funny enough we had similar discussion today on Switchyard IRC (http://echelog.com/logs/browse/switchyard/1415833200) starting at 14:26.
Anyway, I will summarize:
Your option is to include the header in the context mapper "includes" configuration, so you get it back from the first call. And then use it in the following calls, also allowing for this property to be set on the HTTP transport.
There are some bugs related to this, and also, when you set a header in the SOAPMessageComposer it will try to set it as as SOAP header, so you'll need to set the correct scope (endpoint.http) I think.
I would recommend you to look at SOAPContextMapper as there is where all the logic happens. To understand better the context mappers, read: http://unpoucode.blogspot.com.es/2014/10/message-composers-in-switchyard.html
If you have more problems, shout again for more help here.
And if you make it work, do not forget to share your solution. Somebody else may hit same problem in the future.
Thanks Jorge for the information. Seems maintaining SOAP session isn't a unique problem.
I tried now using ".*" for "includes". Also enabled message tracing. The only HTTP header it prints additionally is "Accept", which isn't useful in this case. I tried to specify "Set-Cookie" explicitly (with both camel/lower cases), but it didn't help. I played with both versions 1.1 and 2.0alpha3.
In CXF and JaxWS you can specify required behaviour simply by enable one property. Pity, SY hides this useful feature (and also the headers).
I didn't get about setting "endpoint.http", at which place/phase I need to do it?