| OOP |
Architecture
Where does the web GET/PUT/POST object system fit in, compared with the object models and type systems of Java, SmallTalk, Objective C, Modula-3, python, perl, Tcl, REXX, ILU, Ada9x, scheme, CLOS, ML, C++?
This is a comparison of systems which specify have not just an abstract model, but also runtime (intra- or inter-process) mechanisms. CORBA in general is not such a system, but the CORBA language mappings and IIOP are.
I should add info on the runtimes of python, perl, tcl, scheme48, Modula-3, and smalltalk-80, as well as inter-process mechanisms used with those languages. Aha! Also plan 9 name/file service protocol (union links)
I should learn enough to add SOM/DSOM, dylan, and commonlisp to this table.
The web column is something of a guess
| Issue | COM/DCOM notes | ILU notes | Java/RMI notes | Web | |
|---|---|---|---|---|---|
| Interface Identifiers | IID is a guuid; by convention/spec, changing the interface requires changing the IID | typeid is a hash of the object type (interface), wich can include a brand | administrative hierarchy (ala DNS) of interface names (java.lang., sun., w3c. ...). I haven't seen any conventions regarding lifecycle issues of Java interfaces | things like HTTP/1.0 are interface IDs of a sort, as are RFCNNN. Accept: headers and PEP protocols affect the interface. Some folks have talked about URLs that refer to collections of Accept: headers or PEP protocols. | |
| Interface Negotiation | QueryInterface | punt to name service | ??? | Accept: headers (ala multi-QI?) PEP protocols. interface info in DNS (webX records ala MX records? path: scheme?) | |
| Object identifiers (accross address spaces) | Monikers (including URL monikers): binding, asynchronous binding | object ID = server ID@object ID. string binding handle has oid + contact infos. Extensible parsing support for URLs, CORBA IORs | ??? | URLs | |
| interface artifacts (files) and naming (interface repository) | many .idl files to many interfaces. Type library maps IID to compiled representation of interface from .idl file for dynamic dispatch | one .isl file to one "interface" (namespace), which can contain many object types (interfaces) Hmmm... some runtime interface discovery? (type info over the wire?) | one public interface per .java/.class file perhaps use foo.jar#interface when multiple .class files in one .jar file | RFC index :-) We've talked about using a link relationship as an interface discovery mechanism | |
| Namespaces and code artifacts (files) | registry maps clsid's to DLL filenames | no direct support for dynamic loading, as far as I can tell | ??? | URLs point to implementations (format, i.e. instruction set can be negotiated) | |
| Code Migration | Custom marshalling | ??? | object pass-by-value including bytecode implementation | GET migrates (well... snapshots) object state | |
| Inheritance of interfaces | Single Inheritance | MI. multiple SUPERTYPES allowed in object types. | SI | ||
| Imlementation inheritance | classes (implementations) can expose (inherit) multiple interfaces. Aggregation models implementation inheritance. Delegation (TIE) is always an option, of course. | Implementation inheritance is a language-runtime issue | Classes can implement (inherit) multiple interfaces, but can only extend (inherit) one superclass | ||
| Return values, exceptions | COM methods must (should?) return HRESULT, ala Tcl_Result: an exit status. MIDL has a [retval] attribute | ILU has both first class return values and typed exceptions. Hmmm... how are exceptions identified? | first class return values and exceptions (which are objects). | NNN result code + one-liner + MIME header/body | |
| Out Parameters | MIDL [out] attribute. COM uses these a lot, N.B. the RIID/void** combo | ISL OUT keyword | how do these map to java? | ||
| Root of object hierarchy | IUnknown (QueryInterface, Addref, Release) |
see runtime/kernel/type.c ILUGetTypes ILURegisterGCInterest ILUUnregisterGCInterest ILUPing -is-a /* for CORBA support */ |
CORBA object reference operations. | GET/POST? | |
| Asynchronous methods | not implemented in DCOM so far, so I hear. I suppose there's a MIDL attribute (or one could be added) | ILU has an ASYNCHRONOUS keyword. Supported inTCP and UDP (hack!) transports. | |||
| Resource management | AddRef/Release. PING sets (see DCOM internet draft) | COLLECTIBLE keyword (implemented -- at some level -- using reference counting, as I recall) | implicit storage mgmt (weak refs? finalization?) | Referrer: gives clues about in-links. We should work towards mechanisms that make the web "eventually consistent" |
HMMM: GET is kinda like
bind("http://...").walk(accept-headers).openReadClose()
all in one round-trip.
perhaps format negotation/PEP negotation and QueryInterface relate in some way: model each combination of request headers and return types as a separate method signature. Then consider the GET method as horrendously overloaded. Or another way to look at it: a zillioin different interfaces with subtly different GET methods.
Have a look at burchard's model for starters. (as he says, the IDL needs spec annotations. What was that larch-like thingy I saw for IDL? And I also saw a CORBA/Larch reference... levinson, I think).
Hmmm... URLs that represent DII invoke stuff (aka IDispatch::invoke) from DOMC workshop.
What are the Patterns for the web?
The web is a collection of documents, which have similar structure and intent; concurrent get()s, atomic put()s and delete()s...
See: www.isl