How would i go about creating a distributed application with LLBLGen?

I need the DAL and BAL to run together on a seperate server. Any idea?

The idea is to take the straign of from the webserver and place it on a seperate machine.

WS = Web Server AS = Application Server DS = Database Server

[WS] hosts the website (Nothing else) [AS] is where all the background services and DAL and BAL must run. [DS] where the big fat database sits.

Now how do i get the webserver to use the DAL and BAL that is on another machine. AS is suppose to do the processing for the webserver. The BAL on AS must also be able to switch between database servers depending on their load.

Please don't say something like webservices... If that is the case won't it mean installing IIS on AS aswell?

Schema below should give an idea of what i need... I hope.

|------| |------| |------| | WS |-| AS |-| DS1 | |------| |------| |------| | |----|------| | DS2 | |------|

This layout is going to get screwed by the HTML. it does not like my spaces. DS2 must be below DS1 and attached to AS.

Thanks Wayne

No Answers? Can this be done?

You should use remoting if you want to use an api on another machine. THere is a small remoting example in the examples section available to look at the very basic principles. Webservices are not natively supported, due to the fact that the code supports cyclic references, something XmlSerializer can't handle (among a lot of other things)

This seems like alot of work!

I think i will just tell my cleint that this is currently not a possibility.

It's not that hard Once you're accustomed to it, it's very easy.

Now how do i get the webserver to use the DAL and BAL that is on another machine.

If the client talks directly to the DAL then you are breaking your own best practices.

I would use remoting and the adapter pattern. Then I would create a Facade Layer, that was remoting compliant. The Facade Layer should contain namespaces / obects that provide methods like, getByAccountID, CreateInvoice, ShipProduct, etc. The client would have a reference to the objects in the DatabaseGeneric assembly e.g. the entities, factories, and helpers, and a reference to the business facade. The client would call into the the facade object via a remote proxy to do its CRUD operations.

On another note, just because an application is physically distributed, dosent always have a performance increase. Why cant you package the Presentation Services, Business Services, and Data Services on the same web server, and keep the database on a seperate machine? Do you need to use application load balancing or something, or are your shooting for 24x7x365 availability and application clustering ?

Why cant you package the Presentation Services, Business Services, and Data Services on the same web server, and keep the database on a seperate machine? Do you need to use application load balancing or something, or are your shooting for 24x7x365 availability and application clustering ?

Well, it all boils down to security.

This system is a financial system interfacing with lots of other financial institutions. Currently they are running the Presentation Services, Business Services, and Data Services on the same web server and the database on a seperate machine. But they now require the following.

Because the services takes alot of CPU time the webserver is slow

And for security reasons they require the following layout.

Internet -> Firewall -> WebServer -> Firewall -> Application Server -> Database Servers.

Now this makes the design a bit tricky.

The 2nd firewall only allows incoming traffic from the WebServer to the application server.

The Webserver is the only machine accessible from the Internet and the webserver must only have rights to the application server.

Only the Application Server is allowed to access the Database Server.

Well, that being said, remoting is definately the way to go. You have more control over the message sinks when using remoting. COM+ could be an option, but sometimes, there are real issues when trying to raise an event with COM+ through a firewall. Sometimes with COM+ it is easier to manage role based security, but you loose some functionality.

With remoting you can easily control your ports, verify identities, and event encrypt messages going from point A to point B. HIPPA has some of the same requirements.

You can use simple code access security to keep untrusted callers from executing code at runtime.

One thing that is commonly overlooked with a distributed application is that when the app is distributed, you are build latency into the picture due to the physical separation of layers. Have they considered clustering to be able to scale out the existing web app and business services?

Devildog74 wrote:

Have they considered clustering to be able to scale out the existing web app and business services?

I am not sure what you mean. Can you maybe explain?

Wayne, a few messages ago you said:

Because the services takes alot of CPU time the webserver is slow

Typically what I have found is that processes like IIS and COM+ are heavy on the memory load of a given server. Depending on the types of calculations being done, and instructions, and threads, etc. CPU load will increase as users do. On the otherhand, OLTP systems cause large volumes of file I/O.

Scaling up refers to adding additional hardware to an existing server to make it more optimized for performance, i.e. adding secondary RAID arrays, isolating database files to seperate physical partitions, extra processors, and extra RAM. If your server is not upgradable, you scale the application out. Scaling out, refers to adding additional servers to balance the load and to support more concurrent users. You can use application server and application load balancing to divide the load across servers.

For example, lets say that your site averages 2000 concurrent users per hour and the ram averages 60% usage and the processor usages averages around 80%. That would be pretty much optimum performance (according to some enterprise architechts.) So now you need to roll out a new peice of the business model, and your stress tests show that if you increase the load to 3000 users per hour, then the server starts to implode. You can roll out a new server in a clustered environment, and send 1500 users to server A and 1500 users to server B. You also get the extra security of having a redundant system. One server can go down, and the application can function properly until IT fixes the bad server, and the application is just less responsive for a short period of time due to the increased workload.

Scaling up and our are not cheap. Especially when you start to look at multiple RAID 5 disk arrays and database redundancy and SAN solutions for database mirroring and failover. However, client XYZ might feel that they get the return on investment by the product that youre developing.

One thing that I am curious about is what type of processors is their current setup running, whats the normal concurrent user load, and what types math are you doing that causes the CPU to be pegged?

If you want to drop me an email to the one in my profile, I would be happy to kick around some ideas with you.

The current webserver spec is:

Intel Rack Server. Windows 2000 Server Dual 2.4 Hyper threading Xeon
4 GB Ram 1 80GB Scsi Drive.

Sit on 2MB Backbone.

The Database Server spec is: Duel PIII 500 Windows 2000 Advance Server SQL Server 2000 2 GB RAM Think 5 80GB Scsi Drives in raid 5 config.

Services and calculations: Currently i don't know what the calcs are doing or in what languages they have been coded in as my team \ company is only handling the distribution of the Web Application.

I will contact you as soon as i have more info.

wayne wrote:

Well, it all boils down to security.

This system is a financial system interfacing with lots of other financial institutions. Currently they are running the Presentation Services, Business Services, and Data Services on the same web server and the database on a seperate machine. But they now require the following.

Because the services takes alot of CPU time the webserver is slow

And for security reasons they require the following layout.

Internet -> Firewall -> WebServer -> Firewall -> Application Server -> Database Servers.

Now this makes the design a bit tricky.

The 2nd firewall only allows incoming traffic from the WebServer to the application server.

The Webserver is the only machine accessible from the Internet and the webserver must only have rights to the application server.

Only the Application Server is allowed to access the Database Server.

Wayne, not sure this ever really got a satisfactory answer. I find myself in the exact same position - not able to have any application components on the web server and the same firewalled deployment. We run an app with COM and .NET portions and although the COM side seems to be "remotable" via DCOM config (no code changes), there seems to be no equivalent configuration-level remoting technique for .NET components. My hope is that we do not have to start changing code, it seems to me that the actual location of an assembly should be flexible amongst machines without code changes.

Does anyone else have insight into this kind of setup? Wayne, did you make any progress.