Re: Connecting Out of Process Servers via COM+

Unfortunately, this project was dropped in my lap at the last minute, and I
don't have a lot of time to get it out. (We're talking several weeks.)

I have 90% of it done (or it was already 90% done with our existing system),
I am using a number of COM+ registered components, and Transaction aware
components to handle our internal business logic, and workflow, it's just
this last connection to the external company's RMI app that is the weak
link. The fact that the java app is limited to only allowing one
connection, and in fact we can only use one connection because of the way
they are handling logins means that all internal clients have to share that
one connection.

Definitely not ideal, and certainly not the way I would choose to do it, but
unfortunately that's the way it is. I wrote some stuff similar to this
years ago when I needed a number of clients to share a single serial
connection into a phone switch, and it worked fine, but I used TCP/IP and a
custom broker to manage the connections. hopefully I'll get this to work
with a singleton server, and COM so I don't need to reinvent the wheel. (Of
course the singleton design is foreign to me, so we'll see how it goes!)

Thanks for all your help! It is much appreciated!

Lance




"Ralph" <nt_consulting64@xxxxxxxxx> wrote in message
news:C8adnVjYh-s1033fRVn-rg@xxxxxxxxxxxxxxx

"Lance Wynn" <lance_wynn@xxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:eZobDukjFHA.3144@xxxxxxxxxxxxxxxxxxxxxxx
> This is what I was thinking of doing.
>
> Have you ever done anything like this before, and if so did it work well,
> did you get any difficult to track errors? I have never tried using a
> singleton server in this way, and so I am unaware of the many pitfalls
that
> could arise out of implementing it like this.
>
>

Yes, quite often. Every situation is different.

As you no doubt know - COM+ transcends just one language development
environment. Although VB has some unique builit-in properties to make it
easier to provide the working elements, COM+ itself is a different world,
its own quirks, its own rules, and don't take shortcuts.

The only real pitfall that might await you - is if you piss off your admin.
Then it can get ugly. Buy him beer, or her flowers, but get to know them,
keep them on your side.

<g>
-ralph

>
> "Schmidt" <sss@xxxxxxxxx> wrote in message
> news:OLKVp%23jjFHA.1148@xxxxxxxxxxxxxxxxxxxxxxx
>
> "Lance Wynn" <lance_wynn@xxxxxxxxxxxxxxxxxxxxxxx> schrieb im Newsbeitrag
> news:eW0UczijFHA.2152@xxxxxxxxxxxxxxxxxxxxxxx
>
> > Is there a setting where I can have COM+ instantiate only one instance
> > of the object (In this case, my connection wrapper) and allow client
> > applications to "share" this one instance of the COM+ object?
> I wouldn't try to find a setting for COM+ itself, to restrict the PoolSize
> of a specific COM+-object to 1.
> I would allow your clients, to access a "normal" configured COM+ Object
> (name it ComPlusRMIWrap).
> This ComPlusRMIWrap-Object (if requested) then accesses the
> RunningObjectsTable (ROT) on the serverside per GetObject(,
> "COMRMI.cServerDispatcher"), to get a (marshaled) Reference to your own
> ServerApplication (running as a sessionwide Singleton-Object on the
> COM+-Host).
> If you want to implement such a "Singleton-Server" in VB, you can use a
> Standard-Exe, that loads your RMI-DLL-Instance once, makes the connect to
> the Java-Environment and registers this Object in the ROT.
> Another (better, but more complicated) approach is, not to use a
> VB-Standard-Exe, but an ActiveX-Exe instead.
> With an ActiveX-Exe you can write a Server-Application, that can create
more
> than one instance of your RMI-Connection-Wrapper on different threads. If
> the AX-Exe starts, it would create a Dispatcher-Object first and registers
> that in the ROT (cServerDispatcher). This Dispatcher-Object is the
> Singleton-Object, that the COM+Objects can reference per GetObject. Inside
> the Dispatcher is a Thread-Pool-Collection (created at Startup) of (for
> example 10) RMIWrapper-Objects (cRMIWrapper). Those Wrappers are the
> (threaded) COM-Objects, wich create and hold a separate RMI-Connection
(from
> your Dll) inside.
>
> > If this is possible, how would I instantiate the teh object at the
client?
> > GetObject? CreateObject? When one client sent a command, it would
> > have to wait until the command had finished completely before
> > allowing the next client's command through.
>
> If two Clients at the same time are requesting the COM+-Server, the
requests
> are processed in parallel up to the point, where the Interface of the
> ROT-Singleton (the Proxy) is used. Interface-Calls of a marshaled
ROT-Object
> are queued automatically (the call, wich is a moment later will be blocked
> until the first request against the interface of the ROT-Singleton is
> finished).
> This means, altough COM+ would allow parallel requests, the calls would be
> serialized regarding the internal ROT-Object-Requests.
> In case of the VB-Standard-Exe, wich could place your RMIWrapper-Object
> directly in the ROT, your Clients would block each other during parallel
> RMI-Calls against the same ROT-Instance (I don't write a Code-Example for
> the COM+WrapperClasses - that case would be easy)
>
> In Case of the VB-AxtiveX-Exe, the ROT-Object is not the RMIWrapper
itself,
> it's a Dispatcher-Object, wich allows 'ThreadpoolCollection.Count'
parallel
> and async requests.
> Your COM+ Objects would then have some Code like this (Aircode, no
> error+timeout handling):
>
> Private RMIDispatcher as COMRMI.cServerDispatcher
>
> Public Function DoRMIRequest(Params)
> Set RMIDispatcher = GetObject(, "COMRMI.cServerDispatcher")
>
> 'The Dispatcher takes the Params, chooses a free RMI-Pool-Object
> internally
> 'and creates an EventObject, calls the PoolObject async and returns
> immediately
> hEvt = RMIDispatcher.GetFreePoolObjectAndCallAsyncWith(Params)
>
> 'The Dispatcher will raise a SystemWide-Event, if the threaded
RMI-Pool
> '-Object has finished the request and informed the ROT-Dispatcher
> WaitForSingleObject hEvt, TimeOut
> DoRMIRequest = RMIDispatcher.GetResult(hEvt)
> End Function
>
> Olaf
>
>
>



.

Relevant Pages

  • Re: Context Switches, Web Gardens and InProc Session State
    ... serialized and therefore we cannot use StateServer for the Session mode. ... the requests are routed back to the same worker process." ... Are your clients connecting via a proxy or firewall, ... That said its not possible to guarantee a fixed connection. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: The "Reconnect" Problem
    ... requests over the same connection. ... processes a queue of pending requests to be sent. ... Clients that want to send messages put them into a queue. ...
    (comp.programming.threads)
  • Re: Network desintegrating(?)
    ... 15 clients XP Pro SP2 ... I made a reservation for Noodserv in DHCP. ... I know PDC and BDC are NT 4 terms, TELSERV is the SBS box, NOODSERV ... Ethernet adapter Local Area Connection: ...
    (microsoft.public.windows.server.sbs)
  • Re: output.c error in multithreaded program
    ... >>I find an access violation windows message and start the JIT debugger to ... > thread will block until the Sleep() expires, ... >>it a good enough approach to handle repeated requests. ... connection. ...
    (microsoft.public.vc.mfc)
  • Re: Connect to Small Business Server VPN
    ... Here is the results of an ipconfig /all from one of my clients: ... Ethernet adapter Internet Connection: ... "Cris Hanna " ... Actually the subnet is correct on a VPN ...
    (microsoft.public.windows.server.sbs)