Re: Web Object Services

Thanks for your response Brendan,

> > Object services should address:
> >
> > - instantiation and naming
> > - locations, copy control, caching and mobility
> > - reference management and garbage collection
> > - metadata management
> > - access control
> > - object and object class versioning and update control
> > - introspection
> > - transaction control
> > - event (and fault) monitoring
> > - security
> > - licensing

Brendan Macmillan wrote:

> I think that once the above issues are addresses, "web services" will be
> similar to CORBA over XML...
...
>  (1). corba is a good place to look for ways of addressing these issues, and we
> can learn from what worked, and what didn't.

I agree completely. CORBA represents a rich Object functionality set
which is thoughtfully designed and robust.  Furthermore, CORBA
interfaces can readily be expressed in SOAP/UDDI/WSDL.

>  (2). One lesson of corba is that distributed garbage collection etc is complex
> and difficult.  A strength of web services is simplicity - they are pretty
> close to being the simplest remote method invocation possible.  But when all
> the above features are added, will it still be attractive?

I hope so. First, you can ignore functionality you don't need. Second,
If we were to add object services as HTTP-NG was considering at one time
in the HTTP layer we would be increasing web complexity.  Instead adding
object services as standard Web Services accessible using XML/SOAP we
are not increasing the complexity of the web itself.  Third, we can only
provide standards to allow Web Object environments to collaborate, we
are not forcing them actually utilize or obey the functionality in a
particular way.  Each Object can control it's own management by the by
the Object services it employs, if any, and we would want the object
user to be able to employ local cooperating object management services
for arbitrary Web Objects as well. Integration of certain services, such
as access control, with the web server is highly desirable, but this not
difficult where enterprise services such as LDAP are already in use. 
The use of CORBA as a model would be especially convenient for access to
CORBA based objects the web.

> Also, your point:
> > - object and object class versioning and update control
> is especially interesting to me.  Evolution of classes/objects is very
> important for any long-term solution, and also for loose coupling across
> different applications.  One solution is to make an entirely separate "data
> layer", which handles the translation of objects into a canonical form, and
> which switches on different versions, to select different translation code.
 
We might employ XSL for that purpose.  I have used several very
different techniques in Smalltalk for managing mixed version objects.  I
think our goal here should be to facilitate rather than dictate the
mechanism while establishing relevant conventions.  

In addition to CORBA, we can borrow interfaces for relevant services
from J2EE (JNDI, JINI, JMX(http://jboss.org) etc.) expressed as
XML/SOAP, and perhaps a subset of the Common Warehouse Metamodel (CWM,
http://www.omg.org/technology/cwm/index.htm ) may be useful as well as
UDDI and WSDL applied to objects rather than services.  For certain
services such as mobility we might borrow interfaces from leading
research such as MobileRMI etc. at
http://cui.unige.ch/~ecoopws/ws00/index.html

Borrowing largely from CORBA, I whould think, should simplify our design
process considerably.

>It sounds like the work you are doing is interesting!

At this point I'd be happy if there was a standard way to get a URN for
a URL and URL's for a URN.  Does that exist anywhere? Of course then
I'll want the rest of the meta data...

I am happy you responded, I hope we are not the only two interested.
<smile>


Thanks,

Jim

Received on Wednesday, 29 August 2001 17:44:54 UTC