Caveat Lector: The code that I mention, though it compiles, hasn't even been executed, and certainly hasn't been tested.
Steve Maine has a number of good posts on WSE 2.0, including a couple of detailed entries on his attempts to write a transport-independent, next-hop routing intermediary. His first article highlighted several interesting problems:
Routing Roadblock #1: What endpoint is my router listening on, exactly?
The answer involves WSAddressing.AnyRoleRouting Roadblock #2: “This envelope’s already been processed!”
He basically does a clone of the envelope. I am thinking about a different solution from his, because I would like to avoid the memory and service time hit. I skirt the issue on the inbound side by setting the Pipeline.IsIntermediary to true.Routing Roadblock #3: What to do about MessageId?
WSE is pretty picky about the messageIds. His cloning approach works, as I am hopeful mine does as well.The second article digs into the replyTo processing issues. I also have an interest in this, though it is not addressed below. I am thinking that you could dyamically modify the ReferralCache and use ReferralCache.Query(...), but that runs into scalability problems that might require wrapping the referral cache in a service interface. Then you would have to deal with clustering/federating the referral services, which would be a really fun problem to solve, but certainly non-trivial. Graham Glass could probably hack it up in Glue in no time, though. And it would be really quite compact!
I removed the code, because it just looked like crapola. I will include a link.
-------------------------------------------------------------
My [hopeful] code follows. The formatting got a bit screwy, so please forgive the k&r if it isn't your preference. It is not mine either. My approach is to avoid the clone, munge the original soap envelope and mess with the transports and channels directly, bypassing the soap sender side of things.
Comments