Middle Tier Dev for legacy app

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

BillAtWork - 03 Apr 2007 16:54 GMT

Hi,
We have a .NET 1.1 legacy application which we are rewriting in order to
improve the structure of the codebase and performance where possible. We are
extracting business logic, currently held in DB procedures and in ASP.NET UI
code (C#) and moving it to middle-tier classes.

We want to implement the middle tier with the following in mind (fairly
standard stuff):

1) Expose the business logic to the UI application to improve code structure
in the UI and keep performance high (this is a high-volume UI application).
2) Potentially expose some of the logic to external clients in the future.
3) Potentially move the middle tier to a separate server (currently running
as one IIS server + a separate DB cluster) to improve performance.

Can anyone suggest (or point me toward) information on the best
architecture. WebServices look good but we don't know about performance for a
high-volume app. We want to avoid writing code now that works fast while
everything is on the same server, but then have to change it if we deploy the
middle-tier to another server.

I'm really looking for "best of breed" articles about this stuff :)

Thanks.

Reply to this Message

Luke Zhang [MSFT] - 04 Apr 2007 03:30 GMT

Hello,

I think you may have several choices for the Midddle Tier component here:

Web Service
COM+
Remoting
WCF

WebService is a good choice and even even most popular in these days, If
you want to expose your logic to external clients, it may be the best
solution. For performance, it may depend on the design and business volumn.

COM+ is a mature technology which is still can be used within .NET
application, it has better performance but not suitable to expose to
external clients because it rely on Windows NT domain.

Remoting & WCF are new technology in .NET framework, which may be popular
in later enterprise application architecture.

Sincerely,

Luke Zhang

Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

Reply to this Message

James Crosswell - 07 Apr 2007 16:16 GMT

> WebService is a good choice and even even most popular in these days, If
> you want to expose your logic to external clients, it may be the best
> solution. For performance, it may depend on the design and business volumn.

Just adding to what Luke said, I'd recommend WCF over web services if
you can. WCF gives you all the advantages of web services but adds a
whole lot more. It allows you to replace XML serialization with a more
performant binary/other serialization technique, control exactly what
gets serialized and how (using things like surrogates). So I think it's
unlikely you'll run into an unsolvable performance issue in WCF.

The only real disadvantages of choosing WCF over web services are that:
1. WCF doesn't have any notion of sessions (well it does but they're not
what you would think of as sessions if you're coming from an ASP.NET
background) so if you want to maintain context information about the
clients on your server you'll have to build your own framework for doing
that.
2. A WCF middle tier will have to run on a machine that supports .NET
3.0 (which means Windows XP SP2, Windows 2003 Server or Windows Vista).
Depending on how you architect the application (and how you're
serializing your data), this may also be a requirement for the clients
that use the functionality of your WCF middle tier as well.

Also note that none of the solutions proposed above by Luke will address
how you should be moving data across the boundary between your middle
tier and your client apps. You might use datasets for that (not that
I've heard anyone highly recommending that) or that might be some other
custom set of objects/classes (maybe an ORM/OPF framework - something
like nHibernate).

Some other options for the middle tier architecture are things like
Genuine Channels (add on for Remoting that adds a bunch of neat
features) and RemObjects (which is an alternative to remoting/web
services which is somewhat restricted in terms of the types it allows
you to transport but does come with a solution for handling data out of
the box - namely DataAbstract... which is something none of the other
frameworks really have).

There are plenty of books out there talking about building web services,
remoting applications and even building WCF services - so if you're new
to it all then I guess one of those would be a good place to start. If
you're looking at WCF then there are a bunch of pretty good videos on
the netfx site as well.

Best Regards,

James Crosswell
Microforge.net LLC
http://www.microforge.net

Reply to this Message

Middle Tier Dev for legacy app

Free Magazines