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
Re: Remotable interfaces and pass by value, was: Data transformation from/to POJO
Simon Nash wrote: 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 I agree that we need to take JSON into account (that was my next thought too I just didn't want to pile too many aspects in this discussion). I think it would be useful to put a table together comparing the JSON mapping and the JAXB mapping. Wouldn't it be nice if we could tell application developers if you use these patterns and types, your business object will work unchanged with XML and JSON? Concrete use case in hand, the store scenario flows the Item bean over XML, JSON and in-VM pass-by-value interactions. I'd hate to have to write 3 different Item beans and mediation code to cover these 3 cases. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remotable interfaces and pass by value, was: Data transformation from/to POJO
Giorgio Zoppi wrote: 2007/12/5, Jean-Sebastien Delfino [EMAIL PROTECTED]: 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
Re: Remotable interfaces and pass by value, was: Data transformation from/to POJO
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
Re: Remotable interfaces and pass by value, was: Data transformation from/to POJO
Great!
Giorgio, if I understand correctly, the above scheme will help you
trigger the XStream databinding for objects that implement the
XStreamable interface you've defined.
Yes. I use it also for serializing Jobs, but I'm going to change this.
I feel that too much xml
is compute extensive.
You also said that you were using Java serialization and tunneling the
resulting bytes as base64. Could you expand a little on this and help me
understand how you do it?
Simple. Look in the same way I patched CallableReferenceImpl. I
serialize and base64 and then i add a trasformer for it.
Are you doing the serialization in your SCA component's implementation
logic and then passing the bytes to a service interface like:
JobManager {
run(byte[] serializedJob);
}
No it has something like the following:
and then letting the Axis2 binding send the byte[] as base64 (using the
JAXB mapping)?
No. a custom trasformer, that now it's useless :) I'm planning to use
java.io.Serializable and sending a bunch of jobs at time.
Jean Sebastian, this is what i'm doing. That's my workpool readme,
work in progress..it might change:
README.
This readme explains how to use my workpool application.
You can configure the workers by subclassing the WorkerServiceImpl class,
and you should give to this class a COMPOSITE scope, i.e.:
import org.apache.tuscany.sca.core.context.CallableReferenceImpl;
import org.apache.tuscany.sca.databinding.job.Job;
import org.apache.tuscany.sca.databinding.job.JobDataMap;
import org.osoa.sca.annotations.Scope;
/*
This is the example class in order to use the workpool service
*/
@Scope(COMPOSITE)
public class MyWorker extends WorkerServiceImplObject, Integer {
@Override
public ResultJob computeTask(JobObject,Integer job) {
ResultJob result = new ResultJob();
JobDataMap map = new JobDataMap();
map.addJobData(result, job.compute(new Integer(5)));
result.setJobDataMap(map);
return result;
}
}
This worker class receives a job stream and it give us a result a so
called in a hashmap. This way of working is quite similar to how
Quartz Scheduler handles the results.
In order to customize your workpool application, you also should modify the
Workpool.composite. For example for my nodeB:
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=http://sample;
xmlns:sample=http://sample;
name=Workpool
component name=WorkerManagerNodeBComponent
implementation.java class=workpool.WorkerManagerImpl/
property name=nodeNamenodeB/property
property name=compositeNameWorkpool.composite/property
property name=workerClassworkpool.MyWorker/property
service name=WorkerManagerInitService
interface.java
interface=org.apache.tuscany.sca.node.NodeManagerInitService/
binding.sca/
/service
service name=WorkerManager
binding.sca uri=http://localhost:13000/WorkerManagerNodeBComponent/
/service
/component
/composite
In the slaves nodes. So each slave node in the workpool is managed by
a WorkerManager, which is in charge to add/remove dynamically workers
in order to adapt all the system to the load. At boot time each nodes
has no worker component instance until the workpool master starts.
The workpool master node is made up of two components:
- WorkpoolManager - which has the task to control/adapt worker numbers
- WorkpoolService - which simply submit jobs to a worker on demand. I
say on demand because when a worker gets started from its node
manager send it a NullJob, and then it refers to the WorkpoolService's
queue to get other jobs.
The peculiar structure of this system is that the WorkpoolManager
holds on its internals a Rule Engine for its business decisions. It's
simply a Java Drools instance, an open source engine widely used in
SOA enviroments.
In this way you can post to the WorkpoolManager (by WebServices) your
own rule set in order to adapt the system to your particular computing
task. Now in this system, the features that can be checked and
controlled are incapsulated in a JavaBean, called WorkpoolBean.
public class WorkpoolBean
{
private double loadAverage = 0;
private int nodeNumbers = 0;
private int workers = 0;
private double averageServiceTime = 0;
// skipped setter/getter methods
}
This Workbean is registered inside the rule engine, and when one of
its properties change, a rule is fired. That's all for now.
Cheers,
Giorgio.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remotable interfaces and pass by value, was: Data transformation from/to POJO
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
Re: Remotable interfaces and pass by value, was: Data transformation from/to POJO
2007/12/5, Jean-Sebastien Delfino [EMAIL PROTECTED]: 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
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
