Ed,
I would say that I was reasonably close, and THANKS for the clarifications!

Note, though, that the discussion revolves around VFP, so the fact that a C++ OUT-PROCESS server *can* handle multiple simultaneous clients is *NOT* material to this discussion. In fact, it is the general clouding of this very issue by many many writers that prompted me to say what I originally did - to "warn" anybody who may care that when people talk of being able to do most whatever one wants, that certainly is *NOT* the case for VFP despite what they may read.

I still believe this to be correct and the more germane aspect of the general discussion.

Cheers,

Jim N

>>Marc,
>>
>>I presume that this is really aimed at Jim B, but in case not, here is my attempt to answer you (the blind leading the blind). . .
>>
>>OUT PROCESS is the case where a VFP server (in our discussions) runs on a separate and distinct machine from the clients. The registry is used for the client to successfully "find" the Server program.
>>IN PROCESS is the case where a VFP server runs as a DLL on the same machine as its client. So for each client there is also a IN-PROCESS server (when that is the implementation of choice).
>
>Not quite right. There are three states to consider, two of which run on the local system, and one on a remoted resource. A vast oversimplification follows:
>
>In-process refers to a server running in the application's address space. Advantages are primarily speed and security; the data structures remain within the application's address space, and are passed about as simple memory references. The data is more secure because unless steps are taken to specifically share a process' memory space, it is not accessible to other processes except those that are running at a more 'trusted' process level (like OS services.)
>
>Disadvantages are that an in-process server is instanced at least once per caller, and if ill-behaved, can kill the client process quite easily - a system fault from within the in-process server will kill the current process.
>
>Out-of-process refers to servers that run outside the process address space, in another process address space on the same machine (ie as a distinct and different process that can exist independently of the current process, and can instantiate an have a longer life (started before the client or living on after the client terminates) than the current process) or as a separate process on a different machine (across a network). Out-of-process servers have higher communications overhead than in-process servers, have somewhat higher security risk since the data is more visible (shared segment of memory on the local machine, and a commincations link to a remote machine) and don't have the option of interacting with the internals of the client - the COM interface is what you get to play with.
>
>An out-of-process server can, if constructed to do so, process requests from more than one client. An out-of-process server may be limited to servicing a single client instance, and this is often desirable when the relationship between client and server is stateful, requiring that the server context in relation to client requests be maintained.
>
>Death of the server process does not automatically cause the client to die an ugly, unexpected and unrecoverable death.
>
>>There is very little difference between the two from a coding point of view - just a option or two when BUILDING the server.
>>
>>IN PROCESS, though, gives you significantly more "scope" as to what problems you can handle (which of course *does* become a coding issue) because you can use features and facilites which are innate to that single machine where it is running (like Copy/Paste, as a simple example).
>>
>
>COM relies on the COM interface to maintain portability and scalability of the process. If you rely on things other than the COM interface of the server to communicate between client and server, you lose the primary advantage of COM; flexibility of deployment. The interface should remain the same whether the COM object deploys in-process, out-of-process locally, or out-of-process on a remote machine.
>
>>Additionally, an OUT-PROCESS server could be hit by many clients simultaneously BUT it can handle only one at a time, and must fully complete it before handling the next. An IN-PROCESS server, of course, would not have this problem since it serves only one client.
>>
>
>That depends on a synchronous sequence of execution, where the client doesn't continue its work until the server completes the requested task. It is possible to construct COM objects (not VFP COM objects AFAIK, but certainly in C++) that accept a request and return control to the client immediately, relying on a callback or client polling to determine the completion state of the request. Asynchronous, non-blocking COM objects make things like job servers possible, where the client needs to request that something gets done, but can continue along without that service request having finished execution.
>
>>Regarding your question about sata-awareness for Browsers. . . I know too little for sure on this, but I would think it *has* to happen. Indeed, I harbour the hope that VFP6. new functionality regarding Browser support *is* a good beginning of this. But, not having VFP 6 to play with, I don't know.
>>
>>Middle tier is still a good design objective, especially as applied in an OUT-PROCESSOR situation. I guess its roughly the same for IN-PROCESSOR, but with much more to administer/replace on upgrade.
>>
>>I would consider consolidating 2nd/3rd tier before consolidating 1st/2nd if faced with that decision.
>>
>>I truly hope that this is helpful, and not too bunk-ridden.
>>
>>Cheers,
>>
>>Jim N
>>>Jim,
>>>
>>>At risk of sounding perfectly ignorant, would you explain to me what is meant by OUT PROCESS?
>>>
>>>And if Browsers _are_ going to be the front end, which even to me sounds very probable, will there be some kind of a data awareness built in them in your view?
>>>
>>>And if so, what would be the use of a middle tier? Business rules would be enforced at the (O)DBMS level. Or are we to look at VFP as a ODBMS?
>>>
>>>Just wondering.
>>>
>>>Thanks.
>>>
>>>Marc
>>>
>>>
>>>
>>>>OK Bob, I went back and re-read the thread.
>>>>
>>>>No, I don't see what my problem is. . . what I was doing was offering my understanding that VFP as a middle tier can really only be deployed as an IN-PROCESS server becuase of constraints of the language as it is now endowed.
>>>>
>>>>I do not see where DCOM is automatically IMPLIED by any of the discussion, and my purpose was to ensure that *IF* anyone was thinking OUT-PROCESS, maybe they should think again. Though I was also deferring to Jim B to correct this if it was wrong.
>>>>
>>>>Cheers,
>>>>
>>>>Jim N
>>>>>>I don't know, Bob. . . who said anything about remote COM (DCOM)???
>>>>>>
>>>>>>Cheers,
>>>>>>
>>>>>>Jim N
>>>>>
>>>>>Well, if you go back and read this thread, multi-tier and middle tier were being discussed.
>>>>>
>>>>>That usually, but not always, assumes that the middle tier will be on a high powered server that many front ends talk to, hence DCOM.
>>>>>
>>>>>That's why I asked that question.
>>>>>
>>>>>BOb