asp, dcom and mts 2

[sweetleaf]

Hi,

Wasn't sure which forum to post this in b/c of scope.
Currently at my work iis and all the activex dll's reside on the same machine(while the database sits in a seperate unix server).
We will get a seperate application server to house the activex dll's - we want to put MTS on this machin. So, there will soon be 3 physical tiers.
Once split how would an active server page (sitting on iis)call a method of an object on a remote machine(on the application server) - lets say the method returns a recordset - and how would the active server page recieve the returned recordset?
Are interfaces, stubs, proxies etc a must in this scenario or does the programmer merely have to hardcode the name of the application server into the createObject() syntax of the calling active server page? Does the dll have to be recompiled in a special way?
What sort of network issues does the programmer need to work on with the network administrators?

any help would be greatly appreciated
thanks

 

[htin11]

Hi,

I am not sure if i am right, but from what i can see is that you will also need to create a dcom object on the same server, so the dcom object can talk to another dcom object where is the application server.

That means 1 server will house the ASP pages + DCOm that just passes information tot he application server. Another server will be the application server which will house another type of dcom that speaks to this end. And the last one i guess is the database server..that way you have a 3 tier application.

I hope that helps,
Hui Emagine Solutions, Inc.

http://www.emagine-solutions.com

 

[sweetleaf]

thanks Hui,

Does "Dcom object" just refer to an activex dll compiled in a certain way? If so what kind of coding goes inside these dll's?
So, the web server needs a dcom object to "talk" to the dcom object on the application server?
Does this mean that everytime an asp on the web server calls a class on the app server its doing it through the Dcom object on the web server? ie. does createObject on the asp call the remote object directly or does it call the Dcom object on the web server which in turn calls the Dcom object on the application server?
Sorry if this doesn't make sense..

 

[JJR]

Hi,

Dcom just means distibuted com, so what it really says is that your dll's don't reside on your machine, but on another machine. The only thing you have to do to get it to work is to register the dll's on the IIS machine.

Just run regsvr32 on the iis machine and point to the components on the other machine. So when you call createobject in your asp IIS will use the components on the other machine, no extra programming needed.

Make sure you haven't registered your dll's while they were physically on your IIS server, because then you can't be sure that when you call createobject IIS uses the components on the IIS machine or on the other machine due to the concept of late binding.

Hope it helps.

Jordi Reineman

 

[sweetleaf]

Thank You Jordi,

That was very helpful. Can you please explain this one portion to me again: 'Just run regsvr32 on the iis machine and point to the components on the other machine'.

Does this mean that the components are to reside physically on the app server but are to be registered on the web server? Sorry if i totally make no sense. If so, how do you register components residing on one machine into the registry of another machine?

thanks

 

[dilettante]

I figured this was an easy one, and then I had to crack some books (er, my MSDN Library CDs). Regsvr32.exe is used to register locally installed COM objects, not remote DCOM servers. See:

-- Q249873 - Explanation of Regsvr32 Usage and Error Messages

So.

The details may vary based upon the development language of the DCOM objects you want access to, and I haven't gone into the MTS ramifications (if any) yet.

I started with KB article:

-- Q266717 - HOWTO: Create a DCOM Client/Server Application by Using Visual Basic

This tells you how to make a simple DCOM server and a DCOM client to call it in VB. My problem is to call the dumb thing WITHOUT using a VB client. We want to use VBScript (as in an ASP page or a WSH .VBS file). If I were to create the VB client and install it I'd get things set up for an ASP page as a side-effect, but you probably only have the SERVER OBJECTS to work with, not VB clients for them.

Let's say you have a simple VB ActiveX EXE server on your remote box though, one that returns the local time as the result of its single method call "ServerTime()". This is exactly what was done in the first parts of Q266717. When the DCOM server gets created, you end up with a .VBR and a .TLB file that must be used to register it on your client machine (your IIS box).

So if I install DCOMDemo_Svr at "Mutley" and want to call it from my VBScript on another box "OldYeller" I need to copy four files to OldYeller to set it up:

Clireg32.exe in winnt or someplace (from VStudio CD)
AutPrx32.dll in System or System32 (from VStudio)
DCOMDemo_Svr.VBR (created by VB)
DCOMDemo_Svr.TLB (created by VB)

I run "Clireg32 DCOMDemo_Svr.VBR" which links to AutPrx32.dll but doesn't use it here (but it must be installed in System or System32). Clireg32 finds the .TLB and pops up a dialog in which I select that I'm using DCOM and then I enter the name or IP of my server host (Mutley). Easy!

To test it I used a teeny VBScript on OldYeller, junk.vbs:

dim ob

Set ob = WScript.CreateObject("DCOMDemo_Svr.DemoClass")
MsgBox ob.ServerTime
Set ob = Nothing

Works like a champ!

See KB articles:

-- Q198038 - INFO: Useful Tools for Package and Deployment Issues

Scroll down to the part on how to use Clireg32.exe

-- Q194636 - HOWTO: Manually Register a VB Remote Component Using CLIREG32

Details on use of Clireg32.exe, like specifying everything on the command line and bypassing the dialog box referred to in Q198038.

I sincerely hope this helps, or gets you on the right track. Remember, your server objects have to get registered on your client (IIS) box before you can use them, which means you need deployment files from the developer (the .VBR and .TLB or equivalent).