You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Guillaume Dufrene <Gu...@lifl.fr> on 2006/04/03 14:33:40 UTC
SDO and DataFactory ...
Hi all,
I'm curently playing around with Tuscany but I'm still confused with SDO
and the DataFactory usage.
I've created a new project from scratch an fallow the tutorial "Building
your first application"
(note that the svn version is different from this document on the sdo
handle)
My goal is to obtain a simple component which I can reach with WebService.
The client side component will be developed in an other SCA (fractal,
AOKell).
My Service Interface seems like this :
@Remotable
public interface AccountService {
public OperationList getOperations( String id );
}
fallow my OperationList Interface :
public interface OperationList {
public List getOperations();
public void addOperation(OperationItf operation);
}
And My OperationItf like this :
public interface OperationItf {
public int getAmount();
public void setAmount(int amount);
public Date getDate();
public void setDate(Date date);
public String getDetails();
public void setDetails(String details);
}
I wrote a component implementation :
public OperationList getOperations( String _ ) {
DataFactory datafactory = DataFactory.INSTANCE;
OperationList lst = (OperationList)
datafactory.create(OperationList.class);
for (OperationItf operation : operations) { // operations is a
local field
OperationItf o = (OperationItf)
datafactory.create(OperationItf.class);
o.setAmount( operation.getAmount() );
o.setDate( operation.getDate() );
o.setDetails( operation.getDetails() );
lst.addOperation(o);
}
return lst;
}
Ok, I wrote common files : module.sca and a wsdl file ... nothing
special in those
I Deploy this on the tomcat server ...
I wrote a WebService Client, based on the helloworldwsclient sample,
launched it ... and crashed :-c
Error on the server side :
java.lang.NullPointerException
at org.eclipse.emf.ecore.util.EcoreUtil.create(EcoreUtil.java:2906)
at
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.java:58)
at
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.java:52)
at bank.AccountImpl.getOperations(Unknown Source)
It comes from the datafactory create call on my Interface ...
Seems that no types are registered into the TypeHelper for this interface.
Does the loader generate the sdo definition from the wsdl file on
"remotable" interface ?
On the bigbank svn version, all the sdo implementations are generated
(surely from the
tuscany-sdo-tool ...) Is there a way to generate this on load time ?
Thanks for reply, I keep an eye on this dev-list.
When an user-list is made, I subscribe to it ;-)
sorry for this hugly english :-p
Re: SDO and DataFactory ...
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Guillaume Dufrene wrote:
> Jean-Sebastien Delfino wrote :
>
>> To define your SDOs you need to write an XML schema and run it
>> through our SDO generator. Another option, if you don't want to write
>> an XML schema is to start contributing to Tuscany and help us
>> implement our Java interface -> SDO generation :) We're running into
>> more and more cases where we'd prefer to just write Java interfaces
>> instead of XML schemas so we'll welcome any contribution helping us
>> to support this.
>
> Ok, that's clear.
> I'm not sure if I have enough time to contribute to the Tuscany
> project but be sure that I take a look at your code and help you if I
> can. Where does your "SDO Generator from JAVA Interface" is packaged ?
>
We're trying to address two different scenarios:
1. Generate implementations of business object interfaces at
development/build time, with a command line tool or a maven2 plugin.
2. Generate implementations at runtime, when somebody calls
DataFactory.create(businessObjectInterface) for example and we detect
that there's no implementation registered for the interface.
If you're ok with trying approach (1) with your application for now, I
just checked in some prototype code that should get you started. I did a
quick test with business object interfaces similar to yours (I reused
the interfaces under accountdata in BigBank and added a list of
operations to look a little more like your interfaces). You'll find the
code for the command line generator and the Maven plugin in our sandbox
under
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/sebastien/java/sdo/plugin-java2sdo.
I also put a copy of bigbank under
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/sebastien/java/sdo/account-java2sdo,
modified to illustrate how to use the generator. The accountdata
business objects are defined as interfaces and the build runs this new
java2sdo maven2 plugin to gen the SDO classes (see pom.xml).
This code is still a little rough, with some limitations, for example
I'm not sure that the generator works if you're using the default (no)
package (I was not sure if you had a package name or not from what you
pasted in your original email). The good news is that there's not much
code so you should be able to adjust it to do what you need. Also,
you'll have to change your list of operations to List<Operation> to tell
the generator which type of SDOs are allowed in the list.
You could also try to integrate the Axis2
o.a.axis2.wsdl.builder.SchemaGenerator instead of doing all the class
introspection in the SDO generator. SchemaGenerator has logic to
introspect classes and generate (XSD) types for them. To get this
working you 'd have to customize SchemaGenerator a bit to take multiple
classes, use the SDO XSD <--> type mappings and maybe also get it to
handle typed Lists, but I think it should be easy to do.
For approach (2) there is the code under
java/sdo/impl/src/main/java/org/apache/tuscany/sdo/codegen that I
mentioned before. This shows how to generate the bytecode for the SDOs
at runtime, you may want to look into this as well later. More work will
be required there to get something working end to end.
>>> My goal is to obtain a simple component which I can reach with
>>> WebService.
>>> The client side component will be developed in an other SCA
>>> (fractal, AOKell).
>>
>>
>> I took a look at the Fractal component model at
>> http://fractal.objectweb.org/specification/index.html and found it
>> interesting, there are some similarities with SCA. Could you tell us
>> a little more about your Fractal client side components and what they
>> will look like?
>
>
> Fractal is a Service Component Architecture developped by INRIA and
> France Telecom.
> AOKell is a java implementation of those specifications.
> You could have more information about AOKell particularities at :
> http://fractal.objectweb.org/tutorials/aokell/index.html
> I'm currently working on a project that aim to allow bindings between
> ours components with other SCA components.
> We choose Tuscany for this TestCase and try to build a minimal
> application with two components (one on earch environment)
>
> Components are defined in a text file with an Architecture Description
> Language (ADL).
> This is really similar to your sca.module file.
> Components are offering services described by Java Interfaces or
> Fractal descriptions. They can be "primitives" or "composed"
> (sub-conponents are inside these kind of components)
>
> Components are binded together by the ADL or with the API and they can
> be swapped at runtime (ie a new
> version of component can be deployed without restarting all the
> environment)
> Currently only fractal components can be binded together. A fractalRMI
> project exists to distribute the
> components on many jvm (or computers) but all the components must be
> some fractal components.
>
> Some controllers are glued to components. Those controllers allow
> Separation of Concern (SoC) and
> implements fractal preocupation and other non-business preoccupation.
> The glued code is merged with component implementation at compile time
> with aspectJ or Spoon.
>
> What else ? .... there is a lot of projects around the Fractal API
> which implements specifics features...
> You could visit the Fractal's website for an overview.
>
>
>
>>>
>>> I wrote a WebService Client, based on the helloworldwsclient sample,
>>> launched it ... and crashed :-c
>>> Error on the server side :
>>> java.lang.NullPointerException
>>> at
>>> org.eclipse.emf.ecore.util.EcoreUtil.create(EcoreUtil.java:2906)
>>> at
>>> org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.java:58)
>>>
>>> at
>>> org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.java:52)
>>>
>>> at bank.AccountImpl.getOperations(Unknown Source)
>>>
>>> It comes from the datafactory create call on my Interface ...
>>> Seems that no types are registered into the TypeHelper for this
>>> interface.
>>>
>> Yes, you're right. That's the problem here. You need generated SDO
>> classes, and you need to register them. IMO you should get a nice
>> exception saying that instead of a NullPointerException... Could you
>> please create a JIRA issue to report this? our JIRA issues are there:
>> http://issues.apache.org/jira/browse/TUSCANY.
>
> JIRA issue created ;-)
>
>>> Does the loader generate the sdo definition from the wsdl file on
>>> "remotable" interface ?
>>> On the bigbank svn version, all the sdo implementations are
>>> generated (surely from the
>>> tuscany-sdo-tool ...) Is there a way to generate this on load time ?
>>>
>> Currently, we only generate SDO classes and interfaces at
>> development/build time. Our SDO code generator command line tool
>> (java/sdo/tools/src/main/java/org/apache/tuscany/sdo/generate/JavaGenerator.java)
>> takes an XSD or WSDL and generates SDOs for all the XSD complex
>> types. We have a Maven2 plugin (tuscany-sdo-plugin) that wraps the
>> code generator, this is what we use to generate SDOs in the Bigbank
>> sample (see java/samples/bigbank/account/pom.xml).
>> [...]
>> Again, we want to support your scenario with Java interfaces in a
>> first class way in a near future. Application developers should be
>> able to develop SCA applications and use SDOs without having to write
>> any WSDL or XSD. We need to detect the types flowing through service
>> interfaces and generate SDO implementation classes for them if
>> necessary, at runtime. Another idea that we've discussed in the past
>> is to use Java 5 annotations to mark Java interfaces and trigger the
>> generation of SDOs. We have some experimental code under
>> java/sdo/impl/src/main/java/org/apache/tuscany/sdo/codegen that shows
>> how to use the ASM library to generate bytecode for skeleton SDO
>> classes, if you're interested and want to take a look...
>
> I will.
> ASM is an hard way to generate some class... In our AOKell project, we
> currently try to replace some ASM bytecode generation with some Spoon
> source code generation (and compile them, at runtime or compile time).
> The templates features are quite easy to use and much comprehensive
> than all the nasty ASM API code :-)
> You could have a look at http://spoon.gforge.inria.fr/
>
>>
>> Let us know if you have more questions. Please also open JIRA issues
>> if you run into any problems, and don't hesitate to send us any
>> patches if you have fixes for them :)
>
> Thanks for your reply, I'll try to contribute to your project.
> Congratulation to all of you, Tuscany seems me to be a good work !
>
> -----
> Guillaume Dufrene.
>
--
Jean-Sebastien
Re: SDO and DataFactory ...
Posted by Guillaume Dufrene <Gu...@lifl.fr>.
Jean-Sebastien Delfino wrote :
> To define your SDOs you need to write an XML schema and run it
> through our SDO generator. Another option, if you don't want to write
> an XML schema is to start contributing to Tuscany and help us
> implement our Java interface -> SDO generation :) We're running into
> more and more cases where we'd prefer to just write Java interfaces
> instead of XML schemas so we'll welcome any contribution helping us to
> support this.
Ok, that's clear.
I'm not sure if I have enough time to contribute to the Tuscany project
but be sure that I take a look at your code and help you if I can. Where
does your "SDO Generator from JAVA Interface" is packaged ?
>> My goal is to obtain a simple component which I can reach with
>> WebService.
>> The client side component will be developed in an other SCA (fractal,
>> AOKell).
>
>
> I took a look at the Fractal component model at
> http://fractal.objectweb.org/specification/index.html and found it
> interesting, there are some similarities with SCA. Could you tell us a
> little more about your Fractal client side components and what they
> will look like?
Fractal is a Service Component Architecture developped by INRIA and
France Telecom.
AOKell is a java implementation of those specifications.
You could have more information about AOKell particularities at :
http://fractal.objectweb.org/tutorials/aokell/index.html
I'm currently working on a project that aim to allow bindings between
ours components with other SCA components.
We choose Tuscany for this TestCase and try to build a minimal
application with two components (one on earch environment)
Components are defined in a text file with an Architecture Description
Language (ADL).
This is really similar to your sca.module file.
Components are offering services described by Java Interfaces or Fractal
descriptions. They can be "primitives" or "composed" (sub-conponents are
inside these kind of components)
Components are binded together by the ADL or with the API and they can
be swapped at runtime (ie a new
version of component can be deployed without restarting all the environment)
Currently only fractal components can be binded together. A fractalRMI
project exists to distribute the
components on many jvm (or computers) but all the components must be
some fractal components.
Some controllers are glued to components. Those controllers allow
Separation of Concern (SoC) and
implements fractal preocupation and other non-business preoccupation.
The glued code is merged with component implementation at compile time
with aspectJ or Spoon.
What else ? .... there is a lot of projects around the Fractal API which
implements specifics features...
You could visit the Fractal's website for an overview.
>>
>> I wrote a WebService Client, based on the helloworldwsclient sample,
>> launched it ... and crashed :-c
>> Error on the server side :
>> java.lang.NullPointerException
>> at
>> org.eclipse.emf.ecore.util.EcoreUtil.create(EcoreUtil.java:2906)
>> at
>> org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.java:58)
>>
>> at
>> org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.java:52)
>>
>> at bank.AccountImpl.getOperations(Unknown Source)
>>
>> It comes from the datafactory create call on my Interface ...
>> Seems that no types are registered into the TypeHelper for this
>> interface.
>>
> Yes, you're right. That's the problem here. You need generated SDO
> classes, and you need to register them. IMO you should get a nice
> exception saying that instead of a NullPointerException... Could you
> please create a JIRA issue to report this? our JIRA issues are there:
> http://issues.apache.org/jira/browse/TUSCANY.
JIRA issue created ;-)
>> Does the loader generate the sdo definition from the wsdl file on
>> "remotable" interface ?
>> On the bigbank svn version, all the sdo implementations are generated
>> (surely from the
>> tuscany-sdo-tool ...) Is there a way to generate this on load time ?
>>
> Currently, we only generate SDO classes and interfaces at
> development/build time. Our SDO code generator command line tool
> (java/sdo/tools/src/main/java/org/apache/tuscany/sdo/generate/JavaGenerator.java)
> takes an XSD or WSDL and generates SDOs for all the XSD complex types.
> We have a Maven2 plugin (tuscany-sdo-plugin) that wraps the code
> generator, this is what we use to generate SDOs in the Bigbank sample
> (see java/samples/bigbank/account/pom.xml).
> [...]
> Again, we want to support your scenario with Java interfaces in a
> first class way in a near future. Application developers should be
> able to develop SCA applications and use SDOs without having to write
> any WSDL or XSD. We need to detect the types flowing through service
> interfaces and generate SDO implementation classes for them if
> necessary, at runtime. Another idea that we've discussed in the past
> is to use Java 5 annotations to mark Java interfaces and trigger the
> generation of SDOs. We have some experimental code under
> java/sdo/impl/src/main/java/org/apache/tuscany/sdo/codegen that shows
> how to use the ASM library to generate bytecode for skeleton SDO
> classes, if you're interested and want to take a look...
I will.
ASM is an hard way to generate some class... In our AOKell project, we
currently try to replace some ASM bytecode generation with some Spoon
source code generation (and compile them, at runtime or compile time).
The templates features are quite easy to use and much comprehensive than
all the nasty ASM API code :-)
You could have a look at http://spoon.gforge.inria.fr/
>
> Let us know if you have more questions. Please also open JIRA issues
> if you run into any problems, and don't hesitate to send us any
> patches if you have fixes for them :)
Thanks for your reply, I'll try to contribute to your project.
Congratulation to all of you, Tuscany seems me to be a good work !
-----
Guillaume Dufrene.
Re: SDO and DataFactory ...
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Guillaume Dufrene wrote:
> Hi all,
>
> I'm curently playing around with Tuscany but I'm still confused with
> SDO and the DataFactory usage.
> I've created a new project from scratch an fallow the tutorial
> "Building your first application"
> (note that the svn version is different from this document on the sdo
> handle)
Yes, our current BigBank scenario is slightly different from the
scenario described in the "Building your first application" document.
The document shows how to define SDO DataObjects using Java interfaces.
We do not support this yet in Tuscany. Currently we only support the
definition of SDOs using XML schema. To define your SDOs you need to
write an XML schema and run it through our SDO generator. Another
option, if you don't want to write an XML schema is to start
contributing to Tuscany and help us implement our Java interface -> SDO
generation :) We're running into more and more cases where we'd prefer
to just write Java interfaces instead of XML schemas so we'll welcome
any contribution helping us to support this.
>
> My goal is to obtain a simple component which I can reach with
> WebService.
> The client side component will be developed in an other SCA (fractal,
> AOKell).
I took a look at the Fractal component model at
http://fractal.objectweb.org/specification/index.html and found it
interesting, there are some similarities with SCA. Could you tell us a
little more about your Fractal client side components and what they will
look like?
>
> My Service Interface seems like this :
> @Remotable
> public interface AccountService {
> public OperationList getOperations( String id );
> }
>
> fallow my OperationList Interface :
> public interface OperationList {
> public List getOperations();
> public void addOperation(OperationItf operation);
> }
>
> And My OperationItf like this :
> public interface OperationItf {
> public int getAmount();
> public void setAmount(int amount);
> public Date getDate();
> public void setDate(Date date);
> public String getDetails();
> public void setDetails(String details);
> }
>
> I wrote a component implementation :
> public OperationList getOperations( String _ ) {
> DataFactory datafactory = DataFactory.INSTANCE;
> OperationList lst = (OperationList)
> datafactory.create(OperationList.class);
> for (OperationItf operation : operations) { // operations
> is a local field
> OperationItf o = (OperationItf)
> datafactory.create(OperationItf.class);
> o.setAmount( operation.getAmount() );
> o.setDate( operation.getDate() );
> o.setDetails( operation.getDetails() );
> lst.addOperation(o);
> }
> return lst;
> }
>
> Ok, I wrote common files : module.sca and a wsdl file ... nothing
> special in those
> I Deploy this on the tomcat server ...
> I wrote a WebService Client, based on the helloworldwsclient sample,
> launched it ... and crashed :-c
> Error on the server side :
> java.lang.NullPointerException
> at
> org.eclipse.emf.ecore.util.EcoreUtil.create(EcoreUtil.java:2906)
> at
> org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.java:58)
>
> at
> org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.java:52)
>
> at bank.AccountImpl.getOperations(Unknown Source)
>
> It comes from the datafactory create call on my Interface ...
> Seems that no types are registered into the TypeHelper for this
> interface.
>
Yes, you're right. That's the problem here. You need generated SDO
classes, and you need to register them. IMO you should get a nice
exception saying that instead of a NullPointerException... Could you
please create a JIRA issue to report this? our JIRA issues are there:
http://issues.apache.org/jira/browse/TUSCANY.
> Does the loader generate the sdo definition from the wsdl file on
> "remotable" interface ?
> On the bigbank svn version, all the sdo implementations are generated
> (surely from the
> tuscany-sdo-tool ...) Is there a way to generate this on load time ?
>
Currently, we only generate SDO classes and interfaces at
development/build time. Our SDO code generator command line tool
(java/sdo/tools/src/main/java/org/apache/tuscany/sdo/generate/JavaGenerator.java)
takes an XSD or WSDL and generates SDOs for all the XSD complex types.
We have a Maven2 plugin (tuscany-sdo-plugin) that wraps the code
generator, this is what we use to generate SDOs in the Bigbank sample
(see java/samples/bigbank/account/pom.xml).
To get things working now, you can try the following:
- Write an XML schema containing XSD complex types for your
OperationList and OperationItf types. I'm guessing that you probably
already have this schema or a similar one in your Web Service definition.
- Run the JavaGenerator command line tool or (easier) add our
tuscany-sdo-plugin Maven2 plugin to your pom.xml. This should generate
SDO classes and interfaces for OperationList and OperationItf, plus a
Factory interface.
- Register the Factory for your generated SDOs like we do in
java/samples/bigbank/account/src/main/java/org/apache/tuscany/samples/bigbank/account/services/account/AccountServiceImpl.java.
You need to do this before using any of the generated SDOs, this is
temporary until we find a better way to register SDOs with the SDO
runtime...
SDOUtil.registerStaticTypes(YourFactoryInterface.class)
Again, we want to support your scenario with Java interfaces in a first
class way in a near future. Application developers should be able to
develop SCA applications and use SDOs without having to write any WSDL
or XSD. We need to detect the types flowing through service interfaces
and generate SDO implementation classes for them if necessary, at
runtime. Another idea that we've discussed in the past is to use Java 5
annotations to mark Java interfaces and trigger the generation of SDOs.
We have some experimental code under
java/sdo/impl/src/main/java/org/apache/tuscany/sdo/codegen that shows
how to use the ASM library to generate bytecode for skeleton SDO
classes, if you're interested and want to take a look...
Let us know if you have more questions. Please also open JIRA issues if
you run into any problems, and don't hesitate to send us any patches if
you have fixes for them :)
> Thanks for reply, I keep an eye on this dev-list.
> When an user-list is made, I subscribe to it ;-)
> sorry for this hugly english :-p
>
--
Jean-Sebastien