Jim Marino wrote:
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?
I was explicitly trying to create a different thread of discussion here,
on a different level. IMHO both the SDO based approach and Jeremy's StAX
approach can be made extensible and support pluggable databindings and
pluggable factories for properties. But again I was trying to initiate a
discussion of the actual scenarios for using properties and requirements
at the programming model level. The SDO vs StAX discussion is an
interesting discussion, but a different one, and I'd prefer to continue
it in its own thread, not this one.
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.
Yes, I agree with you for some use cases. If I'm going to write a
component in language X, I'd like to define my property types in the
same language X. On the other hand I can see other use cases (e.g. top
down scenarios) where I'm going to define a component type without
caring or even knowing about how it's going to be implemented. I'm not
sure which implementation neutral form/language I'll want to use to
define the component properties. Will I use XMLSchema? Any thoughts?
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
--
Jean-Sebastien
