Data intensive web services

[Meena]

Hi ,

I am developing a web service for a customer hosting an
online job application form. The customer has about 200
input fields ( mostly boolean values of Yes / No
questions , string and integers ) which he will be sending
to my webservice . Currently I have just written the
skeleton code for my web service which is a simple web
methodd that accepts 10 i/p fields , validate them and
write them to my database

My question is what is the best way to accept and send
such a large flow of input data? Should I use this same
simple function with i/P parameters , or should I go for a
structure , collections etc?

Keeping in mind that this is an online job application
feeding data to my webservice , what is teh best approach
one must follow when desiging such data intensive yet time
critical web services?



Thanks
Meena

 

[Simon Smith]

On Fri, 3 Oct 2003 12:27:35 -0700 in article
<[email protected]> in
microsoft.public.dotnet.framework.aspnet.webservices , "Meena"

Hi ,

I am developing a web service for a customer hosting an
online job application form. The customer has about 200
input fields ( mostly boolean values of Yes / No
questions , string and integers ) which he will be sending
to my webservice . Currently I have just written the
skeleton code for my web service which is a simple web
methodd that accepts 10 i/p fields , validate them and
write them to my database

My question is what is the best way to accept and send
such a large flow of input data? Should I use this same
simple function with i/P parameters , or should I go for a
structure , collections etc?

Keeping in mind that this is an online job application
feeding data to my webservice , what is teh best approach
one must follow when desiging such data intensive yet time
critical web services?

I would go for a structure, depending on what the caller of the
service is: if it's asp.net then definitely go for a structure:

a) it will ensure that fields are of the correct type
b) it puts them in an easily accessible and organised format
c) calling any method with 200 parameters is lunatic Put them into
one structure which could even do some pre-validation before the
actual call
d) an alternative is to pass an XML string. You will then have to
validate that the XML contains all the elements/attributes you expect
with valid values - takes time! A structure does it for you.

It's definitely what I'd do, anyway.....

 

[Eirik M.]

I thought the idea behind web-services was interoperability. Is your client
a .Net house? If not, can you make sure they can use a structure or do they
have to perform some sort of conversion? Then , I would use an XML-document.
If you define a schema for your document (which you should) both your client
and you can use the schema to validate the document.

Eirik M

 

[richlm]

You would also want to avoid using a structure, if it is
likely to change - since that would require rebuilding
and redeploying ALL of your clients. You can't handle
multiple client versions - it will just break.

You can do it if you use XML and schemas (although it
still requires a fair bit of analysis & dev work on the
server side).

-----Original Message-----
I thought the idea behind web-services was

interoperability. Is your client