Discussions

News: Introduction to Service Data Objects

  1. Introduction to Service Data Objects (18 messages)

    We have all been focused on the other side of persistence, but IBM has come out with an article on Service Data Objects (SDO). SDO is a framework for data application development, which includes an architecture and API. The article goes into how SOA relates to other standards, and shows an example application using it.
    If you think the J2EE programming models and APIs force developers to spend too much time on technology-specific configuration, programming, and debugging, then this article is for you! Many Java¬ô developers are skeptical about how heterogeneous data can be accessed uniformly, and have been disappointed in the various programming frameworks that propose to solve the problem. In this article, Java developers Bertrand Portier and Frank Budinsky introduce you to next-generation data programming with Service Data Objects (SDO).
    Read: Introduction to Service Data Objects

    Threaded Messages (18)

  2. SDO Question/Confusion[ Go to top ]

    Hello there.

    This was a very interesting article and SDO seems to be compelling technology. There is a point of confusion I currently have regarding this technology. It seems like the current notion of the client being disconnected from the data mediator (dms) is incomplete. The disconnected use case, as presented, makes great sense for a single user session, i.e. pull a customer account from a dms, edit it (track changes during edit), push edits to the data store via the dms. What happens, however, if I want to use this same concept to pull something into an Eclipse editor and work on it for several days? It seems to me, in this use case, I need to serialize intermittently to the Eclipse workspace (both data graphs and change logs) and be able to interact with two different dms's (Eclipse workspace and ultimately the original dms). Support of this use case would make SDO very compelling within the Eclipse environment.

    Thanks in advance for your thoughts on this,
    Chris Potter
  3. Introduction to Service Data Objects[ Go to top ]

    Just what we needed: Another buzzword!

    No. Seriously. This is basically JDO with brackets.

    It will be slow, too generic and probably very successfull.
  4. Introduction to Service Data Objects[ Go to top ]

    I think serverside.com is running out of topics. I remember a while ago they posted the same topic, but any way I think SDO is nothing but a copy cat of ADO.NET DataSet object model, where client can create the in memory data and relation ship in disconnected mode and push that changes to RDBMS (or any other supported data source) and vice versa. This idea only fly when you write hello world kind of apps or you have to bind the data to some front end GUI control. Besides that it has no use in enterprise applications, and even Microsoft still encourages you to use the stored procedure for serious development.
  5. I think serverside.com is running out of topics. I remember a while ago they posted the same topic, but any way I think SDO is nothing but a copy cat of ADO.NET DataSet object model, where client can create the in memory data and relation ship in disconnected mode and push that changes to RDBMS (or any other supported data source) and vice versa. This idea only fly when you write hello world kind of apps or you have to bind the data to some front end GUI control. Besides that it has no use in enterprise applications, and even Microsoft still encourages you to use the stored procedure for serious development.
    I thought the J2SE 5 now included Rowsets which is their equivalent of AD0.NET?
  6. OT: Stored Procedures[ Go to top ]

    ...Microsoft still encourages you to use the stored procedure for serious development.
    Which is a great way to get developers to write applications that only work with SQL Server.

    Stored procedures are certainly a very valuable tool, but I would tend to think that "serious development" includes identifying the best tools rather than applying a golden hammer...
  7. OT: Stored Procedures[ Go to top ]

    ...Microsoft still encourages you to use the stored procedure for serious development.
    Which is a great way to get developers to write applications that only work with SQL Server.Stored procedures are certainly a very valuable tool, but I would tend to think that "serious development" includes identifying the best tools rather than applying a golden hammer...
    It is true that stored procedures lock you to specific vendor, but it has no significance if any way you are developing applications using Microsoft technology. Besides that I am bit skeptical about O/R mapping or in memory data, these things usually don’t work for data demanding applications. The most logical and the easiest solution is of course OO databases, but for some reason big guys in the market still don’t want to go towards that path.
  8. Buzz words[ Go to top ]

    well....
    This is not a question of too many buzz word....itz question of weather developer world is under standing all important things that they should adopt between lot of things comming up every day.......
    r we ignoring good btw evils ??
    And in case of SDO it is very important to under stand why SDO is there and where it shd is used
  9. I am excited with this SDO initiative. Since ADO.NET arrival I am watching out for similar initiative in java world. Finally IBM & BEA did it. It will be intersting to see how all different worlds of data access merge together.
  10. Finally ADO.NET is coming to J2EE[ Go to top ]

    ...It will be intersting to see how all different worlds of data access merge together.
    Uhm, don't bet your money on that happening.
  11. One global API[ Go to top ]

    With SDO, you do not need to be familiar with a technology-specific API in order to access and utilize data. You need to know only one API, the SDO API, which lets you work with data ...
    We here this "One global API" story every time a new technology comes out. Thus I dont see any "buzz" on this now.
  12. Just another way to sell hardware[ Go to top ]

    This is just another way for IBM to sell more and bigger hardware.
  13. Somehow i get the idea…[ Go to top ]

    Somehow i get the idea that IBM can not do anything that get the approval in some parts of the j2ee community.
    Because Microsoft does not participate in the j2ee community, we need to bash against something other big, hmmm ok…let’s take IBM.

    What is your point? Please explain.
  14. So, I have this "open" mind while reading this article, then the Eclipse plug appears. The Java community should not tolerate these hidden agendas, the title should have been "Introduction to Service Data Objects with Ecipse".
  15. Introduction to Service Data Objects[ Go to top ]

    SDO in theory seems convincing. But I couldn't find out answers to certain questions.

    1. Where exactly SDO falls in the application layer? DTO , business objects? or both ? As far as my understanding, the SDO can be send to the client, where you can track the changes. In that way you can treat it as a DTO. In other words, the SDO is created from a DMS. I really don't understand where I can write some business logic. Is it only for "put data" "get data" kind of applications. In this perspective I dont know what aspect of *J2EE complexity* SDO is trying to solve.


    2. I don't need many objects,ONLY few - EReference, EAttribute etc. and I can work with the data graphs. This flexibility is something we need to analyse further. What we are trying to do is creating a data structure which is very much loosely coupled and flexible. This will lead to un maintainable code, where no one will understand what you are trying to do. Assume that if i re-write the sample code,

    DataGraph dataGraph= mediator.get("name");
    ...
    DataObject root = dataGraph.getRootObject();
    ...
    child = root.getDataObject("employees.0");

    Especially in a service provider consumer scenario, you need to know what exactly the name,type and the graph heirarchy , the provider used for the attributes and references.

    3. I am not sure if I have many bi-directional relationships in my data model. I guess the XML serializer and the Xpath implementation should be good enough to handle that.

    4. I like to see how simple I can implement a data graph for updating a [Manager---> Employee --- > Progress Report] data graph. Where the modification happens on any levels.
  16. Introduction to Service Data Objects[ Go to top ]

    Where exactly SDO falls in the application layer? DTO , business objects? or both ?
    SDOs ain't business objects. Sun's Core J2EE Pattern Catalog defines a Transfer Object Assembler whose usage has the most overlap with SDO. Of course SDO has additional benefits that the Core J2EE Patterns lack: language-agnostic XML externalization, and disconnected offline operation.
    I really don't understand where I can write some business logic. Is it only for "put data" "get data" kind of applications.
    SDO is document oriented and REST-like. For monitoring and other querying use SDO. Since SDO defines an XML externalization, non-Java applications can produce and consume data more easily than they could with JavaSpaces. SDO competes with RPC, though SDO's underlying implementation relies on RPC. In theory SDO could replace much or all of a service's public RPC entry points (in much the same way that SOAP's document encoding can replace SOAP's RPC encoding).

    But SDO is missing important features that more advanced SOA data frameworks have. For example WS-Resource allows business logic (client or server) to subscribe to data change events. SDO lacks eventing, lifecycle, etc. WS-Resource, Jini, or JXTA have expiration of data. SDO lacks reliability, whereas JXTA and WS-Resource offer hierarchical caching and discovery, which enable business service replication. In practice SDO's use is limited to intranets, where reliability is presumed of the shop's infrastructure. More advanced SOA frameworks such as JXTA or WS-Resource give reliability for multi-site grids whose individual hosts may be unreliable.
  17. Looks to me that SDO's Data Graph is covered as part of "Liquid Data for WebLogic"

    "the SDO API, which lets you work with data from multiple data sources, including relational databases, entity EJB components, XML pages, Web services, the Java Connector Architecture, JavaServer Pages, and more."

    I thought if I learn BPELJ, I can do all of above. So why SDO API?

    -Kirupa
  18. Answers to technical questions[ Go to top ]

    For technical discussions (as opposed to general IBM bashing :-), there is an EMF/SDO newsgroup at news://news.eclipse.org/eclipse.tools.

    Go to http://eclipse.org/newsgroups/index.html to request a password, and then post your question there for prompt help and advice from the EMF team.

    Thanks,
    Bertrand.
  19. ADO .Net for Java?[ Go to top ]

    SDO seems like a weak approximation of ADO .Net. The only thing I see in this is what amounts to a collection of serialized data structures, minus typed members as it looks like everything is stored as a string within the SDO Data Graph. The idea of a disconnected data set is way cool, especially for SOA, but without any kind of a query engine that allows for filter/sort criteria it leaves all the work to the programmer.

    To pull data out I have to traverse the object tree manually, and I have to know what the type of the data object is before I can load the data into a usable container. There are no real helper methods to deal with merge operations, and the SDO does not allow for multiple containers within the object.

    In ADO .Net the DataSet is treated just like a collection of tables from a database, and a strongly typed structure can be defined which allows me to use the row data fields directly as typed values. Tables can be merged, which allows joins between DataTables, and the Select method provides a convenient method for filtering relevant data collections and sorting the result set. It is almost like an in memory Database.

    SDO seems quite weak in comparison, which is too bad since I was hoping to leverage it in a similar way to ADO .Net in a Java project I am working on.

    Does anyone know if there is anything similar to ADO .Net for Java? Specifically I am looking for a dataSet that has the above mentioned functionality. SDO looks like a nightmare to manage compared to ADO .Net, as the disconnected container has no database functionality embedded in the object class. If not I will have to do some serious coding to get the functionality I need, :(