Architecture question

[z71mdridin]

I currently have a classic asp/COM+ architecture setup as following:

Server A- hosts all the classic asp front end pages
Server B- host all the business layer dlls. They are currently
registered through COM+
Server C- contains database

We are migrating to .NET and I would like to keep the same distributed
architecture, but it appears that asp.net applications copy all the
business layer dlls into their bin directory. I know that distributed
computing must be possible in .NET but I am overlooking something.
Can anyone give me any suggestions?

Any help you provide would be greatly appreciated! Thanks.

 

[Aidy]

Look into EnterpriseServices, remoting and web services.

 

[sloan]

If you are at the beginning of the road for distributed architecture as of
today.

Then WCF is your starting point. It is the fruition of many previous DotNet
technologies like Remoting and MSMQ.

If you are going to be working in a "DotNet to DotNet" world , where all of
your clients are DotNet enabled, then look here:
http://sholliday.spaces.live.com/blog/cns!A68482B9628A842A!158.entry


If you're going to support non dot net clients (java, asp, other), then WCF
is still the answer. But you will generate proxies for the client, instead
of my interface method.

...................

I also have a Remoting entry at my blog you might read over as well. Its
about "keeping your secret code safe". However, that is an old article, and
you want to learn from Remoting, but WCF is the way to go.

...............

You might also check out some videos on channel9 from Greg Leake.....about
the stocktrader sample application.
http://www.google.com/search?hl=en&q=channel9+greg+leake
There are 2 videos to watch. They're roughly 2 hours (in total).

 

[z71mdridin]

Thanks for the replies so far, but I am still working through how to
organize my middle tier.
I understand that webservices is probably my best option for
communicating between server A(front-end aspnet pages) and server
B(business layer dll)
But...
On Server B I have many business-layer class libraries. For example
an inventory class library, an order class library, an accounting
class library, etc
I also have several utility class libraries: a database class library,
a logging class library, an authentication class library.

Say I want my inventory, order, and accounting class libraries to all
make use of the same logging class library without having multiple
versions of the dll in three different places. I would like to do
this without having to wrap a service interface around each utility
class library. When I add a reference to a class library is there a
way to define a relative path to the reference rather than having it
import the dll into the bin directory of each class library?

 

[sloan]

There's no free lunch, BUT, if you look at my blog entry, you need to see
that the .Interfaces project is in its own assembly, and its the "master
contract" of all the stuff.

In my sample, the client does NOT get any of the concrete business layer
dlls. It only gets a copy of the .Interfaces projects.

// I would like to do

this without having to wrap a service interface around each utility
class library.//

The trimmest you can make it is using the .Interfaces library.

//
When I add a reference to a class library is there a

way to define a relative path to the reference rather than having it
import the dll into the bin directory of each class library

//

That is what my .Interfaces project (the actual .csproj) is all about. Its
the thing you reference and distribute around.

Open up the solution AND look at what each sub csproj references. This is
the key.
Notice that Presentation.Web.1 does NOT reference the concrete business
objects.



They've been telling you for years to "code to a interface, not an
implementation"
http://www.google.com/search?source=ig&hl=en&rlz=&q="to+an+interface"+not+an+implementation

This is (another) reason to do this.


Good luck. I'm not trying to antagonize you, only provide you with some of
the baseline truths of the situation.


Again, my "interfaced" based solution is best of a "dot net to dot net
world" (aka, no non-dot-net clients).
But I spent over a month playing and tweaking and looking for the best
solution....and I'm comfortable with my setup.

.....
YOu can also read through this:
http://sholliday.spaces.live.com/blog/cns!A68482B9628A842A!122.entry
and this:
http://secretgeek.net/QAD_Remoting.asp
though those are .Net Remoting articles, and you can learn from them. But
WCF is the way to go in 2008.