> -----Original Message----- > From: ANDREW MICONE [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 23, 2004 5:43 PM > To: [EMAIL PROTECTED] > Subject: RE: Web Service with state > > Many web services also use some kind of transaction id passed > around at the application layer on each invocation of the web > service to maintain state. Some consider that a best pratice > because it will continue to work as web standards evolve and > change. -- Andy
Agree! :-) Some web services (I have to implement such one) have to maintain kind of a hierarchy of objects - with a lifetime (where timer/timeout stuff comes into play and all). For example, I have to provide my web service clients with "databases" and "applications from databases". The thing is, I cannot hand over ANY database/application to a given client, but only database/application the client really has requested with his login account information. I cannot just open the database under the hood with an internal login account and serve all clients with just a database from a pool and all. So, for this stuff I use what you called "transaction id". In fact, when I had my first look at SOAP and web service technologies at all, I was really really wondering that such "object mapping" mechanisms were not (and are not) well defined by the (SOAP, WSDL) standards itself! I mean, something you can trust like HTTPSession in the servlet/JSP world. It's a mechanism which is well defined and I think (at leat I hope) that there are rules defined to prevent someone from faking the session ids (in most implementations, this is HTTP cookie stuff, AFAIK). I think a lot of people who have to implement web services will invent their own "transaction id" stuff again and again, have to think about how to make this id stuff secure and have to implement timers to forget the ids (the real objects behind the ids) ... :-) cu Merten
