OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdo message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: AW: [sdo] ISSUE 161: Implications of removing DataGraph


Hi Ron,

Nice job! This is pretty much what I had in mind. I noticed one gramatical error:

Earlier versions of SDO viewed this as the normative state ...

Thanks,
Frank.

Inactive hide details for "Barack, Ron" <ron.barack@sap.com>"Barack, Ron" <ron.barack@sap.com>


          "Barack, Ron" <ron.barack@sap.com>

          07/06/2009 09:21 AM


To

<sdo@lists.oasis-open.org>

cc


Subject

AW: [sdo] ISSUE 161: Implications of removing DataGraph

Hi Everyone,

Here's my attempt to rewrite chapter 3 of the core spec. The current version of this chapter focuses on DataGraph and DAS's, both things we have agreed to avoid talking about in SDO 3. This is really the only place where we talk about the disconnected model, however, so I wanted to retain that topic.

_____________________________________________________________________________________________

1 Architecture
The core of the SDO framework is the
DataObject, which is a generic representation of a business object and is not tied to any specific data source.

A data graph is a set of interrelated DataObjects. Data graphs are often enclosed in envelope objects. These envelopes are in fact normal DataObjects but have special technical properties, for instance, to enable change tracking. Such properties are termed “technical” because they do not represent business data.

The relationship between DataObjects can be through containment and non-containment references. Containment references are special in that a DataObject is contained by at most one other DataObject. DataObjects related through containment form a tree having a single root DataObject that directly or indirectly contains all the other DataObjects in the tree. A closed data graph is a data graph having such a tree-like form, where even the non-containment references refer only to DataObjects in the tree. Earlier versions of SDO viewed as the normative state for data graphs and required closure for serveral fundamental operations, for instance, for serialiization. In SDO 3, envelopes can be given technical properties that enable SDO functionalities even if the embedded data graph is not closed.

Most DataObjects come directly or indirectly from some persistent storage. The persistence mechanism is typically exposed as a service. SDO supports the use of a disconnected interaction model, in which changes made by the client are not written back onto the persistent storage unless some explicit service call is made to the storage mechanism. During both read and update operations, potentially large and complex data graphs are transmitted between the persistence mechanism and the client application. Thus, a typical scenario for using a data graph involves the following steps:

One way that SDO supports the disconnected model is by providing a mechanism though which the server can find the client's modifications to the graph and retrieve old values. All the changes made by the client, including creation, deletion and modification of DataObjects are contained in the ChangeSummary.

SDO specifies minimum functionality for implementations. An implementation may provide additional function so that valid results would be returned where this specification would produce an error, provided that the functionality is a strict superset and all valid uses of the SDO specification operate correctly.

_____________________________________________________________________________
Von:
Barack, Ron [mailto:ron.barack@sap.com]
Gesendet:
Mittwoch, 1. Juli 2009 13:38
An:
sdo@lists.oasis-open.org
Betreff:
AW: [sdo] ISSUE 161: Implications of removing DataGraph

Hi Everyone,

The CoreSpec, section 2.1, "Key Concepts", lists DataObjects, DataGraphs, and DAS's as the 3 key concepts behind the SDO spec. I believe we have also made the decision to remove references to DAS's. It seems to me that this section can be removed without much loss to the spec.

The CoreSpec chapter 3, "Architecture" also focuses very much on DataGraphs and on DAS's (). In this case, however, I would not want to eliminate the entire chapter, since this is where the "disconnected model" is described. The chapter would have to be more or less completely rewritten, however.

Unless someone else volunteers, I am willing to take a stab at re-writing chapter 3, but would first like some feedback from the group regarding whether they agree to a rewrite, or won't to try to eliminate DataGraph in a less invasive procedure.

Best Regards,
Ron

_______________________________________________________________________________

Von:
Barack, Ron [mailto:ron.barack@sap.com]
Gesendet:
Freitag, 26. Juni 2009 12:08
An:
sdo@lists.oasis-open.org
Betreff:
[LIKELY JUNK][sdo] ISSUE 161: Remove references to DataGraph from Spec

http://www.osoa.org/jira/browse/SDO-161

GIF image



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]