soap.inproc:// ??

WSE 2.0 introduces some support for HTTP and HTTPS. It also added full support for SOAP based messaging over TCP. If you look real hard you will find an implementation of an Inproc channel to allow sending and receiving messaging SOAP messages within the same process.

When I found this, I got curious if Microsoft was sneaking in an alternatives to using remoting between AppDomains and I had to check it out. It's very easy to get a SoapSender and a SoapReceiver going as long as the two run in the same AppDomain. But it doesn't work when I move the sender into an AppDomain different from the one the receiver is running in. I am getting a NullReferenceException from the SoapSender's Send method. Now I am wondering if this is really the intent or just a bug in the WSE TP.

If that's really the intended behavior, then what interesting uses can I find to send XML messages over SOAP within the same AppDomain instead of just calling methods on objects?

  • Simpified debugging maybe? Sure
  • WS-* as aspects? Nah ... aspects should be processed by the compiler, not at runtime and a Soap messaging(!) stack.
  • Implementing inprocess intermediaries. Forwarding SOAP messages that were received over TCP or HTTP? Maybe ... I need to think about finding scenarios where this would be helpful.
  • App Server (COM+) functionality? Maybe, given that soon WS-* covers many the aspects of traditional enterprise app servers.

But what's the reason I can not communicate across AppDomains? If I can't then don't call in inproc, call it what it is: IntraAppDomain, AND give me an exception message that doesn't make me guess!

3 Comments

  • One scenario that I can think of would be a router/broker which provides one external SoapReceiver that routes messages to two or more external (http or tcp) or internal (inproc) endpoints. If the endpoint is internal there is no need to deserialize the message before passing it along. Also, using inproc instead of calling the internal soapreceiver directly would make it easy to redirect to a different endpoint later.

  • Drew,



    thanks for the thoughts. That's about what I had in mind when I said "Implementing inprocess intermediaries". It sure makes the intermediaries very efficient if you no longer have to go back onto the wire.



    The question I have not answered to myself is why I would want to route a message from an external SOAP interface to an internal SOAP interface, when both are running in the same process, even the same AppDomain.



    Is it to layer aspects on to a web service interface? Is it to modify the message before handing ot to the internal interface?



    In both cases I would argue that the cleaner, better preforming solution would be plugging filters into the WSE pipeline rather than wrapping the existing interface behind an inproc SOAP interface.



    What am I missing?



    Christoph

  • Sadly, it appears that it should have been called soap.inappdomain. Damn!

Comments have been disabled for this content.