You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by George Willis <be...@yahoo.com> on 2007/02/20 23:56:38 UTC
Fw: JSDO for FLEX/OpenLaszlo to RoR linkage
I'ld like to open "SDO Ruby" development. See below.
----- Forwarded Message ----
From: George Willis <be...@yahoo.com>
To: david@loudthinking.com
Cc: maurice.codik@gmail.com
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 <be...@yahoo.com>
To: adobe-rubyonrails-ria-sdk@googlegroups.com
Cc: Sue Liu <sl...@laszlosystems.com>; laszlo-dev@openlaszlo.org
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
Re: Fw: JSDO for FLEX/OpenLaszlo to RoR linkage
Posted by Simon Laws <si...@googlemail.com>.
On 2/20/07, George Willis <betrueto1@yahoo.com > wrote:
>
> I'ld like to open "SDO Ruby" development. See below.
>
>
> ----- Forwarded Message ----
> From: George Willis < betrueto1@yahoo.com>
> To: david@loudthinking.com
> Cc: maurice.codik@gmail.com
> 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 <be...@yahoo.com>
> To: adobe-rubyonrails-ria-sdk@googlegroups.com
> Cc: Sue Liu <sl...@laszlosystems.com>; laszlo-dev@openlaszlo.org
> 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