I would argue that it wasn't safe in 1.x. Using session relies upon cookies,
which replies upon HTTP. WebServices were originally meant to be protocol
agnostic. If your design replies upon cookies, then it would fail when used
over TCP, MSMQ, FTP, SMTP or any other non-HTTP protocol. It was a horrible
design flaw by Microsoft to allow that attribute in the first place.
Also, if you're going for interop (which is what web services are all about)
then this is a broken design, since WSDL doesn't make any mention of cookies.
That's an out of band agreement between the client and server to utilize
cookies, which falls outside the scope of the web services spec. Thus falls
outside of the intended goal of interoperability.
If you want operations on your web service to have coorelation, then build
it into your contract:
[WebMethod]
string PlaceOrder(...); // returns an OrderID (string, int, GUID, whatever
unquie ID)
[WebMethod]
Status GetOrderStats(string OrderID);
[WebMethod]
bool CancelOrder(string OrderID);
The coorelation has now been built into the contract via the OrderID and
1) doesn't reply upon out of band info like cookies, and 2) can work over
any protocol.
I know this is probabaly completely counter to your current design. Sorry
about that. Shame on Microsoft.
-Brock
DevelopMentor
http://staff.develop.com/ballen
> For the life of me I can't find anything online to backup what I
> thought I read a few months back regarding session access from web
[quoted text clipped - 33 lines]
> Thanks!
> -Mike
MikeM - 31 Mar 2005 13:33 GMT
Brock,
Thanks for the response and I agree. It is not really a big deal. We've
got ways to work around it. It was just handy to use before, but I guess
just because something is handy or easy, doesn't mean it is wise!
Thanks again.
-Mike
> I would argue that it wasn't safe in 1.x. Using session relies upon cookies,
> which replies upon HTTP. WebServices were originally meant to be protocol
[quoted text clipped - 29 lines]
> DevelopMentor
> http://staff.develop.com/ballen