We had some discussions before on this list how the pass-by-value should be
enforced. IIRC, the conclusion is that it would be a joint effort between
the implementation/binding type and the runtime. In most cases, bindings
representing remote protocols marshal/unmarshal the data on the wire. And
the pass-by-value is enforced by default and there is no need to do a copy
by runtime. For some implementation types, for example, xquery, it won't
modify the java objects, pass-by-value is guaranteed at the implementation
type level.
Thanks,
Raymond
----- Original Message -----
From: "Simon Nash" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Thursday, December 06, 2007 6:32 AM
Subject: Re: Remotable interfaces and pass by value, was: Data
transformation from/to POJO
This approach sounds good to me. I'd like to suggest one small
addition to the final "else" clause, based on the following spec quote:
Java SCA Annotations and APIs spec: 1531
Complex data types exchanged via remotable service interfaces must be
compatible with the marshalling technology used by the service binding.
If the binding uses XML serialization, then the proposed final "else"
will do the right thing. (For Tuscany, this includes the default
binding.sca.) However, if the binding uses some other serialization
such as JSON, then it might be more compatible to use this same
serialization in the local pass-by-value case. There are libraries
(e.g., [1]) that provide this functionality.
So the final "else" would become:
else // if we have a simple JavaBean and an XML binding
symbol is copied using JAXB XML serialization
else
else // if we have a simple JavaBean and a JSON binding
symbol is copied using JSON serialization
else
// I'm not going to list all possible bindings but you get
// the picture...
Thoughts?
Simon
[1] http://json-lib.sourceforge.net/usage.html
Raymond Feng wrote:
Hi,
What we have today is mostly in line with your proposal. Only a few
twicks are needed.
1) If the data type is recognized by a known databinding, for example,
SDO or JAXB, the databinding specific-copy is used. For SDO, it will be
SDO CopyHelper.copy and for JAXB, it will be marshal/unmarshal. (This is
the what we do in the code).
2) If the object implements java.io.Serializable, it is copied using Java
serialization [2] (We already have it)
3) Assuming we have a simple JavaBean, and it is copied using JAXB XML
serialization [3] (To be added)
Thanks,
Raymond
----- Original Message ----- From: "Jean-Sebastien Delfino"
<[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Tuesday, December 04, 2007 3:26 PM
Subject: Re: Remotable interfaces and pass by value, was: Data
transformation from/to POJO
Jean-Sebastien Delfino wrote:
Some answers after researching the spec docs:
Raymond Feng wrote:
Hi,
I think this issue needs to be brought up at the spec level.
Basically, the following have to be clarified:
1) What interfaces are qualified to be remotable?
2) What are the characteristics of the input/output types for
remotable interfaces?
Assembly spec: 697
"Whether a service of a component implementation is
remotable is defined by the interface of the service. In the case of
Java this is defined by adding the @Remotable annotation to the Java
interface (see Client and Implementation Model Specification for Java).
WSDL defined interfaces are always remotable."
Java SCA Annotations and APIs spec: 297
"Java interfaces generated from a WSDL portType are always remotable."
I think that says that JAX-WS generated interfaces should be considered
remotable even in the absence of an @Remotable interface.
Java SCA Annotations and APIs spec: 1531
Complex data types exchanged via remotable service interfaces must be
compatible with the marshalling technology used by the service binding.
For example, if the service is going to be exposed using the standard
web service binding, then the parameters must be Service Data Objects
(SDOs) 2.0 [2] or JAXB [3] types.
Independent of whether the remotable service is called from outside of
the composite that contains it or from another component in the same
composite, the data exchange semantics are by-value."
This leaves the door open for other data representations supported by
other service bindings, e.g. a DOM or a Java Serializable object.
The Java SCA Annotations and APIs spec Errata adds this:
"The SCA Client and Implementation Model for Java applies the WSDL to
Java and Java to WSDL mapping rules as defined by the JAX-WS
specification [4] for generating remotable Java interfaces from WSDL
portTypes and vice versa.
For the purposes of the Java-to-WSDL mapping algorithm, the interface
is treated as if it had a @WebService annotation on the class, even if
it doesn't, and the org.osoa.OneWay annotation should be treated as a
synonym for javax.jws.OneWay. For the WSDL-to-Java, the generated
@WebService annotation should imply that the interface is @Remotable.
For the mapping from Java types to XML schema types SCA supports both
the SDO 2.1 [2] mapping and the JAXB [3] mapping. Having a choice of
binding technologies is allowed, as noted in the first paragraph of
section 5 of the JSR 181 (version 2) specification, which is referenced
by the JAX-WS specification."
EJB binding spec: 105
"When used with the EJB binding, a service or reference interface must
be compatible with a session bean interface, according to the following
rules:
- The interface offered by a reference MUST be remotable if the remote
session bean interface is being accessed, and MUST be local if the
local session bean interface is being accessed.
- The methods on the session bean MUST be a compatible superset of the
methods in the interface used by the reference.
- The interface used by a reference MAY NOT contain any methods
inherited from EJBObject or EJBLocalObject.
- Compatibility for an individual method is defined by the SCA Assembly
Model Specification [4], and can be stated simply as compatibility of
the signature. That is, the method name, input types, and output types
MUST be identical.
- The order of the input and output types also MUST be identical."
This brings interesting points:
- EJB binding does not imply remote, local interfaces are also
supported (contrary to the common belief that "binding" implies
"remote").
- an SCA reference can use a newly defined Java interface (compatible
with the session bean interface but not dragging javax.ejb.Remote) with
a @Remotable annotation".
3) What are the semantics of pass-by-value?
Assembly spec: 706
"Independent of whether the remotable service is called remotely from
outside the process where the service runs or from another component
running in the same process, the data exchange semantics are by-value.
Implementations of remotable services may modify input messages
(parameters) during or after an invocation and may modify return
messages (results) after the invocation. If a remotable service is
called locally or remotely, the SCA container is responsible for making
sure that no modification of input messages or post-invocation
modifications to return messages are seen by the caller."
Does that help answer your questions?
So, based on all the above, I'd like to come up with a reasonable
implementation of the pass-by-value behavior for in-VM interactions.
By in-VM I mean:
- a reference is wired to a service
- both run in the same node
- the SCA binding is used.
Disclaimer: In-VM can have many different meanings so people not
comfortable with that definition of "in-VM", valid only withing the
context of the present email, can call it "in-Foo" if they want :)
Assuming the following remotable business interface:
@Remotable
interface StockQuote {
getQuote(X symbol);
}
Assuming getQuote(String symbol)
String is immutable and doesn't need to be copied
Now assuming getQuote(Symbol symbol)
if Symbol implements commonj.sdo.DataObject
symbol is copied using the SDO copy util
else if Symbol is a JAXB generated object
symbol is copied using JAXB XML marshalling [1]
else if Symbol implements java.io.Serializable
symbol is copied using Java serialization [2]
else if Symbol implements StAX XMLStreamReader
symbol is copied using StAX streaming
// I'm not going to list all possible databindings but you get
// the picture...
else // assuming we have a simple JavaBean
symbol is copied using JAXB XML serialization [3]
[1] Provides consistent behavior between in-VM and XML-based networked
interactions.
[2] Provides consistent behavior between in-VM and RMI and EJB
interactions.
[3] Provides consistent behavior between in-VM and XML-based networked
interactions. This covers the issue that I ran into with the store
scenario, where JavaBeans that worked well with XML-based networked
interactions started to break when I started to use them in in-VM
interactions.
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
