I am a bit saddened by the Open Source community mainly siding behind REST. REST will not get you there, I hope you guys know what you are doing, because this could be a historical mistake. I don't see any serious open source Composite Application Platform.BTW, many of the links are broken on your site.
Classic.
Final Update:
Bottom line: for the current implementation of JRuby implementing this does not seem possible. A near-future release is supposed to improve on the Java/Ruby integration. In this case what is needed:
PyInstance class (a Java class) in the Jython implementation.
newInstance() in Java also creates a corresponding JRuby instance. Similar to the JythonPropertyHandler class I defined in Jython, corresponding to the JRubyPropertyHandler class I attempted to define in JRuby, below.
Sometimes I drink to forget, and sometimes I just forget. Several years ago I blogged about using JXPath to query Jython objects. Sometime since then I forgot all about JXPath. I remember it now being fairly simple, and working with all kinds of structures. (And so JXPath should be a fairly simple way to use XPath to query JSON objects in Java, BTW.)
I started playing with JRuby recently to see how it's doing. When I came across the Jython code I just mentioned, I thought I'd try the equivalent in Jruby. Here's what I have so far, but I have two question marks preventing it from running. I sent them to the JRuby users list, but if anyone reading this has an answer or a hint, I'd appreciate that.
It's that call to
class JRubyPropertyHandler
include org.apache.commons.jxpath.DynamicPropertyHandler
def getPropertyNames(robject)
return robject.instance_variables.to_java
end
def getProperty(robject, property)
if robject.instance_variables.include?(property)
robject.instance_variable_get(property)
else
nil
end
end
def setProperty(robject, property, value)
robject.instance_variable_set(property, value)
end
def JRubyPropertyHandler.register()
introspector = org.apache.commons.jxpath.JXPathIntrospector
introspector.registerDynamicClass(???, ???)
end
end
registerDynamicClass (javadoc) that has me stumped. The first argument is a class of all the instances that should be handled by JRubyPropertyHandler.
The second argument ideally should just be JRubyPropertyHandler. i.e. not an instance of the handler, but the handler class itself.
I tried calling...
But these two arguments are each instances of
introspector = org.apache.commons.jxpath.JXPathIntrospector
introspector.registerDynamicClass(Object, JRubyPropertyHandler)
org.jruby.RubyClass, not java.lang.Class as needed.
In Jython the two arguments to register a handler are PyInstance, the Java class that is the superclass of all Jython instances, and the handler class itself. The code for my working Jython implementation is on my original blog post.
Update: from the jruby user's mail list, Nick Sieger drops a good hint, and I have more questions until I can get back to a jirb prompt...
> Perhaps this snippet helps?
>
> $ bin/jruby -S irb
> irb(main):001:0> class Foo
> irb(main):002:1> include java.lang.Runnable
> irb(main):003:1> end
> => Foo
> irb(main):004:0> Foo.new.java_class
> => $Proxy7
Thanks. Maybe. I'll look into it when I can get back to my jirb prompt.
That will work for the second argument *if* it implies that when the
jxpath java code creates a new instance of $Proxy7 then what actually
happens is a new jruby instance of Foo is created.
But what does this say about all jruby objects?
i.e. in jruby, they are all instances of the class Object, but if I do
the following...
o = Object.new
j = o.java_class
...then can I assume that all jruby objects are (in java-land)
instances of a java class that inherits from "j"?
Or is the java_class $ProxyN class more of an on-demand, dynamically
generated, bridge to the other world?
Cincom VisualWorks Smalltalk is an extremely mature, efficient implementation of a dynamic language runtime. James Robertson points to one of the payoffs, running Seaside, on VW Smalltalk...
I tested: Seaside 2.8 in Squeak (using the "one click experience" image), Seaside 2.7 on VW, and Seaside 2.8 on VW - the latter required the under development release that's coming. Here's a summary of what I got:If you are looking at Ruby on Rails or a similar dynamic language web framework, there should be several reasons to put Seaside and VW Smalltalk on your list of options.
Platform Sessions Avg Sessions per Second Avg Pages per Second Seaside on VW 7.5 97 1.62 17.9 Seaside 2.8 on Squeak 370 6.17 48 Seaside 2.8 on VW 7.6 582 9.7 79.4 ...
Also relevant is this: In Seaside 2.7 on VW, pages per second started off at 34, and then dropped to 10 by the end of the one minute test. Squeak dropped from 50 to 45.5, which is pretty stable. VW 7.6 with Seaside 2.8 started at 81, and dropped to 79.5 - which is even more stable.
Update: James updates the tests and brings in Ruby on Rails for comparison. Seeing an "engineering shootout" shape up among these variations would be a fun time. Let various teams engineer the bits out of their own stacks on fairly similar functionality. (Of course a Ruby on Rails on the VW virtual machine would be fun too. :-)
Gemstone Seaside guru, Dale Henrichs, reminds me in the comments:
Patrick, don't forget that there's another mature dynamic runtime system out there that provides transparent persistence along with pretty good performance that even scales across multiple cores... benchmark.Sorry, Dale!
Get hooked on Seaside, then get hooked on Smalltalk.
I have not brought out the Kimball in a while. Recently Bill de hÓra linked to the collection of Kimball articles, but without context. The thing about Kimball's design approach is I've found applications of it, at least significant aspects of it, to several systems beyond data warehouses. Understanding the essence of Kimball's approach should be a fundamental part of a software developer's education.
One reason for this is the Kimball approach is a form of domain-driven design. Another reason is the technical aspects are relatively simple. And so the result is not a be-all and end-all solution to everything, but it is a tool with legs the go beyond the original intent.
The Kimball approach has influenced how I think about objects, data, and (from this 2003 blog post) integration...
His keys to an effective virtual database (or data bus architecture in his words) is conformed dimensions, smallest grain facts, etc. Most of these principles apply to the largest data warehouses or the smallest databases, and would benefit any Enterprise Information Integration effort.What is the web, but a kind of large "virtual database"?
At the time I was in the middle of a large project integrating several systems with a new installation of the SAP FI-CO general ledger module and those systems with a new Teradata data warehouse. We more directly applied these ideas to the warehouse, but generally to information exchange.
Today with groups looking at Restful web services centered around resources, representations, and relationships/links among them, the Kimball approach also applies. It is domain driven, concerned about the entities and activities of the enterprise.
Until we get more analysis patterns from real-world, machine-machine Restful web service applications, the Kimball approach to, and examples of, information management should probably be a key ingredient of this kind of design. We should, of course, expect some similarities in the domain view of information across systems integration, data analysis, and the web of documents and events.
