Board index » delphi » Re: OPF and RemObjects/Data Abstract

Re: OPF and RemObjects/Data Abstract


2003-07-28 02:06:21 AM
delphi175
Rob Schuff writes:
| Just curious if anybody here who really knows OPFs well has looked at
| Remobjects / Data Abstract with an eye towards evaluating if/how the
| two might fit in with an OPF.
From what I can see, RemObjects seems to be an SDK to various Windows
services and access to SOAP and Web services.
Data Abstract is simply a common API wrapper to different data backends
using the same data access components.
My OPF autogenerates SQL, reading portions of SQL clauses from a 'database'
component that dispenses them along with abstractions of transactions and
queries that can be implemented for different RDBMSs. So for me, Data
Abstract would not be necessary but could be useful if you wanted to save
about an hours work for each flavour of DB.
My personal feeling is that RemObjects has very little to do with OPFs and
Data Abstract is not worth getting for the limited use I'd make of the
components.
Joanna
 
 

Re: OPF and RemObjects/Data Abstract

"Rob Schuff" wrote
Quote
RemObjects / Data Abstract with an eye towards evaluating
if/how the two might fit in with an OPF.
Don't know if anyone has built an OPF on RO/DA, or adapted their existing
OPF to use it, but if so haven't seen it discussed here.
RO/DA are enabling technologies for moving objects and data between process
contexts (with the client and server processes on the same or different
machines). As such, they address core tasks that OPFs generally require, and
I don't see any reason why the two would _necessarily_ conflict.
Of course, the devil is in the details, and it is a characteristic of OPFs
that they change the nature of the persistence problem. An existing OPF
design might require considerable adjustment to run over RO/DA--so much so
that it would be easier to simply start over by extending RO/DA until a full
OPF implementation had been achieved.
Finally, most OPF designs (as Joanna explains) already undertake the
responsiblities of abstracting the specific data store in use and generating
or otherwise obtaining appropriate SQL statements to run--a task that DA
apparently also addresses--so that might or might not present a problem in
trying to weld one to the other unless the OPF was designed specifically to
use DA.
It's an interesting question.
bobD
 

Re: OPF and RemObjects/Data Abstract

"Joanna Carter" <XXXX@XXXXX.COM>writes
Joanna,
Quote
From what I can see, RemObjects seems to be an SDK to various Windows
services and access to SOAP and Web services.
I don't understand what you mean with "SDK to a various Windows services"
but ROSDK is a remoting framework which allows you to build Smart Services,
aka services accessible through a variety of network and messaging protocols
at the same time (i.e. BIN over TCP + SOAP over HTTP + BIN/SOAP over SMPT,
etc), compressed and encrypted. A service is a remote business object with
methods. Also RO works on Windows, Linux and .Net (client only for now on
.Net).
Quote
Data Abstract is simply a common API wrapper to different data backends
using the same data access components.
Actually DA is *much* more than that.
DA is a cross-database framework which allows you to completely abstract the
data access layer of an nTier system and separate it from the physical
structure of the DB as well as the components you use to access it.
For instance you can write a client application that targets at the same
time Northwind on MS SQL and Employee.gdb on Interbase.
And of course, DA doesn't expect you to start your DB from scratch but
allows you to use the specific SQL syntax of your RDBMS and stored
procedures.
Quote
My OPF autogenerates SQL, reading portions of SQL clauses from a
'database'
component that dispenses them along with abstractions of transactions and
queries that can be implemented for different RDBMSs. So for me, Data
Abstract would not be necessary but could be useful if you wanted to save
about an hours work for each flavour of DB.
This is one of the things DA does as well BTW but it is just a very smal
subset of the framework.
We also have macro processors which adapt SQL to target the SQL syntax of
your target DB in order to minimize SQL written.
i.e. SELECT * FROM Orders WHERE OrderDate>{AddTime(GetDate(), -1, week)}
This for instance would get translated in MS SQL in one way while in IB and
Oracle in different ways.
For complex SQLs that need to use SPs or TSQL/PL-SQL syntaxes you have
statement collections.
Quote
My personal feeling is that RemObjects has very little to do with OPFs and
Data Abstract is not worth getting for the limited use I'd make of the
components.
RO has *nothing* to do with OPFs and neither does DA which starts from a
totally different perspective on data access (similar to Data Objects
included in C#Builder by the way). Of course, we find that a better way but
this is very personal ;-)
--
Regards,
Alessandro Federici
RemObjects Software, Inc.
www.remobjects.com
Best Communications Tool In 2003 Delphi Informant Readers Choice Awards
 

Re: OPF and RemObjects/Data Abstract

"Bob Dawson" <XXXX@XXXXX.COM>writes
Quote
I don't see any reason why the two would _necessarily_ conflict.
They wouldn't at all.
RO can remote anything and it is built with that in mind.
It doesn't depend on TDatasets, doesn't need you to use them or anything
like that.
Pure breed remoting ala .Net that you can use however you want (i.e. to
internet enable a Bold or IsnatntObjects app for instance).
Quote
Of course, the devil is in the details, and it is a characteristic of OPFs
that they change the nature of the persistence problem. An existing OPF
design might require considerable adjustment to run over RO/DA--so much so
that it would be easier to simply start over by extending RO/DA until a
full
OPF implementation had been achieved.
That is beyond our goals. You can integrate any existing OPFs with RO and DA
starts from a completely different approach which is designed for
distributed, multi-tier applications. Also DA doesn't assume you are at
freedom to start a DB from scratch and simply adapts over existing ones.
Quote
Finally, most OPF designs (as Joanna explains) already undertake the
responsiblities of abstracting the specific data store in use and
generating
or otherwise obtaining appropriate SQL statements to run--a task that DA
apparently also addresses--so that might or might not present a problem in
trying to weld one to the other unless the OPF was designed specifically
to
use DA.
DA generates SQL automatically too, of course.
Between the BusinessProcessor components and the Schema Modeler you can
potentially write apps without ever writing a single line of SQL. But when
you want high performance, this is of course not possible so that is where
the rest of the framework comes handy ;-)
--
Regards,
Alessandro Federici
RemObjects Software, Inc.
www.remobjects.com
Best Communications Tool In 2003 Delphi Informant Readers Choice Awards
 

Re: OPF and RemObjects/Data Abstract

Alessandro Federici - RemObjects Software writes:
| RO has *nothing* to do with OPFs and neither does DA which starts from a
| totally different perspective on data access (similar to Data Objects
| included in C#Builder by the way). Of course, we find that a better way
| but this is very personal ;-)
So, it is very much horses for courses?
I just want to make it clear that my opinion was based on a cursory glance
at the blurb on the web site, not an educated opinion. I have no problem
with the products, just would not use them myself.
:-)
Joanna
 

Re: OPF and RemObjects/Data Abstract

"Alessandro Federici - RemObjects Software" wrote
Quote
You can integrate any existing OPFs with RO
Wouldn't deny it. As before, however, the devil is in the details. I'm
simply not aware of anyone who's done it.
Quote
DA starts from a completely different approach
Things get more problematic here, because DA undertakes several
responsibilities that OPFs generally also address: db abstraction, SQL
generation, metadata management (data dictionaries of various sorts). For
example, an OPF might track for an object attribute
--input field display name
--constraints (length if string, etc)
--whether the field is considered searchable
(e.g., does the owning object spport ad-hoc query
generation based on or including the field)
[if the owning object is grid-displayable]
--visibility and display order
--column heading
[and by database]
--supporting table/view and field name
--whether the field is nullable
etc.
To the extent that DA also addresses these tasks, it would appear to be
either duplication/overkill, or else (more positively) a service layer that
an OPF could really take advantage of, if designed from the start to do so,
and if DA exposes its services in compatible ways.
Quote
[...] DA doesn't assume you are at freedom to start a DB from
scratch and simply adapts over existing ones.
DA's understanding that 'the object model is not necessarily the data model'
is extremely attractive, in that while my own OPF also has a contractual
rather than shared model relationship with the supporting database(s), I'm
not aware of any commercially available OPF that has this characteristic.
Even the newest OPF (forthcoming from DevExpress) appears to assume that the
object model owns the database--a bad assumption if one is not doing
green-field work.
bobD
 

Re: OPF and RemObjects/Data Abstract

"Joanna Carter" <XXXX@XXXXX.COM>writes
Quote
So, it is very much horses for courses?
?
Quote
I just want to make it clear that my opinion was based on a cursory glance
at the blurb on the web site, not an educated opinion. I have no problem
with the products, just would not use them myself.
It was clear and I didn't take it in a bad way ;-)
But because of that I had to describe what they really are <G>
--
Regards,
Alessandro Federici
RemObjects Software, Inc.
www.remobjects.com
Best Communications Tool In 2003 Delphi Informant Readers Choice Awards
 

Re: OPF and RemObjects/Data Abstract

Quote
They wouldn't at all.
RO can remote anything and it is built with that in mind.
It doesn't depend on TDatasets, doesn't need you to use them or anything
like that.
Pure breed remoting ala .Net that you can use however you want (i.e. to
internet enable a Bold or IsnatntObjects app for instance).
A moment please!.. so, if i understand, i can send/return any kind of
object? So, is possible to get a BOLD object and play with them??
In the modeldriven groups i read a lot of complains mainly in the
remote-communications (like webservices, n-tier, com+, across netwaorks, bla
bla)
I plan to use Bold in the near future but i don't like be tied to COM+ or
.NET remoting, so i want to see how work together BOLD+RO...
The weak point (my opinion) in the current bold implementation is that is
not multi-tier friendly...
 

Re: OPF and RemObjects/Data Abstract

Bob Dawson writes:
Quote
"Rob Schuff" wrote
>RemObjects / Data Abstract with an eye towards evaluating
>if/how the two might fit in with an OPF.

Don't know if anyone has built an OPF on RO/DA, or adapted their
existing OPF to use it, but if so haven't seen it discussed here.
I have done just that. My OPF is able to read/write to local XML files,
or it can communicate with a local RemObjects based server via Windows
COPYDATA messages (all built into RemObjects) which handles the
abstraction to different DBMS backends, or it can communicate with the
same RemObjects based server across a network or the web using
compressed XML via http.
RemObjects is a joy to work with. It can be as data-oriented or
object-oriented as you want. It supports a wide range of objects, both
primitive and complex, and uses a CORBA like approach to generating
interface stubs for the client and server. You have a choice of plug-in
transport mechanisms and you can easily add your own. I thinking of
implementing RFC1149 (look it up!) - I can not foresee any serious
problems, such is the ease of use that RemObjects offers.
--
Cheers,
Carl
 

Re: OPF and RemObjects/Data Abstract

Quote
Carl, how would you feel about writing a small sample we can include in our
next build and show to the Bold community?
And write an article to go with it and publish it on the BDN?
Cheers,
Jim Cooper
____________________________________________
Jim Cooper XXXX@XXXXX.COM
Tabdee Ltd www.tabdee.ltd.uk
TurboSync - Connecting Delphi with your Palm
____________________________________________
 

Re: OPF and RemObjects/Data Abstract

"Jim Cooper" <XXXX@XXXXX.COM>writes
Quote
>Carl, how would you feel about writing a small sample we can include in
our
>next build and show to the Bold community?
And write an article to go with it and publish it on the BDN?
Interesting idea.
 

Re: OPF and RemObjects/Data Abstract

Quote
>>Carl, how would you feel about writing a small sample we can include
in
our
>>next build and show to the Bold community?
>And write an article to go with it and publish it on the BDN?

Interesting idea.
How about a more fundamental article surrounding a source of confusion:
Comparing/contrasting DataAbstract to OPF's.
You can use Ambler's OPF requirements paper as a reference.
 

Re: OPF and RemObjects/Data Abstract

"Brian Moelk" <XXXX@XXXXX.COM>writes
Quote
How about a more fundamental article surrounding a source of confusion:
Comparing/contrasting DataAbstract to OPF's.
Hmzzz....
Not sure how to tackle this one.
Any suggestions?
Quote
You can use Ambler's OPF requirements paper as a reference.
URL?
 

Re: OPF and RemObjects/Data Abstract

Quote
>How about a more fundamental article surrounding a source of confusion:
>Comparing/contrasting DataAbstract to OPF's.

Hmzzz....
Not sure how to tackle this one.
Any suggestions?
You could discuss things like: an OPF typically wants total control over DB
schemas vs. DA approach of leveraging/mapping existing DB schemas.
I'm guessing here: DA doesn't go as far as a traditional OPF in terms of
encapsulating/translating objects, but offers a richer, more flexible
framework.
Could even extend to "How to write an OPF using DA".
One thing I am curious about DA is: does it support TTables or navigational
based Data storage?
Quote
>You can use Ambler's OPF requirements paper as a reference.

URL?
www.ambysoft.com/persistenceLayer.html
 

Re: OPF and RemObjects/Data Abstract

"Brian Moelk" wrote
Quote

You could discuss things like: an OPF typically wants total control over
DB
schemas vs. DA approach of leveraging/mapping existing DB schemas.
Actually I would argue that that is a design mistake based on the desire to
provide design-time tools: automatic schema generation based on UML, schema
updating as a result of object model revisions, etc. I don't see it as
inherent to the OPF project.
Quote

Could even extend to "How to write an OPF using DA".

That would be an interesting article, yes.
bobD