tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raymond Feng" <enjoyj...@gmail.com>
Subject Re: Remotable interfaces and pass by value, was: Data transformation from/to POJO
Date Thu, 06 Dec 2007 17:12:04 GMT
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" <nash@hursley.ibm.com>
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" 
>> <jsdelfino@apache.org>
>> 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: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


Mime
View raw message