You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2007/11/14 00:18:12 UTC

How to write a simple SDO class for the tutorial?

The online store tutorial currently uses a simple handwritten JavaBean 
to represent the Items in the store catalog and shopping cart. I'm able 
to flow that Item bean over local calls, WS, Atom and JSON bindings.

Here's what it looks like:
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/tutorial/assets/services/Item.java
Note: the "implements Serializable" is a work around and should be 
eventually removed.

If I want to start using SDO in the tutorial, make that Item an SDO and 
write it by hand (with my user hat on, I'm going to assume that I don't 
know what XSD is about), what is the minimum code that I need to write?

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: How to write a simple SDO class for the tutorial?

Posted by Jean-Sebastien Delfino <js...@apache.org>.
kelvin goodson wrote:
> Sebastien,
> 
> There's the basis of a Java interface to SDO generator at [1] but it
> hasn't been developed to a working state and hasn't been looked since
> the initial drop of code into Tuscany.  It would be great to get this
> or similar function up and running.
> 
> If you take a look at the noInterfaces test [2] of the toolsTest
> project you'll see that we don't need interfaces,  we can use classes.
> 
> I think in the scenario that you paint it's just abut possible you may
> just about be able to get away without a factory.  As evidence I
> changes the referenced sample [2] to have
> 
> //com.example.noInterfaces.simple.Quote quote =
> //(com.example.noInterfaces.simple.Quote)scope.getDataFactory().create(com.example.noInterfaces.simple.Quote.class);
>       com.example.noInterfaces.simple.Quote quote = new Quote();
> 
> and the test passed.  But this wouldn't be acceptable in general.  The
> major showstopper that occurs to me instantly is having a Type that
> has a Property of a generated Type. so the call to
> 
> myComplexType.createDataObject("myPropertyOfGeneratedType");
> 
> must have a means to create a child DataObject using the generated
> class rather than the generic DataObject. It does this by maintaining
> an association with the Type of the Property and the associated
> Factory.


If the Type already has an association with the corresponding class (and 
I think it does if the DataObject is represented by a class and not an 
interface) then again we would not need the factory, 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: How to write a simple SDO class for the tutorial?

Posted by kelvin goodson <ke...@thegoodsons.org.uk>.
Sebastien,

There's the basis of a Java interface to SDO generator at [1] but it
hasn't been developed to a working state and hasn't been looked since
the initial drop of code into Tuscany.  It would be great to get this
or similar function up and running.

If you take a look at the noInterfaces test [2] of the toolsTest
project you'll see that we don't need interfaces,  we can use classes.

I think in the scenario that you paint it's just abut possible you may
just about be able to get away without a factory.  As evidence I
changes the referenced sample [2] to have

//com.example.noInterfaces.simple.Quote quote =
//(com.example.noInterfaces.simple.Quote)scope.getDataFactory().create(com.example.noInterfaces.simple.Quote.class);
      com.example.noInterfaces.simple.Quote quote = new Quote();

and the test passed.  But this wouldn't be acceptable in general.  The
major showstopper that occurs to me instantly is having a Type that
has a Property of a generated Type. so the call to

myComplexType.createDataObject("myPropertyOfGeneratedType");

must have a means to create a child DataObject using the generated
class rather than the generic DataObject. It does this by maintaining
an association with the Type of the Property and the associated
Factory.

Regards, Kelvin.


[1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/tools/src/main/java/org/apache/tuscany/sdo/generate/Interface2JavaGenerator.java

[2] http://svn.apache.org/viewvc/incubator/tuscany/java/sdo/tools-test/src/test/java/org/apache/tuscany/sdo/test/GenPatternsTestCase.java?view=markup


On 17/11/2007, Jean-Sebastien Delfino <js...@apache.org> wrote:
> kelvin goodson wrote:
> > If you are discounting using XSD for the source of metadata to
> > describe the SDO types then there is the SDO API provided for dynamic
> > metadata creation.  The sample at [1] gives an introduction to this.
> > The paper at [2] discusses the subject also, and the program
> > underlying the discussion in the paper is at [3] (no change
> > monitoring) and [4] (with change monitoring).
> >
> > You say that you want to write the minimum code.  There is a quick and
> > simple Tuscany API for simple cases that you could use instead (See
> > the MetaDataBuilder inner class in [5]).  Whilst the code to create
> > the type system with this project specific API is simple to understand
> > and implement it has some drawbacks.  We don't have a sample program
> > for this,  but I believe the DAS uses it) I'm happy to discuss further
> > if you want some more insight into this.
> >
> > Kelvin.
> >
> >
> > [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/intermediate/DynamicCustomerTypeSample.java
> > [2] http://java.sys-con.com/read/358059_2.htm
> > [3] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenario.java
> > [4] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenarioWithChangeMonitoring.java
> > [5] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/lib/src/main/java/org/apache/tuscany/sdo/api/SDOHelper.java
> >
> >
> Thanks.
>
> Follow-up questions:
>
> - Is there an SDO Helper that can introspect my handwritten Item Java
> class and drive the calls to the TypeHelper APIs? If not, can I add one?
>
> - I see that I can associate a class with a type, does it have to be an
> interface or can it be a class?
>
> - If it can be a class do I really need a factory class or is the SDO
> runtime able to instantiate the class?
>
> - I see methods like getStaticType on generated SDOs, do I need to
> implement that method in my handwritten SDO and why?
>
> --
> 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: How to write a simple SDO class for the tutorial?

Posted by Frank Budinsky <fr...@ca.ibm.com>.
Sebastien,

You're generic implementation is fine as long as TypeHelper.INSTANCE is 
the right scope where the type is registered.

If you aren't interested in supporting dynamic subclasses of static 
classes, then getStaticType() is always == DataObject.getType(), so you 
might not even need to implement getStaticType().

Frank




Jean-Sebastien Delfino <js...@apache.org> 
11/19/2007 11:25 AM
Please respond to
tuscany-dev@ws.apache.org


To
tuscany-dev@ws.apache.org
cc

Subject
Re: How to write a simple SDO class for the tutorial?






kelvin goodson wrote:
> I missed you last point in my reply.  getStaticType() is required to
> underpin fundamental EMF behaviour.  Without it EMF's capacity to know
> the class of an EObject (which all our DataObjects are derived from)
> is broken for all static classes,  and that would break many SDO
> behaviours, e.g. serialization, copying,  and I'm sure lots more.
> 
> Kelvin.
> 

Assuming that my DataObjects are simple classes without interfaces, 
isn't the type already registered with my DataObject's class?

In other words can I implement getStaticType generically as follows:

Type getStaticType() {
                 TypeHelper.INSTANCE.getType(this.getClass());
}

-- 
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: How to write a simple SDO class for the tutorial?

Posted by Jean-Sebastien Delfino <js...@apache.org>.
kelvin goodson wrote:
> I missed you last point in my reply.  getStaticType() is required to
> underpin fundamental EMF behaviour.  Without it EMF's capacity to know
> the class of an EObject (which all our DataObjects are derived from)
> is broken for all static classes,  and that would break many SDO
> behaviours, e.g. serialization, copying,  and I'm sure lots more.
> 
> Kelvin.
> 

Assuming that my DataObjects are simple classes without interfaces, 
isn't the type already registered with my DataObject's class?

In other words can I implement getStaticType generically as follows:

Type getStaticType() {
	TypeHelper.INSTANCE.getType(this.getClass());
}

-- 
Jean-Sebastien

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


Re: How to write a simple SDO class for the tutorial?

Posted by Frank Budinsky <fr...@ca.ibm.com>.
Hi Sebastien,

One thing to note is that the static SDO supported in Tuscany today is an 
EMF-style pattern that is intended to be the highest performance in-memory 
static DataObjects. Other less-performant patterns, that use a dynamic 
(DataObject) proxy, for example, are possible and probably easier achieve 
without a code generator. There are two features in the SDO 3 charter 
related to this topic: 1) standard SDO annotations on Java interfaces to 
define SDO metadata, and 2) unify static SDO with other static bindings 
like JAXB (this covers POJOs as well). If you want to experiment with some 
ideas in this area, that would be great. We could use it as input to the 
SDO 3 discussions when they start.

Thanks,
Frank.

kelvingoodson@gmail.com wrote on 11/19/2007 05:53:25 AM:

> I missed you last point in my reply.  getStaticType() is required to
> underpin fundamental EMF behaviour.  Without it EMF's capacity to know
> the class of an EObject (which all our DataObjects are derived from)
> is broken for all static classes,  and that would break many SDO
> behaviours, e.g. serialization, copying,  and I'm sure lots more.
> 
> Kelvin.
> 
> On 17/11/2007, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > kelvin goodson wrote:
> > > If you are discounting using XSD for the source of metadata to
> > > describe the SDO types then there is the SDO API provided for 
dynamic
> > > metadata creation.  The sample at [1] gives an introduction to this.
> > > The paper at [2] discusses the subject also, and the program
> > > underlying the discussion in the paper is at [3] (no change
> > > monitoring) and [4] (with change monitoring).
> > >
> > > You say that you want to write the minimum code.  There is a quick 
and
> > > simple Tuscany API for simple cases that you could use instead (See
> > > the MetaDataBuilder inner class in [5]).  Whilst the code to create
> > > the type system with this project specific API is simple to 
understand
> > > and implement it has some drawbacks.  We don't have a sample program
> > > for this,  but I believe the DAS uses it) I'm happy to discuss 
further
> > > if you want some more insight into this.
> > >
> > > Kelvin.
> > >
> > >
> > > [1] http://svn.apache.
> 
org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/intermediate/DynamicCustomerTypeSample.
> java
> > > [2] http://java.sys-con.com/read/358059_2.htm
> > > [3] http://svn.apache.
> 
org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenario.
> java
> > > [4] http://svn.apache.
> 
org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenarioWithChangeMonitoring.
> java
> > > [5] http://svn.apache.
> 
org/repos/asf/incubator/tuscany/java/sdo/lib/src/main/java/org/apache/tuscany/sdo/api/SDOHelper.
> java
> > >
> > >
> > Thanks.
> >
> > Follow-up questions:
> >
> > - Is there an SDO Helper that can introspect my handwritten Item Java
> > class and drive the calls to the TypeHelper APIs? If not, can I add 
one?
> >
> > - I see that I can associate a class with a type, does it have to be 
an
> > interface or can it be a class?
> >
> > - If it can be a class do I really need a factory class or is the SDO
> > runtime able to instantiate the class?
> >
> > - I see methods like getStaticType on generated SDOs, do I need to
> > implement that method in my handwritten SDO and why?
> >
> > --
> > 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: How to write a simple SDO class for the tutorial?

Posted by kelvin goodson <ke...@thegoodsons.org.uk>.
I missed you last point in my reply.  getStaticType() is required to
underpin fundamental EMF behaviour.  Without it EMF's capacity to know
the class of an EObject (which all our DataObjects are derived from)
is broken for all static classes,  and that would break many SDO
behaviours, e.g. serialization, copying,  and I'm sure lots more.

Kelvin.

On 17/11/2007, Jean-Sebastien Delfino <js...@apache.org> wrote:
> kelvin goodson wrote:
> > If you are discounting using XSD for the source of metadata to
> > describe the SDO types then there is the SDO API provided for dynamic
> > metadata creation.  The sample at [1] gives an introduction to this.
> > The paper at [2] discusses the subject also, and the program
> > underlying the discussion in the paper is at [3] (no change
> > monitoring) and [4] (with change monitoring).
> >
> > You say that you want to write the minimum code.  There is a quick and
> > simple Tuscany API for simple cases that you could use instead (See
> > the MetaDataBuilder inner class in [5]).  Whilst the code to create
> > the type system with this project specific API is simple to understand
> > and implement it has some drawbacks.  We don't have a sample program
> > for this,  but I believe the DAS uses it) I'm happy to discuss further
> > if you want some more insight into this.
> >
> > Kelvin.
> >
> >
> > [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/intermediate/DynamicCustomerTypeSample.java
> > [2] http://java.sys-con.com/read/358059_2.htm
> > [3] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenario.java
> > [4] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenarioWithChangeMonitoring.java
> > [5] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/lib/src/main/java/org/apache/tuscany/sdo/api/SDOHelper.java
> >
> >
> Thanks.
>
> Follow-up questions:
>
> - Is there an SDO Helper that can introspect my handwritten Item Java
> class and drive the calls to the TypeHelper APIs? If not, can I add one?
>
> - I see that I can associate a class with a type, does it have to be an
> interface or can it be a class?
>
> - If it can be a class do I really need a factory class or is the SDO
> runtime able to instantiate the class?
>
> - I see methods like getStaticType on generated SDOs, do I need to
> implement that method in my handwritten SDO and why?
>
> --
> 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: How to write a simple SDO class for the tutorial?

Posted by Jean-Sebastien Delfino <js...@apache.org>.
kelvin goodson wrote:
> If you are discounting using XSD for the source of metadata to
> describe the SDO types then there is the SDO API provided for dynamic
> metadata creation.  The sample at [1] gives an introduction to this.
> The paper at [2] discusses the subject also, and the program
> underlying the discussion in the paper is at [3] (no change
> monitoring) and [4] (with change monitoring).
>
> You say that you want to write the minimum code.  There is a quick and
> simple Tuscany API for simple cases that you could use instead (See
> the MetaDataBuilder inner class in [5]).  Whilst the code to create
> the type system with this project specific API is simple to understand
> and implement it has some drawbacks.  We don't have a sample program
> for this,  but I believe the DAS uses it) I'm happy to discuss further
> if you want some more insight into this.
>
> Kelvin.
>
>
> [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/intermediate/DynamicCustomerTypeSample.java
> [2] http://java.sys-con.com/read/358059_2.htm
> [3] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenario.java
> [4] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenarioWithChangeMonitoring.java
> [5] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/lib/src/main/java/org/apache/tuscany/sdo/api/SDOHelper.java
>
>   
Thanks.

Follow-up questions:

- Is there an SDO Helper that can introspect my handwritten Item Java 
class and drive the calls to the TypeHelper APIs? If not, can I add one?

- I see that I can associate a class with a type, does it have to be an 
interface or can it be a class?

- If it can be a class do I really need a factory class or is the SDO 
runtime able to instantiate the class?

- I see methods like getStaticType on generated SDOs, do I need to 
implement that method in my handwritten SDO and why?

-- 
Jean-Sebastien


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


Re: How to write a simple SDO class for the tutorial?

Posted by kelvin goodson <ke...@thegoodsons.org.uk>.
If you are discounting using XSD for the source of metadata to
describe the SDO types then there is the SDO API provided for dynamic
metadata creation.  The sample at [1] gives an introduction to this.
The paper at [2] discusses the subject also, and the program
underlying the discussion in the paper is at [3] (no change
monitoring) and [4] (with change monitoring).

You say that you want to write the minimum code.  There is a quick and
simple Tuscany API for simple cases that you could use instead (See
the MetaDataBuilder inner class in [5]).  Whilst the code to create
the type system with this project specific API is simple to understand
and implement it has some drawbacks.  We don't have a sample program
for this,  but I believe the DAS uses it) I'm happy to discuss further
if you want some more insight into this.

Kelvin.


[1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/intermediate/DynamicCustomerTypeSample.java
[2] http://java.sys-con.com/read/358059_2.htm
[3] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenario.java
[4] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenarioWithChangeMonitoring.java
[5] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/lib/src/main/java/org/apache/tuscany/sdo/api/SDOHelper.java

On 13/11/2007, Jean-Sebastien Delfino <js...@apache.org> wrote:
> The online store tutorial currently uses a simple handwritten JavaBean
> to represent the Items in the store catalog and shopping cart. I'm able
> to flow that Item bean over local calls, WS, Atom and JSON bindings.
>
> Here's what it looks like:
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/tutorial/assets/services/Item.java
> Note: the "implements Serializable" is a work around and should be
> eventually removed.
>
> If I want to start using SDO in the tutorial, make that Item an SDO and
> write it by hand (with my user hat on, I'm going to assume that I don't
> know what XSD is about), what is the minimum code that I need to write?
>
> Thanks
>
> --
> 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