Discussions

News: Service Data Objects specification 2.0 released outside of JCP

  1. IBM has released the SDO specification 2.0, written by BEA and IBM in conjunction, dated "June 2005." It looks like this specification is being developed outside of the JCP, despite existing as JSR-235.

    From a BEA white paper entitled Next-Generation Data Programming with Service Data Objects:
    Service Data Objects (SDO) is designed to simplify and unify the way in which applications handle data. Using SDO, application programmers can uniformly access and manipulate data from heterogeneous data sources, including relational databases, XML data sources, Web services, and enterprise information systems.
    The implication is that IBM and BEA felt the specification's existence as a JSR wasn't very important, as it's been inactive lately. (See What's happened to Service Data Objects?.)

    However, BEA recently released the AquaLogic product family, integrating the former Liquid Data product as the Aqualogic Data Services Platform. Bill Roth, vice president of product management at BEA, described this as being an implementation of Service Data Objects to EWeek, leading some to say that SDO as a specification exists, just not within the framework of the JCP.

    Resources:

    Threaded Messages (16)

  2. Why outside JCP?[ Go to top ]

    Does anybody know the reason why it's being done outside the JCP? The JSR review ballot comments indicate licensing concerns. Is that why?
  3. That JSR seems totally dead from the outside - nothing has happened since the expert group was created over two years ago. Anyone knows if it is dead? Is BEA doing it by themselves?
  4. Service Data Objects (SDO) is designed to simplify and unify the way in which applications handle data. Using SDO, application programmers can uniformly access and manipulate data from heterogeneous data sources, including relational databases, XML data sources, Web services, and enterprise information systems.
    Doesn't SDO coincide with JRC's use? Both seem to have the same goal: shield app from data store detail. Do they differ in implementation, design, feature, applicability, or are both really redundant?
  5. JCR: http://www.artima.com/lejava/articles/contentrepository.html
  6. SDO design goals[ Go to top ]

    While SDO and JSR 170 both deal with access and manipulation of disparate data sources, they address somewhat distinct design concerns. Our intent with SDO was to provide a uniform data model for heterogeneous data sources. Specifically, SDO is concerned with:

    1. Disconnected data access involving multiple data sources. SDO provides the ability to access and modify data in a uniform way across multiple tiers. This typically involves accessing a data graph, disconnecting from the data source(s), modifying the data graph "offline," and sending updates back to the data source(s). JSR 170, in contrast, focuses on other concerns such as layering additional semantics on data access related to content management, including the concepts of workspaces and versioning.

    2. Defining a deep data transfer technology. SDO specifies a way to perform automated *data* marshaling between remote application tiers. SDO has focused on several aspects of this problem, including:

    - Change tracking, namely the ability to provide change summaries so that data sources may be efficiently updated in a disconnected fashion. Note that this is different than versioning as desribed by JSR 170.

    - The ability to produce XML schema representations of Java object graphs and the ability to bind from XML schema into Java-specific types.

    3. An API for dynamic data traversal. SDO provides a mechanism for traversing object graphs whose "shape" may not be known until runtime.

    That said, I could imagine using SDO on top of a JSR 170 repository or other persistence technologies such as JDBC, EJB 3, JDO, or Hibernate. In SDO parlance this would involve having the JSR 170 repository (or other persistence engine) act as a data mediator service.

    Jim Marino
    BEA Systems
  7. Anyway, That's good to hear SDO is still alive,
    I hope We can see an open source implementation of the spec in the near future.

    Alireza Taherkordi
    http://jroller.com/page/alireza
  8. For an open source implementation of portions of SDO, see the EMF-SDO components in Eclipse 3.x
    http://download.eclipse.org/tools/emf/scripts/downloads.php
  9. Doesn't work![ Go to top ]

    programmers can uniformly access and manipulate data from heterogeneous data sources, including relational databases, XML data sources, Web services, and enterprise information systems.

    This has never worked. The 'heterogeneous data sources' are too, well, heterogeneous to be uniformed. Yes, you can define a uniform interface for them. But it always turns out to be a clumsy compromise.
  10. Doesn't work![ Go to top ]

    It should work, why not? Because of transactions or type or what?

    public makeTransfer(Account a, Account b, long sum) {
    try {
    tx.startTransaction();
    a.withdraw(sum);
    b.dispose(sum);
    tx.commit();
    } catch (Exception ex) {
    tx.rollback()
    }
    }

    This code should work same way above file based xml or SQL database. Only problem which I see is query language. XPath, XQuery, SQL, OQL, ... just to name some. However I know that you can build object based query language which will translate your conditions to specific query language. I did this for one project and it fit for 95% of cases. Data manipulation is so simple.
  11. Doesn't work![ Go to top ]

    The primary part that doesn't work (in many cases) are the update actions (create, update, delete). Reads can be made to work semi-automatically in many more cases because its just locating fields. (IBM's DB2 integrator and other products do this.) But even that requires that you do some mapping.

    Your example is trivial from a data perspective. You have a couple of fields. The problems start when you have more complex structures and relationships.

    The reason "it doesn't work" is because each of the different system types stores an incomplete representation of the data reflecting the biases of the model (relational, network, hierarchical), the data manager, the applications (how data is used), its developers and administrators.

    Additionally, over time the application developers and data store administrators combine poor modeling with tuning tweaks (specific to the products they are using) to further distort the data model being represented in storage. (Your physical structures or schema is not the data model.) Much of your data model is buried in COBOL or other programming languages your applications are written in.

    While it is true that in theory you can implement any data model as hierarchical, networked, OO (usually networked), relational, sequential or whatever and that you can maintain a mapping between all of them, in the real world you don't ever see it.

    Ever work with a "legacy" database? Ever work with lots of "legacy" databases? You can often automate the creation of a common interface for reading - products do that, but not for update, delete or create. That requires an understanding of the underlying model and its mapping to the mess in front of you. You have to do some analysis, reverse engineering of the model and then hand code (via 3gl, mapping with rules, etc.) the write actions.

    So, all SDO can contribute are common interfaces that products like TopLink will have to support. You aren't going to avoid any of the really hard work because of SDO or anything else.
  12. Doesn't work![ Go to top ]

    That requires an understanding of the underlying model and its mapping to the mess in front of you. You have to do some analysis, reverse engineering of the model and then hand code (via 3gl, mapping with rules, etc.) the write actions.

    So, all SDO can contribute are common interfaces that products like TopLink will have to support. You aren't going to avoid any of the really hard work because of SDO or anything else.

    Well, that's sort of the point. It's kind of like saying JDO or EJB CMP doesn't work because a product needs to implement it.

    BEA AquaLogic Data Services (aka Liquid Data) is the implementation of SDO, in beta now, due out mid-summer. It's a distributed/streaming query & transform engine, with read-write facilities, and SDO.

    Of course, if your data doesn't match up, there's a lot of work to be done to clean up your data environment - not unlike the work data warehouses need. Actually, it's good for Liquid Data to take advantage of a data warehouse for that reason -- the difference is that it can supplement whatever query you make on the DW with live data from the operational systems. And you can expose it as a service or a set of views queriable via JDBC....
  13. Doesn't work![ Go to top ]

    I didn't mean that SDO software or the standard won't function. What I meant is that it doesn't solve the really hard problems most organizations face when trying to integrate data across multiple applications and technologies. SDO, JDO, etc. help encapsulate the solutions in many cases, but they can't automate or greatly simplify the creation of the solution in non-trivial cases.

    Many people (IT managers and their bosses) tend to leap on these things (with encouragement from vendor sales) as silver bullets the let them avoid the really hard modeling and mapping work. They are fooling themselves.

    Also, in many cases that I have had to deal with, the solution cannot even be efficiently implemented in the lower tiers (data access layers, etc.) These situations don't have clean solutions. Think about joins and unions across VSAM, relational and networked databases. Think about systems with data model (domain and referential integrity) rules written in assembler. Think about VSAM files that represents everything as application specific codes (to save space) and have multiple variable structures.

    So, SDO may be fine and I really like JDO. I don't like Entity Beans (for many other reasons). All of them are more useful for new applications with simple legacy integration requirements than they are for dealing with complex, messy, tightly coupled legacy applications and data stores. Maybe you can put SDO (lipstick) on these systems (pigs) to as part of a larger migration strategy, but that is still hard work and there is a danger that your bosses will forget that you aren't done.
  14. Doesn't work![ Go to top ]

    If I understook it correctly you have no problem with data manipulation but data integration. That's different problem. However I still hope data manipulation against common structure should be independent of real storage.
  15. Doesn't work![ Go to top ]

    If I understook it correctly you have no problem with data manipulation but data integration. That's different problem. However I still hope data manipulation against common structure should be independent of real storage.

    Right. So, what real world problem does SDO solve? Why would you store your data in a wide variety of systems and models? If you began your work today, you would have a data architecture and data model and you would create services the provide others with the access to you data you wish to support. Within any given domain, why would you intentially choose to store the data in multiple products? If you don't then the existing solutions work fine.

    Why would you want to give components outside your domain full privileges to work with your data? Wouldn't you want them to come through your services instead? If so, given the previous assertion, why would you need SDO?

    If you try to tell me that within a given domain you have to partition the data across different products for performance or capability, I'd question your architecture, your model and/or your design. JDO handles relational and object databases and neatly encapsulates the O-R mapping. A number of RDBMS and ODBMS products manage CLOB and BLOB data as well as XML. Many RDBMS products claim to be Object-Relational. So, why would you start out creating the problem SDO is intended to solve?

    If someone can give real world examples of why we need SDO, I'd like to see it.
  16. Where SDO may fit[ Go to top ]

    Our experience has been that many organizations have data stored in a variety of places for a variety of reasons. Sometimes it even makes sense to do so, such as placing user logins and credentials in LDAP and other information in an RDBMS. SDO aims to provide a uniform data model for traversing and manipulating that data.

    In response to your question regarding having to give full domain privileges to enable SDO, I don’t see this as necessary. SDO can be used in conjunction with a variety of security models or “service architectures”. For example, a web service could return data for an operation that was a graph of SDO objects. In the latter case, SDO provides a data model (including the ability to generate XML schema), change tracking, and marshalling between tiers.

    Of course, SDO is not a solution for everything. If an application accesses a single relational database and is not multi-tier, then SDO would likely be superfluous. It would probably be better to use a persistence technology such as JDBC, EJB 3, Hibernate, JDO, etc. directly. In that case, it still may make sense to partition a data model among multiple databases to scale as long as data in different partitions does not need to be updated as part of a single transaction.

    Regards,
    Jim Marino
    BEA Systems
  17. Hello,

    I once had to move quite a bit of code up to JDK1.5. In some places in the code, because of making use of generics everywhere, I found some skeletons in the closet: code that compiled earlier since casts were used but does not compile now with generics. And, in fact, making it compile with generics wasn't easy, because the real problem was messy design.

    The migration report at walmart.com does not go into any issues of that kind. It gives the impression that there are no imponderabilities and that everything is just a matter of planning. For my personal taste the report shows a bit too much calculated optimism. But it is nonetheless an interesting read.

    Regards, Oliver Plohmann