views:

180

answers:

1

I am to design a webservice using WCF that yields methods that don't require a session (like static calls, eg: giving back some information about the webservice itsself) and other methods that require a session.

furthermore, the session based methods are using Workflows that are supposed to be able to be changed at runtime.

my current design would look like this:

there is a singleton service that runs in IIS that handles all the per call methods which also works as a host for the session based services. that way the singleton class knows about all the sessions and can halt the running workflows to exchange them.

is this a good/possible design choice?
is this a common scenario that uses a common design?
would be happy about any reading hints as the msdn help wasn't such a help to me.

thanks for your answers
-redoced

+1  A: 

Using a singleton WCF service class is almost never a good idea - unless you really have just one single (physical) resource which you want to protect from concurrent access, it doesn't really make sense.

Because: either it's not multi-threading capable, but in this case, it becomes a huge bottleneck - requests are handled strictly sequentially - one after another. Not very good for performance.

Or then you need to make the whole service multi-threading aware - and let me tell you, making this properly, safely, and efficiently isn't for the faint of heart. It's really really hard to get this right, and make it perform well.

I really don't see any need for this, at all.

  • leave you "static" message calls (as you call them) be per-call services - those are easy to program, work well, perform well, never cause any multithreading issues

  • those few service calls (hopefully!) that do require a session - put them on their own service endpoint(s), make them per-session, use the "SessionId" in your session to identify them. It's a bit more work than per-call - but still nowhere near as complicated and error-prone as multi-threaded programming

Resources for WCF sessions:

Resources for WCF durable services (that persist their state between calls):

Resources for WCF Workflow Services:

marc_s
i probably don't know enough yet about Workflows but i don't see how i could possibly bring the running workflows in the sessions to a halt and exchange these workflows, that is what bugs me(thanks for the links, will be reading them)
redoced
@redoced: you need to have a look at WCF Workflow services - added a few more links. This area will improve significantly in .NET 4
marc_s
thanks again for your links. i think i now have a deeper insight and decided to refrain from using sessions (or durable services) at all as the the data that would need to persist in the session is small enough to get transferred in a response/new call. the links to Workflow services are very neat - will be looking into this further
redoced

related questions