IBM & BEA Share the Technologies (commonJ). Consists of SDO (originally IBM called it Websphere Data Object but renamed to SDO), WorkManager for Application Servers (API to schedule work items for concurrent execution), and Timer for Application Servers (API for setting timers to do work actions like CRON within container).
They approached each other, then created JSR235: “Defines core infrastructure APIs for heterogeneous data access that supports common application design patterns and supports higher-level tools and frameworks.”
Webspshere 6 is slated to include SDO later this year. JSF with SDO redbook
With SDO it is what do you want to do, not what technology do you want to use. A higher level of abstraction.
More easily to bind, query, view, update, introspect data.
The data comes from different places (heterogeneity), decouple application code from data access code.
Support for Tools and Object/Relational disconnect.
SDO has API that is applicable to all types of data sources, dont assume back end store.
Based upon disconencted data graphs (tree or graph structured data) – retrieve graph, update the graph, and apply changes back to data source.
Access to data with classes which use data mediator services.
Data Transfer Object – move several pices of data over the network in a
single call in order to reduce number of method calls. Usually an assember is
used to keep the domain model and the data transfer objects independednt of each
No comments yet.