Re: AW: [sdo] HelperContext material for vF2F

[Blaise Doughan <blaise.doughan@oracle.com>]

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
>