https://issues.apache.org/jira/browse/TUSCANY-1493 is for exploring the proposal of a snapshot mapping framework that has been attached to the JIRA by Bert and Kris, for the purpose of transforming data between different representations to cope with imposed legacy backend formats and the desire to use SDO in the user interface layer. I've been looking at it to begin understanding if/how we might apply the principles to Tuscany (see my earlier note in this thread for a link to the code/javadoc). Take a look at the discussion there for the full context and motivation for this work. I'll probably be repeating some of that info below in trying to understand how to go forward, and perhaps misinterpreting what's there, so please view this as discussion material/ not reference material.
I think the first thing to say is that we'll need to get our heads round how what's already there in the snapshot code implementation extends to the Tuscany implementation. I say this because the attached impl has been written to support a subset of SDO features, e.g. no support for Open Content and Sequences. However, there's clearly contention between using all the SDO features or a subset of them, since we can only have 100% reversible transforms between representations if we use only the lowest common denominator of features that can be represented by the set of formats that we might want to transform between. Given that JavaBeans is definitely going to be one of those formats we'd need to tackle the issue of a generic mapping between sequenced SDOs and JavaBeans. I'm sure this kind of thing will have been tackled elsewhere, such as in JAXB, but I'm not up to speed with any solution. Perhaps the thing to do is to start experimenting with the existing capabilities of the snapshot framework, expressing pre-requisities for its use, or better still adding in diagnostics that enforce constraints on the complexity of the type systems that can be used. There's also one addition that's been made in this implementation to the SDO API which is made use of in the snapshot impl whcih may cause us problems, as it is not generally valid in an implementation that supports open content. This is the getIndex() method of Property, which is undefined for an open content property, and I guess this is the primary reason why it wasn't included in the SDO spec. We can work out the index of a given Property in the context of a given SDO DataObject; and whilst the Property remains an instance Property of that DataObject then the index will be a constant, but we'd have to have a good think about whether the corner cases where sequences of state transitions for a DataObject mean that the index might vary over time. As Bert and Kris have described in the JIRA the implementation extends SDO to introduce the concept of PartialDataObjects, proxies and identity Properties, and again the snapshot implementation depends on some or all of these concepts. So we'd need to decide what value the new function might have without these concepts. This is a question to you the user community, I don't think I'm close enough to the real action to have a sufficiently well informed opinion here. A PartialDataObject is parameterized by state which has the effect of making a subset of the Properties in its Type unavailable. I think this is primarily there to address the need to present different views to different viewers without having to have multiple metadata descriptions, one per view. For example, when presenting data to a medical secretary and to a clinical practitioner, the former should not be able to see the details of medical data. With a PartialDataObject these data can be hidden from view without the need for creating extra medadata. A PartialDataObject also introduces the concept of an identity Property. I guess this is most useful when committing back changes to a back end store. there have been other similar questions on this matter on our mailing lists, but the SDO API has deferred this issue to be the responsibility of a data access service. This seems to be a way of catering for that behaviour within SDO, and I guess is tied up with the desire in this implemetation not to have a profusion of metadata all relating to different views of the same back end data. Building on the hiding of Properties, and the introduction of an identity Property, the implementation defines a DataObject for which all Properties except its identity Property has been hidden, to be a Proxy. If I recall correctly, all these concepts surface in the implementation of the snapshot, so we either have to find a way to introduce the concepts to Tuscany's API or to do without them. The implementation makes use of Java generics, yet the SDO 2.1 spec requires Java 1.4 compatibility, so this would have to be a bolt on feature for those who are not constrained to keep to 1.4. Can I ask who would use this feature? how much pain does it's absence cause you? in what scenarios might you might apply it? how what's been described so far fits your needs? who'd be prepared to get involved in implementing it in Tuscany? I think this is the kind of exploration we really ought to be doing as a community in Tuscany, addressing real users needs and providing the opportunity to feed back to the SDO 3 spec effort. Kelvin. On 05/12/2007, kelvin goodson <[EMAIL PROTECTED]> wrote: > I've finally managed to add Bert and Kris's SDO implementation with > snapshot data mapping to svn in my sandbox. I'd hoped to get to this > a while back, but have been unwell. See [1]. I added javadoc under > the apidocs directory (for some reason firefox doesnt like the doctype > header in the javadoc html, but i.e. is fine with it). I've got an > A0 sheet of scribbled UML on my office floor that contain a kind of > stream of consciousness sequence of observations on the snapshot > implementation and how it relates to the facets of the agfa SDO > implementation. I'll convert these into a more coherent form and > append here shortly. > > Kelvin. > > > [1] http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/kgoodson/agfasdo/ > > > On 31/10/2007, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > We've developed a custom data mapping framework that provides a mapping > > between objects and dataobjects. We use this framework to convert between > > our Hibernate POJO's, legacy business objects and data objects. > > > > We're currently looking on how to contribute this to Tuscany (see > > http://issues.apache.org/jira/browse/TUSCANY-1493). > > > > Bert > > > > > > > > > > "Adriano Crestani" <[EMAIL PROTECTED]> > > Sent by: [EMAIL PROTECTED] > > 31/10/2007 02:28 > > Please respond to > > [email protected] > > > > > > To > > [email protected] > > cc > > > > Subject > > Re: Applying SDO to databases? > > > > > > > > > > > > > > > > Hi Jason, > > > > Give a look at Tuscany DAS: > > http://incubator.apache.org/tuscany/das-overview.html > > > > There are versions for Java and C++. You can load data from rdb into SDO > > Graph and vice-versa. > > > > Adriano Crestani > > > > On 10/30/07, Jason Clark <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > I've been reviewing all the SDO information I can find in my continued > > > quest > > > to learn about SCA and complemenatry technologies to enhance the project > > I > > > am currently working on. > > > > > > > > > > > > To be specific, I have a database of people's contact information in the > > > event of an emergency. > > > > > > > > > > > > I've seen lots of SDO information regarding dealing with XML and such, > > but > > > what would the strategy be for dealing with the same information but > > > gathered from a database? In this case, SQL Server using their JDBC > > > driver. > > > Maybe that's to specific, but generally, how do you approach this > > problem? > > > I > > > see XML Helper classes but not much in the way of dealing with database > > > persistence in any of the samples I could find. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > -Jason Clark > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
