On 2/20/07, George Willis <[EMAIL PROTECTED] > wrote:
I'ld like to open "SDO Ruby" development. See below. ----- Forwarded Message ---- From: George Willis < [EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, February 20, 2007 3:12:53 PM Subject: Fw: JSDO for FLEX/OpenLaszlo to RoR linkage David, This is really a step beyond ActiveResource, where RESTful actions are consumed and abstracted into a multi-tiered intelligent cache, that updates via "push/pull" techniques. Imagine a world where the DOM in an RCI Browser client is actually an intelligent cache that is synced to a business server model. Unbeknown to the RCI client, the business server does not have have any persistence, but is itself another intelligent cache that coordinates the various RCI client concurrency, and acts as an intelligent cache client backended by another server that provides "data mediation" to S3. All the synchronization happens ubiquitously, and RESTful client can also access the "model". This is my dream of JSDO for Rails -- an RCI technology to allow RCI developers to work with "datasets" (DOM), and for the synchronization of concurrency issues to be accomplished via an SDO pattern using javascript and Rails. This may be the most important email you'll read today -- if you actually read it :) George Willis, ex-Fortune 500 J2EE architect turned sane (208) 340-8246 P.S. See the Apache Tuscany project ----- Forwarded Message ---- From: George Willis <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Sue Liu <[EMAIL PROTECTED]>; [email protected] Sent: Friday, February 16, 2007 1:06:22 PM Subject: JSDO for FLEX to RoR linkage I've looked at the various "RESTful" ways of interfacing FLEX/OpenLaszlo with RoR, and they all seem to be taking a step back. Let me explain. Whether you use WebOrb services, SOAP, or REST, you are usually still adhering to a CRUD design pattern. You map four distinct actions on the client side into four distinct services on the server side. (The nature of the new ActiveResource initiative). Now, there is nothing wrong with this, and I'm not trying to get into a flame war. But there have been some better design patterns that have come forth. Before I go on, there is some homework to be done to understand Javascript Data Object and the SDO inititive. http://en.wikipedia.org/wiki/Service_Data_Objects http://www.osoa.org/display/Main/Service+Data+Objects+Home - Note, no Ruby :( http://www-128.ibm.com/developerworks/java/library/j-sdo/ http://dl.alphaworks.ibm.com/technologies/faces4laszlo/faces4laszlo_whitepaper.pdf- SDO for OpenLaszlo to Java (Section 3.4 talks about WDO4JS is synonomous with SDO4JS which was later renamed JSDO) http://www.nyphp.org/content/presentations/ibm/ria-nyphp-overview.pdf - The best article around on this stuff http://sourceforge.net/project/showfiles.php?group_id=173788&package_id=199079&release_id=439723- Faces for Laszlo download Now, if you are still with me, perhaps the lights are on. Basically, some bright folks at BEA had an idea and implemented it in LiquidData. IBM liked the design, and partnered with them to create the formal name of SDO. IBM used the pattern to handle persistence in Eclipse, and then both of them built the pattern into their J2EE servers to enable Ajax. It has since been ported to other platforms, most notibly to enable OpenLaszlo/Java and Ajax/PHP. Let me explain why we should all be interested. Did you ever stop to think about what we were really doing to the MVC model with AJAX/RIA? We are basically caching a submodel (in MVC terms) on the client, manipulating that cloned copy, and then merging it back. The only gotcha is concurrency issues -- others making updates that impact the submodel we are working on. Wouldn't it be great to have a technology to handle all this in the background? That's what SDO is all about. It's is basically the ideal of creating a "dataset" (in SDO and Laszlo terms, "Dataprovider" I believe in Flex) and making that the focus of what the client side code works on. The idea of focussing on datasets on the client side is very appealing. It allows you to substitute test datasets from files or embedded as objects in an RIA client and focus getting the client experience developed. It creates as natural a division of labor as when JSP tags are implemented properly (I know, a stretch). Basically, an RIA UI coder can develop in some RIA syntax (openLaszlo, Flex) using the power of a declaritive format with constraints to provide the interaction between components, and stay focus on this task. The marshalling of the submodel from the server to the client and the merging of submodal changes on the issues of locking and concurrency are handled by standard code. Now, don't get confused when you read this stuff. I'm not talking about trying to use some kind of JSP tag metaphor with RoR. What I am trying to say is there are a lot of pieces lying around to build a truly remarkable architecture that leverages the beautiful ActiveRecord capabilities of RoR and the declaritive UI specification of modern RIA technologies and allow both to do their jobs well and loosely coupled. This is the beauty of the SDO design pattern, and there is already a javascript implementation of it that IBM wrote that does the server to RIA client bridgework!!!! Do youe here what I am saying? Imagaine developing an app in Flex or openLazslo and getting the RIA client done using generic datastes from xml files. At the same time, you develop you database model using ActiveRecord migration techniques. All that's left is to get a DOMish submodel up to the client to manipulate and than handle merge and excetions from concurrency. This last part is exactly what SDO does. No calls to Create, Request, Update, or Delete -- just work on the client dataset, and changes are reflected back to the server. Optimistic locking automatically engaged, exceptions thrown on the occasional concurrency issue of updating the same data. In essence, a "smart cache" that take care of it's own housekeeping. This is what I would love to see -- Flex/OpenLaszlo on the front end, RoR on the backend, and JSDO as the "smart cache" to surface the model to the client. The must radical part is -- all the hard work has been done. JSDO ships with every version of Websphere as a javascript library to handle to browser side dataset implementation. The server side has reference models in several other languages, including PHP. Does anyone else out there feel the passion? -George Willis
Hi George. I've not soaked up all of the thoughts you have in you mail but SDO in Ruby sounds like a good idea in itself. If that could also be extended to provide a more coherent data model between RIA and server then that would be an interesting scenario. A little background info in the mean time. We currently have SDO implementations in Java and in C++ (the Tuscany Native runtime) in Apache Tuscany. I, along with others, also contribute to a PHP PECL extension ( http://pecl.php.net/package/sca_sdo ) where we have an SDO implementation for PHP. This actually uses the Tuscany C++ SDO implementation under the covers so we may be able to share some lessons here about implementing SDO in a server side scripting environment. I would say that we are not pushing SDO to the level that you are talking about just yet but anything we can do to make it more useful and develop motivating use cases has got to be a good thing. There is Ruby script support in both the Java and C++ SCA runtimes. This allows you to use Ruby scripts as SCA component implementations. To date I've only played with the Ruby support in the C++ SCA runtime and in this case there is no SDO support. Instead, for doing XML things you need to use the Rexml package. Regards Simon
