[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]Message passing between webservices

From: Chris Smith
Subject: Re: [DotGNU]Message passing between webservices
Date: Thu, 16 Jan 2003 12:18:16 +0000

On Wednesday 15 January 2003 12:46, you wrote:
> I'd rather see this:
> [WebVariable(...)]
> public static int FooBar
> {
>         get
>         {
>                 ...
>         }
>         set
>         {
>                 ....
>         }
> }
> And then the accessors are automatically named get_Foobar and set_Foobar.
> However it will also be possible to access Foobar as a variable through
> message passing with the accessors invoked automatically.

We'll have to experiment with this.
Exposing a property in .net is (apparently) a hack because the get_ and set_ 
methods do not appear to physically exist in the assembly.  I think MS 
introduce some wrapper methods to do perform the get_ and set_ for you.

Perhaps Rhys, Gopal and others could comment on this?

A warning here though.  Exposing properties as web methods and developing 
applications that use them will result in a hideously slooooow system (read 
"unusable").  The overhead in doing the whole round trip over the internet 
just to get '42' back probably takes someewhere in the region of 7.5 million 

The additional overhead in returning an entire object is negligable.
So if you want to get and set properties, you are far better off abstracting 
this at the client and server end, and doing your property setting in batches 
'commiting' the changes when appropriate.
In fact, you should probably get the FooBar object back, call get_/set_* on 
*that* and then persist it back.

I'm just finishing off a system for the UK Gov. that uses self-persisting 
objects. When you create an object, it instantiates itself from the db and 
when you explicitly ->Save() it or it goes out of scope and modifications 
have been made to it, it automatically persists itself back to the db (unless 
you ->Discard() first....).  It works really well and was a bit of an 
experiment to begin with, no-one ever thinks about the DB being there any 
more and never has to think about restoring state as it all happens 
This would definately work with web services as they're equally as stateless 
and multi-process as my self-persisting obj system.


Chris Smith
  Technical Architect - netFluid Technology Ltd.
  "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
  E: address@hidden  W:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]