Access Controls

[Tyson Dowd]

On 02-Jan-2001, linas@linas.org <linas@linas.org> wrote:
> Tyson,
> 
> Re: 
> It's been rumoured that Christopher Browne said:
> > CORBA Notification or Event services rather than changing GUIDs all the
> > time.
> 
> 
> We also have Derek Atkin's announcement that he has demo code working
> that does event notification via onc-rpc.  Since soap/xml is our third
> candidate for network services, does it have something analogous that
> we're not aware of?  What's the recommended practice? Also, what
> about Microsoft's .net?  Do they punt on this issue?  Are the .net
> users SOL?

Ok, we are starting to reach the edge of my understanding of SOAP, since
it has been largely driven by need.  I'm thinking of going out and
buying a book on the topic so I don't have to go out on such a limb.

However, my (possibly imperfect) understanding is:

With respect to SOAP, there's nothing builtin.  It's either provided by
your language binding or toolkit, or you roll your own in a pretty
similar way to how Derek has described.

	http://www.extreme.indiana.edu/soap/events/report.html

gives a sample of doing events with SOAP.

SOAP is *just* message passing, an RPC in SOAP is two messages, one of
which happens to be called a "response".  This is what Derek Atkins
described as option 2. in his list of options -- everything is
asynchronous.

I will have to read up more to see what the recommended practice is. 
I suspect it is "whatever you are using now -- just use SOAP to pass
messages".  I think Derek's proposal would work just fine.


With respect to .NET, I'm a bit more knowledgable but it's still and
area that I have read about more than used (but given how new it is,
most people are in that boat).

.NET provides quite a bit of guidance and support when it comes to
asynchronous programming and events.  The event is a built-in primitive
in the type system of the .NET VM.  (I believe it was been built in to
COM+ which was the main technology behind "DNA", and it might have been
added to J++ too).  A class defines the events it can trigger, and you
can subscribe to those events by providing a handler for callbacks (they
call it a "delegate").  Depending on the language you are using to
generate .NET code this might look like an API, or you might have
special keyword support for it.

Their model is basically that the caller makes the decisions about
asynchronous calls, and the callee treats all calls as synchronous. 
The surrounding infrastructure puts wrappers around them to handle
the asynchronous stuff at the appropriate place.  Compilers targetting
.NET are expected to generate according to a particular convention.
SOAP/XML is (I think) completely orthogonal, this stuff happends
regardless.

There are also classes provided that do event logging and all sorts of
things.  I don't know much about them right now.

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd@cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #