On Mar 28, 2006, at 7:20 AM, Jean-Sebastien Delfino wrote:
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.
O.K. sorry I couldn't help myself. Can't we take the list of
requirements last updated by Jeremy and fold the items you outlined
here into them, changing the subject to the current? I'm happy to do
that if it works for you. I kind of think the two discussions are
intertwined since the StAX vs. SDO is an issue related to how the
requirements should be implemented. I was trying to suggest the
following:
- We must support a simple, easy bottom up extensibility story that
feels natural in whatever implementation *major* language/programming
model people are using.
- We also need to support a top-down approach. My opinion is the
buttom up approach is more important given our user base but I don't
think we should debate that.
- The most realistic way it seems to me that we can be successful in
achieving support for such varied use cases is we have a "binding
infrastructure" that is extremely open and not tied to a particular
binding technology. I realize we need to go through the use cases in
more detail before we arrive at this conclusion but I figured it
would be useful to state prejudices up front
- Jeremy's StAX approach may provide this for us, with the ability to
"layer" a variety of binding technologies on top. I definitely don't
think we should conclude this yet. My intention was to point
out that we shouldn't necessarily presume it is StAX *vs.* SDO.
Anyway, do you want me to fold these into a requirements list?
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
