On Mar 24, 2006, at 4:21 PM, Jean-Sebastien Delfino wrote:
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...
I'm wondering if now if the question isn't a choice between Jeremy's
approach and going with SDO ( or some other binding technology. Since
we will need maximum extensibility to handle all of these different
component types, It seems to me what we need is a "low-level" binding
infrastructure that things like JAXB or SDO can plug into. Another
way to view this would be the low-level infrastructure delegates to
other binding technologies, which would allow us to support multiple
binding solutions as opposed to just one at a time. This low-level
infrastructure would be responsible for partially parsing the XML and
delegating to a factories if necessary to instantiate property
instances. I think this would allow for *multiple* binding frameworks
as opposed to just one. Jeremy, do you think this is feesible and if
so could you provide a sketch of how this would look in code?
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.
Yes, this was an area left for further work due to time constraints.
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:
Yea, we definitely need to improve since that level of support is
kind of lame.
- 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
My opinion here is we want to go the language-specific route since we
need to make working with properties natural to the implementation
language. I think the most important goal of property configuration
is to configuration points of variability on a specific
implementation, not as a general representation of configuration data.
- 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
Jeremy, could you provide an outline of how the StAX work could
enable this?
- 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 think that makes sense based on the use case you brought up, e.g. a
Java component that takes POJOs and a BPEL engine that only
understands SDO.
I'm probably missing many more questions/items here :) I just
wanted to initiate this discussion which I think is important. Any
thoughts?
This is good - I think we're hammering out some important things even
if the discussion gets heated at times :-)
--
Jean-Sebastien
