Re: [DotGNU]Message passing between webservices

[Peter Minten]

Gopal V wrote:
> 
> If memory serves me right, James Michael DuPont wrote:
> > You are talking about creating a new set of attributes (they are not
> > implemented yet) that will allow for the specification of messages
> > using c#?
> 
> DGEE is using [WebMethod] attribute for identifying exposed methods
> right now ... would this be that different ? ...

I've looked into the DGEE code, DGEE uses the following 2 attributes:

WebMethod with arg Description.
WebService with args Description and Namespace.

The WebMethod attribute seems to be a bit like the PublishedMember attribute I
use (the one with description="foo", :-), but PublishedMember is meant for
variables too.

Might I suggest a new setup?

I was thinking across the following lines:

* Classes, class members and object members become visible to the internet when
you publish them, publishing means that the class and it's metadata become
visible from the internet.

* Webservices are not defined by putting [Webservice] above a class but by
creating an webservice object.

* A class becomes accessible as part of a webservice when you put
[PublishedClass(ws="webservicename")] above it. The description can also be set
in the PublishedClass attribute.

* A member of a published class becomes automatically part of a webservice
unless [UnpublishedMember] is put above it. The description of a published
member can be set using [PublishedMember(description="foo")]

Thus we would get the following classes:
PublishedClassAttribute
PublishedMethodAttribute
UnpublishedMethodAttribute
Webservice

> Except for one major difference ... XmlRpc does not allow you to call
> instance methods that well ... So the get_Property,set_Property does
> not work very well ...
> 
> Though static properties should be settable , we have multiple VM
> instances running and HTTP is stateless .. So
> 
> a.set_X(42);
> print a.get_X();
> 
> might not always give 42 ... if it gets handled by different VMs in the
> DGEE message buffer/scheduler ?.. This is the case for php or mod_perl
> or cgi unless they use an external data store ...

That's why I'm pushing Jabber-RPC as primary DotGNU protocol, since it has state
(I use the id attribute as session key and asume that RPC calls are blocking.
This of course also means it will be rather hard to use DotGNU with Apache.
 
> This might be something we could add as a Goldwater server like DGEE
> or something like the age old database server :) ... (IMHO a simple
> hashed dictionary would be useful for small stuff, and a database for
> the big & bulky) ..

Good idea.

> Remote updation is risky business ... atomicity,reliability and concurrent
> writes are some of the "well studied" problems ... my textbook instincts
> suggests liberal use of locks....
 
> > have long thought that C# is an ideal specification language for
> > interfaces.

It pretty much rocks there, can't think of a better language for this kind of
thing :-).

Greetings,

Peter