What's happened to Service Data Objects?

Discussions

News: What's happened to Service Data Objects?

  1. Service Data Objects was proposed and accepted as a JSR in December 2003. However, almost eighteen months later, there's not even an expert community outside of IBM and BEA, no draft of the spec is available. What's happened to the SDO spec?

    SDO is a specification covering data transfer between the persistence and presentation layers. From BEA's "Service Data Objects":
    SDO is based on the concept of disconnected data graphs. Under the disconnected data graphs architecture, a client retrieves a data graph (i.e., a collection of tree-structured or graph-structured data objects) from a data source, mutates the data graph, and can then apply the data graph changes back to the data source.
    It's almost a direct competitor to .NET's DataSet idea, and could be very useful in Java, even though SDO's support for transactions is unclear.

    However, the JSR was supposed to deliver a final release in the Fall of 2004. Instead, the expert group is still just IBM and BEA; there's no draft of the spec from the JSR formal process, nor any mention of a formal release. The only data about SDO is BEA's specification referred to above, an update from IBM on SDO and other technologies called "Service Data Objects, WorkManager, and Timers," and an EMF-based implementation by IBM.

    So... what's happened to SDO? Is the JCP simply too slow to move on such a specification? Is the specification itself too confusing for people to work with or participate in?

    Threaded Messages (34)

  2. SDO in IBM RAD6.0[ Go to top ]

    Interesting...

    I've just returned from a Websphere Portal conference where IBM demonstrated RAD6.0 developing JSF+SDO based portlets. Looks like they've gone on to implement SDO regardless of JCP ratification.

    Have BEA done the same?
  3. SDO in BEA liquid data[ Go to top ]

    AFAIK, BEA already uses SDO in their Liquid Data framework.
  4. I recently attended an IBM RAD workshop (Rational Application Developer for WebSphere) and in it SDO was on the slides and mentioned several times. The presenter stated that it was sent to JCP some time back, and asserted that it would be an actual standard "very soon". I am not sure if this was just marketese but at this particular IBM held RAD demonstration it was clearly stated that IBM felt SDO would be not just proprietary to IBM and rather would be approved "soon" as a standard by JCP.
  5. SDO at IBM[ Go to top ]

    IBM Education Assistant: Rational Application Developer Service Data Objects (SDO)

    IBM apparently has an implementation already, yes.
  6. BEA[ Go to top ]

    Interesting...I've just returned from a Websphere Portal conference where IBM demonstrated RAD6.0 developing JSF+SDO based portlets. Looks like they've gone on to implement SDO regardless of JCP ratification.Have BEA done the same?

    BEA needs to get with the program (JCP). They are off adding all of this non-standard functionality to their platform, yet they are about a year or so behind the Servlet/JSP specification-- ??

    Truthfully, most developers that I know wouldn't commit their company's infrastructure to a single vendor specification.
  7. nice try[ Go to top ]

    Nice try by IBM and BEA to try and undermine J2EE and create their own proprietary specification. You ain't gonna get anywhere without support from Sun, Oracle, and JBoss.
  8. nice try[ Go to top ]

    Nice try by IBM and BEA to try and undermine J2EE and create their own proprietary specification. You ain't gonna get anywhere without support from Sun, Oracle, and JBoss.

    Undermining J2EE... well, I think J2EE has been nicely undermined by Sun itself during the last years:
    • Except for Servlets, out of here is a plethora of web frameworks. Sun added their own in order to stick it everywhere.
    • Integration tier: EJBs have been substituted by IoC, Hibernate and iBatis. Let's avoid talking about the hilarious local interfaces.

    JBoss: JBoss hasn't been officially J2EE compliant until 4.0, and the web tier is Jetty or Tomcat; I don't understand why should they sit on the J2EE table.
  9. About Licurgo[ Go to top ]

    I'm one of the developers of Licurgo. We are working in Licurgo since about 6 months, altough not constantly. It was hosted in javaHispano.net (now down due to an upgrade), but we where planning to move to SF.

    In fact, we have already implemented much of the RDBMS funcionality, for some vendors (Oracle, MySQL, PostgreSQL and HSQLDB), using the TypeObject pattern (something like the puposal of the old EntityEngine of Open4Business). It will be online in SF very soon.

    Thanks for your "interest".
  10. What?[ Go to top ]

    Without JBoss, I will go quite far, thank you very much.

    Putting JBoss on par with Sun and Oracle - I have to laugh.

    Lashing out at IBM - sounds like JBoss is sensing a threat.
  11. What?[ Go to top ]

    [...] Lashing out at IBM - sounds like JBoss is sensing a threat.

    Sensing a threat? First the JBoss leaders openly lost control of their bowels when IBM adopted Geronimo, then they tried to gloss over their fear by declaring that, in fact, IBM is afraid of JBOSS.

    Bill's post just fits nicely into this series of pant crapping incidents and cover-up attempts, so take it with a pitcher of salt. It is nothing new that the JBoss guys have a high opinion of themselves and look down on everyone else. At least he posted using his real name...

    Cheers, Lars
  12. nice try[ Go to top ]

    Hahah Jboss aahhahahahaha jboss! ahahahah mbeans hahah jboss aop haha jbossernate hahaa.
  13. See in some products[ Go to top ]

    I'm interested in SDO, i want to use it for implementing databinding with Swing, and i've seen SDO in a few products:

    XCalia implementation of JDO supports SDO. See:
    Lido

    And Alphaworks' dataBinding4SWT uses SDO.

    There is also a project from Spanish people to implement SDO as open-source, Licurgo, but the project doesn't seem to have started.
  14. LiDO supporting SDO[ Go to top ]

    Hi all,

    As Ludovic said in this thread, Xcalia is also working on an SDO implementation.
    The next version of our product (due mid-june 05) will have a support for SDO.
    That said, the specification is still incomplete today.
    So we decided to provide our own implementation for the DMS (Data Mediator Service) that is based on product LiDO.
    So there is a complete, efficient and fully functional way to access the database with an object query language and transactions, before detaching a DataGraph.

    What is really annoying is the lack of specification for the protocol between the SDO client and the DMS. Also few things are missing about collection management.

    I don't want to speak for IBM, but I think they try to fix somes legal issues with the JCP in order to start the expert group.

    Xcalia as a provider of data access solutions is committed to SDO because:
    1. we have some requests from existing customers
    2. and also because it will participate to our new offer (announcement in June) targeting unified access to both databases and services.

    NB: I've downloaded LiquidData and didn't see the SDO implementation in it.

    Best Regards, Eric.
  15. It is interesting to see that IBM and BEA are working so closely together outside the purview of the JCP. Perhaps they are taking the pragmatic approach and trying out ideas like SDO in their products before trying to make the 'the Way'.

    I have no idea whether this is the case or not for SDO, but it seems that other works under the CommonJ banner have made their way into WL 9.0.

    I personally think that by trying out these technologies in their applications first, BEA and IBM are going to reasonable lengths to ensure that any resultant specs will, at least, be usable.

    Rob
  16. Eclipse has SDO implementation[ Go to top ]

    The Eclipse Tools Project for EMF continues to ship a free SDO implementation and it is activly updating it.

    http://www.eclipse.org/emf/
  17. How are they doing an SDO implementation when SDO isn't even formally specified?
  18. JSR 235: Service Data Objects

    There is plenty of info as to what BEA and IBM *want* it to look like, and it has been submitted, its just not an accepted JCP "standard" yet.
  19. JSR 235: Service Data Objects

    "2.3 What need of the Java community will be addressed by the proposed specification?

    Data Transfer Objects are an established J2EE application development pattern. The Service Data Objects proposed specification standardizes Data Objects in terms of change history, compound data objects, dynamic and generated API, meta-data, support for XML and Web Services, neutral representation of business data, import/export from common formats, validation and constraints, relationship integrity, and navigation."
  20. SDO 1.0 has been formaly specified under the commonj umbrella for a bit, it just hasn't been specified under the JCP:

    http://www-128.ibm.com/developerworks/library/j-commonj-sdowmt/

    or

    http://dev2dev.bea.com/wlplatform/commonj/sdo.csp
  21. Sure - note that the original article made reference to both of those, and both of those URLs are in the proposal at the JCP as well.

    But those aren't a formal specification, even if they're formal documents at BEA and IBM.
  22. We use plenty of tools that don't have formal specifications, Spring and Hibernate come to mind. Furthermore, we often implement specifications that are not part of the JCP, for instance the many RFCs that are implemented in Java.

    Just because a specification is not a JCP specification does not mean that we cannot implement and use it.

    Rob
  23. If a JCP sits for a year and a half with no activity, maybe no one is interested. It would not be the first time IBM and/or BEA have come up with a solution no one was interested in.

    Personally, what has been developed so far, is not very impressive.
  24. If a JCP sits for a year and a half with no activity, maybe no one is interested. It would not be the first time IBM and/or BEA have come up with a solution no one was interested in.Personally, what has been developed so far, is not very impressive.

    Right. If other companies were interested then they would have gotten on board. Two companies sitting together as a committee does not a JCP specification make.
  25. SDO and DTO?[ Go to top ]

    Could someone please clarify the relationship between SDO and DTO? On the JSR page it says SDO are used both "to pass data between a business tier and a persistence tier" AND "to pass data from the presentation tier...to the business logic tier". What I'm used to is getting "Business Objects" or "Domain Objects" from a DAO and using DTO to pass information from the Business/Service layers to the Presentation layer. The Domain Objects are not simple 'structs' and may contain limited business fucntionality that may or may not be appropriate for the Presentation layer. The DTOs are another abstraction that is aimed specifically at the Presentation layer, and these are just 'structs'. Am I supposed to have two sets of SDOs? Are they more or less what I just described? Or am I stuck with 'struct' objects all the way up and down?
  26. SDO and DTO?[ Go to top ]

    Could someone please clarify the relationship between SDO and DTO? On the JSR page it says SDO are used both "to pass data between a business tier and a persistence tier" AND "to pass data from the presentation tier...to the business logic tier". What I'm used to is getting "Business Objects" or "Domain Objects" from a DAO and using DTO to pass information from the Business/Service layers to the Presentation layer. The Domain Objects are not simple 'structs' and may contain limited business fucntionality that may or may not be appropriate for the Presentation layer. The DTOs are another abstraction that is aimed specifically at the Presentation layer, and these are just 'structs'. Am I supposed to have two sets of SDOs? Are they more or less what I just described? Or am I stuck with 'struct' objects all the way up and down?

    I would recommend reading some of the articles from BEA and IBM. What you will find is that conceptually, SDOs don't serve any purpose other than providing metadata to vendor tools.

    The one benefit is that your code can work off of a generic API, such that the data representing the objects you need could come from XML, DB, or straight JavaBeans. Think XML DOM, but for pseudo JavaBeans.
  27. SDO and DTO?[ Go to top ]

    I would recommend reading some of the articles from BEA and IBM. What you will find is that conceptually, SDOs don't serve any purpose other than providing metadata to vendor tools.The one benefit is that your code can work off of a generic API, such that the data representing the objects you need could come from XML, DB, or straight JavaBeans. Think XML DOM, but for pseudo JavaBeans.

    Ah, thank you. That makes more sense.
  28. Opinion: SDO is good[ Go to top ]

    I've blogged about my take on SDO. I hope somebody finds it of interest.
  29. SDO and DTO?[ Go to top ]

    Could someone please clarify the relationship between SDO and DTO?

    You could see SDO as a generic implementation of the DTO pattern, with the ability to add meta-data to describe object types (as is good practice for any generic approach).

    If used in this way, there would be no need to write your own class for each type of DTO - you could just use the generic SDO classes.

    Additional power comes from a "mediator layer" that translates to/from data stores and SDO object graphs. That's hopelessly underspecified at the moment, though.

      cheers,
      gerald

    http://www.gerald-loeffler.net
  30. BEA already implemented SDO specification starting from the Liquid data 8.2.

    Thanks
    Santosh
  31. The Spec Has Been Renamed[ Go to top ]

    Rumor: The actual progress of this JSR has been appropriately renamed to "Stale Data Object".

    I just wonder how do I transfer my "business tier" objects/meta-objects to this SDO and then from SDO to my presentation objects? Maybe it is time to create another JSR named "Duplicating Data Object (DDO) specification" So you can transfer from EJB->DDO->SDO->DDO->POJO->JSF->HTML. How can we do EJB->DDO? You guess! ;-)
  32. The Spec Has Been Renamed[ Go to top ]

    So you can transfer from EJB->DDO->SDO->DDO->POJO->JSF->HTML.

    A smililar pattern has actually been used in a failed J2EE project in the real world (in an organization I worked at before). Here it is:

    BusEntity --> VO --> DataBean --> Form Bean --> JSP
  33. Versata's new Eclipse based implementation uses Service Data Object's.

    A client layer can interact with transfer objects within Versata 6 in two ways. The objects can be treated as SDO objects, using the API defined for that spec. They are also available as “plain old Java objects” (POJOs). The DataGraph is an object which extends the DataGraph interface and gives convenience methods for accessing objects in a JavaBean-like manner. This gives the end user the flexibility to deal with incoming data in the most natural form for the intended UI.

    Logic in the services layer receives the transfer objects usually as mutable SDO Data Graph or Data Object parameters. This services layer logic may make changes to these objects including destroying them and creating new objects, and may access the DMS in the persistence layer, or any other DMS for that matter, as it sees fit. It may call the DMS multiple times or not at all. It may deal with exceptions from the DMS, or may allow them to be map to faults automatically by the framework.

    The current Eclipse SDO implementation requires a metamodel instance using ecore as the metamodel. Versata's metamodel instance is used to generate an ecore metamodel instance with just enough information to allow the creation of SDOs based on the application metadata. Once this ecore metamodel instance is created, it can then be passed into the SDO genmodel to generate the SDOs as usual.

    The interface through which the SDO objects are obtained with Versata 6 demarcate the transaction boundaries of the system. The transaction demarcation point will be at the external side of the service layer. An incoming call will start a transaction and the transaction will be committed when the call returns. This has the effect of pulling the transaction capabilities away from the client and moves it onto the server. The result of this is a more coarse-grained, batch oriented approach, in line with a Services Oriented Architecture (SOA).
  34. SDO in javascript?[ Go to top ]

    Some time ago I read about javascript implementation for SDO (in one of the IBM technical journal). It is a client-side (browser) library. I'm interesting in using it together with AJAX. But I could not find any information on it.

    Does anyone know anything about it?
  35. SDO in javascript?[ Go to top ]

    I am using that IBM library called Faces Client Framework. At IBM site you'll found a PDF wich explains a lot about SDO4JS (Sdo for Javascript). Also, you can go to ibm alphaworks site (www.ibm.com/alphaworks) and look for openLaszlo for faces. Here is a good example for integrate XML/Flash technologies with SDO4JS and Java server Faces.