[python-win32] Question on server architecture

[Jens B. Jorgensen]

Using a COM service exe would certainly have the advantage of getting 
rid of the process startup overhead. This can be a very convenient way 
to do things. I like the approach. I've written a system with similar 
properties that used a COM exe service that had threads doing the real 
work while COM object method calls were used to manipulate the process, 
get results, etc. In my case the system was written in c++ but the 
essence is the same and there's no reason you couldn't do it in Python I 
can think of. Anyhow the main thing you'll need to watch out for with 
this approach is the the COM SCM will want to create separate processes 
for requests coming from different users. That is, as you say you're 
using integrated authentication so the process is impersonating the 
authenticated user. When the client code goes to create an instance of 
the object (or more specifically calls CoGetClassObject) the COM SCM 
looks to see if there is already a class object registered for the one 
you're asking for. It matches on the CLSID but *also* checks to see if 
it has compatible security to the caller. If no explicity access control 
is set this means that if the user the process is running as is not the 
same as the user that is making the request this this fails. With a 
non-NT-Service COM server the SCM would just merrily create a new, 
separate process to service the request running as the same user as the 
requestor. IIRC though if it is a service it won't start a new process 
and will instead just fail. There are APIs though that you can call to 
explicitly set security access for your object and you'll probably need 
to do this.

Now, that said, there are some interesting wrinkles most of which I 
don't clearly remember the details but they are there nonetheless. When 
IIS starts a process that impersonates a user it isn't the same as a 
real process started by that user say, on the desktop. I think this 
applies to requests which go over the network but would also think this 
would apply to inter-process requests on the same machine but perhaps 
not. This stuff all gets down to the details of security delegation. In 
our case the client requests did not originate from IIS so we didn't 
really have to deal with this. I'd be happy to field any questions you 
come up with on this and I'll try to answer as best I can.

Don Dwiggins wrote:

>I have an architectural question:
>
>Background:
>I currently have a program that handles long-running requests on behalf of
>web clients.  Essentially, the flow is:
>
>1) The client (an ASP page) fires up an instance of the program, with
>   arguments to begin the request processing (which will store its results
>   in a database).
>
>2) Subsequent requests "ping" the program to determine the status of the
>   processing.
>
>3) When the return is "finished", a redirect is done to query the database
>   and format the results for the initiating user.
>
>(I've glossed over several details of the requestors, which aren't important
>here.)
>
>Currently, the whole thing is tied together by a generated token I call a
>"session ID" (nothing to do with ASP sessions).  The program, on startup,
>creates a named pipe whose name includes the ID; the ping requests "call"
>the program using the pipe.
>
>This works, but it's proving to be less than ideal for a few reasons:
>- If a few requests come in at once, the processor load spikes; it can take
>  several seconds for the program to get going.  
>- Also, the ping requests seem to have a heavier impact than I'd thought.
>- In addition to web requests, I'm using as a client a scheduled process,
>  run by the Cygwin cron daemon.  This means that the process runs under the
>  LocalSystem account, which oddly enough can't use named pipes (which must
>  have names in a UNC format, which LocalSystem doesn't have access to).
>  For this reason, I have to use a different scheduler started up under a
>  logged-in user account.
>
>Oddly enough, when I ran stress tests on this setup, it was able to handle
>many simultaneous requests.  The difference is that the stress test was
>using anonymous web clients, while in production the site uses integrated
>authentication.  I'm not sure why this should make a difference, but it
>does.  The result is long wait and execution times for the ASP requests.
>
>
>Question:
>I'm thinking of replacing the per-request process by a long-running process
>that takes requests by registering itself as a COM server.  The problem is,
>I'm not sure that this approach will work.  The idea is that the client
>would instantiate an object to make the initial request, then dismiss the
>object.  The ping requests would operate similarly.  Thus, between requests,
>the server would continue (presumably in different threads) running the
>request processes.  Can anyone give insight as to whether this can/can't
>work?  (I'll probably experiment with it, so I may have more to say if
>anyone's interested.)
>
>If you've gotten this far, thanks for your attention and any good words...
>  
>

-- 
Jens B. Jorgensen
jens.jorgensen@tallan.com

"With a focused commitment to our clients and our people, we deliver value through customized technology solutions"