AW: [sdo] HelperContext material for vF2F

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

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