[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]Message passing between webservices

From: Chris Smith
Subject: Re: [DotGNU]Message passing between webservices
Date: Thu, 16 Jan 2003 11:58:04 +0000

On Wednesday 15 January 2003 12:41, Peter Minten wrote:

> Remember the service level plan? You don't want to send a new session
> reference every time if you can suffice with one session key. That won't be
> much of a problem with DGEE I guess and is much more consistent.

Here are some findings:
.net provides the api's to leave this up to the webservice author.  However 
they discourage sharing of a session between wbeservices as it makes the 
design of one webservice reliant on another.  Actually I do this all the time 
with webservices in a 'set'.  MS's point is that without being properly 
managed incompatibilities can arrise.

But the api is there for you to use (Big mistake if MS hadn't!)

Everything in .net is done through a 'proxy' (which is just a class that does 
the parameters->SOAP->HTTP->webservice .. and back again .. stuff for you) a 
bad coice of name in a web arena if you ask me :o)
Anyway, it's the proxy that handles the session ticket, though I think you 
can get at it.  One proxy can only have one 'session'.

There are some problems with .net though:
1. session tickets can only be sent and received via COOKIES, and thus you 
can only do a stateful design if you're using HTTP.
2. Web services cannot have state - I think they're talking about 'methods' 
here, and now I come to put it in an email I'm confusing myself.  Will go an 
reread that stuff later.
3. If you want to use INPROC state retention (ie not in a db) then you have 
to use keep-alive connections - again just HTTP! .  You can't use keep-alive 
to get round having to use a cookie either, because you may have several 
'proxies' each with it's own state at the server.

MS have identified all the problems and suggest a preferred approach, which 
is good. Generally they suggest not using state at all.  However, a lot of 
the problems stem from their base architecture (and I'm not having a dig 
here) IIS and all that - they'll find it very difficult to support things 
like Jabber.

Chris (your roving .net webservices reporter, on location with a book)

Chris Smith
  Technical Architect - netFluid Technology Ltd.
  "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
  E: address@hidden  W:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]