create property in web services

[ypul]

How to use properties in webservice ?

if I want to create a webservice as my middle tier and want to create
public properties so that the presentation layer can assign values to the
property and then call insert() method in webservice. how should I do that I
web service does not allow public properties .

there is one option of passing the property values through webmethod...but
it will disturb the architecture ...
what is a standard method of doing it ....??

also give me a alternative method of using webservices as middle tier for
insert update select operations ..

Please ...
waiting for many comments
vips

[Keenan Newton]

Web serives are stateless, and atomic. They do not and should not
support properties. You are going to have to abstract your middle tier
with a web service, and pass the values you are going to insert as
parameters of the insert method. Web Services don't support pure
Object Orientation

[vips]

How should I use web services for inserting and updating database ??
I want to keep my middle tier seperate from the presentation tier...

vips

"Keenan Newton" <ka*********@yahoo.com> wrote in message
news:11*********************@l41g2000cwc.googlegro ups.com...

Web serives are stateless, and atomic. They do not and should not
support properties. You are going to have to abstract your middle tier
with a web service, and pass the values you are going to insert as
parameters of the insert method. Web Services don't support pure
Object Orientation

[Keenan Newton]

Create a web service method, that accepts the parameters that need to
be populated. They parameters can be the different data elements that
need to be saved, or it can eb an object with properties. I prefer to
use the object with properties were a lot of data is being saved it
also makes it clearer when you pass in a collection.

[cecil]

Vips,
Why do you want to use web services? Why do you want to have
separate physical tiers? It is important to have layers of
responsibility in your application but this does not require web
services or separate physical tiers, it can be accomplished with simple
well designed classes. Web services are first and foremost about
interoperability. Are you expecting to have non .Net clients? If you
need separate Physical tiers and all your clients will be .net then go
with .Net remoting The main reason for a separate physical middle tier
is for data access to take advantage of connection pooling for
scalability, how many clients are you expecting to have? If the number
is not too big then client server architecture is just fine.
There are of course other factors but the two listed above are the big
ones. If you don't need the extra complexity keep it simple! A single
executable and the db, client server may be all you need. Just follow
good class design principals and latter moving to a more complex
physical architecture posses few obstacles.

Cecil Howell
MCSD, MCAD.Net, MCT
www.ceciltech.com

[Keenan Newton]

Well there are more things to consider then simply just connection
pooling and interoperability. Such as is this application going to be
just one part of an Enterprise application? Will other applications
potentially be able to use your services down the road? Do you expect
your infrastructure to always be pure Microsoft? I agree with Cecil
that you can start small with client/server but between the layers I
would not use a Object Orientated Architecture. I would side with a
Service Orientated Architecture, and this does not mean the use of web
servers necessarily. Just make sure that you are passing the "message"
and not the implementation between the tiers, and you should be fine.
it is very hard to determine growth, but it is going to be a forgone
conclusion that technology will change. With that do you feel more
comfortable using a vendor specific transport like remoting, or a more
common one such as SOAP via http (web services). If you are looking to
longevity and if you ever forsee the need to be interoperable not only
between different vendor, but between different evolutions of a
specific. I would create a client/server application with a "service
thinking" (SOA) approach. .Net Remoting in my mind will only make you
re-write code down the road.