Simon Nash wrote:
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.
The pass by value copying needs to be consistent (with respect to what
it can copy, what is potentially lost in the copying, the patterns and
data representations that it supports) with the case when the remotable
interface is mapped to WSDL/XSD and used over a networked interaction
when data flows as XML compliant with that WSDL+XSD.
So, we can invent 3 different algorithms to do that copy but if they
give different results than what JAXB or SDO would have done, we're not
helping the application developer, we're just creating confusion.
With respect to RMI friendly interfaces and EJB remote interfaces, I
think you've uncovered an issue in the SCA specs: EJB session bean
remote interfaces are not always mappable to WSDL/XSD, they can flow
data types that won't map to XSD types. So these interfaces will break
with a WS binding, probably JSON as well, ATOM, and won't work with a
BPEL or XQuery component for example.
Basically, such interfaces do not meet the criteria for remotable
interfaces defined by the assembly spec. On the other hand they need to
be used as "remotable" interfaces on references and services configured
with an EJB binding.
I think that we should raise a spec issue for this and get the spec
issue addressed first, instead of introducing different schemes for
remotable interfaces and different mechanisms for copying data right
now... and in the meantime support well a single consistent algorithm.
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]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
