Mike Edwards wrote:
Folks,
I have some suggestions here:
Jean-Sebastien Delfino wrote:
<snip>
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.
Different rules make it confusing or impossible to rewire your
application without changing your business objects.
+1 - I agree with consistency of rules.
The SCA specs DO define two different cases, and I would accept the idea
of the rules being deliberately different between those two cases:
a) Local interfaces
b) Remote interfaces
I think the discussion so far has really been about remote interfaces. I
am strongly in support of Jean-Sebastien's view that you should get the
same behaviour for remote interfaces wherever the target service happens
to be located. Since in-memory cloning is not possible for remote
targets, it should not be ever be used for remote interfaces.
For Local interfaces, the game is very different. In this case, you
always know that the target is in the same VM. So, for these types of
interface behaviour can be very different - as far as simply sending in
the original objects.
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).
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.
But what happens when the target is remote??
I think this discussion is only about the case of a remotable interface
that is invoked with a local target, and therefore some kind of pass by
value copying needs to be used.
See my previous post today on this, which explains the compatibility
issues in more detail.
Simon
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?
Yes, agree 100%
Yours, Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
