Re: [DotGNU]DGEE/CSLIB Question about webservices lifetime

[Chris Smith]

On Friday 01 Aug 2003 01:09, James Michael DuPont wrote:

> > Application state is basically what you're
> > are talking about here - effectively static 'data' that hangs about at
> > the server and visible to your application.
>
> I want to have a running process for each job. It should fork and just
> continue with a ping pong communcation with the client.
> they can send messages back and forth until the transaction is
> complete.

Okay, positives at the end :o)

You're not talking about dotgnu/.net compatible webservices as what you 
descibe here is not state based webservices.
You'll need to design and implement something above and beyond the call of 
duty to handle this..... basically you'll need to write your own server and 
have a number of short-lived webservices that contact this special server of 
yours to get results or whatever it does.

However I feel sure that you don't need a detached and seperate process 
running in the background, unless it is doing some continuous processing and 
the client doesn't want to have to wait for it to finish.
You'll have to supply some more info to the list so we can help further :o)

In fact, reading again what you're saying about having a process running for 
each job.... you will not be able to tie a single process to a single client 
and have them exchange data back and forth. Ever.  This is not how 
webservices work.  Sorry m8 :o(
To be able to engineer this, you'd have to write some routing code into your 
webservices so that when one of them gets a repeat request from a client that 
your 'application' has seen before, it is able to route that request to the 
appropriate dedicated handler process.  This is a lot of work as you're 
basically writing your own application server.

However, evey cloud has a silver lining! Norbert required a similar concept 
for the Abdabi - where a search request coming in starts a background job 
running.  The client can then poll the Abdabi to get batches of results back, 
all via webservices.  This does involve a couble of DGEE Abdabi servers and 
the use of a goldwater queue, but it works on paper and is pretty simple.
http://www.nfluid.com/images/abdabi.png
So we already have a worked example of "the way to do it" for you to draw 
inspiration from.

You can't think the simple textbook client-server model when you're trying to 
deploy code into an application server (as the DGEE is).  The functionality 
and perfomance of what you're trying to do is _very_ achievable, as the 
Abdabi has shown, but you need to re-jig the functional model in your head.

I know you'll appreciate that implementing the kind of application you're 
proposing will not be portable outside of dotgnu.

If you can provide a state/timing diagram for the sequence of events that 
you're wanting to handle in your application, that would help.

It sounds v. interesting anyway :o)

Best Regards
Chris

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