Is there documentation I could look at about how Rollbase works under the skin? E.g., is there a database with the property values one has filled out on any given screen? Is code for a page corresponding to one page of data expanded on the fly on demand? Or is the code generated on save? If one's ideas change about what code should be generated for any given set of property values, is there a mechanism for getting fresh code? Are the templates or whatever behind this something which a serious development group could modify or are they prescribed by the current release? Is there a run time engine which "executes" the properties?
Obviously, there are only so many questions one can ask until one knows a bit about what to question?
The reference document for Rollbase is Rollbase In Action (www.progress.com/.../Rollbase_in_Action.pdf) and is already quite exhaustive. We however do not publish information about how Rollbase works internally.
I will have a look at that, thanks. I'm not looking for a detailed look at the internals, but more of a conceptual sense of what it is doing. E.g., with OE BPM I can understand the modeling and its relationship to BPMN and how there is a runtime engine to execute those models. From even that little amount I can know a fair amount about the conceptual structure without knowing anything of the particulars. One of my big interests is evolvability, e.g., what happens when requirements change or when the technology changes and with it our ideas of desirable architecture. OE BPM and Corticon should evolve nicely with technology changes because those will happen in the run time engine and one expects that the same models or rule sets will execute on the new platform. Both are also going to be good at responding to requirements change since the needed change can be made at the model level, thus very rapidly, with little work, and with little concern of "breaking something" because one is working highly abstracted from the implementation. Both may have issues of upgrading to an ISV's new version if they have extensively altered the original rule set. I am hoping to get a similar impression of the evolvability of Rollbase.
Having flipped through the document, I am not finding the kind of conceptual overview that I was looking for. Lots of nice detail about how to do things ... lots of stuff that I didn't know was there ... but not what I wanted.
Hi Thomas,
Rollbase does not do code generation. All applications are metadata driven, data is stored to define each object definition and its components, and the platform uses this data at runtime but does not generate code. The Rollbase platform is designed to be backward compatible and customers are shielded from the impact of underlying architectural changes as the platform evolves. We do not have public documents that describe the inner workings of Rollbase and have no plans to publish this type of information in the short term.
Hope this helps,
Matt
It does help. So, you are saying that it is really a lot like Corticon and OE BPM in having a runtime engine driven by metadata so that if the technology evolves, e.g., one adds some new capabilities to the runtime engine, it should just work with the same data ... assuming, of course, that one doesn't change the type of data needed or something, but in any case should remain upwardly compatible.
Yes. Rollbase is meta-data driven. You do have the fallback of adding JavaScript code to add custom behaviors when the built in behaviors don't quite work as you want, but the bulk of the presentation and logical flows are created dynamically at runtime from the meta-data.