A Newbie Question

Hi All,

I'm trying to develop a prototype for a small Room Booking application. This
is a 3 tier application. The presentation layer consists of Windows Forms.
There will be multiple concurrent clients. The application needs transaction
supportivity.I thought of developing in .NET C#. The data base is going to
be SQL Server 2000.

I thought of following the design guidelines mentioned in the
MSDN,Application Architecture for .NET Designing Applications and Services
from Microsoft
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html
/distapp.asp).

I have some questions. For my distributed application which technology would
be best suitable?. Enterprise Services COM+ components or .NET remoting or
Web Services? How can I take the decision? My application needs quick
response (Speed is important).

Thanks in advance.

Regards,
Risath

Bruce
Wed May 18 15:30:09 CDT 2005

I know nothing about COM+, but there are some significant differences
between .NET Remoting and Web Services.

Web Services work best in a stateless world (each request to the server
is an independent request that doesn't require that the server keep
context information). While you can create Web Services that have a
concept of "session" on the server side, it's more difficult than with
remoting.

Web Services have more overhead than Remoting. Remoting uses binary
serialization and avoids layers of communications protocol overhead.

Web Services provide interoperability with other languages and other
environments. You can reuse them. .NET Remoting essentially locks you
into .NET and would probably be applicable only to the app you're
writing. If you want to leverage what you do for future projects then
Remoting is less suitable for this.

For a Room Booking service, I would lean toward Web Services. There
should be little (or no) need to "log in" to the service and maintain a
server-side context, other than the (obvious) need to authenticate who
can do what, and Web Services has standards for that.

As well, you might conceivably want to book rooms from many different
devices and environments. Do you really want to insist that every
person who wants to book a room has to, at some level, be running .NET
and your client? (Or at least surf to a Web page that has .NET and your
client on the back end of it?) If you build a Web service to book the
room then you could later write a client in, say, Java, or use some
other technology that can call a Web Service. With Remoting that's
near-impossible.

The trick with Web Services is to make fewer calls to services and do
more on each call. It leads to a different architecture than you would
get with Remoting.

Unfortunately, with a big architectural decision like "Remoting versus
Web Services" you can't very well choose one and then change your mind
later, because the choice tends to lead to large-scale architectural
decisions that are difficult to reverse. However, I would be very, very
wary of sacrificing scalability and compatibility with future needs on
the altar of speed, speed, speed. I've done that in the past and I've
always regretted it.

As well, if you're using SQL Server 2000, do as much work as you can
inside the database (with stored procedures, etc.) That will bring you
performance gains, as well as making your application simpler.

Just my two cents' worth.

Risath
Wed May 18 23:09:41 CDT 2005

Thanks a lot for the reply

Anybody can tell me the pros and cons of using Enteprise Services for this
purpose.

Thanks in advance

Risath

"Bruce Wood" <brucewood@canada.com> wrote in message
news:1116448209.240705.315680@g49g2000cwa.googlegroups.com...
> I know nothing about COM+, but there are some significant differences
> between .NET Remoting and Web Services.
>
> Web Services work best in a stateless world (each request to the server
> is an independent request that doesn't require that the server keep
> context information). While you can create Web Services that have a
> concept of "session" on the server side, it's more difficult than with
> remoting.
>
> Web Services have more overhead than Remoting. Remoting uses binary
> serialization and avoids layers of communications protocol overhead.
>
> Web Services provide interoperability with other languages and other
> environments. You can reuse them. .NET Remoting essentially locks you
> into .NET and would probably be applicable only to the app you're
> writing. If you want to leverage what you do for future projects then
> Remoting is less suitable for this.
>
> For a Room Booking service, I would lean toward Web Services. There
> should be little (or no) need to "log in" to the service and maintain a
> server-side context, other than the (obvious) need to authenticate who
> can do what, and Web Services has standards for that.
>
> As well, you might conceivably want to book rooms from many different
> devices and environments. Do you really want to insist that every
> person who wants to book a room has to, at some level, be running .NET
> and your client? (Or at least surf to a Web page that has .NET and your
> client on the back end of it?) If you build a Web service to book the
> room then you could later write a client in, say, Java, or use some
> other technology that can call a Web Service. With Remoting that's
> near-impossible.
>
> The trick with Web Services is to make fewer calls to services and do
> more on each call. It leads to a different architecture than you would
> get with Remoting.
>
> Unfortunately, with a big architectural decision like "Remoting versus
> Web Services" you can't very well choose one and then change your mind
> later, because the choice tends to lead to large-scale architectural
> decisions that are difficult to reverse. However, I would be very, very
> wary of sacrificing scalability and compatibility with future needs on
> the altar of speed, speed, speed. I've done that in the past and I've
> always regretted it.
>
> As well, if you're using SQL Server 2000, do as much work as you can
> inside the database (with stored procedures, etc.) That will bring you
> performance gains, as well as making your application simpler.
>
> Just my two cents' worth.
>