We have a 2 server setup. Our clients will into a Terminal Server and run our app from there. Our current system has our business tier and UI running on the terminal server, and our DA tier running on our database server. The business tier talks to our server tier through COM+.

Now we are in the .NET world and using LLBLGEN. How would you all recommend we set up our logical tiers? The first instinct was to keep the business tier running on the UI server (the terminal server) which would create DataAccessAdapters remotely which would run on our server tier. However, it doesn't appear that DataAccessAdapter inherits from MarshalByRefObject which makes this currently impossible. The reason we want it to run remotely is that it needs to be close to the database to do some "extra code" after a fetch call.

Recommendations?

Thanks

mikeg22 wrote:

We have a 2 server setup. Our clients will into a Terminal Server and run our app from there. Our current system has our business tier and UI running on the terminal server, and our DA tier running on our database server. The business tier talks to our server tier through COM+.

Now we are in the .NET world and using LLBLGEN. How would you all recommend we set up our logical tiers? The first instinct was to keep the business tier running on the UI server (the terminal server) which would create DataAccessAdapters remotely which would run on our server tier. However, it doesn't appear that DataAccessAdapter inherits from MarshalByRefObject which makes this currently impossible. The reason we want it to run remotely is that it needs to be close to the database to do some "extra code" after a fetch call.

DataAccessAdapter isn't made serializable as it contains a database resource (which isn't serializable) and it's also not made marshallable by reference as that would create very 'chatty' applications: for each action you have to call the server one or more times, which is not very handy or scalable. Better is to send the server's service a message with what you want to do (e.g. call a method and pass in the data) and there the actions are started and coordinated.

Typically, a distributed system is build from services which expose an interface, like a set of methods. These methods are then called by the other tiers, in you case the BL tier.

as frans said if the DataaccessAdaabter remotable it will be very chatty so to solve this problem read about remote facade or session facade to control the client access to fine-grained component

Question frans how you identfy service layer operations? by the needs of the service layer client which come from use cases? so if you want to add new use cases then you must to modify service layer or there are more generic approach?

Mohammad wrote:

Question frans how you identfy service layer operations? by the needs of the service layer client which come from use cases? so if you want to add new use cases then you must to modify service layer or there are more generic approach?

I think it's a matter of how you define your tier's interfaces. Like what's discussed in the Concepts - n-tier development section in the docs. So it shouldn't matter if all tiers are on one box or on separate boxes. With that in mind I think it's straight forward to define what interface a tier has to expose and thus how your system is designed. But as it's a way of thinking, there is no real 'good' vs. 'bad': for one system there can be several different ways to design the different tiers.

Otis wrote:

Mohammad wrote:

Question frans how you identfy service layer operations? by the needs of the service layer client which come from use cases? so if you want to add new use cases then you must to modify service layer or there are more generic approach?

I think it's a matter of how you define your tier's interfaces. Like what's discussed in the Concepts - n-tier development section in the docs. So it shouldn't matter if all tiers are on one box or on separate boxes. With that in mind I think it's straight forward to define what interface a tier has to expose and thus how your system is designed. But as it's a way of thinking, there is no real 'good' vs. 'bad': for one system there can be several different ways to design the different tiers.

I believe the quesioned being asked is if there is a way to do the facade in a generic way so that new use cases don't necessarily require a change to the session (facade?) layer.

mikeg22 wrote:

Otis wrote:

Mohammad wrote:

Question frans how you identfy service layer operations? by the needs of the service layer client which come from use cases? so if you want to add new use cases then you must to modify service layer or there are more generic approach?

I think it's a matter of how you define your tier's interfaces. Like what's discussed in the Concepts - n-tier development section in the docs. So it shouldn't matter if all tiers are on one box or on separate boxes. With that in mind I think it's straight forward to define what interface a tier has to expose and thus how your system is designed. But as it's a way of thinking, there is no real 'good' vs. 'bad': for one system there can be several different ways to design the different tiers.

I believe the quesioned being asked is if there is a way to do the facade in a generic way so that new use cases don't necessarily require a change to the session (facade?) layer.

That depends if the new use case requires functionality which isn't provided by the service layer. If the new use case requires data which isn't provided or functionality which isn't provided, the service tier has to be adjusted.

So you should design them also as individual systems. The service tier should provide a solid service for consuming clients, not only what one client needs. It's the same with n-tier development: you don't design the BL tier as a 1:1 copy of the gui tier. You design the BL tier the way it makes sense the most for the BL tier. Then in the gui tier you call the methods exposed by the BL tier to make the GUI tier work, which thus makes the BL tier decoupled in a way from the GUI tier, which is the same for a service.

Though it's a tough job, there is no fixed rulebook for this, as I said. It's a way of thinking, not a 10-step plan to get to the pot of gold. Designing a service is hard, you easily leave out important methods and at the same time it's easy to overdo the design also, with methods which are perhaps never called.

thanks frans for your time