Hosting the CLR or the JVM?
I saw this interesting post, which I'm extracting in its entirety:
Cameron Purdy wrote,So that gets me thinking.... What about from VisualWorks? I take the above stuff as glossing over the difficulties and making it sound too easy, but still....So I saw this interesting blog entry. The interesting thing with .NET is that you can actually run the JVM inside the .NET process and use a product like JNBridge to semi-transparently access the one from the other. The best of the Java world easily available in .NET, sans the web services overhead. Could that mean software-level peer-to-peer clustering for .NET? (Heh.) Stay tuned.It goes the other way, too. The CLR can be hosted from a process started by the Java bootstrapper, just as well. For example, I've got some JNI code called from a webapp that loads the CLR and calls into the ASP.NET runtime. At this point, all I'd need to do is (a) build the appropriate HttpRequest class in .NET that knows how to extract the HTTP request data from the servlet HttpServletRequest and HttpServletResponse objects (as well as a few associated others), and (b) set up the webapp to map .aspx, .ashx, .asmx and a few other extension types to a servlet that does this call-transition, and lo and behold, we have ASP.NET running behind a Tomcat front-end. Depending on how the bindings take shape, you could conceivably have shared session state between both environments, all running in-process. The fact that both environments have a well-documented interface for hosting their respective managed environments and that both environments run entirely in-process is what makes this possible. (About the only thing left, then, is to bind in the Python runtime and we've got just about every language in use today covered. Of course, that process will consume about 100,000 megs of physical memory, but hey, memory's cheap, right? :-) )
Comments
OpenTalk and ServerSmalltalk
[Michael Lucas-Smith] January 28, 2003 0:34:49.888
This would be as simple as making a new object marshaller for the CLR object format. Just like we talk RMI, Soap, etc.. we could talk the CLR Object model with an ASP interface to exchange our CLR objects back and forth between .NET components. That's powerful and it's also easy to achieve. CLR.NET complaince..