Hello
Ron,
Below are my responses to your questions:
1. Am I
correct that Resolvable
will not serialize non-closed data graphs, but will instead throw a
"GraphNotClosed" exception when attempting to serialize the root
element? If so, do you think Resolveable should also serialize
non-closed graphs? I believe some sort of envelope with orphanHolder
properties was under discussion here.
Resolvable
was written to reflect the current serialization algorithm which
currently does not support non-closed graphs. How orphans are
serialized
is something as a group we should resolve in the 3.0 time frame.
2. Right
now, the implementation
can only be set through the API. Why not provide the same mechanisms
here
as you use to set the HelperContextFactory? It seems like unless the
user
(as opposed to the vendor) does something, he is stuck with the
DefaultImplementation. And this implementation is certainly not
generally
suitible. For instance, the defaultHelperContext (as I read it) is a
static (shades of INSTANCE), and, furthermore, using WeakRefs to the
HelperContexts in the map may also not be appropriate. (Use case here:
I
serialize an object, and want do deserialize it latter, in the mean
time I
don't necessarily have references to the HelperContext). Bottom line,
I
think DefaultImplementation is too specific to be delivered in the
API.
By making Implementation pluggable, like HelperContextFactory, we can
get
out of delivering an implementation as part of the API.
Agreed
that the implementation should be made pluggable, and I'm ok with
leaving it up to the individual SDO implementations to provide one.
3. As
discussed in the meeting,
"Implementation" is a terrible name. "SDOManager"
maybe?
Currently I'm leaning towards "Environment".
4. The
user currently has to put
in the effort to provide an ID, otherwise he gets an unregistered
context. It could be, though, that he wants a registered context but
doesn't care what the ID is ... he just cares that it is unique, so
that he can
deserialize against it, later. OK, he can always use java.util.UUID,
but
purely from a usability standpoint, it might be better to add a method
that
calls UUID for him.
The
purpose of the ID is to allow the serialization of data from one
HelperContext to another. The problem with UUID is that the
HelperContext
identifier would change each time an application is redeployed.
5. I
think there should be a
standard way to look up the "default" HelperContext based on the
classpath and whatever else is needed to separate applications.
Something
like getDefaultHelperContext(ClassLoader,Properties).
My intention for introducing the
Implementation/Environment piece was to ensure that vendors could still
isolate
the defaultHelperContext at the application level. What is the use
case
for allowing client code to retrieve a defaultHelperContext by
ClassLoader/Properties. What would be the rule if a HelperContext was
not
registered for that ClassLoader, but for a parent ClassLoader?
In
general, support for standard serialization has added another level of
complexity to the API, and I'm wondering if the use-case really
justifies
it. Handling passivation/activation bounces doesn't need any
standardization. The cross vendor use-case within the same VM is
better
served by the API that will be part of SDO 158. That
leaves cross vendor RMI calls. In my opinion, the win here isn't very
big
over using XML/ WebServices.
There is more to serialization than
passivation/activation, and the importance of this use case will of
course vary from vendor to vendor. Since 2.1 we have allowed vendors
to
use alternate serialization mechanisms, so SAP will still have the
opportunity
to do "better" than the spec. But other vendors who want to
interoperate through Java serialization will also have that
opportunity.
The concept of standard serialization is not new to SDO, it just never
worked
before.
-Blaise
Barack, Ron wrote:
7C3EF93EEBC6EB4A8B4470853DE86566A13151@dewdfe18.wdf.sap.corp"
type="cite">
Hi Blaise,
I have a few early comments
on the proposed API.
1. Am I correct that
Resolvable will not serialize non-closed data graphs, but will instead
throw a "GraphNotClosed" exception when attempting to serialize the
root element? If so, do you think Resolveable should also serialize
non-closed graphs? I believe some sort of envelope with orphanHolder
properties was under discussion here.
2. Right now, the
implementation can only be set through the API. Why not provide the
same mechanisms here as you use to set the HelperContextFactory? It
seems like unless the user (as opposed to the vendor) does something,
he is stuck with the DefaultImplementation. And this implementation is
certainly not generally suitible. For instance, the
defaultHelperContext (as I read it) is a static (shades of INSTANCE),
and, furthermore, using WeakRefs to the HelperContexts in the map may
also not be appropriate. (Use case here: I serialize an object, and
want do deserialize it latter, in the mean time I don't necessarily
have references to the HelperContext). Bottom line, I think
DefaultImplementation is too specific to be delivered in the API. By
making Implementation pluggable, like HelperContextFactory, we can get
out of delivering an implementation as part of the API.
3. As discussed in the
meeting, "Implementation" is a terrible name. "SDOManager" maybe?
4. The user currently has to put in the
effort to provide an ID, otherwise he gets an unregistered context. It
could be, though, that he wants a registered context but doesn't care
what the ID is ... he just cares that it is unique, so that he can
deserialize against it, later. OK, he can always use java.util.UUID,
but purely from a usability standpoint, it might be better to add a
method that calls UUID for him.
5. I think there should be a standard way
to look up the "default" HelperContext based on the classpath and
whatever else is needed to separate applications. Something like
getDefaultHelperContext(ClassLoader,Properties).
In general, support for standard
serialization has added another level of complexity to the API, and I'm
wondering if the use-case really justifies it. Handling
passivation/activation bounces doesn't need any standardization. The
cross vendor use-case within the same VM is better served by the API
that will be part of SDO 158. That leaves cross vendor RMI calls. In
my opinion, the win here isn't very big over using XML/ WebServices.
Best
Regards,
Ron
Hi Fuhwei,
In the latest proposal there are actually two plug-in points that can
be configured:
- SDO Implementation
This is for setting up SDO for a particular environment. WebLogic and
WebSphere would each include an implementation of this, so that
instances of HelperContextFactory behaved correctly inside their
environments. An SDO Implementation could also be created for OSGi
environments like Eclipse Equinox so that SDO behaved correctly there
as well. The configuration for this aspect needs to be improved.
- HelperContextFactory
This is the other plug-in point where different vendors can
provide access to their own HelperContexts. This would allow multiple
SDO implementations to be available in the same SDO environment.
-Blaise
Fuhwei Lwo wrote:
OF47D67EB4.B2BCD6F0-ON88257591.00523EE5-88257591.0053E81B@us.ibm.com"
type="cite">
Can we change the following statement in Implementation.java from
static final String PROPERTY_NAME =
"commonj.sdo.helper.HelperContextFactory";
to something like
static final String SDO_IMPL_NAME = "commonj.sdo.impl.Implementation";
because the value of the system property is the user specified Java
class for the SDO implementation.
Thanks.
Fuhwei Lwo
Hello All,
I have added the next revision of the SDO 3 API that includes both
HelperContext creation and standardized serialization.
-Blaise
-- Mr. Blaise Doughan
The document revision named HelperContext Creation - Version 3
(HelperContextCreation-v3.zip) has been submitted by Mr. Blaise Doughan
to
the OASIS Service Data Objects (SDO) TC document repository. This
document
is revision #2 of HelperContextCreation.zip.
Document Description:
API Now Includes:
- HelperContext now has an optional identifier property
- A standard implementation of Resolvable that makes use of the
HelperContext identifier property so that de-serialization can occur
outside of the default HelperContext. Also DataObjects serialized by
one
vendor can be deserialized by another vendor.
- The ImplementationResolver has been renamed Implementation and is
used to
configure SDO for different environments such as Java SE, application
servers, OSGi, etc.
- There is now one default HelperContext available from SDO instead of
one
per HelperContextFactory.
- HelperContextFactory is now an interface.
- Type how has a HelperContext property.
View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=31982
Download Document:
http://www.oasis-open.org/committees/download.php/31982/HelperContextCreation-v3.zip
Revision:
This document is revision #2 of HelperContextCreation.zip. The document
details page referenced above will show the complete revision history.
PLEASE NOTE: If the above links do not work for you, your email
application
may be breaking the link into two pieces. You may be able to copy and
paste
the entire link address into the address field of your web browser.
-OASIS Open Administration