Jim Marino wrote:
[snip]
Thanks Frank for answering these questions. I have a few more that
maybe you or others could offer opinions on.
On Mar 24, 2006, at 12:10 PM, Frank Budinsky wrote:
I don't know much about how the sca properties are configured, but I'll
try to answer your questions anyway.
- As a user what steps do I need to take to provide custom data
values for config properties? In a previous post, I listed an example
of a concrete "Foo" class
Option 1)
Provide an XML schema completxType definition for the Type and let the
generator gen the impl including the deserialization support. In the
future, we plan to also let you provide a Java interface (with
annotations, if necessary) to define the type, and then have the
implementation class generated for you.
The SDO generator will essentially generate the same Foo class that you
showed in the other thread, just with the addition of a base class
(DataObjectBase), and some get/set method overrides that implement
efficient switch-based reflective accessors - used by the generic XML
serializer/deserializer. If we also provide an option to generated a
loader, in the future, we could also provide an option to supress the
generation of the reflective accessors. The resulting class would no
longer be an SDO object in this case - but it would be easy to do as a
value-add feature in our generator (i.e., a -generateSimpleBean option).
Option 2)
Write the Foo implementation class yourself (or maybe generate it with
some other technology - like JAXB) and then simply register it as a
DataType with SDO. Remember that not all objects in an SDO model need to
be DataObjects. If you want non-DataObjects, they're modeled as
DataTypes,
and you need to provide create from and convert to String methods for
them.
I think option two is the more appealing one for applications
developers. I read option 1 to require a schema, which we may be able
to do for extensions, but is a bit much to ask application developers
to produce.
Jim, I'd like to initiate a new thread of discussion on property types
and property configuration, because I think that you're bringing up very
good and interesting points here and we're going to have to explore that
space, which is not really covered by the SCA spec at the moment.
I agree with you that option two is much more appealing to (Java)
application developers. If I'm a Java developer writing POJO components
I probably just want to write Java classes for my complex properties, I
don't want to write an XMLSchema at all. On the other hand, if I'm a
BPEL developer, or writing XSLT components for example, chances are that
I'll actually prefer to write an XMLSchema. I think we need to support
both use cases / populations of developers, like we do for service
interfaces with Java interfaces and WSDL portTypes. I'm also starting to
think that this should even be more extensible. Let's say I'm writing a
Javascript component, a C++ component, or a Ruby component - just using
Ruby as an example here, I don't have a Ruby component container in the
back of my pocket :), will I want to define my property types as Java
classes? as XMLSchema types? I'm not sure... I'd probably prefer to use
the same programming language I'm using to implement my component.
So we have a lot to explore here, and I think that all these questions
are really about finding the right programming model for defining and
configuring properties of SCA components written in various languages.
We also need to add another dimension to that. First we have to deal
with the Java developer, the BPEL developer, the XSLT developer, the
JavaScript developer etc. then we also have to deal with different data
representations and binding technologies. For some languages, like BPEL
for example, the data representation will probably be driven by what
your BPEL engine expects, or for JavaScript what your JavaScript
runtime/VM expects. For Java, we have multiple choices. Some people will
want to use plain JavaBeans, others JAXB, others SDO, others ADB or
XMLBeans etc. So again here, without even going into any implementation
details of how to glue all these technologies together (and independent
of whether or not we use our SDO databinding to load our SCDL files), we
need to define how an SCA application developer, using Tuscany, will
specify what form he wants for his properties...
Now back to the reality of the SCA 0.9 spec :) It currently only defines
support for simple type properties and requires the type of a property
to be expressed as an XML schema type. The <property> element is defined
as follows: <property name="xs:NCName" type="xs:QName"
many="xs:boolean"? default="xs:string"? required="xs:boolean"?/>* where
xs:QName is the qualified name of an XML schema simple type.
Obviously we need to improve this, and maybe we can even provide some
input into the spec with the work we are doing in Tuscany:
- first define what it means to support complex type properties (what
types are allowed? what about special Java collection types, can you
have pointers between properties etc.)
- decide if we want to use a type system that is independent of a
component implementation language, or tie the types of properties to the
component implementation language
- cover the scenario you first brought up where you just want Java
classes and no schema at all
- cover the scenarios where you just want to use XML schemas
- define how an application developer chooses a databinding/representation
- define what happens when an application developer decides to mix in a
single application multiple databinding technologies (or if that even
makes sense at all...)
I'm probably missing many more questions/items here :) I just wanted to
initiate this discussion which I think is important. Any thoughts?
--
Jean-Sebastien
