Fat client - Server: Which technology?

  • Thread starter Thread starter Pieter Coucke
  • Start date Start date
P

Pieter Coucke

Hi,

Which technology's are used to make Windows Forms (Fat) Client - Server
application with VB.NET (2.0)?
- XML Webservices, Remoting, DCOM, ... are there others?
- Which are used the most and why?
- Pro's and cons?

Any help or usefull links would be really appreciated!

thanks a lot in advance,

Pieter
 
Pieter Coucke said:
Hi,

Which technology's are used to make Windows Forms (Fat) Client - Server
application with VB.NET (2.0)?
- XML Webservices, Remoting, DCOM, ... are there others?
- Which are used the most and why?
- Pro's and cons?

Any help or usefull links would be really appreciated!

thanks a lot in advance,
Click to expand...


Short answer: XML Web Services.

Long Answer

Check out

patterns & practices: Smart Client
http://msdn.microsoft.com/practices/apptype/smartclient/

Smart Client Architecture and Design Guide
http://msdn.microsoft.com/practices....aspx?pull=/library/en-us/dnpag/html/scag.asp

Smart Client Baseline Architecture Toolkit Home
http://www.gotdotnet.com/codegallery/codegallery.aspx?id=941d2228-3bb5-42fd-8004-c08595821170


David
 
David Browne said:
Short answer: XML Web Services.
Click to expand...

It did wants performance-test with XML Webservices (.NET 1.1) and abandonned
the use of it because of hte really poor performance, especially when having
to select a lot of records.

Did this get spectaculary better in the 2.0 Framework, or is this something
you jsutn eed to live with when using Webservices?
 
Pieter Coucke said:
It did wants performance-test with XML Webservices (.NET 1.1) and
abandonned the use of it because of hte really poor performance,
especially when having to select a lot of records.

Did this get spectaculary better in the 2.0 Framework, or is this
something you jsutn eed to live with when using Webservices?
Click to expand...

Live with.

XML is XML. Computers are faster now, but all the methods mentioned have
performance concerns. You really have to design around it by limiting the
amount of data moved to and from the client.

For some applications if performance is a huge concern, you can always just
talk to your your database server.

So either, go directly to the database, or use XML Web Services. Forget all
the intermediate options.


David
 
XML Web Services and Remoting are essentially the same thing, as are WCF
services (Vista). DCOM is largely out of the picture right now.

The benefit of Remoting is the flexibility of protocol and the loss of being
coupled with HTTP. But, this benefit, which was largely in performance, is
pretty much gone now. The biggest benefit of Remoting, at this time, is
stateful objects (marshall by reference).

Web services have the benefit of being able to key them to a name service
(UDDI) and have the client automatically check with the name service when it
loses connectivity, giving you a lot of flexibility. The same can be done
with Remoting, but you will have to build it. Moving from ASMX web services
to WCF services is also an easy step, so you are heading in the correct
direction for Vista.

As for usage, I see a lot of Remoting. This is largely due to preoccupation
with performance, even though acceptable level of service is not normally
calculated prior to reducing cycles, so it is an artificial measure. In my
experience, web services in 1.x were fine for apps and 2.0 are even faster,
so the perf argument is bogus in most cases. In addition, I have found a
great number of shops tying Remoting to SSL, which means the only perf
benefit is the fact you do not have to go through a SOAP wrapper. So, you
get very little perf benefit at the cost of a lot of lost maintainability.
Not very wise.

I am sure some will disagree with me. :-)

--
Gregory A. Beamer

*************************************************
Think Outside the Box!
*************************************************
 
As for usage, I see a lot of Remoting. This is largely due to
preoccupation with performance, even though acceptable level of
service is not normally calculated prior to reducing cycles, so it is
an artificial measure. In my experience, web services in 1.x were fine
for apps and 2.0 are even faster, so the perf argument is bogus in
most cases. In addition, I have found a great number of shops tying
Remoting to SSL, which means the only perf benefit is the fact you do
not have to go through a SOAP wrapper. So, you get very little perf
benefit at the cost of a lot of lost maintainability. Not very wise.
Click to expand...

With remoting you also gain access to rich objects. With web services,
you're only able to transfer data objects.

However, remoting is limited to the .NET platform - tho you can gain some
interoperability by using the XML SOAP formatter.
 
Spam Catcher said:
With remoting you also gain access to rich objects. With web services,
you're only able to transfer data objects.
Click to expand...

Which is a good thing, as it guarantees loose coupling of the distributed
parts. Sharing code across remote boundaries is rarely wise. It's usually
better to share a formal data contract (like WSDL), and let each end have
its own implementation.


David
 
I have done a lot of remoting and written a lot of webservices (2.0)
with very good results. The if you go with webservices, you have the
added benefit of incorporating DIME/MTOM into the app. While in some
cases can be a performance hit, can bring huge benefits when used
appropriately.

But you can never go wrong with XML. How you specifically do that, is
open to a lot of debate.

- John Fullmer
 
And do Webservices have a much better performance in 2.0 than 1.1 as they
say?
Whah the difference in percent compared to Remoting?

I noticed (with 1.1) a really bad and too much notisable performance,
especilly when doing a select of some thousands of records (which wil be
unfortunately necessary...)
 
Pieter Coucke said:
And do Webservices have a much better performance in 2.0 than 1.1 as they
say?
Whah the difference in percent compared to Remoting?

I noticed (with 1.1) a really bad and too much notisable performance,
especilly when doing a select of some thousands of records (which wil be
unfortunately necessary...)
Click to expand...

If you want to code a client/server application, just do it. Connect to
your database and get busy. Really it's nothing to be ashamed about.

David
 
Webservices are great, and you'll like the benefits. Performance is
only going to become an issue if it already is, or if it's poorly
designed.

- John Fullmer
 
XML Web Services work fine for us. Just make sure to enable HTTP compression
on client and server or it will be slow. We typically get 6 to 1 compression
ratios which really helps when sending big blobs of XML.

Somebody once installed a proxy server that didn't support compression and
the fat client users started complaining that everything was slow.
 
Back
Top