CODEWITHSUNDEEP
c#.netweb-services
mmattax
mmattax

Reputation: 27660

Best Practices: Persisting data throughout multiple web method calls

I have a web service that has 8 web methods. These methods are called synchronously, the first call authenticates the user, and the rest of the methods perform a unit of work, these methods are called upon until the work is done.

I need to store the state of the work (e.g. what actions to perform next, and what work has been done and is currently being performed.) I currently have a state object that contains this information.

My question is what is the best way to persist this object between each web service call? Note that there may be multiple users calling this web service, each with it's own unique state.

Here are some scenarios that I am thinking:

Idea #1

Store the object in a session.

Idea #2 Create an instance variable that is a HashMap of a userId and their respective data. something like:


[WebService(Namespace = "http://developer.intuit.com/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class QBWCService : QBWebConnectorSvc {

    // instance variable to hold current session data...
    private Dictionary<Guid,Session> Sessions;

    public QBWCService () {

        Sessions = new Dictionary<Guid,Session>();
    }
    [WebMethod]
    public override string[] authenticate(string strUserName, string strPassword)
    {
        ...
        Sessions.Add(UserId, new SessoionObject());
    }
 [WebMethod]
    public override string[] authenticate(Guid UserId)
    {
        SessionObject o = Sessions[UserId];
    }
}

I am thinking that Idea 2 is going to be the cleanest "natural way", however I do not know any of the implication of implementing this sort of scheme...which way or what else would you recommend?

Upvotes: 2

Views: 1673

Answers (4)

TheSoftwareJedi
TheSoftwareJedi

Reputation: 35196

You should take a look at Windows Workflow Foundation (WF). You can design your workflow, then plug in persistence models and such.

That being said - you can't use the session! it won't scale once you create multiple web farms/servers. Surely the QBW developer API needs to scale and be fault tolerant!

Some more info about using this with ASP.NET is here.

Upvotes: 1

joshua.ewer
joshua.ewer

Reputation: 3962

This might be one of those situations where you are already too far to do a large refactor, but ...

Sounds identical to a state workflow in Windows Workflow. If your plan is eventually expose each of those methods as their own encapsulated services, it would give you all that state management for free, plus you get the added benefit of being able to visually define the workflow between these service calls.

http://msdn.microsoft.com/en-us/magazine/cc163538.aspx

[EDIT]: Shoot, Jedi beat me to it. What he said.

Upvotes: 1

Mitchel Sellers
Mitchel Sellers

Reputation: 63126

Idea one has the benefit of ASP.NET managing the sessions for you. I could see the second option becoming problematic if you have users that don't complete the full lifecycle as then you have entries in the hash table that reference old sessions. At minimum if going with #2 I would be building in a cleaning process to ensure that old sessions are expiring.

If you just need to hold current step information, I'd almost vote for session as there is no point trying to re-invent it.

Upvotes: 0

cfeduke
cfeduke

Reputation: 23226

Idea 2 is mimicking Session state management. I don't see an intrinsic benefit from performing your own session statement management.

Upvotes: 0

Related Questions