(B----- Original Message -----
(BFrom: "David Peterson" <[EMAIL PROTECTED]>
(BTo: <[EMAIL PROTECTED]>
(BSent: Wednesday, January 15, 2003 12:48
(BSubject: Re: Stateful Web Services
(B
(B
(B>
(B> Hi Steve,
(B>
(B> But in the simplest possible case, where I just want to persist data
(B> between *invocations* (i.e. separate calls), do I still need session
(B> info to be propogated client side?
(B>
(B> e.g.
(B>
(B> Call 1: deposit(100);
(B> Call 2: deposit(200);
(B> Call 3: getBalance() -> 300
(B> Call 4: withdrawl(50);
(B> Call 5: getBalance() -> 250
(B>
(B> Where Call 1 - Call 5 are 5 separate invocations (maybe from the same
(B> client, but maybe not).
(B
(Bthink about this for a moment. How are you going to specify bank account and
(Bauth info? If it goes with every request, then you could be stateless.
(BOtherwise the caller needs to first 'bind' to an account, then make requests
(Bon it. We call that 'state', no matter how it is actually implemented.
(B
(BNb, this example is a bit dangerous as http is inherently unreliable, you
(Bneed to make the calls idempotent. Otherwise, how do you know when a deposit
(Bfailed, where
(B
(Bone way to do this in soap would be
(B
(B* a required SoapHeader that contains authentication info, whatever that may
(Bbe
(B
(B* all requests include
(B -a requestID, that is some guid to distinguish requests (if we have a logon
(Bcall then it could be a sequence number since logon)
(B -account info
(B
(B* the getbalance call includes not just the balance, but the time that
(Bbalance was valid. I'd use xsd:long containg time_t in GMT, for that, as
(Bxsd:dateTime always causes problems for me wrt timezones.
(B
(B* you also need the from/to details for all withdrawals and deposits; 'cash'
(Bprobably needs to include location details like ATM#242.
(B
(BSplitting auth info from account info allows for logins with >1 account, and
(Bfor admin 'bank teller' accounts that have broader rights. The requestID can
(Bbe used to discard repeated requests.
