Re: [DotGNU]Message passing between webservices

[Chris Smith]

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
> IIRC.

absolutely.

> 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
-- 
Chris Smith
  Technical Architect - netFluid Technology Ltd.
  "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
  E: address@hidden  W: http://www.nfluid.co.uk