robert burrell donkin wrote:
On 8/10/05, Dennis Sosnoski <[EMAIL PROTECTED]> wrote:
I definitely agree that start-from-Java can be very useful, Robert. I'm
planning to work on adding support for my JiBX data binding framework
(http://www.jibx.org) to Axis2, starting after the next release.
would that be the next Axis2 release or JiBX release?
Next Axis2 release.
I think JiBX is one of the nicest start-from-Java frameworks around, though it's
also being extended to better support start-from-schema.
AIUI JiBX is known primarily as a generative start-from-java binder
(though now i've dug a little, i've found that it also supports
dynamic binding). i had in mind a dynamic approach which is why i
suggested xstream. (JiBX and xstream are - in my mind - third
generation approaches with better architectures more suitable for axis
2 than the second generation ones.)
XStream is an XML serialization framework, while JiBX is XML data
binding. I don't know of any formal definition of the difference between
these two types of frameworks, but the way I'd put it is that XML
serialization generally uses formats that are defined by the
serialization framework itself, while data binding allows the user to
define the XML formats.
SOAP encoding is just a particular serialization format, as is JAX-RPC
1.X doc/lit. If you want to support these formats using reflection you
could use something like XStream as a good base. The drawbacks are
likely to be somewhat poorer performance and limited flexibility (as
seen with Axis 1.X). JiBX would be more useful for people who want
better doc/lit support with a full range of XML structures supported.
i'm convinced that start-from-java is a small but vital part of the
web service ecology and think it's unfortunate the advantages of the
third generation binders are not more widely know. in some ways, i
think it's a small but crucial cog in the axis2 machine: delivering
support for poor schemas and quicker prototyping by java-centric
developers.
I actually don't see this as a small part of the problem, but as a large
part. AFAIK the vast majority of .NET work is being done as
start-from-C# (or VB... shudder). That's not going to be everything -
over time, the move is clearly toward standard schemas for data
exchange, including web services - but it's a large part of why
developers find web services today so much more difficult in Java than
in .NET.
There are other problems lurking in the wings from the standard schemas
approach, too. Schema versioning is not well handled by any of the
existing frameworks that I'm aware of, though JAXB 2.0 is moving in this
direction. Right now the schema-centric frameworks require you to
generate a new set of classes for each version of the schema you want to
support. I don't think that's a practical solution, given the trend
toward industry-wide schemas being updated every year or two. In a way
this becomes a variation of start-from-Java, even if the Java you're
starting from was generated from version 1.0 of the schema and you just
want to work with version 1.1.
do you plan to work on the proposed module here or over sourceforge?
I'm planning to handle this with a JiBX data binding interface that's
part of the Axis2 code (though presumably optional, so that people who
aren't using JiBX don't need it installed). This will need to include
not only runtime support but also client stub generation (which in the
JiBX case will need to generate the binding definition as well as the
actual data classes). I'd think that's what would need to be done for
other data binding frameworks, too.
- Dennis
