Jean-Sebastien Delfino wrote:
Simon Nash wrote:
Jean-Sebastien Delfino wrote:
Jean-Sebastien Delfino wrote:
Raymond Feng wrote:
I think there are two options:
1) Make the JAXB databinding as the default databinding for POJOs
(simple and complex types).
What about doing that? any drawback?
And, jumping ahead and assuming that any drawbacks are acceptable,
what about using that as well instead of where we currently use Java
serialization to achieve "pass by value" through remotable interfaces.
That'll allow us to remove the requirement for objects that flow
through a remotable interface to implement java.io.Serializable,
which is not quite right.
I think the main issue we need to resolve in order to make this change
is to solve the problem with passing interface types that has been raised
on the user list. Java serialization takes care of this by encoding the
class name in the serialized form.
There are also likely to be a number of restrictions on what is allowed
in the object being copied that are imposed by the default JAXB mapping
but don't apply to Java serialization. I'm a bit concerned that we could
end up with limitations that are more severe than the current limitation
of needing to implement java.io.Serializable.
I prefer to have consistent rules (with respect to what the business
objects can look like or must implement) between a remotable interface
bound to an XML-based binding and a remotable interface used for in-VM
communication.
If all remotable interfaces were bound to XML-based bindings, this
would be a good solution. Unfortunately, things are not that simple.
An SCA Remotable interface could use some other binding such as RMI-IIOP.
In this case, the simple and consistent solution would be to use
Java serialization to pass things by value, since this is what will
be used in the truly remote case.
Different rules make it confusing or impossible to rewire your
application without changing your business objects.
This raises another dimension of the problem. Changing a wire from
remote to local can cause different serialization to happen. Also,
reconfiguring a wire from one binding to another can cause different
serialization to happen. We can have consistent serialization between
local and remote cases for the same binding, or we can have consistent
serialization between different bindings, but not both.
I ran into this right away in step 2 of the store tutorial (merger). The
Item bean was working well over XML, but broke when I tried to pass it
through an in-VM call (see the wire between Catalog and FruitsCatalog in
store-merger.composite).
Agreed that this is a problem. We need to find a way to solve this
without breaking the other cases I mentioned above.
Another alternative to using Java serialization is to write an in-memory
reflective cloning function. This would probably be more efficient
than serialization, would not require java.io.Serializable, and should
be able to support pretty much any Java object.
There's also the possibility of a hybrid approach, where we would use
Java serialization if the object implements java.io.Serializable and
some other approach (e.g., JAXB or cloning) if it doesn't.
How about starting simple with one option that's consistent with the
spec and really works instead of three that work differently?
>
If we could find one option that does all this, that would be great.
It isn't that simple though, because different remote communication
bindings require different kinds of local pass-by-value serialization
in order to make the local case consistent with the remote case.
Specifically, if we change to an XML-friendly algorithm, it would
break remote-local transparency for anyone using RMI-IIOP as a
remote binding. So there is no "one size fits all" solution.
The options seem to be:
1. Pick one pass-by-value serialization algorithm, based on the
most common use case, and let the other less common cases break.
2. Support different algorithms and let the runtime choose between
them based on some rules that Tuscany defines.
3. Like 2 and allow the user to control/override the selection of
which algorithm is used, by intents or some some mechanism.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
