Maintaining Properties with a web service

[John Wright]

Is is possible to set properties in a web service and retreive those
properties at a later time? We need to expose some properties from a class
and want to make the class a web service? If this is possible, can you
point me to any references that demonstrate how this is done?

Thanks.
John

 

[Tomas Restrepo \(MVP\)]

John,

Is is possible to set properties in a web service and retreive those
properties at a later time? We need to expose some properties from a class
and want to make the class a web service? If this is possible, can you
point me to any references that demonstrate how this is done?

WebServices are not about remoting objects. Exposing "Properties" on a
webservice would be a really bad design, and goes again the real objective
of WebServices.

What is it exactly you want to accomplish? Perhaps we can suggest an
alternative approach...

 

[John Wright]

My current company has a lot of older VB classes that expose properties. I
am trying to convince them that web servcies are a better approach. Ideally
we would like to be able to have one GAC for the company in which we put all
the assemblies we need that way we only have to maintain one GAC instead of
trying to keep track of 2600 of them. Is it possible to do this? If so
then we could write .dll's that could expose the properties. There are
developers here who insist that objects in OOP have properties and will
continue to develop this way. Any other alternative you have I would
consider.

John

 

[Tomas Restrepo \(MVP\)]

Hi John,

My current company has a lot of older VB classes that expose properties. I
am trying to convince them that web servcies are a better approach. Ideally
we would like to be able to have one GAC for the company in which we put all
the assemblies we need that way we only have to maintain one GAC instead of
trying to keep track of 2600 of them. Is it possible to do this?

Possible, perhaps, but I'd stay away from it. There are several reasons, but
one pretty convincing one is the same one why you wouldn't want to deploy
all of them in COM+, either: it's expensive.

The key here is to realize that once you go this way, you're making an
explicit choice to deal with a boundary, and make "calls" (or in
webservices, send messages ) across the boundary. Crossing said boundary is
logically more expensive that crossing no boundary. This is one key reason
why designing remote services as if they were local leads to poorly
performing applications!

Not only that, but things like security, state management and so one become
real issues (webservices or not) you probably didn't even bother considering
when you created the original classes. Things like this are why the whole
"location transparency" thing in distributed objects doesn't really work
well!

What I would advice you is to carefully consider what you have. Instead of
just doing a broad generalization, think of coarse services that add value
and that make sense in the business domain you are working on, and then
incrementally replace/migrate code in the older libraries to reuse these new
services.

 

[Dino Chiesa [Microsoft]]

+1

Hi John,


Possible, perhaps, but I'd stay away from it. There are several reasons, but
one pretty convincing one is the same one why you wouldn't want to deploy
all of them in COM+, either: it's expensive.

The key here is to realize that once you go this way, you're making an
explicit choice to deal with a boundary, and make "calls" (or in
webservices, send messages ) across the boundary. Crossing said boundary is
logically more expensive that crossing no boundary. This is one key reason
why designing remote services as if they were local leads to poorly
performing applications!

Not only that, but things like security, state management and so one become
real issues (webservices or not) you probably didn't even bother considering
when you created the original classes. Things like this are why the whole
"location transparency" thing in distributed objects doesn't really work
well!

What I would advice you is to carefully consider what you have. Instead of
just doing a broad generalization, think of coarse services that add value
and that make sense in the business domain you are working on, and then
incrementally replace/migrate code in the older libraries to reuse these new
services.