- From: Adi Oltean <aoltean@Exchange.Microsoft.com>
- Date: Thu, 18 May 2000 11:52:25 -0700
- To: <xml-dist-app@w3.org>
- Message-ID: <19398D273324D3118A2B0008C7E9A56909C91FE8@SIT.platinum.corp.microsoft.com>
> The "SOAP object reference" concept is a declared non-goal of the > current SOAP spec. Therefore capabilities cannot fit naturally in SOAP > design. [Constantine] I think that they will be quite easy to add. [adi] In my personal opinion the problem is not how easy/hard is to add these feature but how do you solve scalability problems that occur. Dealing with object references will limit the scalability of a Web-based component server. Such a server must scale beyond millions of clients per day - and many of these clients may either become unreachable in time as a consequence of bad network conditions or these clients can die unexpectedly. Since each client may create potentially several objects the net result is that you have a huge amount of objects that must be garbage collected. And distributed garbage collection mechanisms is a difficult problem at Internet level. Not to mention that you must keep in-memory state at the server side for the entire life of the object... (which is not needed for lightweight stateless objects that seems to fit very well in SOAP model). The picture looks even worse in capability world since a single object can have many different capabilities - as opposed to a single type of reference - and each capability must be GC-ed independently. > That's because since a capability is nothing more than a > (marshalled) object reference that has associated a set of access rights > which were marshalled together with the reference (because even after > marshalling you must maintain the rule that you cannot perform an action > to a capability unless you have the proper access right to do it). [Constantine] AFAIK Rights are not usually marshaled with reference in implementations I have seen. Pointer representation was generated with secure random number generator and some sort of proxy object lived on server. Implementation like you described was done in e-speak 2.2 (www.e-speak.net). But I do not like it. [Adi] Agree, but that's an implementation detail. From the client point of view both models should look the same (almost). > (check > http://www4.cs.fau.de/~riechman/papers/abstract-smo-nspw-97.shtml for > example) [Constantine] The paper cannot be downloaded (dead link) so I have not read it. [adi] Ok - check http://www4.cs.fau.de/~riechman/papers/nspw-97-meta-sec.ps instead. Thanks, Adi
Received on Thursday, 18 May 2000 15:00:14 UTC