Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "EclipseLink/UserGuide/SDO/Introduction to SDO (ELUG)"
(→Introductin to SDO) |
m (→What Is SDO?) |
||
| Line 4: | Line 4: | ||
==What Is SDO?== | ==What Is SDO?== | ||
| − | SDO is designed to be a unified view of data, much like the POJO is in Java EE. | + | SDO is designed to be a unified view of data, much like the POJO is in Java EE. There are several programming languages (of which Java is one) that support the SDO specification. |
You can use SDO to develop data-oriented applications. SDO includes an architecture and API. | You can use SDO to develop data-oriented applications. SDO includes an architecture and API. | ||
The following are possible expressions of SDO: | The following are possible expressions of SDO: | ||
| − | + | * [[Dynamic Object Model]] | |
| − | + | * [[Typed Object Model]] | |
| − | + | * [[XML Representation]] | |
| − | + | * [[Disconnected Object]] | |
| − | For more information, see | + | For more information, see ... |
| Line 20: | Line 20: | ||
===Dynamic Object Model=== | ===Dynamic Object Model=== | ||
| − | SDO metadata is represented as Type and Property objects. A Type is comparable to a Java class, and a property to a Java field. | + | SDO metadata is represented as Type and Property objects. A Type is comparable to a Java class, and a property to a Java field. This metadata is defined at run time either programmatically or from an XML schema, as follows: |
| − | + | <code> | |
Type customerType = TypeHelper.INSTANCE.getType(“urn:example”, “customer”); | Type customerType = TypeHelper.INSTANCE.getType(“urn:example”, “customer”); | ||
Property firstNameProperty = customerType.getProperty(“first-name”); | Property firstNameProperty = customerType.getProperty(“first-name”); | ||
| Line 34: | Line 34: | ||
DataObject addressDO = DataFactory.INSTANCE.create(“urn:example”, address); | DataObject addressDO = DataFactory.INSTANCE.create(“urn:example”, address); | ||
addressDO.set(“street”, “123 Any Street”); | addressDO.set(“street”, “123 Any Street”); | ||
| − | + | </code> | |
| Line 40: | Line 40: | ||
SDO as dynamic object models is useful in certain frameworks (dynamic models allow metadata to be added without requiring a redeployment of the application), but in other situations a strongly typed model is required (typed models allow for code completion in an IDE). A code generation step can be performed to produce typed interfaces complete with bean style accessors. | SDO as dynamic object models is useful in certain frameworks (dynamic models allow metadata to be added without requiring a redeployment of the application), but in other situations a strongly typed model is required (typed models allow for code completion in an IDE). A code generation step can be performed to produce typed interfaces complete with bean style accessors. | ||
| − | + | <code> | |
Customer customerDO = (Customer) DataFactory.INSTANCE.create(customerType); | Customer customerDO = (Customer) DataFactory.INSTANCE.create(customerType); | ||
CustomerDO.setFirstName(“Jane”); | CustomerDO.setFirstName(“Jane”); | ||
| − | + | </code> | |
| Line 49: | Line 49: | ||
SDO has built in support for handling XML. The SDO metadata can be introspected to determine what the corresponding XML representation is. | SDO has built in support for handling XML. The SDO metadata can be introspected to determine what the corresponding XML representation is. | ||
| − | + | <code> | |
XSDHelper.INSTANCE.isMixed(customerType); | XSDHelper.INSTANCE.isMixed(customerType); | ||
XSDHelper.INSTANCE.isElement(firstNameProperty); | XSDHelper.INSTANCE.isElement(firstNameProperty); | ||
| − | + | </code> | |
| − | The DataObjects themselves can then be converted to from | + | The DataObjects themselves can then be converted to and from XML. |
| − | + | <code> | |
XMLHelper.INSTANCE.save(customerDO, “urn:example”, “customer”, System.out); | XMLHelper.INSTANCE.save(customerDO, “urn:example”, “customer”, System.out); | ||
| − | + | </code> | |
| Line 62: | Line 62: | ||
SDO was designed to represent disconnected data in a SCA (Service Component Architecture) environment. The main mechanism for accomplishing this goal is the ChangeSummary which tracks changes made to data objects over time (for DataObjects that have a ChangeSummary property). | SDO was designed to represent disconnected data in a SCA (Service Component Architecture) environment. The main mechanism for accomplishing this goal is the ChangeSummary which tracks changes made to data objects over time (for DataObjects that have a ChangeSummary property). | ||
| − | + | <code> | |
List changed = customerDO.getChangeSummary().getChangedDataObjects(); | List changed = customerDO.getChangeSummary().getChangedDataObjects(); | ||
| − | + | </code> | |
| − | EclipseLink is focussed on separating data from its messaging or persisted representations. | + | EclipseLink is focussed on separating data from its messaging or persisted representations. Now with SDO support this data can be a POJO or a DataObject. This allows you to work with data in both Java EE and SCA environments. |
Revision as of 14:39, 21 April 2009
This section introduces concepts of Service Data Objects (SDO) and provides general information on it.
Contents
What Is SDO?
SDO is designed to be a unified view of data, much like the POJO is in Java EE. There are several programming languages (of which Java is one) that support the SDO specification.
You can use SDO to develop data-oriented applications. SDO includes an architecture and API.
The following are possible expressions of SDO:
For more information, see ...
Dynamic Object Model
SDO metadata is represented as Type and Property objects. A Type is comparable to a Java class, and a property to a Java field. This metadata is defined at run time either programmatically or from an XML schema, as follows:
Type customerType = TypeHelper.INSTANCE.getType(“urn:example”, “customer”);
Property firstNameProperty = customerType.getProperty(“first-name”);
Type addressType = TypeHelper.INSTANCE.getType(“urn:example”, “address”);
Data is represented as instances of Types called DataObjects, these correspond to objects in Java. DataObjects have many generic accessors that can be used to manipulate the data.
DataObject customerDO = DataFactory.INSTANCE.create(customerType); customerDO.setString(firstNameProperty, “Jane”);
DataObject addressDO = DataFactory.INSTANCE.create(“urn:example”, address); addressDO.set(“street”, “123 Any Street”);
Typed Object Model
SDO as dynamic object models is useful in certain frameworks (dynamic models allow metadata to be added without requiring a redeployment of the application), but in other situations a strongly typed model is required (typed models allow for code completion in an IDE). A code generation step can be performed to produce typed interfaces complete with bean style accessors.
Customer customerDO = (Customer) DataFactory.INSTANCE.create(customerType);
CustomerDO.setFirstName(“Jane”);
XML Representation
SDO has built in support for handling XML. The SDO metadata can be introspected to determine what the corresponding XML representation is.
XSDHelper.INSTANCE.isMixed(customerType);
XSDHelper.INSTANCE.isElement(firstNameProperty);
The DataObjects themselves can then be converted to and from XML.
XMLHelper.INSTANCE.save(customerDO, “urn:example”, “customer”, System.out);
Disconnected Object
SDO was designed to represent disconnected data in a SCA (Service Component Architecture) environment. The main mechanism for accomplishing this goal is the ChangeSummary which tracks changes made to data objects over time (for DataObjects that have a ChangeSummary property).
List changed = customerDO.getChangeSummary().getChangedDataObjects();
EclipseLink is focussed on separating data from its messaging or persisted representations. Now with SDO support this data can be a POJO or a DataObject. This allows you to work with data in both Java EE and SCA environments.