1 / 37

ActiveRecord and SDO: Adding new data models beneath your Rails applications

ActiveRecord and SDO: Adding new data models beneath your Rails applications. Doug Tidwell, IBM dtidwell@us.ibm.com. Objectives. Discuss emerging technologies (SDO and SCA) Compare SDO to ActiveRecord Discuss impedence mismatches between SDO and ActiveRecord

clodia
Download Presentation

ActiveRecord and SDO: Adding new data models beneath your Rails applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ActiveRecord and SDO: Adding new data models beneath your Rails applications Doug Tidwell, IBM dtidwell@us.ibm.com

  2. Objectives • Discuss emerging technologies (SDO and SCA) • Compare SDO to ActiveRecord • Discuss impedence mismatches between SDO and ActiveRecord • Build bridges between the SCA/SDO and Rails communities

  3. Speaker profile • Doug Tidwell is a Senior Software Engineer at IBM. • He was a speaker at the first XML conference in 1997, and has spoken on technical topics around the world. • He works in IBM’s Software Strategy group, evangelizing emerging XML standards such as XForms, SCA and SDO. • You can reach him at dtidwell@us.ibm.com.

  4. Speaker profile • Doug Tidwell is a Senior Software Engineer at IBM. • He was a speaker at the first XML conference in 1997, and has spoken on technical topics around the world. • He works in IBM’s Software Strategy group, evangelizing emerging XML standards such as XForms, SCA and SDO. • You can reach him at dtidwell@us.ibm.com.

  5. Emerging technologies Service Component Architecture andService Data Objects

  6. Why SDO makes life simpler • One way to look at SDO is that it takes all of the details of access methods, implementations, and moves them into the middleware layer. • Application developers write business logic, code that actually builds value for your organization. • The details of using data sources are handled by SDO. • As the details change, your applications (and the developers who wrote them) aren’t affected. • SCA does the same thing, but includes encryption, authentication, etc. in addition to other details.

  7. The underlying design pattern • We’re taking a physical data source and abstracting out its details. • Our code works with things like: • DataObjects • DataGraphs • ChangeSummary(ies) • Hmmm… • This sounds familiar, doesn’t it?

  8. The underlying design pattern • SDO gives your developers a single programming model for using data sources. • As your applications get more complicated, you have to integrate more and more data sources. • What happens if they’re not RDBs? • Similarly, SCA gives your developers a single programming model for using services. • As your applications get more complicated, your developers have to learn more and more interfaces.

  9. Using a component • When dealing with a component, there are three important pieces of information: • The interface of the component • The implementation of the component • The access methodto invoke the component • We’ll consider how we use this information to invoke components.

  10. The bad old days • Originally, most components were hardwired into an application: • The application knew the details of the component’s interface at build time. • The application accessed the component’s implementation at build time. • The application knew the details of the component’s access method at build time. • This worked (and still does), but the application is relatively brittle. • If the implementation or access method changes, we have to modify our code, rebuild it, retest it and redeploy it.

  11. The early days of Web services • SOAP introduced a way to invoke a remote service with an XML envelope. • The SOAP infrastructure built the envelope and sent it to a particular URL; the SOAP service’s host invoked a service and sent XML back to us. • The application knew the details of the component’s interface at build time. • The application did not access the component’s implementation at build time; the component is invoked at run time by the SOAP infrastructure. • The application knew the details of the component’s access method at build time (usually SOAP/HTTP).

  12. Next-generation applications • An application built with SCA and SDO is even more dynamic: • The application knows the details of the component’s interface at build time. • The application does not access the component’s implementation at build time; the component is invoked by the SCA and SDO frameworks. • The application does not know the details of the component’s access method at build time; this is also handled by the SCA and SDO frameworks. • SCA and SDO move the implementation and access method details out of your application and into the middleware.

  13. Next-generation applications • We mentioned the three important pieces of information: • The interface of the component • The implementation of the component • The access methodto invoke the component • With SDO and SCA, the implementation and the access method are determined at runtime by the infrastructure. • Our code isn’t involved in this determination, so we don’t have to write it or maintain it.

  14. Service Data Objects

  15. Service Data Objects • Started as a research project between IBM and BEA several years ago. • SCA grew out of this work as well. • The standards have been developed in the open and were recently turned over to OASIS.

  16. Service Data Objects • SDO gives you a single API to a wide variety of data sources. • You and I as developers focus on CRUD operations. • We don’t know what the data source actually is. • Relational database • XML database or XML file • EJB • Web service • JCA • LDAP directory

  17. The goal of SDO • I have some data. • I use the data wherever and however it’s stored (RDBMS, XML file, LDAP, etc.) • I use the most convenient language for CRUD operations on the data (SQL, XQuery, modified XPath, etc.)

  18. EJB A disconnected interface to many kinds of data sources RDB JDBC, ODBC Data graph Data object XPath/XQuery XML DB Local Application Data Access Service XML/HTTP Web service Change summary JCA CCI/Proprietary

  19. Data Access Services (DAS) • To use SDO, another technology is needed. • DAS does the work of synchronizing the data graph with a particular kind of data store. • Tuscany has DAS implementations in Java and C++.

  20. Samples • We’ll look at a quick sample that uses the same code to access different data sources underneath. • Changing the data source doesn’t require us to change our code at all.

  21. Configuration • Here’s the DAS configuration file for a relational database: <Config xmlns...><ConnectionInfo dataSource="..."/><Command name="allCompanies" SQL="select * from COMPANY" kind="Select"/><Table tableName="COMPANY"> <Column columnName="ID" primaryKey="true" generated="true"/></Table> . . .

  22. Accessing the SDO data • Here’s how to execute a query: public class CompanyClient {private DAS das = DAS.FACTORY. createDAS(getConfig ("CompanyConfig.xml")); public final List getCompanies { Command read = das.getCommand("allCompanies"); DataObject root = read.executeQuery(); return root.getList("COMPANY");} }

  23. Accessing data with Tuscany SDO • Tuscany SDO development has taken two significant turns in the last few weeks • Adding more data sources: A beta of LDAP support is in the Tuscany code base today. • Adding more query languages: XQuery has also been added to the Tuscany code base in the last couple of weeks.

  24. Building bridges Two great tastes that taste great together

  25. Impedance mismatches • SDO is designed for disconnected access • Get a data graph from a data provider, work with it, then submit a change summary to the data provider if we want. • SDO is closer to XML Schema than the relational model • Mappings have been done to RDBs, XML / Web services, LDAP… • SDO is much more configuration-intensive • Tools exist to do this automatically, but… • This is completely counter to the Rails philosophy

  26. Sequenced data objects • SDO defines sequenced data objects, not something a RDB typically supports natively. • Rails’ acts_as_list fits this perfectly; SDO uses a similar approach. • Sequenced data objects map to XML easily. • Sequenced data objects to LDAP? Not so much…

  27. Query languages • Rails “query” language is tightly integrated with Ruby • Doesn’t seem like a query language at all, really… • SDO supports SQL, XPath (sort of) and XQuery. • XPath support in SDO is awkward, the first item in a sequence or node set is [0], not [1].

  28. Meeting in the middle • What’s in there? ? ActiveRecord SDO

  29. Challenges • SDO maps everything to an XML structure (DataObject). • Rails assumes everything is in a RDB • SDO to RDB implementations are mature (although not all are open-source) • How substantial is the mismatch between, say, LDAP and RDB? • In theory (heh), this is a known and solved problem. • LDAP directories have been implemented on top of RDBs.

  30. Questions • How much value is there in an ActiveRecord to LDAP mapping? • How much value is there in the disconnected nature of SDO?

  31. Quotes • The idea of intelligent persistance (Liquid data or SDO) is in the category of "if I only had time I would build that, and if anyone does I would use it, but I just don't have time to give this gift to humanity"  Surprisingly, that is exactly the mindset which delayed an architecture like Rails from coming to market sooner.  We all owe a debt to the man who bit the bullet and did the heavy lifting.

  32. Quotes • I have not done any development, but have planned a "vision" of how I would implement this into an overarching application development paradigm.  The short answer for you is "I'm not independantly wealthy, but have 3 kids in college, so I work for the machine.“ • George Willis, on the Ruby on Rails RIA SDK Google Group

  33. Resources • Service Data Objects • osoa.org/display/Main/ Service+Data+Objects+Specifications • Java and C++ specs available now, C and COBOL are in draft stage • OASIS CSA group • oasis-opencsa.org • Apache Tuscany • incubator.apache.org/tuscany/ • Next-generation data programming: Introduction to SDO • ibm.com/developerworks/java/library/j-sdo/ and elsewhere…

  34. Resources • SCA component for Ruby • ibm.com/alphaworks/tech/scarubycomponent/ • Other Ruby and SCA resources • See the Tuscany samples—there are examples that use BSF to implement Ruby services inside an SCA environment. • Work for the opposite direction is ongoing, please get involved…

  35. Resources • osoa.org: A group of 17 companies working together:

  36. The specifications work of OSOA has been turned over to OASIS. • The Open Composite Services Architecture group is being formed now. • See oasis-opencsa.org for more details.

  37. Thanks! Doug Tidwell, IBM dtidwell@us.ibm.com

More Related