Understanding of VB and COM+ 3

[jasontektips]

Hi,

I am new to this VB and COM+ environment, but have to take over a project that uses something like this. So, firstly I would like to have a better understanding of the "story" about VB and COM+. I've a simple sample scenario here, and appreciate it if anyone could help to rectify if my understanding is wrong, or suggest better way of handling it ...

My objective is to create a simple client-server application, where the "brains" (I suppose its the DLLs)will be stored in a Server, and the "application skeleton" (I suppose its the standard EXE)in the Client.

I proceed to create the following VB projects (VB6.0) in a development PC:
1. JASON.vbp (type:ActiveX DLL)
-addition.cls (accepts 2 nums, compute and return result)
-subtraction.cls (accepts 2 nums, compute and return result)
2. CHRIS.vbp (type:ActiveX DLL)
-multiplication.cls(accepts 2 nums, compute and return result)
-division.cls(accepts 2 nums, compute and return result)
3. MathsApp (type:standard EXE, ref to JASON.dll and CHRIS.dll)
-2 text fields namely txtNum1 and txtNum2 (for input)
-4 buttons namely btnADD, btnSUBTRACT, btnMULTIPLY and btnDIVIDE (will call the functions in JASON.dll and CHRIS.dll respectively)
-1 text field name txtResult (for result)

The application works fine in my development PC, which has the "brains" and the "skeleton" together. Now, I would like to deploy this application to a client-server environment.
For Server, I guess I just need to copy the JASON.dll and CHRIS.dll and then create COM+ application in a new PC.
For Client, I guess I have to use the Visual Studio Tools to create the necessary setup files and folders(excluding the 2 dlls).

Server:
I have 1 new PC installed with Win2k Pro with SP3, and I would like to create 2 COM+ applications(the "brains&quot (I copied JASON.dll and CHRIS.dll from the development PC)
-JASONCOM (with components JASON.addition and JASON.subtraction)
-CHRISCOM (with components CHRIS.multiplication and CHRIS.division

Then, I proceed to export the 2 COM+ applications as Application Proxy, and I get 2 sets of .MSI and .CAB files

Client:
I have another new PC installed with Win2k Pro with SP3, and I would like to install the "skeleton". I copy the setup files from the development PC and run setup.exe.
I then copy the .MSI and .CAB files from the Server, and run the 2 .MSI files. I can then see 2 COM+ applications created, pointing to my Server (seeing it from the Activation tab of properties)


MY QUESTION IS .... IS THIS THE CORRECT UNDERSTANDING AND WAY OF DEPLOYING A CLIENT_SERVER APPLICATION?

Appreciate deeply if someone can guide and help me in this. Many many thanks in advance.

Jason

 

[vbkris]

what u r talking is bout DCOM, ie server is one machine while client is another machine.

did u try MSDN?

Known is handfull, Unknown is worldfull

 

[SemperFiDownUnda]

Good job Jason. Very well explained question star for you.

Yes, you are correct in your deployment. Let me rehash for you to see if you concure.

Create your ActiveX DLLs projects and applications. Once you are happy with functionality the rest is deployment

1) Create a Setup for your client application via PDW or other setup program.
2) Install the DLL's on you server. Most sites I know do this by having a Components directory on one of the drives and creating sub folders and copying the DLLs into those folders then using Component services create the packages and install the DLLs into those packages.
3) Create the application proxies by exporting the packages.
4) Run the client app setup and all the application proxy's MSI's on the client machine

Ok that is a client server app (note you can just install the client app on the server since the libraries are already registered on the server)

Now what vbkris is true. What you've described is not really COM+ but DCOM under the control of Component Services. Technically speaking COM+ is DCOM with extensions in the DLLs that take advantage of advanced features of Component Services. These services are exposed via the COM+ Services Type Library. Not any time you use COM+ you are using DCOM becuase, unless you have alot of code to allow your DLL to both use COM+ Services and to also be able to run outside of Componenet services, then DCOM is enabled. Dispite what people think DCOM does not mean your COM object have to be on another machine.

Also note that ALL COM objects automatically have DCOM functionality in them even it you don't use that functionality, ie inprocess component. DCOM on a single machine, as in the case where you might have your objects on your development box in component services, uses RPC to talk to the COM objects just like it uses RPC to talk to COM objects on another machine. The fact that a network protocol is used as transport for that RPC is not really relivant to the classification of DCOM or not. DCOM is actually at the application level of the OSI model thus doesn't infer that actual travel across the network is needed or required. It actually sits right on top of RPC. RPC can use networking but agian is just as valid on a single box system.

If you want I can get very detialed on how the client app actually talks to the DLLs if you want 8).

 

[SemperFiDownUnda]

Wooops should have proof read.....thinking faster than I can type.
"Also note that ALL COM objects automatically have DCOM functionality in them even it you don't use that functionality"

should read

"Also note that ALL VB COM objects automatically have DCOM functionality in them even it you don't use that functionality"

 

[jasontektips]

Many thanks for the notes and pointers, SemperFiDownUnda and vbkris
Guess I would really need to digest a little as I'm a new guy here(in the MS and COM world)

Anyway, I have the following queires:

1) when doing the PDW in my development PC, I can see some .VBR and .TLB files included by default. What's these files? And it seems like I do not need to install the application proxy in the client machine if I package the setup.exe including those .VBR and .TLB files. Also, I just amend the Server name for all selected files to the dedicated Server name(I guess that's the "pointing to the Server" portion)

2) When doing a dcomcnfg in both the Server and Client machine(after those installation steps I mentioned earlier on), do I expect to see any of my application items? Thot I saw it at the Client machine?? what does that mean?

3) Currently, I'm having headache in the authentication portion. You see, my project has a dedicated COM+ application with the logon component, and it makes use of LogonUser function of ADVAPI32.dll, but I'm always getting a FALSE return from the function. I've tried a valid domain user, a valid local machine(Administrator of Client) user, logon to the Client OS as a domain user before running my application, logon to the Client machine OS as a local machine Administrator before running my application, but all have the same outcome i.e. unsuccessful logon due to LogonUser returning FALSE. I guess that has something to do with the Security tab of the COM+ application but not too sure. Finally, I tried to install the client portion(the "application skeleton&quot to the Server machine, thinking that it should work cos its like my development environment when both the "skeleton" and "brains" are together, but disappointingly it is still receiving the same result.

Appreciate your pointers again
Many Thanks...
Jason

 

[SemperFiDownUnda]

1).TLB is the Type Library file. This is embeded in the DLL also. As you pointed out with it your client can use objects even if the DLL is not on the machine if you point your code at the correct server. But most of the time this means that the server is probably hard coded. This also means you have to use the CreateObject syntax (Can't use NEW). I'm more comfortable with the use of application proxies but the TLB have their place for certian situations.

For example if you use an application proxy then when ever any client app requests an instance of a class in that application then it will be created on the server that the package live in. If you register the .TBL and use CreateObject then you can have you programs distribute the instances if you wanted to. But most cases there are better ways of doing this.

.VBR is for remote OLE. Its fairly comlicated to get it to work compaired using Component Services and I haven't done it since VB4 or 5.

2) Ok so your making your server a ActiveX.EXE? Is there a reason you are doing this over making your library a ActiveX.DLL and installing it under component services?

After installing, or even just running the ActiveX.EXE if it is completely self contained (ActiveX EXEs are self registering meaning when you run them if the componenents contained within are not in the registry they will be added) you should see some of your classes show up in dcomcnfg. Remember it will be in there by the full ProgID (Library.Class)

3) If you are working in a domain environment and want a security component I HIGHLY recommend using COM+. Let me explain.

One of the services provided by the ObjectContext (think of this as a components guardian angle) is the Security property which holds 4 properties which you can access via code like this

    GetObjectContext.Security.GetDirectCallerName
    GetObjectContext.Security.GetDirectCreatorName
    GetObjectContext.Security.GetOriginalCallerName
    GetObjectContext.Security.GetOriginalCreatorName

Now you might think "STOP! 4 differenent accounts?"
In simple configurations where Program A creates Object B all these will be the same. They will be the logged in user that Program A is running under. Where they start to differ is when your application has many levels and Objects are created in different clients
this could be your EXE or another library as in the case of

Program A creates Object B (in Library X).
Object B creates Object C (in Library Y).

Program A is run by MyDomain\JoeBloggs
Library X is in component services and set to run as MyDomain\AcctCom
Library Y is in component services (in a different package)and set to run as MyDomain\HRCom

Object C can tell that MyDomain\JoeBloggs is the Original Creater/Caller but MyDomain\AcctCom is the direct Creater/Caller.


I'm not sure about the API as i've not used in in a DCOM situation. It could be the fact that your server does not actually log in. Thus the login user is not valid. Server just runs under a given security context. Also not that it wouldn't provide you what you need. You want
MyDomain\JoeBloggs not MyDomain\AcctCom

Also Component services provides a great security model much like SQL Server where you can apply security to components down to the function level via roles. You don't have to add individual users to a role but instead you can use NT Groups. Which means if JoeBloggs is a new employee and Library X is set up so MyDomain\AcctGroup can use it then JoeBloggs gets to use it when his account is set up and he's added to the MyDomain\AcctGroup which he'll probably need for stuff like network drives. All you have to do is code your client app to handle the error that comes back when a unauthorised user tries to run your app.

I have programs that are shared between multiple departments in a organisation and COM is used. Menu items are enabled and disabled just by the app trying to use them. So the program starts up and the app goes out and touches each front line component and based on success or failure menus are made not visible or disabled.

 

[tbrick18]

Hi there,

I have an addition to this question,
I am trying to deploy a COM+ component using an application proxy. When I create the package, add the component, export it and install on my client machine, the actual dll is installed to the ComPlus Applications folder.
I do not want this.

I have read somewhere that when building the dll in VB6 you can set VB to create a TLB file for the component, and then when adding the component to Component Services, also add the TLB file. My understanding of this is that when the export has been done and installed on a client machine, only the TLB file will be installed to the ComPlus Applications folder.

However, when I drag the component and the TLB files into the package, (only the DLL is visible in Component Services when I do this) and try to export it I get an error saying that I cannot create a file in the location I am pointing it at. I have tried new folders and locations but still get the same error.

I am an administrator on the machine I am using.

Will exporting the TLB file do what I expect it to do, and if so why can I not export it?

Any help will be greatly appreciated.

Thanks.

 

[SemperFiDownUnda]

"the actual dll is installed to the ComPlus Applications folder.
I do not want this."
Is there a reason you don't want this?

The TLB is just a type library describing the interface. This is embedded in the DLL. That is all the DLL is used for. The MSI takes care of pointing the instance at the server via the registry.

The only real advantage of using a TLB over the DLL is a diskspace issue. To me not work all the hacking and slashing you need to get it to work most of the time.

I haven't worked with some of this stuff for ..... pffft ..... 4 years now.