[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: [sdo] Containment discussion
Hi Blaise,
Somehow forgot my main question: How connected is
this algorithm to your proposal SDO-126? In some ways, they are completely
orthogonal, I mean, the algorithm does not rely on redefining containment.
On the other hand, the goal is to get a reasonable XSD, no matter where I start,
then it seems there is an implication of cycles, etc., in the containment
graph.
I want to make sure that by selecting your proposal for
SDO-124, we are not implicitly deciding SDO-126. If necessary, we should
discuss SDO-126 first.
Ron Von: Barack, Ron [mailto:ron.barack@sap.com] Gesendet: Donnerstag, 24. April 2008 12:46 An: Blaise Doughan; sdo@lists.oasis-open.org Betreff: AW: [sdo] Containment discussion Hi
Blaise,
First a question: How does the algorithm react
when I use Department as the root of my graph? If I understand correctly, it won't
create an "orphan" element in the XML. How does the algorithm react
here? Does it produce an unclosed graph? If not, where are the
non-contained addresses serialized?
Thanks for the
description of the use-case. My first reaction is that I'm not so sure how
much it matters that the tech root is "unexpected": the main thing is that we
produce something that can be described in a WSDL, and validates against it's
XSD. This can be achieved with by adding a tech root. And as the
model gets more and more complex, won't the orphan properties that collect at
the root start making it look more and more like a technical root, that is, the
presence of the orphans will become just as
unexpected?
Maybe you should
describe what you think the expectations are that are coming from these other
frameworks? The expectation from a WebService is that the payload can be
validated against the WSDL, right? And having a schema, we can also
generate JAXB, so integration with JAVAEE is also covered. I
also think that as soon as we are dealing with references to objects that don't
have @XmlID, then we are losing the semantics of the graph anyway (until the
JAXB integration solves this for
us!) Actually, I think SDO-66 is orthogonal to the current
discussion. SDO-66 is all about adding to a the metadata used in a data
graph, to make the model usable in different scenarios. Let me describe
where I think SDO-66 can be used to solve some of the problems associated with
containment, especially if you combine them with the Oracle's proposal for
defining keys as part of the SDO metadata. I've
been playing with our JPA integration lately, and I've been wondering if,
in a world where we define some objects as having keys, the requirement of
having datagraphs be closed isn't excessive. In a complex data model,
we're always going to have to decide which paths to follow, and where to trim
the graph. Is it necessarily a problem to use a key that is not resolved
in the graph? Image a model like this: Customer has Orders, Orders
have parts, Parts have Suppliers, Suppliers have Addresses, Addresses have
Countries. For a particular WebService, we may need the customer orders,
and for every order the part, but not for every the supplier. In this
case, it might be reasonable to ship the PK of the supplier to the client,
and if he wants, he can follow the link (by using a DAS, or whatever). Or take
the list of countries. Is it really efficient to return this list with
every call that returns an address? Won't we want to return only the
country's PK as part of the graph, and leave it to the application to manage the
cache of countries.
What we need for this is SDOs that have primary keys,
and we need to say that a type is, in the SDO-66 sense, compatible with its
key type. Then, when I project from my JPA model (which has the complete
domain), into my XSD model (which has some complex objects replaced by
keys), I can produce XML that is pruned in all the right places. Actually,
I think the approach is not that different from what AquaLogic does. When
you go over a webservice, you have to replace relations that are there in the
domain model with keys, and you leave it to the application to call the DAS and
follow the keys, as needed. The difference is, that AquaLogic sees the
boundaries as being part of the type definition, with SDO-66 the boundries are
not part of the type definition, but added into it, to support specific
scenarios.
This should be contrasted with the proposals for
SDO-124, both these issues effectively serialize the complete transitive closure
reachable from the root of the data graph. This is not a criticism of the
algorithms, it's just pointing out how they differ from
SDO-66.
But it does impact a little on the discussion of the
use case. If there's a non-SDO client there that cares about the shape of
the XML generated by the SDO service, then, to me, it's very unlikely that the
client will be satisfied with the schema produced by either of the
SDO-124 proposals. In order to bring the graph into an acceptable form,
you're probably going to have to feed in the expected form via SDO-66, and
project into it. That is, I don't think we can solve your second use case
with either algorithm. This makes, to my mind, the use-case where SDO is
on both sides of the web service the more compelling
one.
Ron
Von: Blaise Doughan [mailto:blaise.doughan@oracle.com] Gesendet: Mittwoch, 23. April 2008 18:10 An: sdo@lists.oasis-open.org Betreff: Re: AW: [sdo] Containment discussion XML serialization refers to two concepts in SDO: 1. The XML representation used when a data object goes through Java serialization (see SDO 2.1 section 6 "Java Serialization of DataObjects"). Here we are sending data objects from one SDO environment to another SDO environment. In this arena we can focus on making the transfer of data as efficient and portable as possible (which may require Xcalia's technical root). 2. The XML representation used when a data object is marshalled by XMLHelper. Here we are sending a message that may or may not be received by an SDO client. This is the compelling use case, as it relates to how SDO interacts with other technologies (Web Services, Java EE, .Net, etc.). In this case if we marshal/save an employee data object it would be unexpected to have the result wrapped in a technical root. Here is where the Oracle proposal (SDO-124) fits. Oracle Proposal (SDO-124) and SDO 2.1 SDO 2.1 allows the current metadata: Department --containment --> Address Department --containment --> Employee Employee --non-containment --> Address With this SDO 2.1 compliant metadata it is possible to create a graph that can not be serialized. All you need to do is to specify an instance of Address on an instance of Employee that is not containment by an instance of Department. The algorithm in the SDO 2.1 spec requires that you specify enough containment relationships (and obey them). The Oracle algorithm (SDO-124) makes the assumption that if you specify containment relationships you are specifying enough (just like SDO 2.1), in addition if no containment relationships are specified then there is special treatment for them. Comparing the Containment Proposals Oracle Proposal (SDO-124) One of the interesting aspects of the Oracle proposal (SDO-124) is that XML messages can be sent relative to a particular SDO type. This is very useful for DAS implementations that want to have per type find operations and then send this as an XML message. If the underlying metamodel had a containment relationship between Department and Address then the Oracle proposal (SDO-124) could produce an XML message wrt Department and another XML message wrt Employee. Xcalia Proposal The above use case is not addressed by the Xcalia proposal. SAP's proposal (SDO-66) The SAP proposal (SDO-66) does address this use case, my understanding of that proposal is that a set of metadata would need to be defined per root type and stored in its own instance of HelperContext. DAS would realize data in a HelperContext, and then project that data into another HelperContext that corresponds to the root type of the query. The onus would be on the user to ensure that the types between the HelperContexts are compatible. -Blaise Barack, Ron wrote: 9279AFBA5302884AB7169C4C51B6FDF7F5FE95@dewdfe1a.wdf.sap.corp type="cite">--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]