views:

22

answers:

0

Hi all. I'm currently experimenting with Durable WCF components which persist themselves in between method calls. This uses the [DurableService] attribute. This allows me to add some state to a component, close my connection to the client, perhaps wait for a while, create an entirely new client, hook back to the previous component and get at its state. This is working for me pretty well right now.

The catch is that I want to share the Durable component's state across the boundaries of my application. In order to reconstitute a Durable component's state, you must have a token representing it in its persistent storage (in my cause the default sql server).

So, when I first use this component up in my asp.net app, I can stick the context token into session and reconstitute the component any time I want.

What's the best way to get at the component's state when I go down into my Business Service layer, which is mostly other WCF components? What should I do with that context token?

It seems really cheesy to muck up my interfaces just to pass this token (essentially a guid) around. Besides the persistence database (which is completely automated and abstracted away from me), my app really only relies on other web services (which I don't control) for data storage. i.e. if I persist the token to a database table, there'd be a database just for persisting the token - also lame.

What would you do in this case? Is this a job for Windows WorkFlow? I don't really know much about it, and maybe it does exactly this.

Any help greatly appreciated!