AW: AW: [sdo] HelperContext material for vF2F

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

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:blaise.doughan@oracle.com] 
Gesendet: Donnerstag, 19. Februar 2009 14:59
An: Barack, Ron
Cc: sdo@lists.oasis-open.org
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:
> Hi Blaise, everyone,
>
> My first comments on the proposal.  Perhaps, knowing what our concerns/ questions are, you can address them in your presentation...
>
> First, regarding the "globalHelperContext" (why not "default"?).  I think we need this for more than just java.io.Serialization.  SDO 2.0 did not require client code to pass around helper contexts, users could just use e.g., TypeHelper.INSTANCE.  In 2.1 we made this HelperProvider.getDefaultContext().getTypeHelper().  Having to pass around the helper context (as a parameter in client code), is a big usability problem, in my opinion.  In fact, I was going to suggest having SDO.defaultHelperContext() as a convenience method for SDO.getDefaultHelperContextFactory().getDefaultContect()... Simply to save the user the typing.
>
> I'm a little surprised by the emphasis on the multi-vendor usecase, and I'm wondering about the granularity in which the different vendor's implementations are being mixed.  Of course, in a SOA application I can imagine this occuring, and even within the same VM, where for example 2 JEE applications or 2 OSGi bundles rely on different SDO implementations.  I get the impression, though, that you are imagining a single JEE component, say a SessionBean, that uses 2 SDO implementations.  I agree this is possible, but I think it's very much off the beaten path...not something I would put a high priority on supporting.  What exactly are your usecases here?
>
> In my opinion the spec mainly provides source code compatibility, and we achieve interoperability through XML serialization.  What targets do you have in mind when you say that we should give greater emphasis to interop?
>
> This relates to the reasons why I was actually against standardizing the java.io Serialization back in the 2.1 days.  When a JEE application is under a heavy load and beans are passivated, serialization become a very critical operation indeed.  I think it is necessary that implementations be allowed to optimize this operation as much as possible.  The main motivation for standardizing the serialization format is, in my opinion, to enable RMI calls between two SDO Java implementations on different VMs.  But going between VMs using RMI is relatively rare, and especially going between VMs where different vendors implementations are involved.  Briefly put, my concerns about efficient EJB passivation trumped my interest in supporting the multi-vendor usecase.  One is something that we do everyday, and for which we will be nailed to the wall if we don't achieve... The other is, as you guys often say, something that no user (of ours) has ever requested.
>
> Also, in our java.io.serialization, we store an identifier for the HelperContext in the stream.  This is, in my opinion a required functionality.  The 2.1 serialization algorithm doesn't do this, so we would have really been unable to cover all our usecases if standard serialization was a compliance requirement.
>
> The isStandard method is fine (maybe should be named something like "usesStandardSerialization"), but I wouldn't want to tie it in with what is an acceptable "GlobalHelperContext".  Clients, especially EJB clients, can currently use the default context and have implicitly an efficient serialization.  Requiring them to create and manage their own HelperContext would be a breaking change for us.
>
> Shouldn't HelperContextFactory also provide get methods?  I'm assuming here every "create" returns a new HelperContext().
> We certainly have cases where we want contexts to be shared, for instance, between instances of a SessionBean.  It could be I want to look up a helper context that I've already created.  I am thinking that the Map (or some special entries in the map) that is given to the create method could also be used to identify the context later.  This would open the door to putting the HelperContext identifier onto the serialization stream (I think this should be part of this proposal).
>
> If we think about a JavaEE environment, what is the protection offered so that applications do not interfer with the HelperContexts of other applications?  Under the circumstance that both applications are using the same SDO implementation, then they will both get the same HelperContextFactory, right?   Despite whatever lookup methods we add, we need to make sure that applications cannot interfer with each other.  The classpath argument to the factory create methods seems to me to relate to more than just the classpath to the static SDOs, rather, it identifies the application with which the helper context is associated.
>
> Looking forward to today's meeting,
> Ron
>  
>
> -----Ursprüngliche Nachricht-----
> Von: Blaise Doughan [mailto:blaise.doughan@oracle.com] 
> Gesendet: Sonntag, 15. Februar 2009 13:56
> An: sdo@lists.oasis-open.org
> Betreff: [sdo] HelperContext material for vF2F
>
> Hello All,
>
> Attached is some material for the HelperContext discussion.
>
> -Blaise
>