[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: Tue, 14 Jan 2003 11:00:42 +0000

On Tuesday 14 January 2003 09:57, Gopal V wrote:

> > wouldn't do object serialisation over xmlrpc (i don't think).
> You *can* do Object serialisation over xmlrpc ... but the obvious question
> is "do you want to ?" ... Of course not ! ... it would be a cinch to
> serialize Objects into <structs> provided they do not have circular
> inclusions .... (because XmlRpc does not have a reference tag and will
> always use values for objects).

Yeah, hence "wouldn't" :o)

> So what do you want ? ... this ?
> public static int FooBar
> {
>       [WebMethod("GetFooBar",....)]
>       get
>       {
>               ...
>       }
>       set
>       {
>               ....
>       }
> }
> and get these methods out of it ? "int get_FooBar();" and "void
> set_FooBar(int);" ? ... I think this generates .dgmx with get_Foobar
> and no set_Foobar ... but the Invoke might need some help with that.

That's what I was getting at. Property access is via methods, so just expose 
those methods.
Why not add [WebMethod("SetFooBar",....)] too?

> > Externally property access looks just like member access (and so it
> > should!) so Xml-Rpc and thus all protocols will be fine.
> Hmm.. how about my idea ? "get_" and "set_" methods explicitly ?
> > .... State retention stuff clipped ....
> We have an edge if some of our base classes can offer this facility ? ...
> (because just running IL off a webserver like ASP.Net does not provide
> that). Since we have our own middleware system, we can offer that IMHO ....
> (remember internal calls) ...
> session=DGEESessionManager.RegisterSession("gopal","t3rmin4t0r","*****");
> session.AddKey("name","Gopal.V")... etc...
> and finally send
> session.ToID(); // or ToHash();

Sure.  Something like that.  There would be a session manager GWServer in 
there somewhere.

> ....
> > The original caller (who did the set) gets a session reference back. 
> > When they do the get_ call, the session reference is sent too enabling
> > the execution environment to restore its state and satisfy the request.
> session=DGEESessionManager.RecollectSession(sessID);
> Since we have Goldwater to synchronize between the Apache children, we can
> do this efficently and faster than using a call to a database server !!! ..

Maybe, maybe.  So long as the back back back-end of the session handler in 
the dgee isn't a database itself - but saying that , it'll have a persistent 
connection to the db so would be as fast as we could get it.
Whatever is on the backend storing the states MUST be interchangable.

> And From the looks of it *anything* is faster than ADO.Net :). This however
> requires us to work on the Serialization API which has been unimplemented


> Yeah... Jabber is conversational unlike the "We exist to Serve" attitude of
> HTTP ! .. Jabber means that the server can *push* stuff as well as client
> pull ... And of course you can recieve queued messages via jabber as well.
> (which is like giving a google search, disconnect, come back after 2 hours
>  and get the results)

There is some work to do for Goldwater to support conversational messaging, 
and to resurrect there persistent queuing code that was in place a year or so 
ago.  Things moved on and it didn't.

> IMHO Jabber combines the directness of HTTP with the queuing of SMTP ..
> (which is good , though I don't like the idea of webservice spam).
> A lot of revolutionary stuff is possible with this framework, but we don't
> want to be premature on the market ... But first the foundation design
> has to be complete and rock steady on the development side ... Till then
> let's propose,refine, ad infinitum...

That's the spirit!
That's why I'm keen to get the API sorted out, and to borrow as much on this 
front from MS (the good bits, only the good bits :o) ).
And abstraction!
What we bury under the hood can evolve and grow without (hopefully) breaking 
current usage.

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]