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.
Erik Johnson (via Stefan Tilkov) wonders what's so bad about the "process this" notion. Jim Webber, a coiner of Mest, spent time in his recent QCon talk on this idea before moving on to a nice exposition of HTTP hyperstuff.
I think I have a reasonable handle on what the HTTP methods generally mean. I've not applied them to a wide variety of situations, and I wonder sometimes where that line and whether some specific use is crossing it too far.
More than that though is I've been playing with XMPP a bit again. Where is that line between pushing HTTP too far and jumping over that line into XMPP for "Mest", ad hoc, "process this", I'm not counting on any of the benefits of HTTPness?
These lines are probably fairly blurry on close inspection, when the programmer does not have a clear set of constraints leaning one way (e.g. GET's benefits) or the other (e.g. presence/status). but I've certainly found running an XMPP server and connecting from various systems at least as easy as doing the same with an HTTP server. And XMPP (over HTTP) runs through firewalls, for better or worse.
Anyway... if you are interested in that "one method to process them all" then why not use XMPP for that, and leave HTTP for more specific duties? Or not. If you are in a Mest then are you saying you have no clear understanding of your resources and constraints and so HTTP POST *is* as good as anything?
Just noodling...
James Snell's story highlights the point I just made in the previous post. The conversation about SOA / WS-* / REST should move forward by experience reports not from vendors or implementors but from people developing real applications...
Those who are familiar with my history with IBM should know that I was once a *major* proponent of the WS-* approach. I was one of the original members of the IBM Emerging Technologies Toolkit team, I wrote so many articles on the subject during my first year with IBM that I was able to pay a down payment on my house without touching a dime of savings or regular paycheck, and I was involved in most of the internal efforts to design and prototype nearly all of the WS-* specifications. However, over the last two years I haven’t written a single line of code that has anything to do with WS-*. The reason for this change is simple: when I was working on WS-*, I never once worked on an application that solved a real business need. Everything I wrote back then were demos.Now that I’m working for IBM’s WebAhead group, building and supporting applications that are being used by tens of thousands of my fellow IBMers, I haven’t come across a single use case where WS-* would be a suitable fit. In contrast, during that same period of time, I’ve implemented no fewer than 10 Atom Publishing Protocol implementations, have helped a number of IBM products implement Atom and Atompub support, published thousands of Atom feeds within the firewall, etc. In every application we’re working on, there is an obvious need to apply the fundamental principles of the REST architectural style. The applications I build today are fundamentally based on HTTP, XML, Atom, JSON and XHTML...
Are average developers and architects able to design ANY system correctly? I think if you look at the history of software development as a whole, you’d really have to stop and wonder about the answer to this question. The fundamental challenge comes down to this: developers get paid for coming up with solutions that work; doing so means learning just enough about a technology so address the immediate need so they can move on to the next line item in their list in order to meet the deadline; this will quite often mean that average developers and architects aren’t even going to bother designing and implementing solutions “correctly”; nor should we ever actually think that they will. The best we can do as tool providers is educate users better and provide excellent tooling that makes it easier to do the right thing. Most of the time the tool developers can’t even get it right tho.
Steve Vinoski puts out a request for comments, of sorts...
I personally know of nobody who has ditched REST for WS like this, but if you have, or if you know of someone who has, I’d love to hear the whole tale, so feel free to leave it in a comment.Maybe the next SOA / WS-* / REST confab should be restricted to experience reports about building real applications.
The couple of posts about QCon so far were parts of my experiment with the email-to-the-blog capability. It's simple and it works, and I did not have to lug my laptop around the conference.
However blogging at a conference wound up with the my usual pattern: start out with some items on the first couple of sessions, then the inevitable happens. I meet people on the breaks and the conversations fill up available time, and are more interesting than anything I could blog about.
So to catch up on some thoughts...
Stefan Tilkov kept a pretty good log of the sessions he attended. He put together the agenda for Thursday's SOA/REST track. That whole day was great fun and engaging. The combination of speakers was pretty much a full complement of who you'd like to hear address the issues from any of the perspectives.
The RESTful presenters overlapped little in their content. Anyone attending (or viewing the videos after -- need a link here) should have come away with a good sense of what it means to work with HTTP rather than against it. I mentioned Steve Vinoski's introduction to REST that launched the day (and subsequent back-and-forth salvos with the WS-* folks.) Pete Lacey demo'd a RESTful expense report example using a browser, command-line scripts, Excel, and Word. Well done. He had a lot more to show -- his suite of examples would make a good hands-on tutorial.
Dan Diephouse (who really knows how to order wine, but doesn't quite know when to stop :-) talked about atompub in particular. The Q&A got into some back and forth on "batch" and other topics that kind of stretch the current atompub specification, leading me to wonder: what does anyone *mean* by "batch" -- I can think of several variations -- and why do we try to squeeze any of these activities into atompub per se? Certainly the feed format is a useful one for learning about the results of batch activity. Finding some RESTful but not necessarily atompub mechanisms useful for "batching" may make some good experiments.
Earlier in the day Sanjiva Weerawarana's session included valid explanations of the complexity of HTTP and atompub, and the effort expended getting atompub settled. My thoughts were that observation does not really speak well about the WS-* specifications. Sanjiva repeated that WS-* are mired in vendor politics, poor implementations, and that we end users should have to understand much about them. Arguments I've heard more than once before, but still make me uncomfortable. Are these supposed to put me at ease?
Well, we went out and had fun later anyway. The WSO2 folks are looking, learning, and supporting REST just like the rest of us. So to speak.
I like that atompub has not attempted to specify too much (yet), and fear things could get out of hand, but at least we have something far simpler and easy to use right now. Technical details HTTP and atompub were discussed all day because doing so is *practical*. They are fairly easy to understand even if there are devils in some of the details. There is little hope or encouragement for taking a similar approach to WS-* and best advice we are given is not to worry about them, let the implementors handle it for you, rely on the "tooling".
Which gets back to Pete's presentation: his use of Excel, Word, Firefox, and Ruby was a great demonstration of leveraging the web. The web has won, of course. Thinking back to the Inforworld SOA conference held a year and a half prior to and two blocks away from the QCon conference seems like light years ago, with vendors pushing all kinds of proprietary nonsense on the unsuspecting.
As Sanjiva joked, the new "RESTful Web Services" book is the New Testament. But REST is more of a science to WS-*'s religion. The WS-* leaders ask us application developers to take a leap of faith following their proprietary tooling. REST / HTTP is simple enough to prove to yourself with the tools at hand.
Oh and Jim Webber's presentation is not to be missed, when you can get to the video. I laughed throughout. (Paul Hammant was at QCon the day before but could not attend Thursday. What I'd give to catch Jim and Paul in the same room!)
Jim's presentation rounded out the REST / HTTP agenda -- his illustration of following a workflow via HTTP makes the whole "engines of hypermedia" or whatever you want to call it very clear.
Thanks, Stefan, for organizing a really great day. The audience discussions were great too, with Stu Charlton and others saying stuff.
Someone posted a link recently to an apparently interesting video. Clicking on the link, this is what I get. I'm sorry, I have to join facebook to see your interesting video?
What about just putting it on the web? Gaws.
Patrick Mueller adds in a comment...
Here's the sad part. The movie is already on the web; FaceBook doesn't actually store anything at it's site, it's all pass-through. The movie might well be at YouTube. All FaceBook does in this case is serve as a bottleneck.
Via Ted Leung...
Ben Laurie has posted some initial information about the Caja (Capability Javascript) project that he is leading at Google.About a month ago I came across some information that Mark Miller is at Google working on capability-based security. Turns out he is on Ben's team. This will be useful stuff for moving web and application security forward.
And it is open, as you might expect.
From Douglas Crockford's The Department of Style...
There is one problem in JavaScript that is bigger than all of the others put together: The Global Object. All compilation units are thrown into a shared global container. This gives each unit full access to all of the other units. All units get exactly the same rights and privileges. This turns out to be a huge mistake. It is the root cause of most of the security problems in the browser...In the long term, I want to replace JavaScript and the DOM with a smarter, safer design. In the medium term, I want to use something like Google Gears to give us vats with which we can have safe mashups. But in the short term, I recommend that you be using Firefox with No Script. Until we get things right, it seems to be the best we can do.
Here's my initial, superficial, and brief, take on OpenSocial, as I understand it so far. There are several aspects to OpenSocial, the top two being that there is a Javascript, "gadgets" oriented part, and there is a server, atompub / gdata part.
The part that interests me most, and that has the wider implications in the long run, is the atompub / gdata part. Facebook can make a proprietary api "more truly open," as Mark Cuban says. But that just becomes the means for more easily having "third party" support for an OpenSocial "gateway", if you will, for Facebook.
In that same article Tim O'Reilly focuses too much (as I read it, solely) on the Javascript / "gadgets" part of OpenSocial. That's missing what will, or should, become the key to OpenSocial having a bigger impact on the web, in the long run, that either Facebook or MySpace. Combined, in my opinion.
There are all kinds of "innovation happens elsewhere" implications of the OpenSocial atompub / gdata part that overshadow "gadgetry". From the OpenSocial docs...
The OpenSocial API is a set of common APIs for building social applications on many websites. There are two ways to access the OpenSocial API: client-side using the JavaScript API and server-side using RESTful data APIs.And so, there is no reason the OpenSocial RESTful APIs, even the Persistence API, have to be served by Google. It seems to me from these docs that Google assumes many sites will support these APIs.
Phil Windley writes about creating a domain-specific language...
I'm a big believer in notation. Using the right notation to describe and think about a problem is a powerful tool--one that we're too eager to give up it seems. People seem to believe that (a) all languages are pretty much the same and (b) the world has enough notations. While (a) is true in theory (they're all Turing complete, after all) the power of a notation isn't in what it can accomplish, but the ways in which it allows you to think. I'll deal with (b) in what follows.
Google continues their "open play" if you will, into the mobile world.
Despite all of the very interesting speculation over the last few months, we're not announcing a Gphone. However, we think what we are announcing -- the Open Handset Alliance and Android -- is more significant and ambitious than a single phone. In fact, through the joint efforts of the members of the Open Handset Alliance, we hope Android will be the foundation for many new phones and will create an entirely new mobile experience for users, with new applications and new capabilities we can’t imagine today.
Openness. Hmm. What a concept.
I sure don't understand Facebook. I never even got up to the MySpace stage. Joe Wilcox watches Microsoft...
As I've repeatedly asserted, Facebook is more like an operating system in the cloud than a Web 2.0 service. No one should understand a "walled garden" better than Microsoft's GM of platform strategies. After all, what is Windows but a walled garden?It's autumn. The garden is turning brown. Joe paraphrases Microsoft...
In a blog post earlier today, Fitzgerald asserts that the "sound and fury" of the OpenSocial announcement "actually underscores the weakness of the hand held by Google and their fellow travelers. While nominally about making it easier for developers to write widget applications that can be hosted across multiple sites, it really shows how few options Google has to try to deflate the twin nightmares that Facebook poses to Google."Probably some truth is in there somewhere. The sound and fury is more Mircosoft's though. I think they're doing more bluffing and OpenSocial is more like calling the bluff.
But like I said... I don't understand Facebook. I know some people who use it reluctantly rather than enthusiastically. This also happens to be the characterization of most of the Windows users I know.
Don't bet against the web. Google has its own agenda, but it is simultaneously helping to build out the web.
Microsoft continues to make many more billions of USD than I can fathom. But I don't see how their walls and Facebooks can hold up in the long run.
