You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2007/11/17 01:06:49 UTC
Data transformation from/to POJO
Hi,
With the recent development of the online store tutorial, we encounter quite
a few issues around the transformation between POJO and other databindings
(such as XML, JSON).
Let's take the POJO <--> XML as an example. Here is a set of questions to be
answered.
1) Do we require the POJO to be a strict JavaBean or free-form class?
2) How to read properties from a java object?
The data in a java object can be accessed by the field or by JavaBean style
getter methods. There are different strategies:
a) Always use JavaBean-style getter method
b) Always use field access
c) A combination of a & b
The other factor is the modifier of a field/method defintion. What modifiers
are allowed? public, protected, default and private?
If a property only have getter method, should we dump the property into the
XML? How about transient fields?
3) How to write properties to populate the target POJO instance?
a) Use JavaBean setter?
b) Use field
c) Combination of a & b
When we convert XML element back to a POJO property, how do we instantiate
the property instance if the property type is an interface or abstract
class?
For example,
package com.example;
public class MyBean {
private MyInterface p1;
public void setP1(MyInterface p1) {
this.p1 = p1;
}
public MyInterface getP1() {
return p1;
}
}
Do we require the XML element contains xsi:type attribute which will be
generated from POJO-->XML to represent the concrete property type? Such as:
<myBean xsi:type="ns1:MyBean" xmlns:ns1="http://example.com/">
<p1 xsi:type="ns2:MyInterface" xmlns:ns2=http://example.com//>
</myBean>
Thanks,
Raymond
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Data transformation from/to POJO
Posted by Giorgio Zoppi <gi...@gmail.com>.
>
> In that example, what is the object representing the Job that's going to
> be serialized over the network (and I guess sent to a Worker)? Farm?
> DoSweep? or ParDegree?
>
> What are the main characteristics of the Job objects?
A Job is a java simple class, which implements
a compute method (ala java.io.Runnable) . In Muskel I load separately
job and data.
> Now a different category of questions:
>
> What are you flowing through your Web Service right now? Are you
> serializing Java objects into bytes and then tunneling the bytes in a
> Web Service call?
i'm serializing Job in base64 encode or via xstream over
binding-sca-axis2 with your infrastructure.
> Have you defined a WSDL portType for your Web Service?
> Why are you using Web Services? Is your environment just Java or are you
> integrating with other languages? I'm asking because slide 23 mentions
> WS and "any OS with Java together" and slide 29 mentions C, C++ etc.
Yes. I integrate it with other tools and languages.
Cheers,
Giorgio.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WorkerService component, was: Remotable interfaces and pass by
value
Posted by Giorgio Zoppi <gi...@gmail.com>.
Simon Laws ha scritto:
> On Dec 13, 2007 3:04 PM, Giorgio Zoppi <gi...@gmail.com> wrote:
>
>
>> Jean-Sebastien Delfino ha scritto:
>>
>>> OK I'm starting to understand. That looks like a pretty useful
>>> component to have!
>>>
>>> One more question, after which I may make some suggestions.
>>>
>>> What does the WSDL portType describing your Web Service look like?
>>>
>>> Like that?
>>> <definitions...>
>>> <types>
>>> <schema ...>
>>> <element name="computeTask">
>>> <complexType>
>>> <sequence>
>>> <element name="job" type="xs:base64Binary"/>
>>> </sequence>
>>> </complexType>
>>> </element>
>>> <element name="computeTaskResponse">
>>> <complexType>
>>> <sequence>
>>> <element name="return" type="xs:base64Binary"/>
>>> </sequence>
>>> </complexType>
>>> </element>
>>> </schema>
>>> </types>
>>> <message name="computeTaskRequest">
>>> <part name="parameters" element="computeTask"/>
>>> </message>
>>> <message name="computeTaskResponse">
>>> <part name="parameters" element="computeTaskResponse"/>
>>> </message>
>>> <portType name="WorkerServicePortType">
>>> <operation name="computeTask">
>>> <input message="computeTaskRequest"/>
>>> <output message="computeTaskResponse"/>
>>> </operation>
>>> </portType>
>>> </definitions>
>>>
>>> I guessed the above as you said you were flowing base64 encoded bytes,
>>> and I didn't know what your WorkerManager interface looked like so
>>> assumed it was like your WorkerService.
>>>
>>> Or something else?
>>>
>>>
>> Hi,
>> I don't know how it's my WSDL, because it's automatically generated by
>> Tuscany Runtime whereas I use binding-sca-axis2 module, but the
>> WorkerService and the WorkerManager have different interfaces. By now
>> jobs are sent by my custom binding which uses xstream, so a lot of xml
>> serialization, but it's going to change due performance problems
>> inherent to xml. The WorkerManager has the task to control a group of
>> worker components in a node. So its business intefaces looks like that:
>> import org.apache.tuscany.sca.core.context.CallableReferenceImpl ;
>> import org.osoa.sca.annotations.Remotable;
>>
>> @Remotable
>> public interface WorkerManager {
>> CallableReferenceImpl<WorkerService> addWorker();
>> boolean removeWorker(String workerName);
>> boolean removeWorkers(int k);
>> boolean removeAllWorkers();
>> double getNodeLoad();
>> int activeWorkers();
>> void start();
>> }
>>
>> You can add one or more components at runtime with the composite updater
>> ad then give away to the WorkpoolManager its CallableReference (i use
>> CallableReferenceImpl because my Tuscany runtime is not current patched
>> svn, but an old one). I'll show you a common use case:
>> Use case 1: The WorkpoolManager's polls different WorkerManagers in a
>> SCA domain, then it collects all nodes load with getNodeLoad(), if these
>> loads break some rule in the WorkpoolManager's engine. For example if
>> the system is "run down", then the WorkpoolManager could add a new
>> worker by selecting a node, invoking its WorkerManager and adding a new
>> Worker Component at runtime on that node. After that, the
>> WorkpoolManager receives from that node's WorkerManager, a
>> CallableReference and it sends that reference to the WorkpoolService
>> which has the following interface:
>> @Remotable
>> public interface WorkpoolService {
>> @OneWay
>> void submit(Job i);
>> double getServiceTime();
>> @OneWay
>> void PostWorkerName(String referenceName);
>> @OneWay
>> void PostWorkerReference(CallableReferenceImpl<WorkerService> worker);
>> void start();
>> @OneWay
>> void handleResult(Job j, boolean reuse,
>> CallableReferenceImpl<WorkerService> worker);
>> }
>>
>> In this case it uses a PostWorkerReference. In this interface you also
>> notice handleResult and PostWorkerName, this are my two hacks because i
>> wasn't able to inject dynamically a new component reference throught the
>> WorkpoolManager, so I use PostWorkerReference instead of the
>> PostWorkerName and handleResult instead of standard Tuscany Callbacks.
>> That's all hope it helps.
>> Cheers,
>> Giorgio.
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>> Hi Giorgio. As you know I think we should get this checked in as an
>>
> sca/demo (is that the right place?). Are you happy that 1907 and 1863 are in
> a suitable state to do that.
The code needs some cleanups, but until next year i'll not be able to do
such cleanups, because i'm quite busy
in testing. So I need more time, and JIRA1907 needs some changes in your
current activator composite and builder. I'll use Xmas holiday or a part of
to update JIRA1863 and JIRA1907 to your current rc-1.1. I don't want to
risk moving my code to something that's not well tested because i'm not
preparing for headaches :).
> We don't have to include it in the build
> necessarily but it would be good if we can check out the code and look at
> it.
>
For me it's ok..but remember that it needs some fixes.
> It would be interesting (to me at least ;-) to see how the domain could
> handle some of the issues of deploying the new components for you. I'm
> wondering if you could split the function of the WorkManager in two
>
> 1/ A component that you use that to determine information about the load of
> the node. In fact we could reuse the WorkManager component/service as part
> of the set of node management services.
>
>
the load detection is Linux based, you'll need an JNI extension for
other platforms like Win32 or Solaris that i'm going to provide you in
the future.
Now it's a function which reads /proc/loadavg and it does some checks.
> 2/ When you need a new Worker component on a node use the domain services to
> start a new composite there containing the component.
It works in a bit different way, the WorkerManager updates an existing
composite instead of creating a new one. This was done by modifing your
activator,
and your wirebuilder and using your composite api, copying part of that
code and adapting to a single component. The whole workpool composite,
from an external point of view could be seen as a single managed
component. However it still could be seen as a *hierarchical* composite
component where each new worker is ,if this in your opinion fits
better into SCA model.
> The composite could be created on the fly. We need two features to make this work
>
> A) addDeploymentComposite() which allows a composite to be added to an
> existing contribution. Method is there in the domain but I haven't
> implemented it yet.
>
The solution here, is to use XML processor, to add a composite, isn't it?
> B) a startComposite(compositeName, nodeName) that allows a composite to be
> targetted specifically at named node, i.e the node you have decided is not
> heavily loaded. This you be trivial to add and I think it would be useful
> anyhow.
>
>
Yes. It will be useful for me having some advice on how to work with
callbacks between different composites.
> Just some thoughts ;-)
>
>
Thoughts are food for mind :).
Cheers,
Giorgio.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WorkerService component, was: Remotable interfaces and pass by value
Posted by Simon Laws <si...@googlemail.com>.
On Dec 13, 2007 3:04 PM, Giorgio Zoppi <gi...@gmail.com> wrote:
> Jean-Sebastien Delfino ha scritto:
> > OK I'm starting to understand. That looks like a pretty useful
> > component to have!
> >
> > One more question, after which I may make some suggestions.
> >
> > What does the WSDL portType describing your Web Service look like?
> >
> > Like that?
> > <definitions...>
> > <types>
> > <schema ...>
> > <element name="computeTask">
> > <complexType>
> > <sequence>
> > <element name="job" type="xs:base64Binary"/>
> > </sequence>
> > </complexType>
> > </element>
> > <element name="computeTaskResponse">
> > <complexType>
> > <sequence>
> > <element name="return" type="xs:base64Binary"/>
> > </sequence>
> > </complexType>
> > </element>
> > </schema>
> > </types>
> > <message name="computeTaskRequest">
> > <part name="parameters" element="computeTask"/>
> > </message>
> > <message name="computeTaskResponse">
> > <part name="parameters" element="computeTaskResponse"/>
> > </message>
> > <portType name="WorkerServicePortType">
> > <operation name="computeTask">
> > <input message="computeTaskRequest"/>
> > <output message="computeTaskResponse"/>
> > </operation>
> > </portType>
> > </definitions>
> >
> > I guessed the above as you said you were flowing base64 encoded bytes,
> > and I didn't know what your WorkerManager interface looked like so
> > assumed it was like your WorkerService.
> >
> > Or something else?
> >
> Hi,
> I don't know how it's my WSDL, because it's automatically generated by
> Tuscany Runtime whereas I use binding-sca-axis2 module, but the
> WorkerService and the WorkerManager have different interfaces. By now
> jobs are sent by my custom binding which uses xstream, so a lot of xml
> serialization, but it's going to change due performance problems
> inherent to xml. The WorkerManager has the task to control a group of
> worker components in a node. So its business intefaces looks like that:
> import org.apache.tuscany.sca.core.context.CallableReferenceImpl ;
> import org.osoa.sca.annotations.Remotable;
>
> @Remotable
> public interface WorkerManager {
> CallableReferenceImpl<WorkerService> addWorker();
> boolean removeWorker(String workerName);
> boolean removeWorkers(int k);
> boolean removeAllWorkers();
> double getNodeLoad();
> int activeWorkers();
> void start();
> }
>
> You can add one or more components at runtime with the composite updater
> ad then give away to the WorkpoolManager its CallableReference (i use
> CallableReferenceImpl because my Tuscany runtime is not current patched
> svn, but an old one). I'll show you a common use case:
> Use case 1: The WorkpoolManager's polls different WorkerManagers in a
> SCA domain, then it collects all nodes load with getNodeLoad(), if these
> loads break some rule in the WorkpoolManager's engine. For example if
> the system is "run down", then the WorkpoolManager could add a new
> worker by selecting a node, invoking its WorkerManager and adding a new
> Worker Component at runtime on that node. After that, the
> WorkpoolManager receives from that node's WorkerManager, a
> CallableReference and it sends that reference to the WorkpoolService
> which has the following interface:
> @Remotable
> public interface WorkpoolService {
> @OneWay
> void submit(Job i);
> double getServiceTime();
> @OneWay
> void PostWorkerName(String referenceName);
> @OneWay
> void PostWorkerReference(CallableReferenceImpl<WorkerService> worker);
> void start();
> @OneWay
> void handleResult(Job j, boolean reuse,
> CallableReferenceImpl<WorkerService> worker);
> }
>
> In this case it uses a PostWorkerReference. In this interface you also
> notice handleResult and PostWorkerName, this are my two hacks because i
> wasn't able to inject dynamically a new component reference throught the
> WorkpoolManager, so I use PostWorkerReference instead of the
> PostWorkerName and handleResult instead of standard Tuscany Callbacks.
> That's all hope it helps.
> Cheers,
> Giorgio.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Hi Giorgio. As you know I think we should get this checked in as an
sca/demo (is that the right place?). Are you happy that 1907 and 1863 are in
a suitable state to do that. We don't have to include it in the build
necessarily but it would be good if we can check out the code and look at
it.
It would be interesting (to me at least ;-) to see how the domain could
handle some of the issues of deploying the new components for you. I'm
wondering if you could split the function of the WorkManager in two
1/ A component that you use that to determine information about the load of
the node. In fact we could reuse the WorkManager component/service as part
of the set of node management services.
2/ When you need a new Worker component on a node use the domain services to
start a new composite there containing the component. The composite could be
created on the fly. We need two features to make this work
A) addDeploymentComposite() which allows a composite to be added to an
existing contribution. Method is there in the domain but I haven't
implemented it yet.
B) a startComposite(compositeName, nodeName) that allows a composite to be
targetted specifically at named node, i.e the node you have decided is not
heavily loaded. This you be trivial to add and I think it would be useful
anyhow.
Just some thoughts ;-)
Regards
Simon
Re: WorkerService component, was: Remotable interfaces and pass by
value
Posted by Giorgio Zoppi <gi...@gmail.com>.
Jean-Sebastien Delfino ha scritto:
> OK I'm starting to understand. That looks like a pretty useful
> component to have!
>
> One more question, after which I may make some suggestions.
>
> What does the WSDL portType describing your Web Service look like?
>
> Like that?
> <definitions...>
> <types>
> <schema ...>
> <element name="computeTask">
> <complexType>
> <sequence>
> <element name="job" type="xs:base64Binary"/>
> </sequence>
> </complexType>
> </element>
> <element name="computeTaskResponse">
> <complexType>
> <sequence>
> <element name="return" type="xs:base64Binary"/>
> </sequence>
> </complexType>
> </element>
> </schema>
> </types>
> <message name="computeTaskRequest">
> <part name="parameters" element="computeTask"/>
> </message>
> <message name="computeTaskResponse">
> <part name="parameters" element="computeTaskResponse"/>
> </message>
> <portType name="WorkerServicePortType">
> <operation name="computeTask">
> <input message="computeTaskRequest"/>
> <output message="computeTaskResponse"/>
> </operation>
> </portType>
> </definitions>
>
> I guessed the above as you said you were flowing base64 encoded bytes,
> and I didn't know what your WorkerManager interface looked like so
> assumed it was like your WorkerService.
>
> Or something else?
>
Hi,
I don't know how it's my WSDL, because it's automatically generated by
Tuscany Runtime whereas I use binding-sca-axis2 module, but the
WorkerService and the WorkerManager have different interfaces. By now
jobs are sent by my custom binding which uses xstream, so a lot of xml
serialization, but it's going to change due performance problems
inherent to xml. The WorkerManager has the task to control a group of
worker components in a node. So its business intefaces looks like that:
import org.apache.tuscany.sca.core.context.CallableReferenceImpl;
import org.osoa.sca.annotations.Remotable;
@Remotable
public interface WorkerManager {
CallableReferenceImpl<WorkerService> addWorker();
boolean removeWorker(String workerName);
boolean removeWorkers(int k);
boolean removeAllWorkers();
double getNodeLoad();
int activeWorkers();
void start();
}
You can add one or more components at runtime with the composite updater
ad then give away to the WorkpoolManager its CallableReference (i use
CallableReferenceImpl because my Tuscany runtime is not current patched
svn, but an old one). I'll show you a common use case:
Use case 1: The WorkpoolManager's polls different WorkerManagers in a
SCA domain, then it collects all nodes load with getNodeLoad(), if these
loads break some rule in the WorkpoolManager's engine. For example if
the system is "run down", then the WorkpoolManager could add a new
worker by selecting a node, invoking its WorkerManager and adding a new
Worker Component at runtime on that node. After that, the
WorkpoolManager receives from that node's WorkerManager, a
CallableReference and it sends that reference to the WorkpoolService
which has the following interface:
@Remotable
public interface WorkpoolService {
@OneWay
void submit(Job i);
double getServiceTime();
@OneWay
void PostWorkerName(String referenceName);
@OneWay
void PostWorkerReference(CallableReferenceImpl<WorkerService> worker);
void start();
@OneWay
void handleResult(Job j, boolean reuse,
CallableReferenceImpl<WorkerService> worker);
}
In this case it uses a PostWorkerReference. In this interface you also
notice handleResult and PostWorkerName, this are my two hacks because i
wasn't able to inject dynamically a new component reference throught the
WorkpoolManager, so I use PostWorkerReference instead of the
PostWorkerName and handleResult instead of standard Tuscany Callbacks.
That's all hope it helps.
Cheers,
Giorgio.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
WorkerService component, was: Remotable interfaces and pass by value
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Giorgio Zoppi wrote:
>> 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 WorkerServiceImpl<Object, Integer> {
>
> @Override
> public ResultJob computeTask(Job<Object,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="nodeName">nodeB</property>
>
> <property name="compositeName">Workpool.composite</property>
>
> <property name="workerClass">workpool.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.
>
OK I'm starting to understand. That looks like a pretty useful component
to have!
One more question, after which I may make some suggestions.
What does the WSDL portType describing your Web Service look like?
Like that?
<definitions...>
<types>
<schema ...>
<element name="computeTask">
<complexType>
<sequence>
<element name="job" type="xs:base64Binary"/>
</sequence>
</complexType>
</element>
<element name="computeTaskResponse">
<complexType>
<sequence>
<element name="return" type="xs:base64Binary"/>
</sequence>
</complexType>
</element>
</schema>
</types>
<message name="computeTaskRequest">
<part name="parameters" element="computeTask"/>
</message>
<message name="computeTaskResponse">
<part name="parameters" element="computeTaskResponse"/>
</message>
<portType name="WorkerServicePortType">
<operation name="computeTask">
<input message="computeTaskRequest"/>
<output message="computeTaskResponse"/>
</operation>
</portType>
</definitions>
I guessed the above as you said you were flowing base64 encoded bytes,
and I didn't know what your WorkerManager interface looked like so
assumed it was like your WorkerService.
Or something else?
Thanks.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Remotable interfaces and pass by value, was: Data transformation from/to POJO
Posted by Giorgio Zoppi <gi...@gmail.com>.
> 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 WorkerServiceImpl<Object, Integer> {
@Override
public ResultJob computeTask(Job<Object,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="nodeName">nodeB</property>
<property name="compositeName">Workpool.composite</property>
<property name="workerClass">workpool.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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Data transformation from/to POJO
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Giorgio Zoppi wrote:
> 2007/11/29, Simon Nash <na...@hursley.ibm.com>:
>> Giorgio Zoppi wrote:
>>
>>> 2007/11/28, Jean-Sebastien Delfino <js...@apache.org>:
>>>
>>>> Giorgio Zoppi wrote:
>>>>
>>>>> One of the first problem that i had, when I started using Tuscany, was that
>>>>> I was serialize something without a mapping, because I wanted that a
>>>>> job was something
>>>>> more generics possible, i couldn't.
>>>> I'm not sure I understand what you mean by "serialize something without
>>>> a mapping"? Isn't there always a mapping like:
>>>>
>>>> - Java serialization -> mapping between Java Objects that implement
>>>> Serializable and bytes, as specified in the Java Object Serialization
>>>> specification at
>>>> http://java.sun.com/j2se/1.5.0/docs/guide/serialization/spec/serialTOC.html
>>>>
>>>> or
>>>>
>>>> - XML serialization -> mapping between Java Objects that follow
>>>> specified patterns and XML, as specified (for example) in the JAXB
>>>> specification at http://java.sun.com/xml/downloads/jaxb.html
>>>>
>>>> or
>>>>
>>>> - Java support for Externalizables -> mapping between Java Objects and
>>>> whatever protocol the implementor of the read/writeExternal methods
>>>> decides to implement, again here somebody needs to describe and publish
>>>> that mapping if he wants a chance to talk to other components, or at
>>>> least publish the mapping between the bytes read/written and a known
>>>> type system.
>>>>
>>>> Can you say a little more about what you were trying to do and the
>>>> specific issues that you ran into?
>>>>
>>>> Thanks
>>>> --
>>>> Jean-Sebastien
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>>
>>> Java Serialization ala Serializable, for mapping I wanted to say: xml
>>> mapping ala JAXB. At that time, I thought that a simple POJO, was
>>> serialized by the SCA's runtime, over web services. In our dept.
>>> we've a java tool (muskel, see
>>> www.di.unipi.it/~marcod/Papers/Parco05.ppt) that serializes Jobs via
>>> RMI, and I wanted to do something similar, without any XML mapping.
>>> Thanks,
>>> Giorgio.
>>>
>> Tucsany SCA Java includes an RMI binding. This should do what you
>> want. Can you use that instead of the Web Service binding?
>
> Yes, but my requirement was doing something over ws, in order to test
> its scalability.
> And I'm planning scalability testing with Apache JMeter for end of
> the next week, when my workpool application will be ready. It's a
> workpool that sampling the load on each jvm adds or remove workers
> component.
> Cheers,
> Giorgio.
>
I looked at the slides you pointed to, interesting stuff!
I have a few questions.
You mentioned serializing Jobs. Looking at this example from slide 25:
Compute mainProgram = new Farm(new doSweep());
ParDegree parDegree =
new ParDegree(Integer.parseInt(args[0]));
ApplicationManager manager = new
ApplicationManager(mainProgram);
manager.setContract(parDegree);
manager.inputStream(args[1]);
manager.evalToFile(args[2]);
In that example, what is the object representing the Job that's going to
be serialized over the network (and I guess sent to a Worker)? Farm?
DoSweep? or ParDegree?
What are the main characteristics of the Job objects?
Do they have a static structure defined by an application developer
(like for example a Customer info, an Account info, or StockQuote info
object?)?
Or are they references to files containing parameter data for programs
that will execute on your Grid?
Or are they more like dynamic structures not formally defined by the
application developer, like "An instance of an anonymous class
implementing java.lang.Runnable plus all the final local variables in
its scope"?
Now a different category of questions:
What are you flowing through your Web Service right now? Are you
serializing Java objects into bytes and then tunneling the bytes in a
Web Service call?
Have you defined a WSDL portType for your Web Service?
Why are you using Web Services? Is your environment just Java or are you
integrating with other languages? I'm asking because slide 23 mentions
WS and "any OS with Java together" and slide 29 mentions C, C++ etc.
Thanks.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Data transformation from/to POJO
Posted by Giorgio Zoppi <gi...@gmail.com>.
2007/11/29, Simon Nash <na...@hursley.ibm.com>:
>
> Giorgio Zoppi wrote:
>
> > 2007/11/28, Jean-Sebastien Delfino <js...@apache.org>:
> >
> >>Giorgio Zoppi wrote:
> >>
> >>>One of the first problem that i had, when I started using Tuscany, was that
> >>>I was serialize something without a mapping, because I wanted that a
> >>>job was something
> >>>more generics possible, i couldn't.
> >>
> >>I'm not sure I understand what you mean by "serialize something without
> >>a mapping"? Isn't there always a mapping like:
> >>
> >>- Java serialization -> mapping between Java Objects that implement
> >>Serializable and bytes, as specified in the Java Object Serialization
> >>specification at
> >>http://java.sun.com/j2se/1.5.0/docs/guide/serialization/spec/serialTOC.html
> >>
> >>or
> >>
> >>- XML serialization -> mapping between Java Objects that follow
> >>specified patterns and XML, as specified (for example) in the JAXB
> >>specification at http://java.sun.com/xml/downloads/jaxb.html
> >>
> >>or
> >>
> >>- Java support for Externalizables -> mapping between Java Objects and
> >>whatever protocol the implementor of the read/writeExternal methods
> >>decides to implement, again here somebody needs to describe and publish
> >>that mapping if he wants a chance to talk to other components, or at
> >>least publish the mapping between the bytes read/written and a known
> >>type system.
> >>
> >>Can you say a little more about what you were trying to do and the
> >>specific issues that you ran into?
> >>
> >>Thanks
> >>--
> >>Jean-Sebastien
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
> > Java Serialization ala Serializable, for mapping I wanted to say: xml
> > mapping ala JAXB. At that time, I thought that a simple POJO, was
> > serialized by the SCA's runtime, over web services. In our dept.
> > we've a java tool (muskel, see
> > www.di.unipi.it/~marcod/Papers/Parco05.ppt) that serializes Jobs via
> > RMI, and I wanted to do something similar, without any XML mapping.
> > Thanks,
> > Giorgio.
> >
> Tucsany SCA Java includes an RMI binding. This should do what you
> want. Can you use that instead of the Web Service binding?
Yes, but my requirement was doing something over ws, in order to test
its scalability.
And I'm planning scalability testing with Apache JMeter for end of
the next week, when my workpool application will be ready. It's a
workpool that sampling the load on each jvm adds or remove workers
component.
Cheers,
Giorgio.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Remotable interfaces and pass by value, was: Data transformation
from/to POJO
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Giorgio Zoppi wrote:
> 2007/12/5, Jean-Sebastien Delfino <js...@apache.org>:
>> 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]
>
> This schema is what i needed.
> Cheers,
> Giorgio.
>
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.
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?
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);
}
and then letting the Axis2 binding send the byte[] as base64 (using the
JAXB mapping)?
or are you doing something else?
Thanks.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Remotable interfaces and pass by value, was: Data transformation from/to POJO
Posted by Giorgio Zoppi <gi...@gmail.com>.
2007/12/5, Jean-Sebastien Delfino <js...@apache.org>:
> 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]
This schema is what i needed.
Cheers,
Giorgio.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Data transformation from/to POJO
Posted by Simon Nash <na...@hursley.ibm.com>.
Giorgio Zoppi wrote:
> 2007/11/28, Jean-Sebastien Delfino <js...@apache.org>:
>
>>Giorgio Zoppi wrote:
>>
>>>One of the first problem that i had, when I started using Tuscany, was that
>>>I was serialize something without a mapping, because I wanted that a
>>>job was something
>>>more generics possible, i couldn't.
>>
>>I'm not sure I understand what you mean by "serialize something without
>>a mapping"? Isn't there always a mapping like:
>>
>>- Java serialization -> mapping between Java Objects that implement
>>Serializable and bytes, as specified in the Java Object Serialization
>>specification at
>>http://java.sun.com/j2se/1.5.0/docs/guide/serialization/spec/serialTOC.html
>>
>>or
>>
>>- XML serialization -> mapping between Java Objects that follow
>>specified patterns and XML, as specified (for example) in the JAXB
>>specification at http://java.sun.com/xml/downloads/jaxb.html
>>
>>or
>>
>>- Java support for Externalizables -> mapping between Java Objects and
>>whatever protocol the implementor of the read/writeExternal methods
>>decides to implement, again here somebody needs to describe and publish
>>that mapping if he wants a chance to talk to other components, or at
>>least publish the mapping between the bytes read/written and a known
>>type system.
>>
>>Can you say a little more about what you were trying to do and the
>>specific issues that you ran into?
>>
>>Thanks
>>--
>>Jean-Sebastien
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
> Java Serialization ala Serializable, for mapping I wanted to say: xml
> mapping ala JAXB. At that time, I thought that a simple POJO, was
> serialized by the SCA's runtime, over web services. In our dept.
> we've a java tool (muskel, see
> www.di.unipi.it/~marcod/Papers/Parco05.ppt) that serializes Jobs via
> RMI, and I wanted to do something similar, without any XML mapping.
> Thanks,
> Giorgio.
>
Tucsany SCA Java includes an RMI binding. This should do what you
want. Can you use that instead of the Web Service binding?
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Data transformation from/to POJO
Posted by Giorgio Zoppi <gi...@gmail.com>.
2007/11/28, Jean-Sebastien Delfino <js...@apache.org>:
> Giorgio Zoppi wrote:
> >
> > One of the first problem that i had, when I started using Tuscany, was that
> > I was serialize something without a mapping, because I wanted that a
> > job was something
> > more generics possible, i couldn't.
>
> I'm not sure I understand what you mean by "serialize something without
> a mapping"? Isn't there always a mapping like:
>
> - Java serialization -> mapping between Java Objects that implement
> Serializable and bytes, as specified in the Java Object Serialization
> specification at
> http://java.sun.com/j2se/1.5.0/docs/guide/serialization/spec/serialTOC.html
>
> or
>
> - XML serialization -> mapping between Java Objects that follow
> specified patterns and XML, as specified (for example) in the JAXB
> specification at http://java.sun.com/xml/downloads/jaxb.html
>
> or
>
> - Java support for Externalizables -> mapping between Java Objects and
> whatever protocol the implementor of the read/writeExternal methods
> decides to implement, again here somebody needs to describe and publish
> that mapping if he wants a chance to talk to other components, or at
> least publish the mapping between the bytes read/written and a known
> type system.
>
> Can you say a little more about what you were trying to do and the
> specific issues that you ran into?
>
> Thanks
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Java Serialization ala Serializable, for mapping I wanted to say: xml
mapping ala JAXB. At that time, I thought that a simple POJO, was
serialized by the SCA's runtime, over web services. In our dept.
we've a java tool (muskel, see
www.di.unipi.it/~marcod/Papers/Parco05.ppt) that serializes Jobs via
RMI, and I wanted to do something similar, without any XML mapping.
Thanks,
Giorgio.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Data transformation from/to POJO
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Giorgio Zoppi wrote:
>
> One of the first problem that i had, when I started using Tuscany, was that
> I was serialize something without a mapping, because I wanted that a
> job was something
> more generics possible, i couldn't.
I'm not sure I understand what you mean by "serialize something without
a mapping"? Isn't there always a mapping like:
- Java serialization -> mapping between Java Objects that implement
Serializable and bytes, as specified in the Java Object Serialization
specification at
http://java.sun.com/j2se/1.5.0/docs/guide/serialization/spec/serialTOC.html
or
- XML serialization -> mapping between Java Objects that follow
specified patterns and XML, as specified (for example) in the JAXB
specification at http://java.sun.com/xml/downloads/jaxb.html
or
- Java support for Externalizables -> mapping between Java Objects and
whatever protocol the implementor of the read/writeExternal methods
decides to implement, again here somebody needs to describe and publish
that mapping if he wants a chance to talk to other components, or at
least publish the mapping between the bytes read/written and a known
type system.
Can you say a little more about what you were trying to do and the
specific issues that you ran into?
Thanks
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Data transformation from/to POJO
Posted by Giorgio Zoppi <gi...@gmail.com>.
2007/11/28, Simon Nash <na...@hursley.ibm.com>:
>
> Jean-Sebastien Delfino wrote:
>
> > Jean-Sebastien Delfino wrote:
> >
> >> Raymond Feng wrote:
> >>
> >>> I think there are two options:
> >>>
> >>> 1) Make the JAXB databinding as the default databinding for POJOs
> >>> (simple and complex types).
> >>
> >>
> >> What about doing that? any drawback?
> >>
> >
> > And, jumping ahead and assuming that any drawbacks are acceptable, what
> > about using that as well instead of where we currently use Java
> > serialization to achieve "pass by value" through remotable interfaces.
> >
> > That'll allow us to remove the requirement for objects that flow through
> > a remotable interface to implement java.io.Serializable, which is not
> > quite right.
>
> I think the main issue we need to resolve in order to make this change
> is to solve the problem with passing interface types that has been raised
> on the user list. Java serialization takes care of this by encoding the
> class name in the serialized form.
>
> There are also likely to be a number of restrictions on what is allowed
> in the object being copied that are imposed by the default JAXB mapping
> but don't apply to Java serialization. I'm a bit concerned that we could
> end up with limitations that are more severe than the current limitation
> of needing to implement java.io.Serializable.
>
> 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.
>
> 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.
One of the first problem that i had, when I started using Tuscany, was that
I was serialize something without a mapping, because I wanted that a
job was something
more generics possible, i couldn't. It will be nice if this scenario changes.
There are two ways to serialize something, in the current svn there's
a Externizable trasformer and it's a step forward in changing this
scenario. The next one it will provide something for Serializable.In
this way, you have two choices: an efficient mapping for POJO and a
way for an user to send Objects over your components.
Just,
my 1 cent.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Data transformation from/to POJO
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: 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
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Data transformation from/to POJO
Posted by Simon Nash <na...@hursley.ibm.com>.
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: 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
Re: Data transformation from/to POJO
Posted by Mike Edwards <mi...@gmail.com>.
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??
>> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Data transformation from/to POJO
Posted by Simon Nash <na...@hursley.ibm.com>.
Jean-Sebastien Delfino wrote:
> Simon Nash wrote:
>
>>
>> Jean-Sebastien Delfino wrote:
>>
>>> Jean-Sebastien Delfino wrote:
>>>
>>>> Raymond Feng wrote:
>>>>
>>>>> I think there are two options:
>>>>>
>>>>> 1) Make the JAXB databinding as the default databinding for POJOs
>>>>> (simple and complex types).
>>>>
>>>>
>>>>
>>>> What about doing that? any drawback?
>>>>
>>>
>>> And, jumping ahead and assuming that any drawbacks are acceptable,
>>> what about using that as well instead of where we currently use Java
>>> serialization to achieve "pass by value" through remotable interfaces.
>>>
>>> That'll allow us to remove the requirement for objects that flow
>>> through a remotable interface to implement java.io.Serializable,
>>> which is not quite right.
>>
>>
>> I think the main issue we need to resolve in order to make this change
>> is to solve the problem with passing interface types that has been raised
>> on the user list. Java serialization takes care of this by encoding the
>> class name in the serialized form.
>>
>> There are also likely to be a number of restrictions on what is allowed
>> in the object being copied that are imposed by the default JAXB mapping
>> but don't apply to Java serialization. I'm a bit concerned that we could
>> end up with limitations that are more severe than the current limitation
>> of needing to implement java.io.Serializable.
>>
>
> 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.
>
If all remotable interfaces were bound to XML-based bindings, this
would be a good solution. Unfortunately, things are not that simple.
An SCA Remotable interface could use some other binding such as RMI-IIOP.
In this case, the simple and consistent solution would be to use
Java serialization to pass things by value, since this is what will
be used in the truly remote case.
> Different rules make it confusing or impossible to rewire your
> application without changing your business objects.
>
This raises another dimension of the problem. Changing a wire from
remote to local can cause different serialization to happen. Also,
reconfiguring a wire from one binding to another can cause different
serialization to happen. We can have consistent serialization between
local and remote cases for the same binding, or we can have consistent
serialization between different bindings, but not both.
> 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).
>
Agreed that this is a problem. We need to find a way to solve this
without breaking the other cases I mentioned above.
>> 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.
>>
>> 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?
>
If we could find one option that does all this, that would be great.
It isn't that simple though, because different remote communication
bindings require different kinds of local pass-by-value serialization
in order to make the local case consistent with the remote case.
Specifically, if we change to an XML-friendly algorithm, it would
break remote-local transparency for anyone using RMI-IIOP as a
remote binding. So there is no "one size fits all" solution.
The options seem to be:
1. Pick one pass-by-value serialization algorithm, based on the
most common use case, and let the other less common cases break.
2. Support different algorithms and let the runtime choose between
them based on some rules that Tuscany defines.
3. Like 2 and allow the user to control/override the selection of
which algorithm is used, by intents or some some mechanism.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Remotable interfaces and pass by value, was: Data transformation
from/to POJO
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Remotable interfaces and pass by value, was: Data transformation from/to POJO
Posted by Raymond Feng <en...@gmail.com>.
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" <na...@hursley.ibm.com>
To: <tu...@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"
>> <js...@apache.org>
>> To: <tu...@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
Re: Remotable interfaces and pass by value, was: Data transformation
from/to POJO
Posted by Simon Nash <na...@hursley.ibm.com>.
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"
> <js...@apache.org>
> To: <tu...@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
Re: Remotable interfaces and pass by value, was: Data transformation from/to POJO
Posted by Raymond Feng <en...@gmail.com>.
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" <js...@apache.org>
To: <tu...@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
Re: Remotable interfaces and pass by value, was: Data transformation
from/to POJO
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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
Remotable interfaces and pass by value, was: Data transformation
from/to POJO
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Data transformation from/to POJO
Posted by Raymond Feng <en...@gmail.com>.
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?
3) What are the semantics of pass-by-value?
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Wednesday, November 28, 2007 7:55 AM
Subject: Re: Data transformation from/to POJO
> Simon Nash wrote:
>>
>> Jean-Sebastien Delfino wrote:
>>
>>> Jean-Sebastien Delfino wrote:
>>>
>>>> Raymond Feng wrote:
>>>>
>>>>> I think there are two options:
>>>>>
>>>>> 1) Make the JAXB databinding as the default databinding for POJOs
>>>>> (simple and complex types).
>>>>
>>>>
>>>> What about doing that? any drawback?
>>>>
>>>
>>> And, jumping ahead and assuming that any drawbacks are acceptable, what
>>> about using that as well instead of where we currently use Java
>>> serialization to achieve "pass by value" through remotable interfaces.
>>>
>>> That'll allow us to remove the requirement for objects that flow through
>>> a remotable interface to implement java.io.Serializable, which is not
>>> quite right.
>>
>> I think the main issue we need to resolve in order to make this change
>> is to solve the problem with passing interface types that has been raised
>> on the user list. Java serialization takes care of this by encoding the
>> class name in the serialized form.
>>
>> There are also likely to be a number of restrictions on what is allowed
>> in the object being copied that are imposed by the default JAXB mapping
>> but don't apply to Java serialization. I'm a bit concerned that we could
>> end up with limitations that are more severe than the current limitation
>> of needing to implement java.io.Serializable.
>>
>
> 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.
>
> 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.
>>
>> 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?
>
> --
> 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
Re: Data transformation from/to POJO
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Nash wrote:
>
> Jean-Sebastien Delfino wrote:
>
>> Jean-Sebastien Delfino wrote:
>>
>>> Raymond Feng wrote:
>>>
>>>> I think there are two options:
>>>>
>>>> 1) Make the JAXB databinding as the default databinding for POJOs
>>>> (simple and complex types).
>>>
>>>
>>> What about doing that? any drawback?
>>>
>>
>> And, jumping ahead and assuming that any drawbacks are acceptable,
>> what about using that as well instead of where we currently use Java
>> serialization to achieve "pass by value" through remotable interfaces.
>>
>> That'll allow us to remove the requirement for objects that flow
>> through a remotable interface to implement java.io.Serializable, which
>> is not quite right.
>
> I think the main issue we need to resolve in order to make this change
> is to solve the problem with passing interface types that has been raised
> on the user list. Java serialization takes care of this by encoding the
> class name in the serialized form.
>
> There are also likely to be a number of restrictions on what is allowed
> in the object being copied that are imposed by the default JAXB mapping
> but don't apply to Java serialization. I'm a bit concerned that we could
> end up with limitations that are more severe than the current limitation
> of needing to implement java.io.Serializable.
>
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.
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.
>
> 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?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Data transformation from/to POJO
Posted by Simon Nash <na...@hursley.ibm.com>.
Jean-Sebastien Delfino wrote:
> Jean-Sebastien Delfino wrote:
>
>> Raymond Feng wrote:
>>
>>> I think there are two options:
>>>
>>> 1) Make the JAXB databinding as the default databinding for POJOs
>>> (simple and complex types).
>>
>>
>> What about doing that? any drawback?
>>
>
> And, jumping ahead and assuming that any drawbacks are acceptable, what
> about using that as well instead of where we currently use Java
> serialization to achieve "pass by value" through remotable interfaces.
>
> That'll allow us to remove the requirement for objects that flow through
> a remotable interface to implement java.io.Serializable, which is not
> quite right.
I think the main issue we need to resolve in order to make this change
is to solve the problem with passing interface types that has been raised
on the user list. Java serialization takes care of this by encoding the
class name in the serialized form.
There are also likely to be a number of restrictions on what is allowed
in the object being copied that are imposed by the default JAXB mapping
but don't apply to Java serialization. I'm a bit concerned that we could
end up with limitations that are more severe than the current limitation
of needing to implement java.io.Serializable.
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.
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.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Data transformation from/to POJO
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> Raymond Feng wrote:
>> I think there are two options:
>>
>> 1) Make the JAXB databinding as the default databinding for POJOs
>> (simple and complex types).
>
> What about doing that? any drawback?
>
And, jumping ahead and assuming that any drawbacks are acceptable, what
about using that as well instead of where we currently use Java
serialization to achieve "pass by value" through remotable interfaces.
That'll allow us to remove the requirement for objects that flow through
a remotable interface to implement java.io.Serializable, which is not
quite right.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Data transformation from/to POJO
Posted by Raymond Feng <en...@gmail.com>.
I'll prototype to see if it's feasible.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Tuesday, November 27, 2007 1:18 PM
Subject: Re: Data transformation from/to POJO
> Raymond Feng wrote:
>> I think there are two options:
>>
>> 1) Make the JAXB databinding as the default databinding for POJOs (simple
>> and complex types).
>
> What about doing that? any drawback?
>
>>
>> 2) Keep the POJO databindings and implement the POJO<-->XML transformers
>> using JAXB-impl
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message ----- From: "Jean-Sebastien Delfino"
>> <js...@apache.org>
>> To: <tu...@ws.apache.org>
>> Sent: Monday, November 26, 2007 3:26 PM
>> Subject: Re: Data transformation from/to POJO
>>
>>
>>> Raymond Feng wrote:
>>>> Hi,
>>>>
>>>> I just did a test to see how JAXB-RI handles the POJO without any
>>>> annotations. The result seems to be promising.
>>>>
>>>> I started with a POJO:
>>>>
>>>> public class MyBean {
>>>> private int age;
>>>> private String name;
>>>> private List<String> notes = new ArrayList<String>();
>>>>
>>>> public int getAge() {
>>>> return age;
>>>> }
>>>> public void setAge(int age) {
>>>> this.age = age;
>>>> }
>>>> public String getName() {
>>>> return name;
>>>> }
>>>> public void setName(String name) {
>>>> this.name = name;
>>>> }
>>>> public List<String> getNotes() {
>>>> return notes;
>>>> }
>>>> public void setNotes(List<String> notes) {
>>>> this.notes = notes;
>>>> }
>>>> }
>>>>
>>>> The following test case is then successful.
>>>>
>>>> public void testPOJO() throws Exception {
>>>> JAXBContext context = JAXBContext.newInstance(MyBean.class);
>>>> StringWriter writer = new StringWriter();
>>>> MyBean bean = new MyBean();
>>>> bean.setName("Test");
>>>> bean.setAge(20);
>>>> bean.getNotes().add("1");
>>>> bean.getNotes().add("2");
>>>> JAXBElement<Object> element = new JAXBElement<Object>(new
>>>> QName("http://ns1", "bean"), Object.class, bean);
>>>> context.createMarshaller().marshal(element, writer);
>>>> System.out.println(writer.toString());
>>>> Object result = context.createUnmarshaller().unmarshal(new
>>>> StringReader(writer.toString()));
>>>> assertTrue(result instanceof JAXBElement);
>>>> JAXBElement e2 = (JAXBElement)result;
>>>> assertTrue(e2.getValue() instanceof MyBean);
>>>> }
>>>>
>>>> <?xml version="1.0" encoding="UTF-8" standalone="yes"?><ns2:bean
>>>> xsi:type="myBean" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>> xmlns:ns2="http://ns1"><age>20</age><name>Test</name></ns2:bean>
>>>>
>>>>
>>>
>>> Good that it seems promising :) what do I need to do to get the JaxB to
>>> XML transformer to pick up the Item bean in the store tutorial?
>>>
>>> --
>>> 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
>>
>
>
> --
> 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
Re: Data transformation from/to POJO
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I also added a test case [1][2] to try round trips between POJO and JSON
using com/metaparadigm/json-rpc/1.0/json-rpc-1.0.jar. The result is pretty
much positive. It can work with simple types, collections, arrays and
objects.
Here is a sample result:
{"notes":{"list":["1","2"],"javaClass":"java.util.ArrayList"},"good":false,"rates":[1,2],"service":{"javaClass":"org.apache.tuscany.sca.databinding.json.MyInterfaceImpl","id":"ID001"},"map":{"map":{"1":1},"javaClass":"java.util.HashMap"},"javaClass":"org.apache.tuscany.sca.databinding.json.MyBean","name":"Test","age":20,"otherService":{"javaClass":"org.apache.tuscany.sca.databinding.json.MyInterfaceImpl","id":"ID001"}}
As you can see, I have to enable a flag in the serializer to produce the
"javaClass" hints so that the deserializer can work with interfaces such as
List, Map and MyInterface.
The Map structure is different than we see with JAXB. But it seems to be
reasonable for JavaScripts.
[1] http://svn.apache.org/viewvc?rev=601958&view=rev
[2]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/databinding-json/src/test/java/org/apache/tuscany/sca/databinding/json/POJOTestCase.java
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Wednesday, December 05, 2007 5:45 PM
Subject: Re: Data transformation from/to POJO
> Raymond Feng wrote:
>> Hi,
>>
>> I have checked in the first cut under
>> http://svn.apache.org/viewvc?rev=601501&view=rev. With these changes, we
>> now use JAXB databinding to deal with POJOs (including simple and complex
>> types). By the JAXB Java to XML default mapping, POJOs are supported in
>> line with the JavaBeans patterns with the flowing rules.
>>
>> 1) There is a protected or public no-arg constructor
>> 2) A property is either a public field or public setter & getter. Even
>> for Collection type, the setter is required.
>> 3) The property can not be an interface
>> 4) Circular object reference is not supported
>> 5) References to the same object are flattened
>>
>> One caveat is that it brings the jaxb-api and jaxb-impl as core
>> dependencies (about 1MB). We could try to implement the default Java/XML
>> mapping by ourselves if that's desirable.
>>
>> There are also other things we need to improve, for example, how to
>> render a JAXB object as XMLStreamReader. The quick and dirty way is to
>> marshal the JAXB object into a byte array and create XMLStreamReader out
>> of it. We could even use the fast-infoset to help the performance of the
>> round trip.
>>
>> Thanks,
>> Raymond
>>
>
> Great Thanks!
>
> Now that we have the external behavior right I should be able to clean up
> the store scenario.
>
> +1 for improving and optimizing the implementation over time.
>
> If anybody is interested it would be nice to get concrete performance
> numbers at some point, analyze the numbers and define performance
> objectives. This should help understand what needs to be optimized.
> --
> 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
Re: Data transformation from/to POJO
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> Hi,
>
> I have checked in the first cut under
> http://svn.apache.org/viewvc?rev=601501&view=rev. With these changes, we
> now use JAXB databinding to deal with POJOs (including simple and
> complex types). By the JAXB Java to XML default mapping, POJOs are
> supported in line with the JavaBeans patterns with the flowing rules.
>
> 1) There is a protected or public no-arg constructor
> 2) A property is either a public field or public setter & getter. Even
> for Collection type, the setter is required.
> 3) The property can not be an interface
> 4) Circular object reference is not supported
> 5) References to the same object are flattened
>
> One caveat is that it brings the jaxb-api and jaxb-impl as core
> dependencies (about 1MB). We could try to implement the default Java/XML
> mapping by ourselves if that's desirable.
>
> There are also other things we need to improve, for example, how to
> render a JAXB object as XMLStreamReader. The quick and dirty way is to
> marshal the JAXB object into a byte array and create XMLStreamReader out
> of it. We could even use the fast-infoset to help the performance of the
> round trip.
>
> Thanks,
> Raymond
>
Great Thanks!
Now that we have the external behavior right I should be able to clean
up the store scenario.
+1 for improving and optimizing the implementation over time.
If anybody is interested it would be nice to get concrete performance
numbers at some point, analyze the numbers and define performance
objectives. This should help understand what needs to be optimized.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Data transformation from/to POJO
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I have checked in the first cut under
http://svn.apache.org/viewvc?rev=601501&view=rev. With these changes, we now
use JAXB databinding to deal with POJOs (including simple and complex
types). By the JAXB Java to XML default mapping, POJOs are supported in line
with the JavaBeans patterns with the flowing rules.
1) There is a protected or public no-arg constructor
2) A property is either a public field or public setter & getter. Even for
Collection type, the setter is required.
3) The property can not be an interface
4) Circular object reference is not supported
5) References to the same object are flattened
One caveat is that it brings the jaxb-api and jaxb-impl as core dependencies
(about 1MB). We could try to implement the default Java/XML mapping by
ourselves if that's desirable.
There are also other things we need to improve, for example, how to render a
JAXB object as XMLStreamReader. The quick and dirty way is to marshal the
JAXB object into a byte array and create XMLStreamReader out of it. We could
even use the fast-infoset to help the performance of the round trip.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Tuesday, November 27, 2007 1:18 PM
Subject: Re: Data transformation from/to POJO
> Raymond Feng wrote:
>> I think there are two options:
>>
>> 1) Make the JAXB databinding as the default databinding for POJOs (simple
>> and complex types).
>
> What about doing that? any drawback?
>
>>
>> 2) Keep the POJO databindings and implement the POJO<-->XML transformers
>> using JAXB-impl
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message ----- From: "Jean-Sebastien Delfino"
>> <js...@apache.org>
>> To: <tu...@ws.apache.org>
>> Sent: Monday, November 26, 2007 3:26 PM
>> Subject: Re: Data transformation from/to POJO
>>
>>
>>> Raymond Feng wrote:
>>>> Hi,
>>>>
>>>> I just did a test to see how JAXB-RI handles the POJO without any
>>>> annotations. The result seems to be promising.
>>>>
>>>> I started with a POJO:
>>>>
>>>> public class MyBean {
>>>> private int age;
>>>> private String name;
>>>> private List<String> notes = new ArrayList<String>();
>>>>
>>>> public int getAge() {
>>>> return age;
>>>> }
>>>> public void setAge(int age) {
>>>> this.age = age;
>>>> }
>>>> public String getName() {
>>>> return name;
>>>> }
>>>> public void setName(String name) {
>>>> this.name = name;
>>>> }
>>>> public List<String> getNotes() {
>>>> return notes;
>>>> }
>>>> public void setNotes(List<String> notes) {
>>>> this.notes = notes;
>>>> }
>>>> }
>>>>
>>>> The following test case is then successful.
>>>>
>>>> public void testPOJO() throws Exception {
>>>> JAXBContext context = JAXBContext.newInstance(MyBean.class);
>>>> StringWriter writer = new StringWriter();
>>>> MyBean bean = new MyBean();
>>>> bean.setName("Test");
>>>> bean.setAge(20);
>>>> bean.getNotes().add("1");
>>>> bean.getNotes().add("2");
>>>> JAXBElement<Object> element = new JAXBElement<Object>(new
>>>> QName("http://ns1", "bean"), Object.class, bean);
>>>> context.createMarshaller().marshal(element, writer);
>>>> System.out.println(writer.toString());
>>>> Object result = context.createUnmarshaller().unmarshal(new
>>>> StringReader(writer.toString()));
>>>> assertTrue(result instanceof JAXBElement);
>>>> JAXBElement e2 = (JAXBElement)result;
>>>> assertTrue(e2.getValue() instanceof MyBean);
>>>> }
>>>>
>>>> <?xml version="1.0" encoding="UTF-8" standalone="yes"?><ns2:bean
>>>> xsi:type="myBean" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>> xmlns:ns2="http://ns1"><age>20</age><name>Test</name></ns2:bean>
>>>>
>>>>
>>>
>>> Good that it seems promising :) what do I need to do to get the JaxB to
>>> XML transformer to pick up the Item bean in the store tutorial?
>>>
>>> --
>>> 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
>>
>
>
> --
> 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
Re: Data transformation from/to POJO
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> I think there are two options:
>
> 1) Make the JAXB databinding as the default databinding for POJOs
> (simple and complex types).
What about doing that? any drawback?
>
> 2) Keep the POJO databindings and implement the POJO<-->XML transformers
> using JAXB-impl
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Jean-Sebastien Delfino"
> <js...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Monday, November 26, 2007 3:26 PM
> Subject: Re: Data transformation from/to POJO
>
>
>> Raymond Feng wrote:
>>> Hi,
>>>
>>> I just did a test to see how JAXB-RI handles the POJO without any
>>> annotations. The result seems to be promising.
>>>
>>> I started with a POJO:
>>>
>>> public class MyBean {
>>> private int age;
>>> private String name;
>>> private List<String> notes = new ArrayList<String>();
>>>
>>> public int getAge() {
>>> return age;
>>> }
>>> public void setAge(int age) {
>>> this.age = age;
>>> }
>>> public String getName() {
>>> return name;
>>> }
>>> public void setName(String name) {
>>> this.name = name;
>>> }
>>> public List<String> getNotes() {
>>> return notes;
>>> }
>>> public void setNotes(List<String> notes) {
>>> this.notes = notes;
>>> }
>>> }
>>>
>>> The following test case is then successful.
>>>
>>> public void testPOJO() throws Exception {
>>> JAXBContext context = JAXBContext.newInstance(MyBean.class);
>>> StringWriter writer = new StringWriter();
>>> MyBean bean = new MyBean();
>>> bean.setName("Test");
>>> bean.setAge(20);
>>> bean.getNotes().add("1");
>>> bean.getNotes().add("2");
>>> JAXBElement<Object> element = new JAXBElement<Object>(new
>>> QName("http://ns1", "bean"), Object.class, bean);
>>> context.createMarshaller().marshal(element, writer);
>>> System.out.println(writer.toString());
>>> Object result = context.createUnmarshaller().unmarshal(new
>>> StringReader(writer.toString()));
>>> assertTrue(result instanceof JAXBElement);
>>> JAXBElement e2 = (JAXBElement)result;
>>> assertTrue(e2.getValue() instanceof MyBean);
>>> }
>>>
>>> <?xml version="1.0" encoding="UTF-8" standalone="yes"?><ns2:bean
>>> xsi:type="myBean"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xmlns:ns2="http://ns1"><age>20</age><name>Test</name></ns2:bean>
>>>
>>>
>>
>> Good that it seems promising :) what do I need to do to get the JaxB
>> to XML transformer to pick up the Item bean in the store tutorial?
>>
>> --
>> 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
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Data transformation from/to POJO
Posted by Raymond Feng <en...@gmail.com>.
I think there are two options:
1) Make the JAXB databinding as the default databinding for POJOs (simple
and complex types).
2) Keep the POJO databindings and implement the POJO<-->XML transformers
using JAXB-impl
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Monday, November 26, 2007 3:26 PM
Subject: Re: Data transformation from/to POJO
> Raymond Feng wrote:
>> Hi,
>>
>> I just did a test to see how JAXB-RI handles the POJO without any
>> annotations. The result seems to be promising.
>>
>> I started with a POJO:
>>
>> public class MyBean {
>> private int age;
>> private String name;
>> private List<String> notes = new ArrayList<String>();
>>
>> public int getAge() {
>> return age;
>> }
>> public void setAge(int age) {
>> this.age = age;
>> }
>> public String getName() {
>> return name;
>> }
>> public void setName(String name) {
>> this.name = name;
>> }
>> public List<String> getNotes() {
>> return notes;
>> }
>> public void setNotes(List<String> notes) {
>> this.notes = notes;
>> }
>> }
>>
>> The following test case is then successful.
>>
>> public void testPOJO() throws Exception {
>> JAXBContext context = JAXBContext.newInstance(MyBean.class);
>> StringWriter writer = new StringWriter();
>> MyBean bean = new MyBean();
>> bean.setName("Test");
>> bean.setAge(20);
>> bean.getNotes().add("1");
>> bean.getNotes().add("2");
>> JAXBElement<Object> element = new JAXBElement<Object>(new
>> QName("http://ns1", "bean"), Object.class, bean);
>> context.createMarshaller().marshal(element, writer);
>> System.out.println(writer.toString());
>> Object result = context.createUnmarshaller().unmarshal(new
>> StringReader(writer.toString()));
>> assertTrue(result instanceof JAXBElement);
>> JAXBElement e2 = (JAXBElement)result;
>> assertTrue(e2.getValue() instanceof MyBean);
>> }
>>
>> <?xml version="1.0" encoding="UTF-8" standalone="yes"?><ns2:bean
>> xsi:type="myBean" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:ns2="http://ns1"><age>20</age><name>Test</name></ns2:bean>
>>
>>
>
> Good that it seems promising :) what do I need to do to get the JaxB to
> XML transformer to pick up the Item bean in the store tutorial?
>
> --
> 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
Re: Data transformation from/to POJO
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> Hi,
>
> I just did a test to see how JAXB-RI handles the POJO without any
> annotations. The result seems to be promising.
>
> I started with a POJO:
>
> public class MyBean {
> private int age;
> private String name;
> private List<String> notes = new ArrayList<String>();
>
> public int getAge() {
> return age;
> }
> public void setAge(int age) {
> this.age = age;
> }
> public String getName() {
> return name;
> }
> public void setName(String name) {
> this.name = name;
> }
> public List<String> getNotes() {
> return notes;
> }
> public void setNotes(List<String> notes) {
> this.notes = notes;
> }
> }
>
> The following test case is then successful.
>
> public void testPOJO() throws Exception {
> JAXBContext context = JAXBContext.newInstance(MyBean.class);
> StringWriter writer = new StringWriter();
> MyBean bean = new MyBean();
> bean.setName("Test");
> bean.setAge(20);
> bean.getNotes().add("1");
> bean.getNotes().add("2");
> JAXBElement<Object> element = new JAXBElement<Object>(new
> QName("http://ns1", "bean"), Object.class, bean);
> context.createMarshaller().marshal(element, writer);
> System.out.println(writer.toString());
> Object result = context.createUnmarshaller().unmarshal(new
> StringReader(writer.toString()));
> assertTrue(result instanceof JAXBElement);
> JAXBElement e2 = (JAXBElement)result;
> assertTrue(e2.getValue() instanceof MyBean);
> }
>
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?><ns2:bean
> xsi:type="myBean" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ns2="http://ns1"><age>20</age><name>Test</name></ns2:bean>
>
>
Good that it seems promising :) what do I need to do to get the JaxB to
XML transformer to pick up the Item bean in the store tutorial?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Data transformation from/to POJO
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I just did a test to see how JAXB-RI handles the POJO without any
annotations. The result seems to be promising.
I started with a POJO:
public class MyBean {
private int age;
private String name;
private List<String> notes = new ArrayList<String>();
public int getAge() {
return age;
}
public void setAge(int age) {
this.age = age;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public List<String> getNotes() {
return notes;
}
public void setNotes(List<String> notes) {
this.notes = notes;
}
}
The following test case is then successful.
public void testPOJO() throws Exception {
JAXBContext context = JAXBContext.newInstance(MyBean.class);
StringWriter writer = new StringWriter();
MyBean bean = new MyBean();
bean.setName("Test");
bean.setAge(20);
bean.getNotes().add("1");
bean.getNotes().add("2");
JAXBElement<Object> element = new JAXBElement<Object>(new
QName("http://ns1", "bean"), Object.class, bean);
context.createMarshaller().marshal(element, writer);
System.out.println(writer.toString());
Object result = context.createUnmarshaller().unmarshal(new
StringReader(writer.toString()));
assertTrue(result instanceof JAXBElement);
JAXBElement e2 = (JAXBElement)result;
assertTrue(e2.getValue() instanceof MyBean);
}
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><ns2:bean
xsi:type="myBean" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ns2="http://ns1"><age>20</age><name>Test</name></ns2:bean>
Thanks,
Raymond
----- Original Message -----
From: "Simon Nash" <na...@hursley.ibm.com>
To: <tu...@ws.apache.org>
Sent: Monday, November 26, 2007 1:50 PM
Subject: Re: Data transformation from/to POJO
> There is a default Java to XML mapping (without annotations) in the
> JAXB spec, in addition to the customized mapping (with annotations).
> Does the default mapping have unacceptable limitations? If so, what
> are they?
>
> Simon
>
> Raymond Feng wrote:
>
>> Hi,
>>
>> I'm on the same boat as Mike and you. The discussion was about how can we
>> simplify the data transformation of a subset of POJOs following a strict
>> pattern without starting from a formal model such as XSD. I don't know
>> any JAXB implementation can handle a POJO without JAXB annotations. If
>> there is one with reasonable support of default Java/XML mapping (no XSD
>> or annotations are required), I would be happy to use it.
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message ----- From: "Simon Nash" <na...@hursley.ibm.com>
>> To: <tu...@ws.apache.org>
>> Sent: Monday, November 26, 2007 12:36 PM
>> Subject: Re: Data transformation from/to POJO
>>
>>
>>> Mike has brought up a very good point. I don't think it would make
>>> sense for Tuscany to invent yet another Java to XML mapping. What
>>> are the issues if we were to go with what JAXB defines for this?
>>>
>>> Simon
>>>
>>> Mike Edwards wrote:
>>>
>>>> Raymond,
>>>>
>>>> "Where angels fear to tread"
>>>>
>>>> My initial thoughts about this mused on why people had spent so much
>>>> time on specs like SDO and JAXB. If mapping POJOs to XML was simple
>>>> and straightforward, why did we need those large specs?
>>>>
>>>> Perhaps you are right in thinking that there are simple cases that can
>>>> be mapped simply. But then, what do you do about the more awkward
>>>> cases?
>>>>
>>>> What I'd like us to consider deeply first is whether we want to create
>>>> (yet) another Java <-> XML mapping specification and if so, what is its
>>>> relationship to the existing ones.
>>>>
>>>> My initial 2 cents....
>>>>
>>>>
>>>> Yours, Mike.
>>>>
>>>> Raymond Feng wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> With the recent development of the online store tutorial, we encounter
>>>>> quite a few issues around the transformation between POJO and other
>>>>> databindings (such as XML, JSON).
>>>>>
>>>>> Let's take the POJO <--> XML as an example. Here is a set of questions
>>>>> to be answered.
>>>>>
>>>>> 1) Do we require the POJO to be a strict JavaBean or free-form class?
>>>>>
>>>>> 2) How to read properties from a java object?
>>>>>
>>>>> The data in a java object can be accessed by the field or by JavaBean
>>>>> style getter methods. There are different strategies:
>>>>>
>>>>> a) Always use JavaBean-style getter method
>>>>> b) Always use field access
>>>>> c) A combination of a & b
>>>>>
>>>>> The other factor is the modifier of a field/method defintion. What
>>>>> modifiers are allowed? public, protected, default and private?
>>>>>
>>>>> If a property only have getter method, should we dump the property
>>>>> into the XML? How about transient fields?
>>>>>
>>>>> 3) How to write properties to populate the target POJO instance?
>>>>>
>>>>> a) Use JavaBean setter?
>>>>> b) Use field
>>>>> c) Combination of a & b
>>>>>
>>>>> When we convert XML element back to a POJO property, how do we
>>>>> instantiate the property instance if the property type is an interface
>>>>> or abstract class?
>>>>>
>>>>> For example,
>>>>>
>>>>> package com.example;
>>>>> public class MyBean {
>>>>> private MyInterface p1;
>>>>>
>>>>> public void setP1(MyInterface p1) {
>>>>> this.p1 = p1;
>>>>> }
>>>>>
>>>>> public MyInterface getP1() {
>>>>> return p1;
>>>>> }
>>>>> }
>>>>>
>>>>> Do we require the XML element contains xsi:type attribute which will
>>>>> be generated from POJO-->XML to represent the concrete property type?
>>>>> Such as:
>>>>>
>>>>> <myBean xsi:type="ns1:MyBean" xmlns:ns1="http://example.com/">
>>>>> <p1 xsi:type="ns2:MyInterface" xmlns:ns2=http://example.com//>
>>>>> </myBean>
>>>>>
>>>>> Thanks,
>>>>> Raymond
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
Re: Data transformation from/to POJO
Posted by Simon Nash <na...@hursley.ibm.com>.
There is a default Java to XML mapping (without annotations) in the
JAXB spec, in addition to the customized mapping (with annotations).
Does the default mapping have unacceptable limitations? If so, what
are they?
Simon
Raymond Feng wrote:
> Hi,
>
> I'm on the same boat as Mike and you. The discussion was about how can
> we simplify the data transformation of a subset of POJOs following a
> strict pattern without starting from a formal model such as XSD. I don't
> know any JAXB implementation can handle a POJO without JAXB annotations.
> If there is one with reasonable support of default Java/XML mapping (no
> XSD or annotations are required), I would be happy to use it.
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Simon Nash" <na...@hursley.ibm.com>
> To: <tu...@ws.apache.org>
> Sent: Monday, November 26, 2007 12:36 PM
> Subject: Re: Data transformation from/to POJO
>
>
>> Mike has brought up a very good point. I don't think it would make
>> sense for Tuscany to invent yet another Java to XML mapping. What
>> are the issues if we were to go with what JAXB defines for this?
>>
>> Simon
>>
>> Mike Edwards wrote:
>>
>>> Raymond,
>>>
>>> "Where angels fear to tread"
>>>
>>> My initial thoughts about this mused on why people had spent so much
>>> time on specs like SDO and JAXB. If mapping POJOs to XML was simple
>>> and straightforward, why did we need those large specs?
>>>
>>> Perhaps you are right in thinking that there are simple cases that
>>> can be mapped simply. But then, what do you do about the more
>>> awkward cases?
>>>
>>> What I'd like us to consider deeply first is whether we want to
>>> create (yet) another Java <-> XML mapping specification and if so,
>>> what is its relationship to the existing ones.
>>>
>>> My initial 2 cents....
>>>
>>>
>>> Yours, Mike.
>>>
>>> Raymond Feng wrote:
>>>
>>>> Hi,
>>>>
>>>> With the recent development of the online store tutorial, we
>>>> encounter quite a few issues around the transformation between POJO
>>>> and other databindings (such as XML, JSON).
>>>>
>>>> Let's take the POJO <--> XML as an example. Here is a set of
>>>> questions to be answered.
>>>>
>>>> 1) Do we require the POJO to be a strict JavaBean or free-form class?
>>>>
>>>> 2) How to read properties from a java object?
>>>>
>>>> The data in a java object can be accessed by the field or by
>>>> JavaBean style getter methods. There are different strategies:
>>>>
>>>> a) Always use JavaBean-style getter method
>>>> b) Always use field access
>>>> c) A combination of a & b
>>>>
>>>> The other factor is the modifier of a field/method defintion. What
>>>> modifiers are allowed? public, protected, default and private?
>>>>
>>>> If a property only have getter method, should we dump the property
>>>> into the XML? How about transient fields?
>>>>
>>>> 3) How to write properties to populate the target POJO instance?
>>>>
>>>> a) Use JavaBean setter?
>>>> b) Use field
>>>> c) Combination of a & b
>>>>
>>>> When we convert XML element back to a POJO property, how do we
>>>> instantiate the property instance if the property type is an
>>>> interface or abstract class?
>>>>
>>>> For example,
>>>>
>>>> package com.example;
>>>> public class MyBean {
>>>> private MyInterface p1;
>>>>
>>>> public void setP1(MyInterface p1) {
>>>> this.p1 = p1;
>>>> }
>>>>
>>>> public MyInterface getP1() {
>>>> return p1;
>>>> }
>>>> }
>>>>
>>>> Do we require the XML element contains xsi:type attribute which will
>>>> be generated from POJO-->XML to represent the concrete property
>>>> type? Such as:
>>>>
>>>> <myBean xsi:type="ns1:MyBean" xmlns:ns1="http://example.com/">
>>>> <p1 xsi:type="ns2:MyInterface" xmlns:ns2=http://example.com//>
>>>> </myBean>
>>>>
>>>> Thanks,
>>>> Raymond
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
Re: Data transformation from/to POJO
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> Hi,
>
> I'm on the same boat as Mike and you. The discussion was about how can
> we simplify the data transformation of a subset of POJOs following a
> strict pattern without starting from a formal model such as XSD. I don't
> know any JAXB implementation can handle a POJO without JAXB annotations.
> If there is one with reasonable support of default Java/XML mapping (no
> XSD or annotations are required), I would be happy to use it.
>
> Thanks,
> Raymond
>
I think I can guess where that discussion is going so let me try to
bring a different perspective.
The discussion started from me trying to put together a simple online
store application. My application has a catalog and a shopping cart.
Both contain Item business objects (representing fruits and vegetables).
I need to flow these Items through local calls, ATOMPub, JSON-RPC
and SOAP.
This online store application is developed as a tutorial and in the
initial steps I write Item as a simple JavaBean.
I don't have any strong preference for a particular databinding or
another, but could you guys please help me understand how I go from Item
to something that actually works in the complete application with the
bindings I need?
I'm open to change Item, to write some transformation/mediation code if
there's really no way to flow the same Item through XML and non-XML, or
whatever other creative solution you find, as long as it's reasonably
simple (in other words this little data business doesn't become the most
complicated part of the application).
The current code for the online store is there:
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/tutorial/assets
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/tutorial/store
Thanks.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Data transformation from/to POJO
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I'm on the same boat as Mike and you. The discussion was about how can we
simplify the data transformation of a subset of POJOs following a strict
pattern without starting from a formal model such as XSD. I don't know any
JAXB implementation can handle a POJO without JAXB annotations. If there is
one with reasonable support of default Java/XML mapping (no XSD or
annotations are required), I would be happy to use it.
Thanks,
Raymond
----- Original Message -----
From: "Simon Nash" <na...@hursley.ibm.com>
To: <tu...@ws.apache.org>
Sent: Monday, November 26, 2007 12:36 PM
Subject: Re: Data transformation from/to POJO
> Mike has brought up a very good point. I don't think it would make
> sense for Tuscany to invent yet another Java to XML mapping. What
> are the issues if we were to go with what JAXB defines for this?
>
> Simon
>
> Mike Edwards wrote:
>
>> Raymond,
>>
>> "Where angels fear to tread"
>>
>> My initial thoughts about this mused on why people had spent so much time
>> on specs like SDO and JAXB. If mapping POJOs to XML was simple and
>> straightforward, why did we need those large specs?
>>
>> Perhaps you are right in thinking that there are simple cases that can be
>> mapped simply. But then, what do you do about the more awkward cases?
>>
>> What I'd like us to consider deeply first is whether we want to create
>> (yet) another Java <-> XML mapping specification and if so, what is its
>> relationship to the existing ones.
>>
>> My initial 2 cents....
>>
>>
>> Yours, Mike.
>>
>> Raymond Feng wrote:
>>
>>> Hi,
>>>
>>> With the recent development of the online store tutorial, we encounter
>>> quite a few issues around the transformation between POJO and other
>>> databindings (such as XML, JSON).
>>>
>>> Let's take the POJO <--> XML as an example. Here is a set of questions
>>> to be answered.
>>>
>>> 1) Do we require the POJO to be a strict JavaBean or free-form class?
>>>
>>> 2) How to read properties from a java object?
>>>
>>> The data in a java object can be accessed by the field or by JavaBean
>>> style getter methods. There are different strategies:
>>>
>>> a) Always use JavaBean-style getter method
>>> b) Always use field access
>>> c) A combination of a & b
>>>
>>> The other factor is the modifier of a field/method defintion. What
>>> modifiers are allowed? public, protected, default and private?
>>>
>>> If a property only have getter method, should we dump the property into
>>> the XML? How about transient fields?
>>>
>>> 3) How to write properties to populate the target POJO instance?
>>>
>>> a) Use JavaBean setter?
>>> b) Use field
>>> c) Combination of a & b
>>>
>>> When we convert XML element back to a POJO property, how do we
>>> instantiate the property instance if the property type is an interface
>>> or abstract class?
>>>
>>> For example,
>>>
>>> package com.example;
>>> public class MyBean {
>>> private MyInterface p1;
>>>
>>> public void setP1(MyInterface p1) {
>>> this.p1 = p1;
>>> }
>>>
>>> public MyInterface getP1() {
>>> return p1;
>>> }
>>> }
>>>
>>> Do we require the XML element contains xsi:type attribute which will be
>>> generated from POJO-->XML to represent the concrete property type? Such
>>> as:
>>>
>>> <myBean xsi:type="ns1:MyBean" xmlns:ns1="http://example.com/">
>>> <p1 xsi:type="ns2:MyInterface" xmlns:ns2=http://example.com//>
>>> </myBean>
>>>
>>> Thanks,
>>> Raymond
>>>
>>> ---------------------------------------------------------------------
>>> 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
Re: Data transformation from/to POJO
Posted by Simon Nash <na...@hursley.ibm.com>.
Mike has brought up a very good point. I don't think it would make
sense for Tuscany to invent yet another Java to XML mapping. What
are the issues if we were to go with what JAXB defines for this?
Simon
Mike Edwards wrote:
> Raymond,
>
> "Where angels fear to tread"
>
> My initial thoughts about this mused on why people had spent so much
> time on specs like SDO and JAXB. If mapping POJOs to XML was simple and
> straightforward, why did we need those large specs?
>
> Perhaps you are right in thinking that there are simple cases that can
> be mapped simply. But then, what do you do about the more awkward cases?
>
> What I'd like us to consider deeply first is whether we want to create
> (yet) another Java <-> XML mapping specification and if so, what is its
> relationship to the existing ones.
>
> My initial 2 cents....
>
>
> Yours, Mike.
>
> Raymond Feng wrote:
>
>> Hi,
>>
>> With the recent development of the online store tutorial, we encounter
>> quite a few issues around the transformation between POJO and other
>> databindings (such as XML, JSON).
>>
>> Let's take the POJO <--> XML as an example. Here is a set of questions
>> to be answered.
>>
>> 1) Do we require the POJO to be a strict JavaBean or free-form class?
>>
>> 2) How to read properties from a java object?
>>
>> The data in a java object can be accessed by the field or by JavaBean
>> style getter methods. There are different strategies:
>>
>> a) Always use JavaBean-style getter method
>> b) Always use field access
>> c) A combination of a & b
>>
>> The other factor is the modifier of a field/method defintion. What
>> modifiers are allowed? public, protected, default and private?
>>
>> If a property only have getter method, should we dump the property
>> into the XML? How about transient fields?
>>
>> 3) How to write properties to populate the target POJO instance?
>>
>> a) Use JavaBean setter?
>> b) Use field
>> c) Combination of a & b
>>
>> When we convert XML element back to a POJO property, how do we
>> instantiate the property instance if the property type is an interface
>> or abstract class?
>>
>> For example,
>>
>> package com.example;
>> public class MyBean {
>> private MyInterface p1;
>>
>> public void setP1(MyInterface p1) {
>> this.p1 = p1;
>> }
>>
>> public MyInterface getP1() {
>> return p1;
>> }
>> }
>>
>> Do we require the XML element contains xsi:type attribute which will
>> be generated from POJO-->XML to represent the concrete property type?
>> Such as:
>>
>> <myBean xsi:type="ns1:MyBean" xmlns:ns1="http://example.com/">
>> <p1 xsi:type="ns2:MyInterface" xmlns:ns2=http://example.com//>
>> </myBean>
>>
>> Thanks,
>> Raymond
>>
>> ---------------------------------------------------------------------
>> 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
Re: Data transformation from/to POJO
Posted by Mike Edwards <mi...@gmail.com>.
Raymond,
"Where angels fear to tread"
My initial thoughts about this mused on why people had spent so much
time on specs like SDO and JAXB. If mapping POJOs to XML was simple and
straightforward, why did we need those large specs?
Perhaps you are right in thinking that there are simple cases that can
be mapped simply. But then, what do you do about the more awkward cases?
What I'd like us to consider deeply first is whether we want to create
(yet) another Java <-> XML mapping specification and if so, what is its
relationship to the existing ones.
My initial 2 cents....
Yours, Mike.
Raymond Feng wrote:
> Hi,
>
> With the recent development of the online store tutorial, we encounter
> quite a few issues around the transformation between POJO and other
> databindings (such as XML, JSON).
>
> Let's take the POJO <--> XML as an example. Here is a set of questions
> to be answered.
>
> 1) Do we require the POJO to be a strict JavaBean or free-form class?
>
> 2) How to read properties from a java object?
>
> The data in a java object can be accessed by the field or by JavaBean
> style getter methods. There are different strategies:
>
> a) Always use JavaBean-style getter method
> b) Always use field access
> c) A combination of a & b
>
> The other factor is the modifier of a field/method defintion. What
> modifiers are allowed? public, protected, default and private?
>
> If a property only have getter method, should we dump the property into
> the XML? How about transient fields?
>
> 3) How to write properties to populate the target POJO instance?
>
> a) Use JavaBean setter?
> b) Use field
> c) Combination of a & b
>
> When we convert XML element back to a POJO property, how do we
> instantiate the property instance if the property type is an interface
> or abstract class?
>
> For example,
>
> package com.example;
> public class MyBean {
> private MyInterface p1;
>
> public void setP1(MyInterface p1) {
> this.p1 = p1;
> }
>
> public MyInterface getP1() {
> return p1;
> }
> }
>
> Do we require the XML element contains xsi:type attribute which will be
> generated from POJO-->XML to represent the concrete property type? Such as:
>
> <myBean xsi:type="ns1:MyBean" xmlns:ns1="http://example.com/">
> <p1 xsi:type="ns2:MyInterface" xmlns:ns2=http://example.com//>
> </myBean>
>
> Thanks,
> Raymond
>
> ---------------------------------------------------------------------
> 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
Re: Data transformation from/to POJO
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> Please see comments inline.
>
> Raymond
>
> ----- Original Message ----- From: "Jean-Sebastien Delfino"
> <js...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Saturday, November 17, 2007 9:59 AM
> Subject: Re: Data transformation from/to POJO
>
>
>> Raymond Feng wrote:
>>> Hi,
>>>
>>> With the recent development of the online store tutorial, we
>>> encounter quite a few issues around the transformation between POJO
>>> and other databindings (such as XML, JSON).
>>
>> Yeah :)
>>
>>>
>>> Let's take the POJO <--> XML as an example. Here is a set of
>>> questions to be answered.
>>>
>>> 1) Do we require the POJO to be a strict JavaBean or free-form class?
>>>
>>> 2) How to read properties from a java object?
>>>
>>> The data in a java object can be accessed by the field or by
>>> JavaBean style getter methods. There are different strategies:
>>>
>>> a) Always use JavaBean-style getter method
>>> b) Always use field access
>>> c) A combination of a & b
>>>
>>> The other factor is the modifier of a field/method defintion. What
>>> modifiers are allowed? public, protected, default and private?
>>>
>>> If a property only have getter method, should we dump the property
>>> into the XML? How about transient fields?
>>>
>>> 3) How to write properties to populate the target POJO instance?
>>>
>>> a) Use JavaBean setter?
>>> b) Use field
>>> c) Combination of a & b
>>
>> Can't we just follow the SDO or JaxB spec?
>
> I don't think that's the case. Both SDO and JAXB have addtional
> metadata to help make the decision but POJOs don't. SDO has the
> Type/Property while JAXB uses annotations.
>
>>
>>>
>>> When we convert XML element back to a POJO property, how do we
>>> instantiate the property instance if the property type is an
>>> interface or abstract class?
>>>
>>> For example,
>>>
>>> package com.example;
>>> public class MyBean {
>>> private MyInterface p1;
>>>
>>> public void setP1(MyInterface p1) {
>>> this.p1 = p1;
>>> }
>>>
>>> public MyInterface getP1() {
>>> return p1;
>>> }
>>> }
>>>
>>
>> This goes beyond simple POJOs.
>
> Are you saying we shouldn't support that? One simple case would be how
> do we marshal an Exception into XML.
I'm looking at a typical application like the store tutorial and I don't
really see a use case for flowing an exception in an Atom entry for example.
Remember, I am just trying to represent and flow simple business objects
like the Item bean that I'm using in the ShoppingCart and Catalog
service, I'm not asking for a generalized databinding that can cover all
possible cases and flow anything that can be represented in the Java
language. We already have a ton of sophisticated data bindings like SDO
and JaxB for that.
>>
>>> Do we require the XML element contains xsi:type attribute which will
>>> be generated from POJO-->XML to represent the concrete property
>>> type? Such as:
>>>
>>> <myBean xsi:type="ns1:MyBean" xmlns:ns1="http://example.com/">
>>> <p1 xsi:type="ns2:MyInterface" xmlns:ns2=http://example.com//>
>>> </myBean>
>>>
>>
>> Is the idea to support inheritance?
>
> Yes.
>
Ah, OK, I was not sure about what you were trying to do with xsi:types.
So the good news is that I don't need inheritance in my use case. So if
we can keep the XML simple without all this xsi:type stuff everywhere
it'll be better.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Data transformation from/to POJO
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> Please see comments inline.
>
> Raymond
>
> ----- Original Message ----- From: "Jean-Sebastien Delfino"
> <js...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Saturday, November 17, 2007 9:59 AM
> Subject: Re: Data transformation from/to POJO
>
>
>> Raymond Feng wrote:
>>> Hi,
>>>
>>> With the recent development of the online store tutorial, we
>>> encounter quite a few issues around the transformation between POJO
>>> and other databindings (such as XML, JSON).
>>
>> Yeah :)
>>
>>>
>>> Let's take the POJO <--> XML as an example. Here is a set of
>>> questions to be answered.
>>>
>>> 1) Do we require the POJO to be a strict JavaBean or free-form class?
>>>
>>> 2) How to read properties from a java object?
>>>
>>> The data in a java object can be accessed by the field or by
>>> JavaBean style getter methods. There are different strategies:
>>>
>>> a) Always use JavaBean-style getter method
>>> b) Always use field access
>>> c) A combination of a & b
>>>
>>> The other factor is the modifier of a field/method defintion. What
>>> modifiers are allowed? public, protected, default and private?
>>>
>>> If a property only have getter method, should we dump the property
>>> into the XML? How about transient fields?
>>>
>>> 3) How to write properties to populate the target POJO instance?
>>>
>>> a) Use JavaBean setter?
>>> b) Use field
>>> c) Combination of a & b
>>
>> Can't we just follow the SDO or JaxB spec?
>
> I don't think that's the case. Both SDO and JAXB have addtional
> metadata to help make the decision but POJOs don't. SDO has the
> Type/Property while JAXB uses annotations.
>
Not sure I understand sorry... Yes, I know that SDO and JaxB have
additional metadata, but can't we just follow the SDO or JaxB spec with
respect to deciding between:
a) Use JavaBean setter?
b) Use field
c) Combination of a & b
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Data transformation from/to POJO
Posted by Raymond Feng <en...@gmail.com>.
Please see comments inline.
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Saturday, November 17, 2007 9:59 AM
Subject: Re: Data transformation from/to POJO
> Raymond Feng wrote:
>> Hi,
>>
>> With the recent development of the online store tutorial, we encounter
>> quite a few issues around the transformation between POJO and other
>> databindings (such as XML, JSON).
>
> Yeah :)
>
>>
>> Let's take the POJO <--> XML as an example. Here is a set of questions to
>> be answered.
>>
>> 1) Do we require the POJO to be a strict JavaBean or free-form class?
>>
>> 2) How to read properties from a java object?
>>
>> The data in a java object can be accessed by the field or by JavaBean
>> style getter methods. There are different strategies:
>>
>> a) Always use JavaBean-style getter method
>> b) Always use field access
>> c) A combination of a & b
>>
>> The other factor is the modifier of a field/method defintion. What
>> modifiers are allowed? public, protected, default and private?
>>
>> If a property only have getter method, should we dump the property into
>> the XML? How about transient fields?
>>
>> 3) How to write properties to populate the target POJO instance?
>>
>> a) Use JavaBean setter?
>> b) Use field
>> c) Combination of a & b
>
> Can't we just follow the SDO or JaxB spec?
I don't think that's the case. Both SDO and JAXB have addtional metadata to
help make the decision but POJOs don't. SDO has the Type/Property while JAXB
uses annotations.
>
>>
>> When we convert XML element back to a POJO property, how do we
>> instantiate the property instance if the property type is an interface or
>> abstract class?
>>
>> For example,
>>
>> package com.example;
>> public class MyBean {
>> private MyInterface p1;
>>
>> public void setP1(MyInterface p1) {
>> this.p1 = p1;
>> }
>>
>> public MyInterface getP1() {
>> return p1;
>> }
>> }
>>
>
> This goes beyond simple POJOs.
Are you saying we shouldn't support that? One simple case would be how do we
marshal an Exception into XML.
>
>> Do we require the XML element contains xsi:type attribute which will be
>> generated from POJO-->XML to represent the concrete property type? Such
>> as:
>>
>> <myBean xsi:type="ns1:MyBean" xmlns:ns1="http://example.com/">
>> <p1 xsi:type="ns2:MyInterface" xmlns:ns2=http://example.com//>
>> </myBean>
>>
>
> Is the idea to support inheritance?
Yes.
>
> --
> 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
Re: Data transformation from/to POJO
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> Hi,
>
> With the recent development of the online store tutorial, we encounter
> quite a few issues around the transformation between POJO and other
> databindings (such as XML, JSON).
Yeah :)
>
> Let's take the POJO <--> XML as an example. Here is a set of questions
> to be answered.
>
> 1) Do we require the POJO to be a strict JavaBean or free-form class?
>
> 2) How to read properties from a java object?
>
> The data in a java object can be accessed by the field or by JavaBean
> style getter methods. There are different strategies:
>
> a) Always use JavaBean-style getter method
> b) Always use field access
> c) A combination of a & b
>
> The other factor is the modifier of a field/method defintion. What
> modifiers are allowed? public, protected, default and private?
>
> If a property only have getter method, should we dump the property
> into the XML? How about transient fields?
>
> 3) How to write properties to populate the target POJO instance?
>
> a) Use JavaBean setter?
> b) Use field
> c) Combination of a & b
Can't we just follow the SDO or JaxB spec?
>
> When we convert XML element back to a POJO property, how do we
> instantiate the property instance if the property type is an interface
> or abstract class?
>
> For example,
>
> package com.example;
> public class MyBean {
> private MyInterface p1;
>
> public void setP1(MyInterface p1) {
> this.p1 = p1;
> }
>
> public MyInterface getP1() {
> return p1;
> }
> }
>
This goes beyond simple POJOs.
> Do we require the XML element contains xsi:type attribute which will
> be generated from POJO-->XML to represent the concrete property type?
> Such as:
>
> <myBean xsi:type="ns1:MyBean" xmlns:ns1="http://example.com/">
> <p1 xsi:type="ns2:MyInterface" xmlns:ns2=http://example.com//>
> </myBean>
>
Is the idea to support inheritance?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org