[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
> 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
- [DotGNU]Message passing between webservices, Peter Minten, 2003/01/11
- Re: [DotGNU]Message passing between webservices, James Michael DuPont, 2003/01/11
- Re: [DotGNU]Message passing between webservices, Gopal V, 2003/01/11
- Re: [DotGNU]Message passing between webservices, Chris Smith, 2003/01/11
- Re: [DotGNU]Message passing between webservices, Peter Minten, 2003/01/12
- Re: [DotGNU]Message passing between webservices, James Michael DuPont, 2003/01/12
- Re: [DotGNU]Message passing between webservices, Chris Smith, 2003/01/13
- Re: [DotGNU]Message passing between webservices, Gopal V, 2003/01/14
- Re: [DotGNU]Message passing between webservices,
Chris Smith <=
- Re: [DotGNU]Message passing between webservices, Peter Minten, 2003/01/15
- Re: [DotGNU]Message passing between webservices, Chris Smith, 2003/01/16
- Re: [DotGNU]Message passing between webservices, Gopal V, 2003/01/16
- Re: [DotGNU]Message passing between webservices, Chris Smith, 2003/01/16
- Re: [DotGNU]Message passing between webservices, Peter Minten, 2003/01/15
- Re: [DotGNU]Message passing between webservices, Chris Smith, 2003/01/16
Re: [DotGNU]Message passing between webservices, Chris Smith, 2003/01/11