Data Service Tier Dll

Quote:

---

Originally posted by RobDog888
Also, if everyone is creating a new data tier object then there is no
performance benefits?

---

I hate double-negatives, but to answer this question, no.

In other words, yes, there will be a performance increase from making a server-side object to be an adapter between your client tier and the server tier, if:

You do not simply toss ADO Recordset Objects around your network. Rather, as shunt is suggesting, the client receives an XML representation of a Recordset (created on the server), and then the client can transform that XML representation back to an ADO Recordset after it has received it.

Will all this perform even better if there is only 1 object doing all this server-side work instead of 1 for each client?

Maybe. But I think the lion's share of your optimization should come from XML transformations. Let me know if I've made myself crystal clear. If not, I'd be happy to go into more detail.

Thanks Dave. Clear as the smog filled air here in LA on a good day. ;)

I will try creating the dll then and let you know how it goes.

Thanks.

Cool, please keep us updated.

Is this DLL going to be a DCOM object?

Ie.. That would imply that the client apps are on different machines than the server hosting the DLL. Just asking. It shouldn't change anything we've discussed so far.

I dont know that much at all about DCOM, but the client exe would
need to be on another server network share separate from the
database server because we willl have users connecting to our
Terminal Server to run the program as well as local network users.

Quote:

---

Originally posted by RobDog888
I dont know that much at all about DCOM, but the client exe would
need to be on another server network share separate from the
database server because we willl have users connecting to our
Terminal Server to run the program as well as local network users.

---

At this point, a better description of your topology is in order.

If the client apps are being executed on a different machine than the server, then you have a case where DCOM is required.

If, however, the clients connect to the server where the database is running, via Terminal Services, then the client apps are actually being run on the same machine as the server. There will be no need for DCOM in this case.

Do you know which is the case?

Basic layout:

Database server - DB + proposed data service dll.
Application server - location of executable.
Terminal Server - some remote user will run shortcut to App Server from here.
Local Network Workstations - most users will run program internally from local shortcut to App Server..

:confused:

Quote:

---

Originally posted by RobDog888
Basic layout:

Database server - DB + proposed data service dll.
Application server - location of executable.
Terminal Server - some remote user will run shortcut to App Server from here.
:confused:

---

Are these 3 seperate machines? I guess that wasnt clear.

Yes, three separate physical server machines.

Application Server = Windows Server 2003
Terminal Server = Windows 2000 Terminal Server
Database Server = Windows 2000 Server

:D

Sorry guys... Was out job hunting! :(

Anyways...
You do not have to use GetObject to connect to a single instance of a component or class. You can create a standard dll, host it in COM+, and set COM+ accordingly. This will make sure that only one instance of your component is created regardless of the number of clients connecting to it. You will need to make sure that your exposed classes are stateless however... Otherwise you are going to encounter some nasty bugs. But that should be the case with your data services in any case. In effect, COM+ will act as a ActiveX EXE that wraps the ActiveX DLL, turning it into a fully fledged ActiveX Server!

There are also programming techniques in which you can return a single instance of a class to all clients. Investigate the singleton pattern for this one.

Quote:

---

Originally posted by shunt
Sorry guys... Was out job hunting! :(

Anyways...
You do not have to use GetObject to connect to a single instance of a component or class. You can create a standard dll, host it in COM+, and set COM+ accordingly. This will make sure that only one instance of your component is created regardless of the number of clients connecting to it. You will need to make sure that your exposed classes are stateless however... Otherwise you are going to encounter some nasty bugs. But that should be the case with your data services in any case. In effect, COM+ will act as a ActiveX EXE that wraps the ActiveX DLL, turning it into a fully fledged ActiveX Server!

There are also programming techniques in which you can return a single instance of a class to all clients. Investigate the singleton pattern for this one.

---

Well, I dunno about RobDog, but this would be very useful to know how to do. I can make my own ActiveX DLL. Would you consider making a short tutorial on how to connect 2 clients to a remote COM+ DLL?

I would do some of the work if I could. It should be its own new thread in the DCOM section.

Quote:

---

Originally posted by RobDog888
Basic layout:

Database server - DB + proposed data service dll.
Application server - location of executable.
Terminal Server - some remote user will run shortcut to App Server from here.
Local Network Workstations - most users will run program internally from local shortcut to App Server..

:confused:

---

You have a case where multiple clients connect to the Terminal server. Presumably they will all run their client app from that machine.

The amount of data traffic between the Term server (TS) and the App Server (AS) should be minimized. The best way to accomplish this would be to have the client app be totally thin. The thinnest app I can think of is a web browser like IE, or maybe a little heavier - a VB app with an Internet webbrowser COM control.

Then your application server could be an ASP app running in IIS. Since ASP can instantiate COM objects, you have a link from ASP back to the COM+ idea.

There should then be a pair of COM+ Objects - call them rsSender and rsReceiver. rsReceiver would reside with the web server in the middle and ask the rsSender for a Recordset. rsSender lives on the same machine as the database and queries it for an ADO recordset, but stops short of sending the ADO object across the network to the rsReceiver.

Instead, it serializes the Recordset into an XML file (1 line of code) and sends that file across the network to the rsReceiver.

The rsReceiver then transforms the XML file back into an ADO Recordset and give that back to your ASP application running on IIS.

ASP is more than happy to work with ADO Recordsets. Then it sends either HTML or XHTML (your choice) back to each thin client.

So your NW traffic is like this:

Many Clients connect to TS. Many thin apps on TS connect to web server (App server). App server makes many COM objects. Many COM objects talk to single COM+ rsReceiver object on same machine. rsReceiver object (on app machine) talks to single COM+ rsSender object on DB server.

Quote:

---

Orininally posted by Dave Sell
Presumably they will all run their client app from that machine.

---

Terminal Server users would run a shortcut to the app residing
on the Application Server.

Also, we have another Windows 2003 server, which is our PDC
and Web server, running IIS so I doubt it that the owners would
allow me to install IIS on the Application Server. :(

I really appreciate all the time and effort by you guys to help me
understand and figure out how this app should be
designed. :thumb:

I understand the rsSender and rsReceiver transmitting the xml
string thing and it sounds like a good idea. We are currently
passing the entire ado recordsets. They are being populated by
passing the SQL string as the rs source when its opened. Allot of
network traffic.

I am a beginner at this (n-tier) so please bear with me.

How should I create the Data Service dll? Props, Methods, etc.

Thanks.

Quote:

---

Originally posted by RobDog888
Terminal Server users would run a shortcut to the app residing
on the Application Server.

---

This is no different than running the app from the same machine. This renders your app server useless.

Lets say you and I are on a LAN. You have 2 apps. 1 is on your disk and 1 is on my disk.

Lets say you run your app. Your CPU loads it off disk and plugs in into the execution stack of your CPU. You use your CPU and your RAM.

Lets say you run my app via a shortcut. Your CPU loads it off the network and plugs in into the execution stack of your CPU. You use your CPU and your RAM.

Same thing. Your App Server is nothing more than a File Server.. This is fine, but do you really need another machine for that? This is what I meant when I said the client app should reside on the Terminal Server.

Quote:

---

Originally posted by RobDog888
Also, we have another Windows 2003 server, which is our PDC
and Web server, running IIS so I doubt it that the owners would
allow me to install IIS on the Application Server. :(

---

2 IIS servers can reside peacefully on the same LAN. Your main IIS can listen to port 80. You could set up another IIS to be your App server and listen to port 8080 or whatever.

You will need installation rights to any web server where you are developing resident COM objects like we are proposing.

Quote:

---

Originally posted by RobDog888

I really appreciate all the time and effort by you guys to help me
understand and figure out how this app should be
designed. :thumb:

---

I'm doing this as much for me as for you! This is solid gold!

Quote:

---

Originally posted by RobDog888

How should I create the Data Service dll? Props, Methods, etc.

---

I think that may depend on how you choose the rest of the suggestions above, but in my opinion, you can consider the rsSender to be half of it, and stored procedures on the RDBMS to be the other half. Since they both reside on the same machine, they are considered in the same tier.

I'll give more thought to the kinds of methods that would be helpful, but alot of that may hinge on the App server.

IIS is still no possibility of installing it on the App server because
the app server also runs our Exchange mail.

I have Global Admin rights on the network. So no worries about
that.

Quote:

---

Originally posted by Dave Sell
This is no different than running the app from the same machine. This renders your app server useless.

Lets say you and I are on a LAN. You have 2 apps. 1 is on your disk and 1 is on my disk.

Lets say you run your app. Your CPU loads it off disk and plugs in into the execution stack of your CPU. You use your CPU and your RAM.

Lets say you run my app via a shortcut. Your CPU loads it off the network and plugs in into the execution stack of your CPU. You use your CPU and your RAM.

Same thing. Your App Server is nothing more than a File Server.. This is fine, but do you really need another machine for that? This is what I meant when I said the client app should reside on the Terminal Server.

---

Makes allot of sense now. If I can talk the Network Admin into
this then I will move the client exe to the Terminal Server.

Quote:

---

Originally posted by RobDog888
Makes allot of sense now. If I can talk the Network Admin into
this then I will move the client exe to the Terminal Server.

---

You will more likely win your argument if you stop calling it an App server and call it what it really is planned to be, a File Server. $0.02

So the Data Service dll would have hidden methods for
connecting to the database. A generic procedure to Execute the
stored procedures and return the rsSender xml strings.

I am a little confused about the connecting part. If we want to
make the most of this, then we want only one object and have
clients using the Getobject method? So the first step is to set this
up?

Ok,
Application Server = File Server.
Application Server = File Server.
Application Server = File Server.
'...
'...
'...
Got it now.

:D

Quote:

---

Originally posted by RobDog888
So the Data Service dll would have hidden methods for
connecting to the database. A generic procedure to Execute the
stored procedures and return the rsSender xml strings.

I am a little confused about the connecting part. If we want to
make the most of this, then we want only one object and have
clients using the Getobject method? So the first step is to set this
up?

---

I believe the first step is to decide on your topology. These decisions should not be made until you know the thin-ness of the client app. It sounds like your are not leaning towards the web-browser-type thin client?

Correct. The owners dont like web browser apps.
Neither does the Network Admin.

Would there be a benefit of writting this in .NET? I dont know if there
will be problems with distributing the framework. Could be a big
issue. Would be nice since I'm going to all this trouble of re-writting
it.

Quote:

---

Originally posted by RobDog888
Would there be a benefit of writting this in .NET? I dont know if there
will be problems with distributing the framework. Could be a big
issue. Would be nice since I'm going to all this trouble of re-writting
it.

---

Personally I am sticking with VB6 for now (I am in an almost identical situation as you). I could go .NET for all this inter-process, inter-machine communications, but I already know how to do everything in VB6 and I don't understand a lick of VB.NET/ASP.NET.

These are very advanced programming techniques, and I daresay the crux of the language.

How long did it take you to get to this point in skills in VB6?

How long will it take to master VB.NET to do the same stuff?

I am using VB.NET now for easy stuff like GUIs and crap. But for all this domain design complexity, I'll stick with VB6, but that doesn't mean anyone else has to.

As far as your question, I don't see .NET bringing anything extra to the table that can't get done in VB6 in the same amount of time with the same resources. The only benefit is you could spare your future the drudgery of supporting a legacy app in VB6...

Quote:

---

Originally posted by RobDog888
I want to write a dll for connecting to a SQL server so I can
re-use it on my programs. I think its correct to do it this way for
better performance. Right now I have eveything in the exe. How
can I get started making it so its generic for any server or db?

Also, would running an exe from a network share be detrimental
to performance because of all the network traffic? Better to install
the exe on every pc locally?

Thanks for any help.

---

Here is your original post, with your original intent. You clearly state you have everything in the EXE. This is the very definition of a Thick client (as opposed to a Thin client).

Yet you just got done saying that your bosses or whatever won't let you make a thin client.

They can't have it both ways. Either you go thin client, and spare yourself a ton of pain, or go thick, and you will basically be left with exactly what you got right now. A big ugly mess. Sorry to sound crude, but that's the way I see it.

I'll stick with VB6 for this re-write.

They just dont want a web browser based program for this. We
cant have it a thin client exe without going to browser based?

:(

Quote:

---

Originally posted by RobDog888
I'll stick with VB6 for this re-write.

They just dont want a web browser based program for this. We
cant have it a thin client exe without going to browser based?

:(

---

Of course you can, but then you end up writing an app very much like a web-browser and a server very much like a web-server.

Do you really want to re-write a client-type-browser and also a server?

Do ya? huh? huh? :confused:

:confused: Do I?

Quote:

---

Originally posted by RobDog888
:confused: Do I?

---

I sure the hell don't.

I'll say this. Why don't you do the whole thing with the thin web client (IE) and "real" app server (IIS) and use it as a kind of prototype.

Once everything is up and running and working you can give it to your bosses and let them evaluate it.

If they still hate it, at that point you could re-write the thin client and the web server. Let it be their choice (to spend the extra time on it). You never know, they might just take what you give them and love it. I sincerely believe you will double your design time if you don't go thin client.

I always thought that to do n-tier you didn't need to write a browser
based app?

:confused:

Quote:

---

Originally posted by RobDog888
I always thought that to do n-tier you didn't need to write a browser based app?
:confused:

---

You don't need to write one if you use one that's already made, like netscape or IE. But, if you don't use one that's already made, then you do have to write your own thin client (as well as a corresponding server).

Of course, that client does not have to be an HTML interpreter (web browser), but it will behave in very much the same way regardless how it is written.

As soon as you start placing intelligence into a thin client, you no longer have a thin client, but instead have a thick client which defeats the whole purpose of n-tier design.

Ok, now I'm completely :confused:

Quote:

---

Ok, now I'm completely :confused:

---

Quote:

---

Originally posted by RobDog888
I always thought that to do n-tier you didn't need to write a browser based app?

:confused:

---

OK, then sorry to not speak so clearly. Let me re-phrase. The above assumption is correct.

But... You 1 need to write something as the thin-client front end. You will also have to 2 write some kind of server (service) that talks to and controls that thin client. You also have to write 3 an application-type intelligence to control that server.

The thing I'm trying to impart to you, is: if you 1 use a browser as your thin client, then you don't have to write it. Nor do you have to write 2 the server - use IIS. All you have to write is 3 the intelligence to control the server (like an ASP application).

Crap I think I just said the same exact thing...:blush:

I dont agree with Dave on his views about using the Web Browser as a thin client. You are still going to have to write client side logic to control the web page interaction and server side logic to control the data access. It just makes things more difficult because you have to write everything as a stateless application, meaning you will most likely have to get rid of your business logic component and try and write this stateless... Also, you must remember that web pages are not type safe and are more difficult to debug. In fact, every aspect about writing the applications for a web browser is much more difficult.

I wrote a production planning system that used a web browser as a front end. Trust me! It is much harder! And a real mission to maintain!

Writing the app in VB6, you will not have to re-write a web server nor a web browser... Not even close. Those things only have the plumming work for server-browser communication, not the data transfer, business rules etc. that you require. In any case, you will have DCOM and COM+ that will handle your communication plumming! Thats so much better!

In terms of the tutorial, I'll get started with a simple one right now.

I think you should stick with your client->business logic->data services idea!

Here is my view on your topology.

Quote:

---

Originally posted by shunt
Here is my view on your topology.

---

How did you make those diagrams?

I drew them... with a program...
Why?

Quote:

---

Originally posted by shunt
I drew them... with a program...
Why?

---

Well I want to make a rebuttle, but I just can't do it with words anymore. I'd like to make some pictoral diagrams like you made. What program did you use?

:)

I used Visio. You can use paint if you like. I think it would be good to see some diagrams out here. I think its something that is not used enough on VB forums.

In any case, I would like to see a) how other people draw the diagrams, b) how other people model the applications.

Please, state your case! I am eager to see the knowledge and views of others out there! (0 sarcasm!)

Well, I have Visio at home, so I will install it tonight, but I won't get around to making a full diagram of my ideas until next week most likely...

I understand your disagreement, and you make valid points. But to say its more difficult to make web-controlled apps as opposed to VB6 apps deserves debate.

I agree if: the front end is unreasonably complicated.

I disagree if: the front end is elegantly simple.

I guess that will all depend on the requirements of your customer... They get the ultimate decision in the complexity of their GUI.

It is that decision that can have reprecussions throughout the rest of the entire design.

It is totally true that a web GUI is stateless. But I contend that this is a good thing. Keeping track of state creates more complexity.

It only works for the view size combo box. It looks like there
should be a navigator or some other kind of animation? Maybe its
not working on my system?

Quote:

---

Originally posted by RobDog888
It only works for the view size combo box. It looks like there
should be a navigator or some other kind of animation? Maybe its
not working on my system?

---

What?

From shunt's example. If you look in the support folder you will see
what appears to be rollover images and some other stuff.

Ya I saw alot of JS but nothing really happenned. All I did was look at the main images. I wasn't sure if there was something wrong with my system too.

Ok, I like the design but I wanted to know about the users that will
just be running the app from their workstation (internal use). Will
they be taking a performance hit any different than what it was
originally? They will not want to run the program internally
through Terminal Server.

http://www.vbforums.com/attachment.p...postid=1812793

:)

Question: Why not run the internal users on Terminal Server too?

Anyway, the terminal server in the diagram can be a workstation too. To an end user, the terminal server is a workstation.

In my opinion:
Your business objects should be statefull, providing your rules as to how objects relate, data validation etc. If you use web pages for your front end, you will not be able to use objects and classes. You will have to use Java applets or ActiveX components to accomplish that, and then...you may as well be coding a vb front end. You can try and write objects using javascript...it can be done to an extent, but it is such a mission! I've done that too. I also found that coding the rules of an object into each page of the site was also a real headache! Even if it was a copy/paste affair. One little change takes you hours upon hours to code, debug and test... That equates to $$$$$$$$$$$$!

Your data services component should be stateless, providing access to the data of the system.

On the other hand:
What does your application do? If it is a simple read data, display to user, let user edit data, save data; with very simple business rules and/or data rules, then sure...a web application will do it. In fact, chuck all design out the window and use recordsets in the asp pages to do everything. Also databind the controls to the recordset. Using Visual Studio 6 with its RAD tools, you will have the application banged out in no time!

Quote:

---

If you use web pages for your front end, you will not be able to use objects and classes. You will have to use Java applets or ActiveX components to accomplish that, and then...you may as well be coding a vb front end.

---

No. You can make dynamically generated HTML "forms" without anything special running on the client (javascript, java applet, or client-side ActiveX control).

The pages are generated via code running on the server very easily. Given the simplicity of the GUI, server-side HTML generation can be much much easier than a client-side VB app.

Granted, the GUI will have limits.

Oh, I forgot - yes, you can make Classes and Objects and use them in your web app. That's the real saving grace of crappy ASP 3.0 - the fact that it makes the server infinately extensible through the use of your own custom classes.

I'm talking about ASP code like:

VB Code:

Set myObject = Server.CreateObject("myProject.myClassThatCanDoAnything")

Our program manages client, project, task, and employee information.
So yes, there will be a bit more transactions going on than
searches.

I know you can use server.createobject, but that is server side. Your client application is not going to be able to use that object. Basically, while the user is viewing and interacting with the web page, you will not be able to use objects, unless they are java applets or vb activex's. Basically, your user is chained to simple request data, edit data, submit data.

From RobDog's description here, it looks like thats what they will be doing in any case. If there is no real process for the application then just use recordsets with data bound controls. Its a real simple solution. But if you want to do a really elegant solution, you are seriously going to battle with pure HTML/ASP!

Here is a nice article I think you guys would be interested in:
http://msdn.microsoft.com/architectu...RUD-afford.asp

Quote:

---

Originally posted by shunt
I know you can use server.createobject, but that is server side. Your client application is not going to be able to use that object. Basically, while the user is viewing and interacting with the web page, you will not be able to use objects, unless they are java applets or vb activex's. Basically, your user is chained to simple request data, edit data, submit data.

---

Agreed. That is the nature of a truly thin client. It not a glamorous GUI.

I read the CRUD article and maybe I'm tired but I didn't quite take
it all in. I think I'm getting lost. I need a client/server app design
that will be scallable for a dozen users or so with decent
performance. I would like to stay away from a browser based app
simple because we have had too many issues with them from
before.

Thanks.

Basically, the article is saying that you dont often have pure CRUD operations in the application. So, reading and writing recordsets is actually not good enough. You need to define the operations of the application and implement your database interaction behind that.

Quote:

---

I need a client/server app design
that will be scallable for a dozen users or so with decent
performance.

---

I feel that my topology, you would be able to accomplish this. I think you will get the most performance using a single instance server component with connection pooling, parameterised sql, good database design with appropriate indexes.

Quote:

---

Originally posted by RobDog888
I read the CRUD article and maybe I'm tired but I didn't quite take
it all in. I think I'm getting lost. I need a client/server app design
that will be scallable for a dozen users or so with decent
performance. I would like to stay away from a browser based app
simple because we have had too many issues with them from
before.
Thanks.

---

Try a DCOM Singleton:
http://www.vbforums.com/showthread.p...hreadid=310205

Note: The singleton pattern solves a very different problem to the one discussed in the CRUD article. But I suppose it is very relevant cos it is most likely your service layer to the db...

With the Observer-Broadcaster-Singleton pattern implementation I have been discussing, any client "hooked" into the Event chain can raise an event that an update has been made. All clients will get the message as a Raised Event.

In that scenario, your clients could then re-load the combo-box only when exactly necessary.

I cannot believe I read this entire thread.

All I have to say is ... WHAT THE HELL ARE YOU GUYS SMOKING ? :D :D :D

Ok whats so hard about this:

3 tiers:

Business Tier
Database Tier
Validation Tier

The client (exe) has no access to the db...so I can't understand how hard that it to understand? Your business logic simply accesses the db tier. Your db tier returns data back to the business tier which in turn returns it back to the exe. You probably don't need the validation tier, but you'd be amazed how helpful this can become if you have a lot of business logic rules.
The validation tier validates on your client application before sending anything to your business tier (hope that makes sense)

From a design perspective you are looking at:

[Client (EXE) ] ----> [Validate tier (check it before you even bother)]-----> [business logic tier (ok so the validation worked...now i need to perform some logic and send it to the server)] <----------------> [database tier (ill store this data and return back)]

db tier cannot touch exe, database tier has nothing to do with validation tier, db tier talks back to business logic tier vice versa. Business logic tier only gets validated but talks back to the client application via some records from methods within itself.

Rob, dont make this too difficult man, even if its your first time, draw it out on paper before you start getting too deep into it. Mind you, this is a LOT of code, however this design will pay off in the end when it comes time to maintenance.

Also Rob, the business logic dll should be very versatile. In fact you should be able to pass stored procedure names, etc when retrieving data from the database tier level. Your database doesnt have to worry about the client application at all.

In this entire scenerio you can expect that you have at least the following:

DB SERVER (SQL)
Client Machine (local host to run the application)
Application Server (this is even optional but you can register your validation and business logic tiers here).

Real simple, Woka's got some good examples, else I can write you a small employee type tier application some time soon. I've just been very busy lately.

Jon