Anybody out there interested in talking about MS multitier dev issues? 7

[johnk]

I have a small group (6 of us) of business software developers. Since VB4 we have done nothing but OOP & DCOM. There does not seem to be a large number of folks doing this, yet it may well be the most important technology (along with CORBA) to come along in a while. Now that Microsoft has published its certification specs for Win2000 Distributed Applications it is clear that COM+ is the MS way of the future.<br>
<br>
We have learned much about DCOM, OOP & multitier - most of it the hard way. I'd love to find some more of you to exchange info and experience with.<br>
<br>
John K

 

[johnk]

chiph & palbano,

Just to clarify where my experience and comments come from; our applications are usually for smaller (<50 workstations) networks for internal, non-public use. It is quite practical to arrange scalability in these situations by directing connections between the tiers by the use of ini files or registry entires which must be &quot;hand&quot; maintained.

In some distant hazy future time I hope that our architecture wil be adaptable to load balancing functionality, either by its accomodation of our state maintaining design or our adaptation to stateless objects.

Like so many things in computer programming technology, the target environment is a major factor in the design of multi-tier architecture applications.




John Kisner

 

[chiph]

Pete -
Of course the application itself can maintain state using other techniques otherwise it would be fairly useless.

Sure. You just shouldn't maintain state via the session object, or a loaded DLL or something. We've done it via the database -- we set a session cookie which contains a &quot;Job ID&quot;, which is an index into a table. One drawback of this technique is we have to go through and clean out this table every so often (because of dropped connections), but it's not a big deal -- delete where (now() - lastaccess) > 3 days

JohnK-

You are correct, and that's the one danger in jumping into a thread after 85-some messages have been posted -- you miss some of the operating conditions mentioned way back when. Sorry for the confusion.

So, for 50 users or less, then stated/stateless isn't really an issue, and you certainly can scale via hardware. The maintenance issues are pretty trivial, too. Just send an email telling the users what you want them to do!

Chip H.

 

[sheetaljoshi]

Hi John!
I'm a vb6 programmer,trying COM/DCOM.
Presently i'm working on a small three tier application.
I'm using the frontend screens only for the user input. the database being used at the backend is Oracle 8i.
for data processing and validations, i have created active x dll files .
now this application works perfectly fine, the dlls and the fontend beng on the same machine and the database being on the server machine.
I want to distribute the active x dlls on over the network.
i tried doing it using MTS which is there on the server machine (on which my database resides).
1. I created a package and included the .dll of my machine(Win 98) to the package.
2. I then deployed the package on a third machine which is also a win 98 m/c.
3. During the deployment, MTS created a setup file on the client machine which i ran on the client machine.
4. I intend to use the dll component on the MTS for development purpose.
How do i use it?What steps am i supposed to follow after running the setup file on the client machine?
It will be of great help to me if u could explain me this
regards
sheetal

 

[johnk]

sheetal,

For one thing, you need to compile your 2nd tier objects as Active X Exe's, not Active X DLL's.

We do not use MTS and have no experience with it.

Good luck.



John Kisner

 

[sheetaljoshi]

Hi John!
Thankx for ur reply.
Today i tried DCOM without using MTS;i.e. using Dcomcnfg utility on NT server.
I followed the steps that i ahve given below.Plz tell me if i have missed anything.
1. Created an exe and hosted it on NT server.
2. set the access permissions to a user'A'.
3. Now logged in the n/w as user 'A' on a win 98 machine.
But i fail to set the reference to the exe file as it does not appear in the list of available components.
Please explain me the steps i need to follow on the client machine to be able to set a reference to the remote exe component.
best regards
sheetal

 

[johnk]

Sheeta, I must tell you that I am more of a manager than a technical programmer. I'll try to help here, but I'll also pass this along to one of my programmers later today.

Consider a simple table maintenance situation. A form is created in my client tier project, and a class is created in my 2nd tier project. (We use a total of 4 tiers, but a 2 tier structure would work in similar fashion). I put the 2nd tier into execution. Then when I open my client tier project and look in the reference list for the client tier, the 2nd tier project shows up and can be assigned.

Hope this helps.


John Kisner

 

[sheetaljoshi]

Hi John!
Thankx for ur reply again!
I understood wht u tried to explaination.Let me tell u that i understand the things at the conceptual level.
But i face a problem while implementing it.
As u have mentioned, i'll wait for a more technical answer from one of ur programmers.
Thankx for sparing time to answer my queries.
best regards
sheetal

 

[bilshah]

I have been reading this thread for over year now. Its really interesting.
We are using DCOM environment and we use VB as front and SQL server 7.0 as back over NT server.
Now we are shifting to Windows 2000 and SQL Server 2000.
What we need to do now is guarantee our client that our application wont go down and Database server will not crash anytime.
Now as there are many gurus in this thread so I want to put up my question in this thread. Please provide me with useful information as soon as possible. Because we have to provide solution to client with in few days.
If some one knows what is RAID or if it can help us in this regard then please let us know about it too.

 

[TheBigViking]

Hi JohnK

You seem to be just the right kind of person to ask my question too.

Let me give you a bit of background first though.

I started developing the system about 6 months ago. I am an old hand at assembler language, and a bit risky with C,C++.
How ever ever since I started with VB6 I have found that it fits like a good glove. I like the OO approach. Black boxes with very clearly defined in's and out's. It fitted in very nicely where I left off with my assembler.

I became very bored with my firmware, so I got the oppotunity to develop an access control system with VB6. The first thing that I discovered was interfaces. I love them. The next thing I dicovered was COM+. I love it.

I felt very blessed, because I would be developing a system from the ground up. I developed the access control hardware, the firmware that ran on the controllers, the serial comms protocol between the PC and the controllers, and the first thing I developed on the PC was a DLL that took complete control of all the serial communications requirements of the access controllers.

The next step for me to develop was a system whereby a central server would be able to control a number of remote servers each of would be in control of a COM port. I first tried COM+ to do this, but I found that the whole design of COM+ does not lead to an object that must always stay active (the comms DLL). I then resorted to RPC to talk to the remote servers, with the remote servers sending back running logs with MSMQ. This works very well. I use RPC for the functions for which I need direct feed back from the remote server. For things like card down loads, or configutaion settings I use MSMQ to send the data from the Master Server to these remote servers. Each of the remote servers strores very specific control information for the controllers in registry, so that the actual running of the controllers remains the responsibilty of the remote servers. I will from now on call these remote servers &quot;Polling Servers&quot; which is exactly what they do.

The next step was for me to develop a central database system for recording details such as card numbers, user's names, access profiles and such like. The datbase would also need to log all &quot;events&quot; received from the controllers. I started developing with MSAccess using ADO but quickly made the jump to SQL. I found that the only thing that I had to change was the connection string, so this went absolutely smoothly. I developed a DLL that does literaly all the database work and exposes methods and properties for all its functionality. A nice black box.

The next problem I faced was the fact that the eventual client apps could be running on any PC on the LAN. These client apps, depending on there functions need feed back from the controllers. An example would be as to whether a certain person was in the building or not. This same client app could be running on multiple PCs on the LAN so I somehow needed to broadcast this information to these PC. However to broadcast all the controller events on the network would literrally flood the network. So what I developed was a system whereby a client app would subscribe to the Master server for specific events. What happens now is that when a specific event comes from the controllers, via the Polling servers, via MSMQ, the Master Server then does a RPC call to each of the subscribed hosts. The method called on the ActiveX EXE on the host machine then raises a standard VB event. Any client apps that have this class set with events receives the &quot;event from the controller&quot;.

The next step I needed to develop was that any PC on the LAN running the appropriate client app could start or stop any controller or Polling Server anywhere on the system. They would also be able to initiates card down loads etc. Here is where COM+ comes in. The client app tells the MAster Server that the Controller with this GUID must stop. The master server then determines to which Polling Server the command must go. The command for the controller then gets put on to the MSMQ queue for the specific Polling Server.

As I said this has taken me just under 6 months to develop, but I mean an 18 hour a day 6 months.

To break down the system into tiers.

Level one - The user interface and client apps.
Level two - The master server level where all redirecting takes place whether it be to or from client apps, or to and from Polling Servers. This system consists of about 4 of 5 DLLs and one ActiveX EXE

Level three - I have to divide this level into two parts.
The first part would have to be the database wrapper DLL.
The second part is the Polling Server. This in itself consists of one ActiveX EXE and three DLLs.

Level four is once again divided into two parts. The first part is the database itself. The second part is the actual controllers themselves, which have their own databases.

It took me quite a while to be able to fit the whole system into these tiers. But now that I have it seems to fit nicely.

OK, now that I have finished boasting of my exploits, let me ask you the question I need to ask.

It has got to do with ADO record sets and interfaces.

I use interfaces extensively, and have written IDL code for them and they work well. The client apps all connect to the Master Server via DCOM ala COM+.

The only problem with interfaces that I have is when I am running a client app on remote machine. I cannot use record sets in these interfaces. The only way I can send recordset to and from a client is if these methods or properties are in the VB default interface. The reason for this is because I have to use late binding (DIM XXX as Object) to get access to the interfaces with record set's methods and propeties. Now this goes past the whole method of getting access to my interfaces. These interfaces have to be declared specifically. (DIM XXX as SomeInterface) and then I set XXX to the default interface. I am sure that you must know what I am writing about. Is there any way to get record sets to work on my own interfaces.

The reason I would like to do this, is for compatibility issues. The whole reason I have written the interfaces, is that client apps rely on these interfaces for compatibility via the Type libraries. The clients all connect to the VB default interfaces with CreateObject(&quot;Prog.ID&quot which means they do not care about the class IDs on my server app. But now because of these record set problems the default VB interfaces also have to have methods in them to get and set the record sets. It seems to defeat the whole reason why I use intefaces.

Do you have any solutions for me.


The Big Viking

 

[TheBigViking]

Stupid me.

If I make sure that the client machines are running same version of MDAC as the server machine, I can put record sets in an bloody interface without any problems. Oh how the small things sometimes get the best of minds unstuck Yours sincerely,
The Big Viking