BorlandTalk.com Borland discussion newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Re: OPF and RemObjects/Data Abstract Goto page 1, 2  Next          BorlandTalk.com Forum Index -> Delphi OO design View previous topic :: View next topic   Author Message Joanna Carter Guest Posted: Sun Jul 27, 2003 6:06 pm    Post subject: Re: OPF and RemObjects/Data Abstract Rob Schuff wrote: Quote: 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 would make of the components. Joanna -- Joanna Carter Consultant Software Engineer TeamBUG support for UK-BUG TeamMM support for ModelMaker Back to top Bob Dawson Guest Posted: Sun Jul 27, 2003 10:00 pm    Post subject: 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's 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 Back to top Alessandro Federici - Rem Guest Posted: Mon Jul 28, 2003 5:55 am    Post subject: Re: OPF and RemObjects/Data Abstract "Joanna Carter" <joannac (AT) btinternet (DOT) com> wrote 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 MSSQL 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's 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 MSSQL 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 would 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. http://www.remobjects.com Best Communications Tool In 2003 Delphi Informant Readers Choice Awards Back to top Alessandro Federici - Rem Guest Posted: Mon Jul 28, 2003 6:02 am    Post subject: Re: OPF and RemObjects/Data Abstract "Bob Dawson" <RBDawson (AT) prodigy (DOT) net> wrote Quote: I don't see any reason why the two would _necessarily_ conflict. They wouldn't at all. RO can remote anything and it's 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's 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. http://www.remobjects.com Best Communications Tool In 2003 Delphi Informant Readers Choice Awards Back to top Joanna Carter Guest Posted: Mon Jul 28, 2003 9:03 am    Post subject: Re: OPF and RemObjects/Data Abstract Alessandro Federici - RemObjects Software wrote: Quote: 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's 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 -- Joanna Carter Consultant Software Engineer TeamBUG support for UK-BUG TeamMM support for ModelMaker Back to top Bob Dawson Guest Posted: Mon Jul 28, 2003 12:23 pm    Post subject: 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 Back to top Alessandro Federici - Rem Guest Posted: Mon Jul 28, 2003 3:28 pm    Post subject: Re: OPF and RemObjects/Data Abstract "Joanna Carter" <joannac (AT) btinternet (DOT) com> wrote Quote: So, it's 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. http://www.remobjects.com Best Communications Tool In 2003 Delphi Informant Readers Choice Awards Back to top Mamcx Guest Posted: Mon Jul 28, 2003 6:43 pm    Post subject: Re: OPF and RemObjects/Data Abstract Quote: They wouldn't at all. RO can remote anything and it's 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... Back to top Carl Caulkett Guest Posted: Mon Jul 28, 2003 6:49 pm    Post subject: Re: OPF and RemObjects/Data Abstract Bob Dawson wrote: 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't foresee any serious problems, such is the ease of use that RemObjects offers. -- Cheers, Carl Back to top Jim Cooper Guest Posted: Mon Jul 28, 2003 7:26 pm    Post subject: 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 [email]jcooper (AT) tabdee (DOT) ltd.uk[/email] Tabdee Ltd http://www.tabdee.ltd.uk TurboSync - Connecting Delphi with your Palm ____________________________________________ Back to top Alessandro Federici - Rem Guest Posted: Mon Jul 28, 2003 7:36 pm    Post subject: Re: OPF and RemObjects/Data Abstract "Jim Cooper" <jcooper (AT) tabdee (DOT) ltd.uk> wrote 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. Back to top Brian Moelk Guest Posted: Mon Jul 28, 2003 7:42 pm    Post subject: 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. -- Brian Moelk [email]bmoelk (AT) NObrainendeavorSPAM (DOT) FORc[/email]omME http://www.brainendeavor.com Back to top Alessandro Federici - Rem Guest Posted: Mon Jul 28, 2003 7:42 pm    Post subject: Re: OPF and RemObjects/Data Abstract "Brian Moelk" <bmoelk (AT) NObrainendeavorSPAM (DOT) FORcomME> wrote 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? Back to top Brian Moelk Guest Posted: Mon Jul 28, 2003 7:55 pm    Post subject: 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? http://www.ambysoft.com/persistenceLayer.html -- Brian Moelk [email]bmoelk (AT) NObrainendeavorSPAM (DOT) FORc[/email]omME http://www.brainendeavor.com Back to top Bob Dawson Guest Posted: Mon Jul 28, 2003 8:35 pm    Post subject: 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'd argue that that's 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 Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         BorlandTalk.com Forum Index -> Delphi OO design All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C++ Builder Newsgroups----------------C++ BuilderC++ Builder (ActiveX)C++ Builder (Announcements)C++ Builder (Command Line Tools)C++ Builder DatabasesC++ Builder Databases (ADO)C++ Builder Databases (Desktop)C++ Builder Databases (InterBase Express)C++ Builder Databases (Multi-Tier)C++ Builder Databases (SQL Servers)C++ Builder (Graphics)C++ Builder (IDE)C++ Builder (Internet)C++ Builder (Internet Socket)C++ Builder (Internet Web)C++ Builder (Jobs)C++ Builder (Language)C++ Builder (Language C++)C++ Builder (Compatibility with MFC)C++ Builder (Native API)C++ Builder (Non-Technical)C++ Builder (Students)C++ Builder (Third Party Tools)C++ Builder (Upgrade)C++ Builder (VCL)C++ Builder (VCL Components Usage)C++ Builder (VCL Components Development)C++ Builder (VCL Usage)C++ Builder (WinAPI)C++ Builder Installation Delphi Newsgroups----------------Delphi (General)Delphi ActiveX Controls UsageDelphi ActiveX Controls DevelopmentDelphi As400Delphi DatabasesDelphi Databases (ADO)Delphi Databases (dbExpress)Delphi Databases (Desktop)Delphi Databases (InterBase Express)Delphi Databases (Multi-Tier)Delphi Databases (SQL Servers)Delphi DeploymentDelphi GraphicsDelphi IDEDelphi InternationalizationDelphi InternetDelphi Internet Isapi-WebBrokerDelphi Internet WebSnapDelphi Internet WinsockDelphi JobsDelphi Language BASMDelphi Language ObjectPascalDelphi Model Driven Architecture (General)Delphi Model Driven Architecture (Third Party)Delphi MultimediaDelphi Native APIDelphi Non-TechnicalDelphi ObjectPascalDelphi OLE AutomationDelphi OO designDelphi OpenToolsAPIDelphi Reporting-ChartingDelphi RTLDelphi StudentsDelphi TeamSourceDelphi Thirdparty ToolsDelphi Thirdparty Tools (General)Delphi Thirdparty Tools (IntraWeb)Delphi Thirdparty Tools (RaveReports)Delphi UpgradeDelphi VCLDelphi VCL ComponentsDelphi VCL Components UsingDelphi VCL Components WritingDelphi WebServices SOAPDelphi WinAPIDelphi XMLDelphi Installationcomp.lang.pascal.delphi.components.misccomp.lang.pascal.delphi.components.usagecomp.lang.pascal.delphi.components.writingcomp.lang.pascal.delphi.databasescomp.lang.pascal.delphi.misccomp.sources.delphi JBuilder Newsgroups----------------JBuilderJBuilder AnnouncementsJBuilder Applet IssuesJBuilder As400JBuilder CompilerJBuilder CORBA/RMIJBuilder DatabasesJBuilder DB SwingJBuilder DebuggerJBuilder DeploymentJBuilder DocumentationJBuilder EnterpriseJBuilder HandheldJBuilder IDEJBuilder JavaJBuilder JavaAPIJBuilder Java LanguageJBuilder Java SwingJBuilder Java BeansJBuilder Java Beans UsageJBuilder Java Beans DevelopmentJBuilder JBCLJBuilder JDataStoreJBuilder JobsJBuilder LinuxJBuilder MacintoshJBuilder & MobileSetJBuilder MultiLingual AppsJBuilder Non-TechnicalJBuilder OpenToolsJBuilder Servlets (JSP)JBuilder StudentsJBuilder Team DevelopmentJBuilder Thirdparty ToolsJBuilder UpgradeJBuilder Installation InterBase Newsgroups----------------InterBaseInterBase Bug DiscussionInterBase GeneralInterBase IBConsoleInterBase OpenSourceInterBase ReplicationInterBase SQLInterBase ThirdpartyInterBase Installation Miscellaneous Borland Newsgroups----------------AppCenterAppServerEnteraVisiBroker  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.