Re: Connecting Out of Process Servers via COM+
- From: "Ralph" <nt_consulting64@xxxxxxxxx>
- Date: Thu, 21 Jul 2005 14:07:01 -0500
< managled a bit to manage top posting >
> "Ralph" <nt_consulting64@xxxxxxxxx> wrote in message
> news:yaadnTT6Iu1WsULfRVn-1Q@xxxxxxxxxxxxxxx
>
> "Lance Wynn" <lance_wynn@xxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:%23u13r$WjFHA.3148@xxxxxxxxxxxxxxxxxxxxxxx
> > Hi,
> > It's been a long time since I have done anything with Out-of Process
> > servers, but I have a project that is going to require one.
> >
> > Basically, I have a Java Application that makes a connection to a Java
RMI
> > service. I have managed to create a nice little COM wrapper for it so
> that
> > I can communicate with it from VB6. However, this application can only
> have
> > on instance connected, and the process to create a connection is around
15
> > seconds. I need to load up one instance of this app, and then connect
to
> it
> > from multiple clients.
> >
> > I am thinking of creating an ActiveX.exe, that will run as a service,
and
> > then allow COM+ Components to do a getObject on it, execute the
functions,
> > and retrieve the data.
> >
> > I think that if I match the User that the service logs in under, and the
> > User that the Com+ components log in as, I can pull this off, otherwise
I
> > will need to write a Socket interface, or something else which will be
> alot
> > harder.
> >
> > Has anyone done anything similar to this, and if so can you give me some
> > pointers, or potential risks associated with this?
> >
> > Thanks
> > Lance
> >
>
> First a bit of heresy (as this is a classic vb newsgroup) - Do you know
C++?
> If so, you will be better off creating an ActiveX Server using ATL. (It
just
> runs leaner and provides more options and control.)
>
> However, you can easily create one in VB, just open 'new' and select the
> ActiveX Exe wizard. You can then use it to manage the RMI service. (Just
> curious - do you have to use RMI? Whats the database? Nevermind, non of my
> business. <g>)
>
> Using COM+ is an excellent strategy as it is directly supported by the OS,
> and will provide a well-known (documented), secure (authentication and
> authorization services), easily managed, consistent interface. It can
appear
> daunting at first, but once you learn it - it will quickly become the tool
> of choice for a host of other solutions.
>
> Roll 'ur owns are for people who like to receive calls at 3am.
>
> hth
> -ralph
>
"Lance Wynn" <lance_wynn@xxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:%23OywpIhjFHA.1464@xxxxxxxxxxxxxxxxxxxxxxx
> Hi Ralph, Thanks for the reply.
>
> My question isn't really one of how to build/use COM+, or Activex.exe My
> question is more along the lines of how they work together.
>
> I am using RMI because it is an external Company that we need to connect
to,
> and they only offer an RMI interface to their application.
>
> Unfortunately, the time it takes to connect to the RMI server (15 - 30
> Seconds) makes it so I must keep the connection open, and flow messages
from
> many different clients through the one connection.
>
> The connection is made through a Java component that I have wrapped in a
> Activex.DLL.
>
> My question then is (I guess). Is it feasible to have a single ActiveX
> out-of-process server running on the machine, and maintaining the
> connection, and then connect to that server from many COM+ Components
> running on the same machine?
>
> I think this would allow me to easily maintain the single connection, and
> manage messages to/from the individual clients.
>
> Ideally, I would like for each client to create it's own connection, pass
> the data, receive responses, and close the connection. However, the 30
> second connection time makes this method implausible.
>
> What do you think? Does a single instance ActiveX server play nicely when
> being called from multiple COM+ objects? I know COM+ is the ideal
solution,
> because of the easy of use, and security. What security issues, memory
> issues, etc.. can I expect to run into going the COM+ route versus writing
a
> service that maintains the connection, and passes messages through a
> protocol such as TCP/IP, or even MSMQ, or FileQueue?
>
First let's get some definitions straight. This will help you find articles
and books for more explanation and examples.
COM+, through one of those amazing acronym-re-use-processes that MS does so
well, is not just 'COM' as we generally think of it. [COM itself is a
specification. "OLE" is the internal MS propriatory implementation of
'COM'.]
"COM+" is an advanced COM run-time environment that provides prefabricated
solutions for distributed architectures. It is fully integrated (using OLE
implementation services) into Windows platforms starting with Win2k. Look at
it as a 'ToolKit' or an "API" for additional standard system services.
[ie, you don't have "multiple COM+ components" - you have muliple components
that use the platform's intrinsic COM+ services.]
COM+ provides the following services:
Transaction Services (MTS)
Security Services
Synchronization Services
Queued Components (Messaging)
Event Services
In-Memory Database (a bit clunky)
Load Balancing (you will likely use other services)
So you see if you write a component/client/service/exe to use COM+ you get a
lot of functionality that you don't have to write - only configure. Also
these services are implemented using algorithms that are more efficient than
anything you could write on your own.
[Sidebar: Often you can write a raw sockets process that is 'faster'.
However, it is just that a naked raw process. By the time you add security,
synchronization, logging, error handling, blah, blah - you will have
essentially re-invented the wheel. It will also be at the mercy of each new
MS security patch or platform change. COM+ will port.]
A "Connection" as you describe is expensive and represents the complexities
of opening up a channel of communication between a database and an app. As
you described it, you are dependent on using a Dll that wraps a Java RMI to
supply a connection. However, from that point on you don't have to maintain
that 'connection'. From there on down through the VB/Windows world you can
do pretty much what you want.
Imagine the following stack.
Java RMI thingy (TheThingFromAnotherWorld, aka
thingy)
<wrapper>
Your Wrapper Dll (Wrap.dll)
<COM Component>
ActiveX Server / Exe (Bob.exe)
<Interface to VB clients>
VB Client/Server Dlls (Msg.dll or Trans.dlls)
<Interface to Application>
VB Application (VBApp.exe)
You have a number of choices - here is perhaps one scenario...
Bob fires up on the server and instantiates a couple of Wraps and puts them
into a pool.
Bob waits for somebody to call.
VBApp fires up on the client machine and loads up 'Msg' to send something
interesting and safe (guaranteed delivery) to Thingy. Bob catches the
message from msg, selects a Wrap and passes the information on.
Same basic process with 'transactions' except of course how robust and how
much work you have to do depends on what the Thingy supports.
hth
-ralph
.
- Follow-Ups:
- Re: Connecting Out of Process Servers via COM+
- From: Lance Wynn
- Re: Connecting Out of Process Servers via COM+
- References:
- Connecting Out of Process Servers via COM+
- From: Lance Wynn
- Re: Connecting Out of Process Servers via COM+
- From: Ralph
- Re: Connecting Out of Process Servers via COM+
- From: Lance Wynn
- Connecting Out of Process Servers via COM+
- Prev by Date: Re: Connecting Out of Process Servers via COM+
- Next by Date: Re: Connecting Out of Process Servers via COM+
- Previous by thread: Re: Connecting Out of Process Servers via COM+
- Next by thread: Re: Connecting Out of Process Servers via COM+
- Index(es):
Relevant Pages
|
Loading