Friday, November 28, 2003

More SDO discussions... Crikey, it looks like I got TSS'd. Me and my big mouth :). Here's another follow up to Marks comments... When I first reviewed it, I looked for a "smoking gun"; that thing that would stand out as evidence that the authors hadn't studied the Web in sufficient detail. I didn't see any at the time, but after having a second look I'd say it's the use of XPath; SDO should have used URIs (or perhaps both) as the means of relating objects. Perhaps that might help you see where I'm coming from with my objections, James I think I see where you're coming from. Firstly SDO has absolutely nothing to do with the web per se. Its an API for Java developers to use to access blobs of structured data - typically data available locally in RAM.  So its purely an API for a typed tree-like data structure. e.g. take the use case of parsing some XSD-aware XML (from a file, a message, a URI, a servlet request whatever).  You've broadly got these options use a DOMish API (W3C DOM, JDOM, dom4j, XOM, EXML) create your own hand crafted data structure use generated beans from some schema (like JAXB, XMLBeans etc) use SDO If you choose SDO you get a nice & simple typed graph of data (with numbers, booleans, floats, strings, dates etc).  No need for the XML InfoSet, comments, whitespace and all that stuff - just fields in a purchase order or whatever. So SDO is not unlike a type-aware data-centric DOM API minus the XML infoset (if you see what I mean). The SDO and XMLBeans approaches are similar; SDO is a generic API, XMLBeans creates a specific API based on the XSD. With SDO typically the entire graph of data may be locally in RAM. Though there's no reason why an implementation couldn't lazily fetch more data from some remote resource as you navigate/walk the tree. So an SDO implementation could be a facade on top of one or more RESTful services. Or on top of the file system full of XML documents. Or an SQL database etc. Maybe in my previous post when I said 'API' you were thinking of the REST network API (i.e. the HTTP protocol) rather than the in-process Java programmers API for working with tree data structures? The only data structure that Servlets offers for Java developers to access the state transferred over HTTP is Input/OutputStream. SDO just offers a higher level abstraction. Incidentally, the interesting thing about SDO is that the navigation mechanism is pluggable. So Mark, an SDO implementation could use URIs (or XPointer, or XQuery etc) to navigate through the data graph. 6:51:42 PM    comment []

SDO follow up It looks like Mark doesn't grok SDO. I think the main reason I grokked SDO was that I'd written something very-close to SDO myself about 4-5 years ago on a web system I built - and found it very useful (though rather than DataObject I'd called the interface Record, but other than that things were quite similar). A more recent implementation of a similar idea are DynaBeans. To help set Mark straight; Servlets are a Java API for implementing HTTP operations. (Incidentally Servlets don't have a client side - for that you need to either use the URL class or the commons-httpclient library). So Servlets take care of the server-side part of HTTP protocol for you. To use REST speak, Servlets implement the server side of the transfer part of REST. However Servlets says nothing of the actual state passed across on GET / POST / PUT. From Servlet's perspective state is just an InputStream / OutputStream. Its up to you to encode/decode however you wish & use some API to represent that state. SDO on the other hand is a generic Java API for any arbitrary typesafe blob of state. It says nothing of how you fetch the state, where it comes from, what transfer/marshalling mechanism etc. The state could come from anywhere; from parsing any XML document, calling some RESTful service, a web service, an RMI call, an EJB / JDO / JDBC / JNDI / JMX query etc. So think of SDO as like a DOM API but rather than modelling the XML InfoSet, its modelling any arbitrary structured Java data types, like SQL 92 or XSD types for data-centric developers (without some of the document centric XML/XSD cruft). This is great for UI development, you can let the back end service (a RESTful service, web service, EJB, stored procedure call or whatnot) decide what the structure of the data really is - your code can pass around blobs of state & try process it as best it can. It saves you statically generating code from some external schema. To use Servlets as an example, you could write some servlet that marshals / unmarshals state using some encoding (say XML) to create a restful SDO enabled servlet-like thing like this... public interface Restlet {   DataGraph get(String uri) throws RestException;   void put(String uri, DataGragh state) throws RestException;   ... } So SDO could work quite nicely together with servlets + REST as well as with web services & EJBs & SQL etc. Update: as someone mentioned on the recent TSS thread; SDO is like an implementation of the Table Module pattern from Martin Fowlers enterprise patterns book. With a slight twist; SDO can handle arbitrarily nested data (so many master/detail tables if required) and includes a navigation XPath-like language too to make things easier to use & extract data. 1:22:42 PM    comment []

SDO rocks! Great job IBM & BEA I really like the look of SDO. I've wanted something like this for some time. Its a great abstraction to put user interfaces on top of, without worrying if there's a static data model (e.g. writing beans for your data) or if the data is the result of some arbitrary piece of SQL, parse of some XML file or some web services call. Hopefully JSR 227 could be a layer on top of this, providing standard UI controls & MVC layer for dealing with UI related issues but using SDO as the underlying model for data. SDO is also an ideal abstraction to represent blobs ('documents') of data that pass around a distributed system (e.g. the Data Transfer Object pattern often used in EJB / MOM). Its also a nice simple abstaction above XML Schema types, SQL DDL, UML and MOF stuff and the like - I'm suprised at how simple & clean the API is - nice job! All we need now is an open source reference implementation. (Please IBM/BEA donate the reference implementation it to Apache so we can all hack on it together! :) Interestingly, putting on my groovy goggles (honestly I do take them off now and again! ), we could use groovy inside or outside of SDO. We could use groovy as the query language inside SDO for Java developers to use in normal Java syntax (though the XPath-like language is pretty neat for that too). Though using SDO from Groovy would be even neater.... e.g. Java... DataObject department = company.getDataObject("departments.0"); DataObject employee = company.getDataObject("departments.0/employees[SN='0002']"); Groovy (notice, no query language, just groovy syntax)... department = company.departments[0] employee = company.departments[0].employees.find { it.sn == '0002' } Am really looking forward to being able to use this stuff! Hats off to IBM & BEA on this one 7:14:53 AM    comment []