DCOM is Microsoft’s competition to CORBA and other object development infrastructures. The goals of it are to achieve interoperability, the ability to plug in components at the binary level, and the ability to write components in any programming language and make all these components work together. A lot of things in Windows are now based on COM, with windows 2000 COM is everywhere, all the administrative panels seem to be COM objects, IE is all COM. DCOM is very abstract so here are the basic building blocks of DCOM that an SE needs to know to record/replay with LR:
COM component A DLL or EXE (or OCX) that contains COM objects. This can be a client application, client dll or any kind of server side program. It can be anything, it’s basically a house for COM objects.
COM object “Runtime instance of a COM class”, it’s basically a black box piece of code that provides some functionality, you put something in, something else that you want comes out. These objects are implemented as DLLs. Objects can be developed in any language that supports COM (C, VB, Java, etc…). COM objects have well defined interfaces that are separate from the implementation of whatever it is the code does. Anything that connects to a COM object does so through the interface which should never change once the object is deployed. The code inside the object that implements what the object does can change, even the language it’s written in can change as long as the interfaces behavior doesn’t change. Those very long numbers in curly brackets you see sometimes( {324234-324fb23db-3243254985-45893843}) are object and interface identifiers (IID or GUID). These numbers are supposedly unique for every object and interface ever created, it’s an encrypted number made out of the object name, system time, NIC address and some other things. Objects can be upgraded, modified, swapped in and out of the system without breaking the overall system as long as the interfaces it shows the outside world remain with constant behavior. This is what Microsoft means by binary swapping, you can change an object (by changing the DLL) but that object will still behave the same way as part of the overall system even though the code inside of it may be completely different as long as the interfaces don’t change.
Interface This is how the COM object communicates with the rest of the world. Any other processes can connect to the interface and ask for a service or property. Interfaces are well defined when the object is deployed so that a developer can write any calls to those interfaces in the same way every time. The actual code inside the object that implements and processes the data can be thought of as a black box as long as the interfaces always take and give output in the same way. Since the outside world (outside the COM object) only interacts with the interfaces the code inside the object can be anything as long as the interfaces work as they are expected. Interfaces are defined by the developer (or created automatically with a wizard) with a language called IDL or MIDL (Microsoft interface definition language). In the DCOM qualification sheet we use, you can see that we request the .IDL file be sent to us for qualification purposes. This file contains all the interface definitions and can give R&D a feel for what objects we will be testing. Interfaces can support methods and properties.
Methods Part of the interface which is just like a function. You can access an interface and call any of it’s methods with it’s correct arguments and receive output from it. So for an object that displays a picture on the screen a method may be called “ZoomIn” or “CropImage”.
Properties Also part of the interface, they can be set or queried. These can also be anything the developer wishes. For the same object that displays a picture, it’s properties could be “ShowToolbar” to show or hide a toolbar depending on whether this property is set to true or false. Another could be “Font” and so on. If you have an ActiveX GUI control, some of these properties are visible through the ActiveX viewer in Winrunner. (I think!)
A typical COM diagram for a component looks like:
Every object has an Iunknown interface which is part of the DCOM specifications. It supports three important methods: QueryInterface (will dynamically tell you what interfaces this object has), AddRef and Release for lifecycle management (create and destroy the object). These last two keep track of how many request references are connected to this object, when the connect number equals zero it is safe for the system to clean up and destroy this object to save resources since no one is referencing it. In the script you will actually see calls to this interface and methods as objects are used. I don’t know if these calls can be issues during a LR POC.
Another important interface is called Idispatch. It’s a standard interface that Microsoft provides that has some added functionality. A developer can derive his interfaces from the Idispatch to get all these added functions. This is also something that we ask in the qualification form and if they are being used you will see calls to Idispatch in the script.
The advantage of COM/DCOM is that thanks to the DCOM infrastructure, the objects pictured above can be anywhere, in the same exe or across a network. When a call is made to an object, the caller neither knows or cares where the other object is. If the object is registered, DCOM will find it through the COM Service Control Manager (SCM) which uses the registry to keep track of objects ( In w2000 it also uses the Active Directory). This way many objects can be distributed and still be part of the same application.
Deploying COM components:
Components need to be registered in order for COM to find them.
There is a huge number of combinations that are possible when creating a distributed application with COM since all these components can be anywhere and can run in several modes. There are two general types of server components:
Out-of-Process: The component is an EXE running on it’s own hosting it’s own objects.
In-Process: The component is a DLL that is loaded into the client’s process or into some other “host” process. An In-Process server need to be loaded by an executable, wether it’s the client, some other process, MTS, or in windows 2000 there is an executable available especially for this purpose called dllhost.exe (which happens to host Microsoft’s ASP script engine, another COM component!). The server side of an app can run inside the client’s process or on a totally different computer.
Microsoft Transaction Server:
MTS is a “server’s server”, it’s a home for In-Process servers you can write and deploy in it. You can create DLLs with your objects in them and register them as MTS objects. They will be loaded into the MTS executable and run inside MTS. MTS is an advantage for developers since it offers many features like security, transaction processing, etc, etc… that they would have to write themselves into their objects. In w2000, you can look at and manage the objects registered for the MTS in the “Component Services” applet of the control panel. In NT I think this is under the “option pack”.
Recording the DCOM sample app with LR:
The sample app is available under the downloadable binaries. The client executable is “FRSUI.exe”. This is the same old flight reservation system only that it uses DCOM to communicate with it’s “server” process. The client side is “FRSUI.exe” and the “server” side of this application is “FRSUI.dll”
You can actually get a very good idea of how the application works by looking at it with the Vugen. From what I can see in the Vugen (I may be wrong), the server side is implemented in the FRSUI.dll as three COM objects. It is a DLL so it has to be an In-Process server meaning it has to live inside an executable, I don’t know if it lives inside the client executable (FRSUI.exe) or some other one. I don’t think this important for the recording anyway.
From the Vugen, we can create a new DCOM vuser, click record and go into the recording options. This dialog is the greatest part of the recorder and very impressive to customers, it allows us to define what objects and interfaces we would like to record. Below is a screen capture of the filter tab:
The FRS is the server component of the flight reservation system (contained in h:\docs\DCOM\frs.dll), the ID number of the object is also shown at the bottom. FRS is the name of the component, inside are the three COM objects (login, order, querys) that provide pieces of functionality for these three pieces and finally inside those are the interfaces for each object(the only one showing is _querys for the Querys object). This was added into the filter box by selecting Add, Browse file system, and selecting the FRS.dll which is where the objects are implemented. The Vugen reads the DLL and automatically figures out what objects are in there. (as you can see, some of WR is also built on COM).
By looking at the FRSUI.dll structure in the filters tab a diagram can be drawn that looks like the standard COM diagram on the second page of this document. (This diagram is at the end of the document)
You can also add by browsing the registry which will show you every single COM object registered on that machine (if you want to record IE’s COM activity for example, you can find it in the registry under “Microsoft Internet Controls”). You can also browse COM objects running in the MTS on local or remote machines:
Once you add components into the filter, you can go down to the interface level when recording. This is a great feature. You can’t see all the available methods and properties from the filter, you can only filter to the interface granularity. In the script you will be able to record every method or property call to all the interfaces you specify.
There are three other filters you can set under the environment:
ADO objects for DB access on the machine, RDS for remote data services and Remote objects for remote invocations. Whether these will be on or not depend entirely on the application you are testing, the developer of the application will be able to tell you right away what should be recorded and what should be ignored. For some apps you can just record the things in the environment tab, for others you may need to add into the “Type Libraries” section to define the right objects.
Recording the sample app:
Very simple, once you set the filters for only the FRS component and all the objects inside and turn off the three environment options start the recording of the FRSUI.exe client and there it is. In the script you will see things like:
lrc_CoCreateInstance( <arguments> ); (Instantiate the object)
lrc__Login_GetAgentsArray (<arguments>);
These are interesting, this is a call to the Login object inside FRS.dll calling the GetAgentsArray method of the _login interface. This method just returns the array of names for the drop down list of agent names in the login screen. This is one of the first statements in the script.
And so on… and so on….
In the script you will also see all the arguments being passed in the function calls so it will be very easy to parameterize.
Also, the code in the script will pretty much look the exact same as the code in the client. If you have the app’s developer with you, he/she will recognize all the stuff in the script.
Important stuff for POCs:
For doing DCOM POCs it is imperative that you have the developer of the application with you while you are recording. Before you go into a POC you can alert the developer to think of what objects and interfaces you would need to record to generate a good load test. Only the developer of the app will be able to tell you what to set in the filters tab, what interfaces to record and so on, there’s no way around that. Once you set up the filter, you can save those as user-defined filters for future use which is also a great feature.
The developer is also needed since DCOM apps can vary so much there is no way an SE can be expected to figure it out on his own.
Our solution has not been QA’d on Windows 95. The only officially supported platforms are Windows NT SP 4,5 (not 6) and Windows 2000. I’ve tried recording and playback in W95 and it did not work.
For more info take a look at “learning DCOM” from O’Reilly press.
COM diagram of the demo app
Assuming the objects in the FRSUI.dll are In-Process and are loaded directly by the client executable (FRSUI.EXE) so that both client and server sides reside in the same process. (This may not be the case, I don’t know). The three interfaces contain all the methods the app uses for login, order and querys.