You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by robert burrell donkin <ro...@gmail.com> on 2005/08/08 23:19:21 UTC
[axis2] simple data binder
IIRC at ApacheCon (good talk BTW Ajith) a question were raised (from
the audience) about compatibility with the older axis 1 databinding. i
believe that the reply was that the plan would be to create a new
simple binding framework.
i was wondering whether this has already been created and if the
intention was to make it similar to the BeanSerializer in axis1. (or
whether i'd got it all mixed up...)
- robert
Re: AXIS volunteer
Posted by Davanum Srinivas <da...@gmail.com>.
See http://marc.theaimsgroup.com/?l=axis-dev&m=112249301129363&w=2 for
more information and links.
-- dims
On 8/12/05, Venkat Reddy <vr...@gmail.com> wrote:
> You can start contributing your code right away by creating a new
> issue at http://issues.apache.org/jira/browse/AXIS. Someone will
> review and apply your patches.
>
> - venkat
>
>
> On 8/12/05, janarbek <ca...@yahoo.com> wrote:
> >
> >
> > Dear AXIS developers? I am wondering about AXIS project? Can I be a AXIS
> > developer? stupid question -_-. I mean how can I volunter ? How can I submit
> > my sources, patches..?
> >
> >
> >
> > Thanks you
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Do what you can, for who you can,
> > with what you have, and where you are
> > South Korea.Seoul.
> > Janarbek Matay
> > Tel:82-10-3141-5857
> > mail:canarbekmatay@yahoo.com
> > janarbek@hotmail.com
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
>
--
Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
Re: AXIS volunteer
Posted by Venkat Reddy <vr...@gmail.com>.
You can start contributing your code right away by creating a new
issue at http://issues.apache.org/jira/browse/AXIS. Someone will
review and apply your patches.
- venkat
On 8/12/05, janarbek <ca...@yahoo.com> wrote:
>
>
> Dear AXIS developers? I am wondering about AXIS project? Can I be a AXIS
> developer? stupid question -_-. I mean how can I volunter ? How can I submit
> my sources, patches..?
>
>
>
> Thanks you
>
>
>
>
>
>
>
>
>
> Do what you can, for who you can,
> with what you have, and where you are
> South Korea.Seoul.
> Janarbek Matay
> Tel:82-10-3141-5857
> mail:canarbekmatay@yahoo.com
> janarbek@hotmail.com
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
Re: [axis2] simple data binder
Posted by robert burrell donkin <ro...@gmail.com>.
On 8/17/05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> robert burrell donkin wrote:
>
> >
> >how's JiBX's schema generation?
> >
> >
> Decent, within the limits of both JiBX bindings and schema.
cool :)
> But schema
> is such a horrible, convoluted, mess that it's really difficult to try
> to establish complete equivalences between it and general Java code. The
> frameworks that come closest to full schema support, such as XMLBeans,
> do so by building Java code that's specifically designed to match schema
> constructs and even then fall short in some areas (substitution groups
> in the XMLBeans case, for instance).
yep
but i'm not sure that support for the full schema infoset should
actually be a goal for start-from-java. IMHO it's more important to be
able to produce good mappings from java to a limited subset of schema
concepts.
> On the other hand, most forms of JiBX binding definitions have schema
> equivalents, and most forms of schema constructs have JiBX equivalents.
> I've already got a sort of active model of the JiBX binding definition
> that provides the binding validation support (validates the actual
> binding XML structure, makes sure that referenced classes and methods
> are available, checks for type conflicts, etc.). I've been working on a
> similar representation for schema so that I can improve the code that
> goes code+binding -> schema, and also provide better
> schema->code+binding support. My expectation is that if I can tie these
> together I'll be able to support fast consistency checking that'll allow
> highlighting of problems in IDEs and even suggested fixes.
sounds good
- robert
Re: [axis2] simple data binder
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
robert burrell donkin wrote:
>
>how's JiBX's schema generation?
>
>
Decent, within the limits of both JiBX bindings and schema. But schema
is such a horrible, convoluted, mess that it's really difficult to try
to establish complete equivalences between it and general Java code. The
frameworks that come closest to full schema support, such as XMLBeans,
do so by building Java code that's specifically designed to match schema
constructs and even then fall short in some areas (substitution groups
in the XMLBeans case, for instance).
On the other hand, most forms of JiBX binding definitions have schema
equivalents, and most forms of schema constructs have JiBX equivalents.
I've already got a sort of active model of the JiBX binding definition
that provides the binding validation support (validates the actual
binding XML structure, makes sure that referenced classes and methods
are available, checks for type conflicts, etc.). I've been working on a
similar representation for schema so that I can improve the code that
goes code+binding -> schema, and also provide better
schema->code+binding support. My expectation is that if I can tie these
together I'll be able to support fast consistency checking that'll allow
highlighting of problems in IDEs and even suggested fixes.
- Dennis
Re: [axis2] simple data binder
Posted by robert burrell donkin <ro...@gmail.com>.
On 8/11/05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> robert burrell donkin wrote:
>
> >On 8/10/05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
<snip>
> >>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.
i know xstream describes itself as a serializer but i've been thinking
a lot recently about fusion and commonalities between the various
kinds of binders. i really think that xstream is a data binder but
pretty much at one end of the expressiveness spectrum. (maybe this is
why i also know of no good way to formally definite the difference.)
users have some control over the xml formats generated by xstream but
this is limited in it's expressiveness.
users expect start-from-java to guess well. it's easy to guess well
for beans and regular bean-like objects but there a lot of common
objects which are just odd. after working for a long time on a binder
at the other end of the expressiveness spectrum from xstream, i've
come to the conclusion that in some ways, good guessing for many
common objects is going to require a lot of reasonably fixed mappings
provided by the binder.
i think that for start-from-java to really progress, we're going to
need to see more fusion combining work from different binders with
different strengths rather than working on functionality in parrellel.
IMHO the problem's just too big...
> 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've been wondering recently whether these couldn't be done
effectively as configuration sets for expressive binders. (take an
expressive binder and do all the work required to process easily a
particular set of objects.)
> >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.
i was trying to avoid being too argumentative (which is a little
unlike me, i know ;)
> 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.
+1
> 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.
+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.
how's JiBX's schema generation?
- robert
Re: [axis2] simple data binder
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Copying this to jibx-user, where we really should continue the
discussion if you'd like to go further.
Dan Diephouse wrote:
> Dennis Sosnoski wrote:
>
>> Dan Diephouse wrote:
>>
>>> Dennis Sosnoski wrote:
>>>
>>> ...
>>>
>>>>
>>>>
>>>> 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.
>>>>
>>> I totally agree on the schema-> is very similar to the start from
>>> java case. In each case you're still using a DTO pattern. What do
>>> you see as alternatives to this approach?
>>
>>
>>
>> The only alternative I know of is some form of mapped binding, where
>> you use a binding definition to establish the relationships between
>> your Java classes and XML. In the case of JiBX you can use multiple
>> binding definitions with the same Java classes, so you're able to
>> reuse your existing classes for different schema versions. That
>> doesn't mean the classes don't have to change at all - you'd still
>> need to add fields or new classes for new components from the schema
>> - but you should be able to continue using the modified classes with
>> different versions of the schema, selecting at runtime which binding
>> to use for a particular input document.
>>
> I knew JiBX had some of that capability. This may be a bit off topic,
> but take this example: at first I'm receiving an xsd:double
> representing a price, then I create a complex type which holds both
> the amount and the currency units. Can JiBX take my xsd:double, create
> a new price class with the default currency unit instead of just
> passing me a double?
I can think of at least three simple ways of handling this using JiBX.
Here's your original case:
<price>12.99</price> <-> private float m_price;
Binding: <value name="price" field="m_price"/>
Here's the expanded version:
<price units="USD">12.99</price> <-> private CurrencyAmount m_price;
public class CurrencyAmount {
private String m_units;
private float m_amount;
...
}
Binding: <structure name="price" field="m_price">
<value name="units" style="attribute" field="m_units"/>
<value style="text" field="m_amount"/>
</structure>
You could (1) set the default currency unit directly in the
CurrencyAmount constructor, then just use normal JiBX binding features
for everything. This would change your binding for the old-style
documents to (as the clearest alternative):
Binding: <structure field="m_price">
<value name="price" field="m_amount"/>
</structure>
(2) you could use a factory method for the first case which just sets
the default currency. This would be along the lines of:
public class CurrencyAmount {
...
public static CurrencyAmount newDefaultInstance() {
CurrencyAmount inst = new CurrencyAmount();
inst.m_units = "USD";
return inst;
}
}
Binding: <structure field="m_price"
factory="CurrencyAmount.newDefaultInstance">
<value name="price" field="m_amount"/>
</structure>
(3) you could just use the new binding for old documents as well, making
the units attribute optional but defaulting to your old assumed value:
Binding: <structure name="price" field="m_price">
<value name="units" style="attribute" field="m_units"
usage="optional" default="USD"/>
<value style="text" field="m_amount"/>
</structure>
>
> TIBCO did a cool thing which allowed you to map arbitrary classes to
> arbitrary schema elements that I saw here (watch the screencast, ~5
> minutes in):
>
> http://weblog.infoworld.com/udell/2005/05/25.html
>
> I don't know if others are, but I'd be interested in putting together
> some sort of object/schema relationship designer that allowed you to
> specify these relationships easily.
Doesn't play for me, but sounds like the type of thing I'd love to have
work with JiBX. Want to join the JiBX project?
- Dennis
Re: [axis2] simple data binder
Posted by Dan Diephouse <da...@envoisolutions.com>.
Dennis Sosnoski wrote:
> Dan Diephouse wrote:
>
>> Dennis Sosnoski wrote:
>>
>> ...
>>
>>>
>>>
>>> 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.
>>>
>> I totally agree on the schema-> is very similar to the start from
>> java case. In each case you're still using a DTO pattern. What do you
>> see as alternatives to this approach?
>
>
> The only alternative I know of is some form of mapped binding, where
> you use a binding definition to establish the relationships between
> your Java classes and XML. In the case of JiBX you can use multiple
> binding definitions with the same Java classes, so you're able to
> reuse your existing classes for different schema versions. That
> doesn't mean the classes don't have to change at all - you'd still
> need to add fields or new classes for new components from the schema -
> but you should be able to continue using the modified classes with
> different versions of the schema, selecting at runtime which binding
> to use for a particular input document.
>
I knew JiBX had some of that capability. This may be a bit off topic,
but take this example: at first I'm receiving an xsd:double representing
a price, then I create a complex type which holds both the amount and
the currency units. Can JiBX take my xsd:double, create a new price
class with the default currency unit instead of just passing me a double?
TIBCO did a cool thing which allowed you to map arbitrary classes to
arbitrary schema elements that I saw here (watch the screencast, ~5
minutes in):
http://weblog.infoworld.com/udell/2005/05/25.html
I don't know if others are, but I'd be interested in putting together
some sort of object/schema relationship designer that allowed you to
specify these relationships easily.
>>
>> Personally, I like to be able to change and extend my schemas more
>> than once every year or two. Creating a seperate set of DTOs each
>> time poses a lot of maintenance costs. As does simply parsing the XML
>> by hand. As does transforming inputs and outputs to a new version.
>> Companies like EBay and Amazon manage to change their schemas like
>> every month. I wonder if they have any unique strategies they've
>> worked out.
>
>
> I'm actually teaching a web services class for some Amazon personnel
> right now - I'll have to ask if they can tell me what they're actually
> doing on the backend web service implementation. I haven't followed
> their schema evolution in detail, but I think they're trying to
> minimize update problems for developers between versions of the
> schema. The downside of this is that they're stuck with a horribly
> cluttered and ugly schema for their web service support, but cleaning
> it up would thoroughly break every piece of code that uses their web
> service. The current class assignment is using Axis to build a client
> for their own web service, so maybe that'll add some impetus for
> change within the company. ;-)
>
Nice :-). Let me know how that goes.
Cheers,
- Dan
--
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com
Re: [axis2] simple data binder
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Dan Diephouse wrote:
> Dennis Sosnoski wrote:
>
> ...
>
>>
>>
>> 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.
>>
> I totally agree on the schema-> is very similar to the start from java
> case. In each case you're still using a DTO pattern. What do you see
> as alternatives to this approach?
The only alternative I know of is some form of mapped binding, where you
use a binding definition to establish the relationships between your
Java classes and XML. In the case of JiBX you can use multiple binding
definitions with the same Java classes, so you're able to reuse your
existing classes for different schema versions. That doesn't mean the
classes don't have to change at all - you'd still need to add fields or
new classes for new components from the schema - but you should be able
to continue using the modified classes with different versions of the
schema, selecting at runtime which binding to use for a particular input
document.
>
> Personally, I like to be able to change and extend my schemas more
> than once every year or two. Creating a seperate set of DTOs each time
> poses a lot of maintenance costs. As does simply parsing the XML by
> hand. As does transforming inputs and outputs to a new version.
> Companies like EBay and Amazon manage to change their schemas like
> every month. I wonder if they have any unique strategies they've
> worked out.
I'm actually teaching a web services class for some Amazon personnel
right now - I'll have to ask if they can tell me what they're actually
doing on the backend web service implementation. I haven't followed
their schema evolution in detail, but I think they're trying to minimize
update problems for developers between versions of the schema. The
downside of this is that they're stuck with a horribly cluttered and
ugly schema for their web service support, but cleaning it up would
thoroughly break every piece of code that uses their web service. The
current class assignment is using Axis to build a client for their own
web service, so maybe that'll add some impetus for change within the
company. ;-)
- Dennis
Re: [axis2] simple data binder
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi all,
Perhaps I'm jumping into the middle of a serious conversation but I'm also a
fan of the start-from-code club. contract based approach (start-from-schema)
is cool but my guess is programmers find it much easier to use the start
from code approach. You'll rather get the picture much clearly by looking at
the method signature than the WSDL Operation!
As for the tools, I definitely agree that a good graphical tool set is
missing. I'm sure that some of you guys will not agree with me (:)) but a
lot of users find a good graphical tool appealing than a command line one
(Well I do :)). A good example is Visual Studio, which probably has one of
the best user interfaces for the developer. Actually if Msft stays ahead
it's mostly because of their tools, rather than the technology :)
So here is what I'm getting into. Since we need a good tool set, why don't
we make it a part of Axis2? For starters we can think of at least the
following tools
1. Start-from-WSDL tool (We already have a partly functioning Eclipse
plugin)
2. Start-from-java tool (The plans are for an annotated source file thingy)
Even if we introduce complex functionality, tools can hide that complexity
and make things easier for the user. My guess is we should think a bit more
seriously about the tooling at this point. After all, we'll be facing
competion from Msft in the real world.
any thoughts guys ?
--
Ajith Ranabahu
Re: [axis2] simple data binder
Posted by robert burrell donkin <ro...@gmail.com>.
On 8/12/05, Venkat Reddy <vr...@gmail.com> wrote:
> On 8/11/05, Dan Diephouse <da...@envoisolutions.com> wrote:
> > Personally, I like to be able to change and extend my schemas more than
> > once every year or two. Creating a seperate set of DTOs each time poses
> > a lot of maintenance costs. As does simply parsing the XML by hand. As
> > does transforming inputs and outputs to a new version. Companies like
> > EBay and Amazon manage to change their schemas like every month. I
> > wonder if they have any unique strategies they've worked out.
> >
>
> I'm not here to comment on the main discussion, but it appears to me
> that part of the problem here is the difficulty to work with or
> maintain schemas and update the associated java code. With better
> graphical tooling support for managing schemas and update the linked
> java code, maybe this problem might go away? Would start-from-java
> still be attractive then?
if you're writing a pure web service with no interaction with existing
code then start-from-schema works very nicely. the sweet spot for
start-from-java is for use cases where there the web service is
integrated into a large system with extensive reuse.
the heart of these systems are typical a load of objects (typically
POJOs). it can be difficult to reuse objecs generated from schema.
it's therefore usual to employ a translation phase between the
generated object model and the object model used by the core system
when using start-from-schema. this code needs to be recoded when the
schema changes. i'm not sure whether this translation phase could be
effectively automated.
IMHO one of the missing links in start-from-java is the absence of
good graphic tools sets. given a good graphical tool, it would be
possible just to alter the mapping between the schema and the object
model when using start-from-java when the schema changes. much easier
and quicker than start-from-schema.
- robert
Re: [axis2] simple data binder
Posted by Venkat Reddy <vr...@gmail.com>.
On 8/11/05, Dan Diephouse <da...@envoisolutions.com> wrote:
> Personally, I like to be able to change and extend my schemas more than
> once every year or two. Creating a seperate set of DTOs each time poses
> a lot of maintenance costs. As does simply parsing the XML by hand. As
> does transforming inputs and outputs to a new version. Companies like
> EBay and Amazon manage to change their schemas like every month. I
> wonder if they have any unique strategies they've worked out.
>
I'm not here to comment on the main discussion, but it appears to me
that part of the problem here is the difficulty to work with or
maintain schemas and update the associated java code. With better
graphical tooling support for managing schemas and update the linked
java code, maybe this problem might go away? Would start-from-java
still be attractive then?
- venkat
Re: [axis2] simple data binder
Posted by Dan Diephouse <da...@envoisolutions.com>.
Dennis Sosnoski wrote:
> robert burrell donkin wrote:
>
>> On 8/10/05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>>
[snipped for clarity]
>> 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.
>
I totally agree on the schema-> is very similar to the start from java
case. In each case you're still using a DTO pattern. What do you see as
alternatives to this approach?
Personally, I like to be able to change and extend my schemas more than
once every year or two. Creating a seperate set of DTOs each time poses
a lot of maintenance costs. As does simply parsing the XML by hand. As
does transforming inputs and outputs to a new version. Companies like
EBay and Amazon manage to change their schemas like every month. I
wonder if they have any unique strategies they've worked out.
Anyone on this list have preferred strategies they use to make schema
change easier?
- Dan
--
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com
Re: [axis2] simple data binder
Posted by Davanum Srinivas <da...@gmail.com>.
On 8/11/05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> robert burrell donkin wrote:
>
> >On 8/10/05, Dennis Sosnoski <dm...@sosnoski.com> 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.
Just let us know when you want to get cranking :)
-- dims
Re: [axis2] simple data binder
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
robert burrell donkin wrote:
>On 8/10/05, Dennis Sosnoski <dm...@sosnoski.com> 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
AXIS volunteer
Posted by janarbek <ca...@yahoo.com>.
Dear AXIS developers? I am wondering about AXIS project? Can I be a AXIS developer? stupid question -_-. I mean how can I volunter ? How can I submit my sources, patches..?
Thanks you
Do what you can, for who you can,
with what you have, and where you are
South Korea.Seoul.
Janarbek Matay
Tel:82-10-3141-5857
mail:canarbekmatay@yahoo.com
janarbek@hotmail.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: [axis2] simple data binder
Posted by robert burrell donkin <ro...@gmail.com>.
On 8/10/05, Dennis Sosnoski <dm...@sosnoski.com> 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?
> 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.)
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.
do you plan to work on the proposed module here or over sourceforge?
- robert
RE: [axis2] simple data binder
Posted by Eran Chinthaka <ch...@opensource.lk>.
HI Dennis,
This will be a nice test of Axis2's pluggable data binding capability. We
still have played with XMLBeans only.
And if you could plugin JiBX with our extensions, we can prove the plug
ability, at least a bit more.
This pluggable data binding thing was one of the desires or expectations of
the attendees at ApacheCon.
-- Chinthaka
>
> 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. 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.
>
> - Dennis
>
> robert burrell donkin wrote:
>
> >On 8/10/05, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> >
> ><snip>
> >
> >
> >
> >>Actually, even if Glen's doing an "old style" data binder, I would say
> >>that does not in any way preclude doing a dynamic start-from-java binder
> >>in any way. If yours comes out better we can figure out how to make it
> >>be default.
> >>
> >>
> >
> >i'm a big xmlbeans fan and think it's a good match for axis2. there
> >are a couple of use cases where i think it (and most start-from-schema
> >binders) are weak:
> >
> >1 when faced with a unexpressive schema
> >2 fast prototyping especially when adding a web service interface onto
> >an existing application and in particular by developers with strong
> >java backgrounds but weak xml.
> >
> >IMHO start-from-java is a better match for these cases. (though in the
> >second, it would probably be replaced later by a generative solution.)
> >so, maybe there'd be some reason why people might want to use a
> >start-from-java binder even if it turns out to be better to directly
> >port the old style stuff. opinions?
> >
> >- robert
> >
> >
> >
Re: [axis2] simple data binder
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
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. 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.
- Dennis
robert burrell donkin wrote:
>On 8/10/05, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
>
><snip>
>
>
>
>>Actually, even if Glen's doing an "old style" data binder, I would say
>>that does not in any way preclude doing a dynamic start-from-java binder
>>in any way. If yours comes out better we can figure out how to make it
>>be default.
>>
>>
>
>i'm a big xmlbeans fan and think it's a good match for axis2. there
>are a couple of use cases where i think it (and most start-from-schema
>binders) are weak:
>
>1 when faced with a unexpressive schema
>2 fast prototyping especially when adding a web service interface onto
>an existing application and in particular by developers with strong
>java backgrounds but weak xml.
>
>IMHO start-from-java is a better match for these cases. (though in the
>second, it would probably be replaced later by a generative solution.)
>so, maybe there'd be some reason why people might want to use a
>start-from-java binder even if it turns out to be better to directly
>port the old style stuff. opinions?
>
>- robert
>
>
>
Re: [axis2] simple data binder
Posted by robert burrell donkin <ro...@gmail.com>.
On 8/10/05, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi Robert!
hi glen
> > IMHO start-from-java is a better match for these cases. (though in the
> > second, it would probably be replaced later by a generative solution.)
> > so, maybe there'd be some reason why people might want to use a
> > start-from-java binder even if it turns out to be better to directly
> > port the old style stuff. opinions?
>
> 1) I don't particularly want to call it "old-style" as that feels wrong.
> It'll simply be the Axis2 Data Binding Framework (unless there's a
> better name?).
axis 2 call binding framework?
BTW in the above paragraph i meant the actual old style (axis one)
stuff not the stuff for axis 2.
> And in fact, it'll need to take the old Axis1 stuff and
> fix a lot of the inherent problems therein (in particular the way we
> dealt with arrays of various kinds).
+1
> 2) Our DBF is going to need to go from schema->Java, and also to go from
> Java->schema. To generate WSDLs for DBF-bound services (whether RPC or
> not), we'll need to introspect the Java and generate schemas. It
> doesn't seem XStream does that.
nope. i added (basic) schema support to betwixt without too much
difficulty. since xstream is simpler and cleaner, it should be
possible to added it. it is work that would need to be done, though.
IMHO the substantive issue here is not the ability to generate schema
but to generate schema good enough for decent interoperabilty. the
minimum would have to be accurate schema for all the standards and
reasonably expressive ones for more complex object graphs.
> And even if it did we'd still need to
> take the "data-specific" schemas for the RPC argument objects and wrap
> them in the schema for the actual RPC method element...
how tricky would this be? (i'm probably missing something...)
> 3) I'm a little concerned there will be too much Axis-specific stuff
> we'll need done in the DBF to successfully use a third-party library
> without major changes. I'm certainly open to having the discussion though.
i'm confident that it is possible to do the binding successfully
(start-from-java has come a very long way since axis 1). so for me,
the real question is whether how much effort this would be and whether
the effort would be worthwhile. sounds like quite a bit of effort
would be needed and that you're already well on the way already.
it strikes me that porting the axis 1 data binding would retain the
present weakness in expressive bindings for complex objects. i wonder
how much demand there is likely to be in axis two for these kinds of
bindings.
- robert
Re: [axis2] simple data binder
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Robert!
> IMHO start-from-java is a better match for these cases. (though in the
> second, it would probably be replaced later by a generative solution.)
> so, maybe there'd be some reason why people might want to use a
> start-from-java binder even if it turns out to be better to directly
> port the old style stuff. opinions?
1) I don't particularly want to call it "old-style" as that feels wrong.
It'll simply be the Axis2 Data Binding Framework (unless there's a
better name?). And in fact, it'll need to take the old Axis1 stuff and
fix a lot of the inherent problems therein (in particular the way we
dealt with arrays of various kinds).
2) Our DBF is going to need to go from schema->Java, and also to go from
Java->schema. To generate WSDLs for DBF-bound services (whether RPC or
not), we'll need to introspect the Java and generate schemas. It
doesn't seem XStream does that. And even if it did we'd still need to
take the "data-specific" schemas for the RPC argument objects and wrap
them in the schema for the actual RPC method element...
3) I'm a little concerned there will be too much Axis-specific stuff
we'll need done in the DBF to successfully use a third-party library
without major changes. I'm certainly open to having the discussion though.
--Glen
Re: [axis2] simple data binder
Posted by robert burrell donkin <ro...@gmail.com>.
On 8/10/05, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
<snip>
> Actually, even if Glen's doing an "old style" data binder, I would say
> that does not in any way preclude doing a dynamic start-from-java binder
> in any way. If yours comes out better we can figure out how to make it
> be default.
>
> Also, IIUC Glen's working on the simple type stuff to make rpc/lit type
> stuff work nicely for simple typed parts. Right now the XMLBeans stuff
> does everything but if you give a simple type you get ugly stuff- so
> he's working to fix that so "String echoStr (String)" can be generated.
i'm a big xmlbeans fan and think it's a good match for axis2. there
are a couple of use cases where i think it (and most start-from-schema
binders) are weak:
1 when faced with a unexpressive schema
2 fast prototyping especially when adding a web service interface onto
an existing application and in particular by developers with strong
java backgrounds but weak xml.
IMHO start-from-java is a better match for these cases. (though in the
second, it would probably be replaced later by a generative solution.)
so, maybe there'd be some reason why people might want to use a
start-from-java binder even if it turns out to be better to directly
port the old style stuff. opinions?
- robert
Re: [axis2] simple data binder
Posted by robert burrell donkin <ro...@gmail.com>.
On 8/10/05, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi all!
>
> Sorry I'm a little late to this discussion...
not late at all: still at the idea stage.
> Sanjiva Weerawarana wrote:
> > On Tue, 2005-08-09 at 20:51 +0100, robert burrell donkin wrote:
> >
> >>i've been wonder whether it might not be easier and quicker to use an
> >>existing dynamic start-from-java binder. a lot of progress has been
> >>made in the last year or so on these. i suspect that it might be
> >>possible to attract developers from outside the core axis team to do
> >>the coding (though probably some help with design would be needed) and
> >>so free up some core axis committer time. might make some sense in the
> >>medium term as well: one less non-core technology for the axis team to
> >>support but...
>
> Robert - can you give me an example? Are you talking about packages
> like Beck (http://beck.sourceforge.net/)?
yep
but the one i had in mind was xstream (http://xstream.codehaus.org).
it's under pretty active development (so i had hoped we might be able
to talk them into help out) and seems like it might be a reasonable
match technology-wise.
> >>i guess whether it's worth it depends on how much work's already been
> >>done and how close it is to being finished...
>
> I've got some framework in my sandbox which I'll commit after 0.91 goes
> out. It's indeed fairly like some of the stuff in Axis1, with a
> DeserializationContext and a SerializationContext which keep track of
> multirefs, an RPC MessageReciever which knows how to turn
> <method><arg1/><arg2/></method> into a call to method(arg1, arg2),
> simple serialization/deserialization framework based on the typemappers, etc
cool
the serialization and deserialization bits could be replaced by a more
expressive db than that in axis one. i suspect that it might be
possible to port the old typemappers over to xstream relatively easily
but this would need further investigation (if it sounds like a
plan)...
alternatively, the stuff you have already could be wrapped in objects
and mapped at the top level. (i like the idea a pure document protocol
with rpc being supported by the binding but i'm unsure how good that
would be in practice...)
> It's not that close to being finished yet, though.
>
> > Actually, even if Glen's doing an "old style" data binder, I would say
> > that does not in any way preclude doing a dynamic start-from-java binder
> > in any way. If yours comes out better we can figure out how to make it
> > be default.
>
> +1. Let's continue discussion, and Robert and others can take a look at
> where I'm headed once I commit.
cool. from what i can see, the bits glen has already seem to me to be
the bits that would be need to be written (in addition to the db) in
any case.
what i would like to do sometime soon is to contact the xstream team
and see what they think of the idea (unless there are anyone out there
who'd like to jump in here now ;)
opinions?
> > Also, IIUC Glen's working on the simple type stuff to make rpc/lit type
> > stuff work nicely for simple typed parts. Right now the XMLBeans stuff
> > does everything but if you give a simple type you get ugly stuff- so
> > he's working to fix that so "String echoStr (String)" can be generated.
>
> Correct. Whatever "simple" db framework we include must be able to:
>
> 1) Do rpc/lit AND rpc/enc
>
> 2) Handle WSDL 1.1 "wrapped" style method calls
>
> 3) Handle SOAP 1.1 and SOAP 1.2 data encoding (arrays, mrefs)
>
> 4) Handle WSDL 2.0 RPC style (once we're handling WSDL 2.0 :))
you're right: seems like the framework won't be that simple. i'll use
'old style' in future :)
but it's just binding and nearly anything is possible with enough
effort. the question is how easy those thing would be to do (and how
many hands there'd be to help). i don't know enough about xstream to
give a good idea of that...
> It would be nice if the framework could handle pulling the XML events
> during deserialization in such a way that no OM caching needs to be done
> (a little tricky when multirefs are involved).
AIUI xstream uses pull parsing (which is one of the reasons i thought
it a good match) but i the devil will be in the detail of the
framework...
- robert
Re: [axis2] simple data binder
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi all!
Sorry I'm a little late to this discussion...
Sanjiva Weerawarana wrote:
> On Tue, 2005-08-09 at 20:51 +0100, robert burrell donkin wrote:
>
>>i've been wonder whether it might not be easier and quicker to use an
>>existing dynamic start-from-java binder. a lot of progress has been
>>made in the last year or so on these. i suspect that it might be
>>possible to attract developers from outside the core axis team to do
>>the coding (though probably some help with design would be needed) and
>>so free up some core axis committer time. might make some sense in the
>>medium term as well: one less non-core technology for the axis team to
>>support but...
Robert - can you give me an example? Are you talking about packages
like Beck (http://beck.sourceforge.net/)?
>>i guess whether it's worth it depends on how much work's already been
>>done and how close it is to being finished...
I've got some framework in my sandbox which I'll commit after 0.91 goes
out. It's indeed fairly like some of the stuff in Axis1, with a
DeserializationContext and a SerializationContext which keep track of
multirefs, an RPC MessageReciever which knows how to turn
<method><arg1/><arg2/></method> into a call to method(arg1, arg2),
simple serialization/deserialization framework based on the typemappers, etc
It's not that close to being finished yet, though.
> Actually, even if Glen's doing an "old style" data binder, I would say
> that does not in any way preclude doing a dynamic start-from-java binder
> in any way. If yours comes out better we can figure out how to make it
> be default.
+1. Let's continue discussion, and Robert and others can take a look at
where I'm headed once I commit.
> Also, IIUC Glen's working on the simple type stuff to make rpc/lit type
> stuff work nicely for simple typed parts. Right now the XMLBeans stuff
> does everything but if you give a simple type you get ugly stuff- so
> he's working to fix that so "String echoStr (String)" can be generated.
Correct. Whatever "simple" db framework we include must be able to:
1) Do rpc/lit AND rpc/enc
2) Handle WSDL 1.1 "wrapped" style method calls
3) Handle SOAP 1.1 and SOAP 1.2 data encoding (arrays, mrefs)
4) Handle WSDL 2.0 RPC style (once we're handling WSDL 2.0 :))
It would be nice if the framework could handle pulling the XML events
during deserialization in such a way that no OM caching needs to be done
(a little tricky when multirefs are involved).
Did I miss anything?
--Glen
Re: [axis2] simple data binder
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Tue, 2005-08-09 at 20:51 +0100, robert burrell donkin wrote:
> i've been wonder whether it might not be easier and quicker to use an
> existing dynamic start-from-java binder. a lot of progress has been
> made in the last year or so on these. i suspect that it might be
> possible to attract developers from outside the core axis team to do
> the coding (though probably some help with design would be needed) and
> so free up some core axis committer time. might make some sense in the
> medium term as well: one less non-core technology for the axis team to
> support but...
Hi Robert .. that sure sounds like an offer of help! We would love
it :). Please please go ahead ..
> i guess whether it's worth it depends on how much work's already been
> done and how close it is to being finished...
>
> hopefully glen will jump in about now...
+1 .. Glen?
Actually, even if Glen's doing an "old style" data binder, I would say
that does not in any way preclude doing a dynamic start-from-java binder
in any way. If yours comes out better we can figure out how to make it
be default.
Also, IIUC Glen's working on the simple type stuff to make rpc/lit type
stuff work nicely for simple typed parts. Right now the XMLBeans stuff
does everything but if you give a simple type you get ugly stuff- so
he's working to fix that so "String echoStr (String)" can be generated.
Sanjiva.
Re: [axis2] simple data binder
Posted by robert burrell donkin <ro...@gmail.com>.
On 8/9/05, Ajith Ranabahu <aj...@gmail.com> wrote:
> Hi Robert,
hi ajith
> We actually talked about it that day also. Glen seems to be doing some work
> on a simple data binding framework but I am not really sure how it will turn
> out. I mean I am not sure whether it's based on Axis1 or so.
i've been wonder whether it might not be easier and quicker to use an
existing dynamic start-from-java binder. a lot of progress has been
made in the last year or so on these. i suspect that it might be
possible to attract developers from outside the core axis team to do
the coding (though probably some help with design would be needed) and
so free up some core axis committer time. might make some sense in the
medium term as well: one less non-core technology for the axis team to
support but...
> Any thoughts Glen :)
+1
i guess whether it's worth it depends on how much work's already been
done and how close it is to being finished...
hopefully glen will jump in about now...
- robert
Re: [axis2] simple data binder
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi Robert,
We actually talked about it that day also. Glen seems to be doing some work
on a simple data binding framework but I am not really sure how it will turn
out. I mean I am not sure whether it's based on Axis1 or so.
Any thoughts Glen :)
On 8/9/05, robert burrell donkin <ro...@gmail.com> wrote:
>
> IIRC at ApacheCon (good talk BTW Ajith) a question were raised (from
> the audience) about compatibility with the older axis 1 databinding. i
> believe that the reply was that the plan would be to create a new
> simple binding framework.
>
> i was wondering whether this has already been created and if the
> intention was to make it similar to the BeanSerializer in axis1. (or
> whether i'd got it all mixed up...)
>
> - robert
>
--
Ajith Ranabahu