IBM's developerWorks site has two new articles, from Jean-Louis Marechaux on the key concepts behind Service Data Objects and Elliotte Rusty Harold with an early look at Junit4.

"Simplify and unify data with a Service Data Objects architecture" goes into SDO's objectives, its architecture, and the elements that go into using SDO in some detail. It expresses the objectives as follows:

The goals of SDO are numerous. In a sense, SDO can appear as the "Swiss Army Knife" of J2EE, because it contains many features for a variety of purposes. Basically, there are five main topics SDO and related technologies plan to address:

• Data access simplification: The first goal is to provide uniform data access to a wide variety of Enterprise Information Systems (EIS). This comprises databases, legacy (using JCA), XML, or Web services sources. By using a unique and simple model, applications get rid of the complexity of several data access APIs and frameworks with SDO.
• Data abstraction: Data representation is independent from its source using SDO. This is an implementation of a J2EE pattern called Domain Store. This level of abstraction has several advantages, such as making data manipulation easier and promoting loose coupling between different layers.
• Data manipulation: Once the information is retrieved, SDO also wants to offer a uniformed programming language for data manipulation. In short, using the API and its interfaces, an SDO client must be able to read data and perform changes. SDO features both a connected and disconnected model (explained later in the article.)
• Data transport: One part of the SDO concept is based on the Transfer Object and the Transfer Object Assembler patterns. Once encapsulated into SDO objects, data can be transferred efficiently over J2EE layers.
• Design patterns adoption: A key objective of SDO is to also encourage the adoption of common J2EE patterns. That's why SDO architecture is based on well-known patterns like Transfer Object, Data Access Object, Transfer Object Assembler, and Domain Store (see Resources). Using SDO, an application takes advantage of these proven design strategies. It fosters layering and loose coupling.

His conclusion, which refers to JSR-235 (still in "expert group formation," although IBM and BEA both have specifications and implementations of SDO available):

SDO specification version 1.0 has been submitted and approved by the Java Community Process in late 2003 and it is still a work in progress. Just like any submission, it is hard to forecast whether it will be widely adopted or not in the long run. Nevertheless, the specification is backed by major Java industry stakeholders and it really addresses an important aspect of common enterprise applications: heterogeneous data access. SDO provides a neutral representation of business data, fosters a datasource-agnostic model, and promotes loose coupling. For these reasons, it will probably be a key component of future SOA applications.

"An early look at JUnit 4" shows those familiar with Junit how the upcoming Junit 4 might change how testing is approached, including the use of annotations for testing (which affect setup and teardown on a test-by-test basis as well as at the test suite level, and the actual test cases themselves), testing exception handling (which looks very elegant), tests for performance (i.e., tests with timeouts!), and what people might miss from Junit 3.

Good article.
I'd like to mention Xcalia products also support SDO, and Xcalia has started to work on SDO with IBM and BEA.

Best Regards, Eric.

I'm having trouble understanding why I would possibly want to use a graph of essentially untyped DataObjects rather than typed objects that would be returned from a DAO. It seems like any of the benefits that are discussed in this article are already available by using well known (core) patterns.

I'd be more interested in a strongly typed query language akin to, but not necessarily the same as, Microsoft's recently announced LINQ project (http://msdn.microsoft.com/netframework/future/linq/default.aspx) where the data source is abstracted. EJB3 annotations and the entity manager API are a step in the right direction but it needs to be extended to data access in general regardless of the data source type and then make the queries typed. The whole query/data access arena seems a mess today. There's XPath, XQuery, SQL, EJBQL, and I'm probably missing more and most being untyped. It's a tall order to ask for some uniform method of query and manipulation, but without aiming for it, how many more languages are we going to have to learn?

Here is an example of such typed queries in a product for the .NET platform that I found interesting upon first glance:
http://www.lastcomponent.com/index.php?page=products/quickstart/querying&left=products/quickstart/tree/querying

You can use typed access as well with SDO. You may want to use untyped access when the shape of the data is not known at development time.

Jim Marino
BEA Systems

First of all, I will start my comments by stating that I will be looking for replies from those in the IT industry who are not employed by BEA or IBM. (Yes, there is a biased opinion built into comments from those companies and their employees.)

The fact that BEA and IBM are promoting this and from the article, are pushing that they already provide "...tools that leverage SDO technology..." (what a nice marketing plug) should make us question the importance of this in the grand scheme of things.

Honestly, I would like some more insight from others regarding this "Service Data Objects" pattern as it appears to be just a fancy DAO pattern, in my opinion. From the article SDO (and Data Mediator Service) "...hides the actual data storage and provides a level of abstraction...", which is very similar to the DAO pattern which is used to "...abstract and encapsulate all access to datsources...". The only real difference I see (from the article) is that the SDO pattern uses a common Data Object and Data Graph to represent the data as opposed to the user defining their own data objects with the DAO pattern.

Has anyone (not employed by BEA or IBM) actually researched this new pattern and tried a sample appliction based on this pattern? To me it seems like another new, fancy alternative to which an old, working solution has already been provided.

Beside DAO, SDO also try to solve problems other J2EE patterns like Transfer Object and the Transfer Object Assembler deal with.

For example, SDO can replicate only changed data "over J2EE layers". I guess this means if you have say an instance of class "Customer" who consume 20K in memory and if you change just his address fields - let´s say about 2 K - SDO is smart enough to transfer just these 2K pieces of data over wire. DAO pattern does not have this concern.

Humm, now i got that "liquid" name ;-)

about SDO

Hmmm There are 3 things I don't like.

1. Generic data models
2. Yet Another Abstraction Layer (YAAL)
3. Decopling of data from the source

1. Ive worked with generic data models. They are great if you want to model anything in your 1 time model, but they suck big time if you want to get data out of it with a bit of performance. Besides that, nobody outside your scope of the project will understand the model, and will not get any data out of it. We have just thrown the seperation in development (UI programmers, model programmers etc) overboard.

2. Its yet another layer on top of the already thick stack. I personally thingk that Spring can handle the access of many differnt datasources fine. Again performance will be an issue and the maintainability of your application and the stability (more code, more bugs)

I always like the frase.. Keep it Simple, Stupid.

3. The option to decople the recieved data from the source will give you very many headaches when you have to resynchronise your data again. If it is only to read, then fine my me, but again there are more simple solutions, but for CRUD actions. NOWAY.


This new standard will only bloat your code, make it less maintainable, less stable, performan(e) less and to top it all, nobody will understand the domain you are working with.


about JUNIT4.. it rocks.... they understand the idear to keep things simple.

2c.

1. Generic data models

Someone here already explained actually you can use typed data model and why you should to use generic model instead.

2. Yet Another Abstraction Layer (YAAL)

Right, with Spring you can easily access DataSource beans besides any other resource you can code an interface to it. But seems like in SDO these datasources (database, Web service, Lightweight Directory Access Protocol (LDAP), legacy, and so forth) are actually hidden and clients are exposed to the business objects instead. The SDO take care of low level detais. Apples and oranges.

3. Decopling of data from the source1.

Could you be more specific about this, please ?

@1
If I can use typed models, why do it when you can use spring/hibernate ??

@2
I still have to program DAO's to access my entities in the database. Like I have to code something for hibernate to work with my DB. Lower level details are hidden from me when I use hibernate. I can imagine that there are also tools avail for the other types of access. Spring can then be used to access my domain model.

@3
What I meant was Iam not a fan of offline datastores. Retrieving data from a source and then sever the connection to it. It gives you problems when you connect to the source again and try to synchronize. Unless you use it only to read and then throw away.

Regards.

Generic data models are incredibly useful when dealing with complex data that is evolving rapidly. The XML DOM is perhaps the most widely used example, though I often find it a bit awkward to work with (element/attribute distinction, tree structure). RDF is more powerful (graph structure, ability to merge data from different sources, metastatements), but can be hard to work with. SDO looks very clean and well thought out (containement, change sets etc). I'll definitely give it a try!