Re: Lack of extension
Posted: Feb 25, 2007 9:57 PM
Lots of interesting things in your response...
> One of the more interesting things about this comment is
> the fact that the web is so unicast while the rest of the
> world is so multicast. The scale up required to support a
> multicast style of communication is not really possible
People are doing it now! Go to this site:
There is a lot of info there. But if you download and run the Just for kids distribution you will be amazed. Seeing Firefox run in a 3D collaborative space is amazing. These people have built "The Matrix".
> A key Java technology that everyone passes over is Jini.
> Jini is now officially an Apache podling as the River
> r project. Jini provides a very secure, extensible
> platform for the use of mobile code as a late binding
I like Jini too. I've never understood why Sun never marketed it harder and chose to focus on RMI and EJBs, even after CORBA had shown the limitations of a static "IDL" approach.
> The ServiceUI standard provides a simple extensible
> standardization of a Entry implementation that allows UIs
> to be dynamically added to services by 3rd parties who
> have control access to the service registrations.
The issue possibly with Jini is that Java is not late-bound itself. So an Interface is OK, but what happens when that interface needs to change? Say you want to add an aditional message to a service what happens? The true meaning of polymorphism is "many forms" and following a change in form the exisiting clients should still work. With Java the verifier would see the changed service as a new interface.
Alan Kay and his team wanted to use Java for Croquet and where forced to re-implement Smalltalk themselves (Squeak) because of these types of limitations.
> Because Jini services capitalize on interface based
> programming, the functions of the service are
> programatically visible to the same tools that you use for
> writing code in your IDE. Because it utilizes the
> security features of Java and extends them for the mobile
> code environment, you can achieve a wide range of security
> based control of what is downloaded, who executes it, and
> what authentication you pass around to services you are
I've never used Jini and it would be interesting to see how far you can go with it. My concern though is that with a statically compiled language, all you have a runtime is a collection of bits. So the runtime may not present the required meta features to support what you are suggesting fully. What you would want to do is inspect objects remotely, perhaps read dcoumentation on methods remotely, and send messages and see what responses you get. I know in Smalltalk where each class is an object that can be manipulated, inspected and extended at runtime that all this is possible. The meta facilities in Java though are rather weak.
> This is precisely what the applet paradigm should have
> started out as, and what Java web start should had started
> with. Instead, we have the concept of small applications
> (applets) and seldom changing codebases of large focused
> applications (java web start's download optimization) as
> the platform supported paradigms of distributed
> application deployment strategies.
What a lot of people do not understand is that java was produced in a hurry. Sun saw it a a strategic tool in their battle with Microsoft. The last thing the Oak designers had on their minds was the internet, they where more concerned with toasters :^).
> Jini is targeted at late binding everywhere. It allows
> the exploit of smart proxies to create new, appropriate
> wire protocols to help applications optmize their
> behaviors over time by distributing method calls to
> multiple services or otherwise map an existing interface
> e for backward compatility onto new service
> Because of interface based programming and because service
> discovery is used to "find" the service providing the
> implementation of the needed interface, the implementors
> are free to change the backend implementation in anyway
> they want. They can support old and new implementations
> through the same service object downloaded by all
> IDEs can programatically do discovery of services for
> developers and show them all of the bits of the service
> definition (no WSDL required).
I like the no WDSL! But static interfaces have their limitations too.
> The uniformity of the REST "API" is only a redherring in
> the mix of security, interoperability and extensibility.
> Behind the scenes, client and service software must still
> l be written. Servlets in java or some other parallel in
> another language have to exist. Clients have to use APIs
> that allow them to use HTTP effectively.
I agree, but you do need a common substrate to build on. In dynamic OOP it all starts with the message. With a message you then can start to ask an object questions (whilst knowing nothing about it's implementation). What methods do you have, what can you do? am I allowed to access you? All these things can be addressed with messaging and a meta-protocol that is common to all objects. Again take a look at Croquet.
BTW. I believe that Jini has the same idea of a common substrate. For Jini I believe it is the "lookup".
> > BTW. I would urge you to check out Strongtalk. It's
> > it has message sends, it's dynamically compiled and it
> > static type checking. Strongtalk shows what's
> > possible when marketing and politcs are put to one
> Does it include mobile code and a security model? In this
> world of come as you are computing, security is vital to
> help users get the most out of the mobile code paradigm.
Yes to mobile code. This is why the dynamic compilation is so important. It will compile byte code to machine code on the fly. When a polmorphic message send hits a new method (for example I have changed implementation dynamically), then the VM will de-optimise back to interpreting byte code which is then later compiled. So the implementation can change while the program is still running, all hidden behind a message send.
As for security, like I said this can be implemented as a meta protocol using messaging. I believe this is the approach they intend to use with Croquet.
So technically all these things have been possible for a long while. Strongtalk was designed and built in 1995, before being bought by Sun and buried. The Strongtalk developers went on to work on the Java JIT "hot spot" VM.
So technically all this is possible.