Re: AW: AW: [sdo] HelperContext material for vF2F

Hi Blaise,

I'm definitely resigned to the deprecation of INSTANCE, since we all know that implementing them in a way suitible to an app server requires a bunch of really messy hacks.  SDO.defaultHelperContext() is a good compromise. 

If I read the JAXB spec correctly, users do have to care what implementation they get at runtime: it must be the same one used to generate the POJOs.  I'd be very surprised if I could take a JPA persistent object from eclipseLink and use it in another implementation.  In any case, users being able to deploy to an app server without caring which SDO implementation they care seems to be a function of good source code compatibility.  Anyway, the goal seems at odds with the proposal which includes a lot of mechanisms so that users that do care about the implementation can select the one they want (which is a good thing).  I think in general we are on the same page about the bootstrap functionality in the new SDO class.

I actually like the wording in the spec about the standard serialization algorithm, and I definitely think we should continue to define one.  We define what how interop is supposed to work, but don't require implementation to use it.  We should also improve the algorithm, so that non-closed graphs can also be serialized. This was also a big reason for not using the standard serialization in our implementation, we may revisit the issue when this is fixed.  But I don't have any proposals yet.  For instance, I'm not sure if the implementation name should also be on the stream.

I differenciate betweed source code compatibility (any application using standard SDO behavior will behave the same using any implementation) and interoperability (making calls from one vendor implementation to another).  I think we have a lot of work to do to achieve the first, and the second may be out of our reach for SDO 3.0.

In any case, as I described, I see the default helper context as being only marginally related to the problem of (de-)serialization.  In JEE, I see the defaultHelperContext as being the HelperContext that is associated with the application.  In SCA terminology, it is the HelperContext associated with the contribution.  And users obtain references to it using the SDO.defaultHelperContext() or whatever method.

Talk to you in a few minutes.

Ron

  
-----Ursprüngliche Nachricht-----
Von: Blaise Doughan [mailto:] 
Gesendet: Donnerstag, 19. Februar 2009 14:59
An: Barack, Ron
Cc: 
Betreff: Re: AW: [sdo] HelperContext material for vF2F

Hi Ron,

Thank you for your comments. 

For default/global helper context my intent was to use "default" in the 
API.  When describing HelperContexts I usually use the terms "global" 
and "local" when I speak, so I wanted to ensure that I defined them in 
my slides.

Wrt your comment about having to pass around HelperContexts, are you 
saying that you would rather not deprecate the INSTANCE variables?  Or 
is it enough for you to have the short cut method 
SDO.defaultHelperContext()?

The use cases I want to see are different SDO implementations available 
within a single application server.  Each application should be able to 
use a different SDO implementation.  Also I would like users to be able 
deploy there applications to an app server without caring who the SDO 
provider is.  This ability is a great selling point for JPA and JAXB, 
and SDO's inability to do this is hard to explain to customers.

SDO serialization as it is today means that the same SDO implementation 
is available on the server and client wrt RMI.  Maybe its enough to 
state in the spec that this a known limitation and that serialization 
can not be expected to work unless the both ends are provided by the 
same vendor, even though a vendor independent algorithm is defined in 
the spec.  I agree that HelperContext info should be included in the 
serialization, do you have something that can be proposed?

The "isStandard" method is meant to cover more than serialization.  
Users getting the default HelperContext (possibly through 
SDO.defaultHelperContext()), need to have some expectations on how SDO 
works.  Currently with all the vagueness in the spec that call can 
hardly be recommended (different XML to property name algorithms, 
different handling of sequenced DataObjects and ChangeSummary).  At this 
point I see to high level directions:

1.  We focus on interoperability issues in the SDO spec.  This brings us 
in line with the approaches taken by JPA and JAXB where there is a 
standard set of behaviour and vendors differentiate themselves with 
proprietary extras (i.e.  EclipseLink JAXB offers meet-in-the-middle 
mapping in addition to the spec).  Here users can have confidence using 
SDO.defaultHelperContext() and implementors wanting to vary from the 
spec (in core areas) can indicate their implementation is not a 
candidate to be the default helper context.

2.  We declare that the only integration point between SDO 
implementations is the XML representation.  In this scenario a default 
helper context is meaningless as the user needs to know what vendor they 
are using.  Here I would suggest removing the defaultHelperContext 
methods and focusing on putting HelperContext info in the serialization 
info possibly as you describe.

-Blaise

Barack, Ron wrote: