New Issue: Moving Data Between Contexts

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

Title: New Issue: Moving Data Between Contexts

Motivation:

HelperContexts were motivated principally by the need to allow JEE applications to maintain independent type registries, protected from possibly conflicting types that may be defined in other applications.  In an SCA environment, we can imagine HelperContexts being associated with contributions, since these normally define the boundries of artifact resolution, which includes the XSDs, java classes, or whatever else is being used to define types.

If we envision SDO being used as data transport in a SOA, for example, in SCA wiring, then it becomes clear that SDO must also provide some mechanism for moving data between contexts.  This is, in my mind, the most common use-case for moving data between contexts.  On the other hand, it is completely possible for a single application to want to manage multiple contexts, and to want to move data between contexts.  In the discussion that follows, moving data between applications should be considered as a common use-case for a functionality that can also be used within a single application.

More specifically along the lines of our charter, the ability to move data between contexts is the central concept behind our approach towards relaxing containment requirements.  We are envisioning that some applications within the SOA environment will not have need for or interest in signifying some relationships as being containment, while other relationships are references.  Other applications will require containment, perhaps because they will serialize to XML, perhaps because they use some other feature, such as ChangeSummary, CopyHelper, or EqualityHelper that relies on containment.  If we are going to relax containment requirements, then we must either redefine these features (which would break backwards compatibility), or we must find a way to add containment information on the fly, so that this operations will still be available for data objects that come from contexts where containment does not make sense.  This operation, adding containment information "on-the-fly", is, in this proposal, implemented as moving data objects from a context where the types are defined without containment information to a context where the types do have containment information.  As previously stated, this could mean moving the data objects between applications, or between contexts in a single application.

The cast() method, which I want to introduce with this issue, was discussed at the F2F, and identified as a high priority for SDO 3.0.  For more information on where this is all headed (slowly, with baby steps) please see:

http://www.oasis-open.org/apps/org/workgroup/sdo/download.php/26723/Containment%20in%20SDO%203.ppt and
http://www.oasis-open.org/apps/org/workgroup/sdo/download.php/26711/SDO3%20Java%20Projections.ppt

Description:

Consider a DataObject O1, with Type T1, defined in context C1.  Define an operation that will "cast" from O1 to a DataObject O2, with Type T2, defined in context C2.  The data objects O1 and O2 would provide alternative views of the same data.  The Types T1 and T2 may differ slightly, for instance, in how containment is defined.  In order for casting to make sense, it will be necessary to define some concept of "compatibility" of types, that is, what must T1 and T2 have in common, in order for the cast operation to make sense.  I would, however, like to leave the exact definition of compatibility for a later issue, and discuss the operation in principle first.  The details of the relationship between O1 an O2, for instance, if changes to O2 are visible in O1, however, should be determined as part of the resolution of this issue.

Proposed Assignment JIRA Components:

Topic 10:  Containment
Topic 7: TypeSystem and Helpers