The Excel object model is really a COM/IDispatch object model... it's been accessible from non-VBA applications essentially since the beginning.
Not Excel, but one of my first consulting projects was at a company that developed some custom libraries in Java and for a company that used ASP for the front end. The architecture we used ran the Java code in the Microsoft JVM, which then made Java accessible via IDispatch (and therefore by ASP's scripting engine).
IIRC, we were doing stuff similar to this:
let javaObject = CreateObject("java:com.company.library.ApiClass")
print javaObject.version
This is essentially a part of the 'embrace and extend' functionality that MS added to Java and got sued by Sun over. (There were also mechanisms for relatively easily calling into Windows from the MSJVM too... it felt an awful lot like the Proto-CLR that it was.)
At the moment the implementation is to basically inject code, but I imagine eventually Microsoft would like to move away from that.
Issues like DCOM and legacy systems would need some interface from Microsoft of course to handle IDispatch, GC etc, but thats what Microsoft do.. And to behonest, as much as I like to rip on them, they do it well.
Edit: I think the Java example is a little bit different, but i don't know anything about Proto-CLR!
Not Excel, but one of my first consulting projects was at a company that developed some custom libraries in Java and for a company that used ASP for the front end. The architecture we used ran the Java code in the Microsoft JVM, which then made Java accessible via IDispatch (and therefore by ASP's scripting engine).
IIRC, we were doing stuff similar to this:
This is essentially a part of the 'embrace and extend' functionality that MS added to Java and got sued by Sun over. (There were also mechanisms for relatively easily calling into Windows from the MSJVM too... it felt an awful lot like the Proto-CLR that it was.)