System Architecture / .NET Remoting

[Sam Shrefler]

I'm working on creating a SOA for my applications. We have
numerous .NET IIS applicaitons. They all tie into a central client
database for certain pieces of information. I'm trying to decide the
best way to architect the system.

Placing the business logic into stored procedures seems like an easy
way to allow all the different applications to access the business
logic there.

I'd prefer to somehow keep my Business logic in its own C# busines
layer. My concern is how each of my application will be able to share
that business layer. Would creating a .NET Remoting services be my
best option, or create a strict api and distribute it as a dll to each
of the applications be my best option?

Look forward to some insight....

Thanks

Sam

 

[Peter Bradley]

Not sure I've understood you correctly - but it seems to me that you should
have no problem sharing your SOA amongst many applications. As long as they
have a definition, client side, of the remote object's interface/metadata or
whatever, they can just make calls via the remoting framework. Have I
missed something in what you're trying to do?

We encapsulate all our business logic in remote components running on an
application server. All database access is done via the business logic
layer. This means that the Web server can be off the domain, and totally
ignorant of anything to do with database connections and the like. As far
as the Web server is concerned, we could be storing data in csv files. It
doesn't know and it doesn't care.


Peter

 

[Andy]

I'm working on creating a SOA for my applications. We have
numerous .NET IIS applicaitons. They all tie into a central client
database for certain pieces of information. I'm trying to decide the
best way to architect the system.

Placing the business logic into stored procedures seems like an easy
way to allow all the different applications to access the business
logic there.

I'd prefer to somehow keep my Business logic in its own C# busines
layer. My concern is how each of my application will be able to share
that business layer. Would creating a .NET Remoting services be my
best option, or create a strict api and distribute it as a dll to each
of the applications be my best option?

Look forward to some insight....

Hi,

Check out Expert C# 2005 Business Objects by Rockford Lhotka, from
Apress. The book talks about building a common framework upon which
to build a business layer. Part of that layer is a data portal, which
allows your objects to move from webserver to application server via
remoting (if you choose). The framework is fully functional, and I
use it to build my business applications.

HTH
Andy

 

[Michael Nemtsev]

Hello Sam,

SS> I'd prefer to somehow keep my Business logic in its own C# busines
SS> layer. My concern is how each of my application will be able to
SS> share that business layer. Would creating a .NET Remoting services
SS> be my best option, or create a strict api and distribute it as a dll
SS> to each of the applications be my best option?

The same way as sharing objects but taking into account the followin specific:
if your are going to implement your business logic as set of services, you
need to taxonomy your logic and extract business operations and business
processes. After u implement your services, you need to provide the way
to publish and discover them

So, when onle of your component, for example presentation layer need to process
some logic, it need to ask mediator to find and provide u the spefic business
component which will execute your tasks.


---
WBR, Michael Nemtsev [.NET/C# MVP].
My blog: http://spaces.live.com/laflour
Team blog: http://devkids.blogspot.com/

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangel

 

[Sam Shrefler]

Peter:

I guess my question is what is the best way to expose the applicaiton
server.

Currently, our applications are very tightly coupled with lots of
duplicate code. The majority of our business logic is contained in
SQL stored procedures. I'm looking to refactor the system. I guess
I'm looking for more information how people commonly "encapsulate all
our business logic in remote components running on an
application server" Also, I was trying to determine if the best way
to connect our webservers or any other clients to the application
server is though the .NET Remoting Framework. This is all new to
me....

Thank you for the help!

Sam

 

[Michael Nemtsev]

Hello Sam,

SS> I guess
SS> I'm looking for more information how people commonly "encapsulate
SS> all
SS> our business logic in remote components running on an
SS> application server" Also, I was trying to determine if the best way
SS> to connect our webservers or any other clients to the application
SS> server is though the .NET Remoting Framework. This is all new to
SS> me....

It's not purely true that all business logic should be removed fromt the
stored procedures. Some of them should present. There is no strict rules
of what should or shouldn't be in stored procedures vs business logic in
middleware. It completely depends on one's application.
I'd recommend to read http://msdn2.microsoft.com/en-us/library/ms978496.aspx
and http://www.codeproject.com/gen/design/DudeWheresMyBusinessLogic.asp where
you can find out some recomendations.

What about remoting - consider using WCF to buid your services and some workflow
engines like MS WF or even BizTalk

---
WBR, Michael Nemtsev [.NET/C# MVP].
My blog: http://spaces.live.com/laflour
Team blog: http://devkids.blogspot.com/

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo