"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.