Posted By: Ang3lFir3 | Jul 10th, 2006 @ 2:42 PM
page 1 of 1
Comments: 14 | Views: 12363
Ang3lFir3
Ang3lFir3
Codito Ergo Sum

I would like to find out what the different opinions of other devs/architects are when it comes to using Web Services for data access.

In what scenarios do you believe it is an excellent idea?

In what scenarios do you believe it is a bad idea?

What kind of applications would you expect to use web services for data access and what kinds would you not?

If you have used them for data access, what draw backs if any have you experienced? what benefits can you say make them utimately worth while?

I've experimented with doing so on a smaller demo project but nothing really big yet. Curious as to what everyone else has to say on the topic.

feel free to give opinions on web services in general as well.

HumanCompiler
HumanCompiler
Compiling humans...and code
The serialization and deserialization slows things down, so the only time you should use it is when you want to make data available over the internet and even then, it depends on what you want to do.  It's great if you want to open things to outside users to query your data (like we'll eventually do here on Channel 9).  It's great for smart client applications to access data over the internet, etc.  Web services are mostly great, because they're standards based so anyone that can understand WSDL and SOAP can access your services.
Tensor
Tensor
Im in yr house upgrading yr family
Depends what you want. IMHO, if you are doing a single app, then web services are not usualy the way to go. If its one app accessing another, then web services come in to there own. For a single app, if you want to access data remotely, use Remoting. Its good mojo.
figuerres
figuerres
???
Afew things from my corner:


STATELESS !!!!  STATELESS !!!!

and have clients handle some connection failures!!


now how's this, I have a live system that uses 2 backend servers.

handles about 60+  pc smart clients and about the same number of hand helds running CE.Net 4.1 .Net CF 1.1

the system takes an "average" of about 6,000 orders a day.

has a "peak" time when the handhelds and pc's are all dumping orders -- so about 3,000 orders come in during about 2 hours each day -- sundays are about 2,000 orders.

been running this for about 6 months.

the clients are on different networks from the server data center, we also run SSL and client certificates.

the servers are just normal dell dual cpu boxes -- not super expensive gear.

we update the pc's with new features and bug fixes as needed.

runs like a champ.

but every call to the web services is 100% stateless
you send in a request and get a reply. so no time does any one client block / lock etc...

what we have seen as the most common errors are clients losing TCP or DNS due to the local network .... not a server problem.

now I *MIGHT* re-work this to use WCF later but today the customers love it.

they dealt with a citrix and Java based system before that had lot's of issues with printer drivers and firmware updates etc...
so this system is much less "Brittle" for them.

so when folks say that ws are slow, have to much overhead etc...
I wonder what they are doing...  WRONG Big Smile
Zeus
Zeus
Why is the caption missing??
I am building a system now for a fairly large client which is an admin back-end system and a front end website (3).

I have a webservice running above the database which handles all calls to the DB, both from the backend system and the websites. That will minimize the amount of maintenance for me, and allow the front-end websites to run on any platform that can connect to a webservice.

I am doing all this in C# 2.0 and am very happy with the performance of the system.
JohnAskew
JohnAskew
9 girl in pink sweater
Ang3lFir3 wrote:
I agree with you both on many levels. One of my immediate points of interest is that I am pondering if the flexability of using web services to provide the same data to both multiple applications (for different purposes) as well as the same application in different flavors , i.e. a web app and a desktop or handheld version is the best answer? Is the slight increase in processing time worth the time and flexability saved by using a web service to maintain a singularly manageable mechanism for data access? Or is it better to just roll my own library for accessing the data?

In my opinion it may very well be better to use a web service as this allows for large scale code reuse. In many cases some of my intended targets would be accessed across the LAN while sometimes accessed remotely from the internet. With so many different potential situations of use and locale I at this time believe it best to use a web service where simply using remoting may not offer the best solution.

did that all make sense?


Yes. Smart Client rich Windows Forms 'occassionally-connected' apps might batch up messages that request data from web services when offline. When these apps go online, they processes the messages queued up through the web services. Asynchronous requests and xml-serialization of your messages, it's not so hard, imho, and performance is fine. When online, messages just shoot through the queue on a background thread.

Those same web services could trade messages with a variety of clients.

What the teachers tell us is that we are trading messages, not calling remote procedures through web services and not passing datasets .

Rocky Lhotka wrote:
Create explicit schema for your web service messages, then generate proxy classes in VB or C# or whatever language based on that schema. Then use the proxy objects in your web service code.
JohnAskew
JohnAskew
9 girl in pink sweater

Web services work anywhere and are easy on your network security, imho.

figuerres
figuerres
???
JohnAskew wrote:

Ang3lFir3 wrote: I agree with you both on many levels. One of my immediate points of interest is that I am pondering if the flexability of using web services to provide the same data to both multiple applications (for different purposes) as well as the same application in different flavors , i.e. a web app and a desktop or handheld version is the best answer? Is the slight increase in processing time worth the time and flexability saved by using a web service to maintain a singularly manageable mechanism for data access? Or is it better to just roll my own library for accessing the data?

In my opinion it may very well be better to use a web service as this allows for large scale code reuse. In many cases some of my intended targets would be accessed across the LAN while sometimes accessed remotely from the internet. With so many different potential situations of use and locale I at this time believe it best to use a web service where simply using remoting may not offer the best solution.

did that all make sense?


Yes. Smart Client rich Windows Forms 'occassionally-connected' apps might batch up messages that request data from web services when offline. When these apps go online, they processes the messages queued up through the web services. Asynchronous requests and xml-serialization of your messages, it's not so hard, imho, and performance is fine. When online, messages just shoot through the queue on a background thread.

Those same web services could trade messages with a variety of clients.

What the teachers tell us is that we are trading messages, not calling remote procedures through web services and not passing datasets .

Rocky Lhotka wrote: Create explicit schema for your web service messages, then generate proxy classes in VB or C# or whatever language based on that schema. Then use the proxy objects in your web service code.


Yeah, in 90% or more of my code the "Passed Data" is a class.
the class is whatever data the other side needs.
so it's not generally a "data Set" nor a "Table"
not a "row" from a table.
in most cases it's data from 2 or more tables in a logical unit.

like posting an order -- sends in a collection of detail lines and some info about who is posting the order etc...
and the "result" is an object that tells the caller if the order posted, what kind of problems if any and if the order posted then the caller gets a GUID and date-time and other details so they can print a recipt out.

even when I use a dataset it's not just table rows -- it's some narrow selection to fill a need like: todays orders, Num,Total,time
for a drill down grid.
HumanCompiler
HumanCompiler
Compiling humans...and code
Ang3lFir3 wrote:


agreed.. passing datasets and datatables won't be happening



DataSets and DataTables...what are those?  *giggle*  Tongue Out
HumanCompiler
HumanCompiler
Compiling humans...and code
Ang3lFir3 wrote:

HC can you run over to building 23(IIRC) and tell them to hurry up the O/R mapping bits in ADO.NET please?lol


Sadly, no...I'm only one man...er...compiler...er...yah, whatever...no, I can't.  Wink
I always had performance issues whenever I used webservices. It is fast if one access them in the last 2 -3 mins, but anytime after it feels like it is recompiling everything. I have read that this could be a threading issue and that you can help tweak the performance using some nifty stuff in web.config.

Thats why I switched to using .NET remoting.
Zeus
Zeus
Why is the caption missing??
yman wrote:
I always had performance issues whenever I used webservices. It is fast if one access them in the last 2 -3 mins, but anytime after it feels like it is recompiling everything. I have read that this could be a threading issue and that you can help tweak the performance using some nifty stuff in web.config.

Thats why I switched to using .NET remoting.
That seems a little odd to me ... we have been using WS for years now, and have had no major performance issues regarding recompiling ... and we are not doing anything special in web.config. Our API's get a lot of traffic every day.
page 1 of 1
Comments: 14 | Views: 12363
Microsoft Communities