Hi Amila,
Amila Suriarachchi wrote:
...
you have said.
With JiBX, you first create a binding definition to define how Java
objects are to be converted to and from XML, then compile that binding
using a tool that enhances your data class files by adding methods (as
bytecode) implementing the conversions.
is this means it is mandatory to have data bind java classes written
and the binding file before calling to the wsdl2java tool? (according
to the current axis2 trunk code base)
Yes, that's correct.
in other way if you have a wsdl, is it possible to generate the code
using jibx, just giving some arguments to the wsdl tool? for ADB yes.
According to your article the answer I understood is no. (my apologies
if I am wrong).
Yes, that's also correct. As stated in the summary: "But the JiBX
support integrated into Axis2 doesn't handle code generation from
schema, and even the separate code generation from schema support
provided by the JiBX tools currently provides only limited schema support."
So when considering this fact there is no difference between ADB and
jibx for small wsdls. But what for large ones? users have to go
through the wsdl and schema files and write java classes and the
binding file. (Do you have a tool to generate the binding file?). And
on the other hand users must have and expert knowledge about Schema
and wsdl to read them and produce java files.
This clearly shows ADB and jibx try to solve different kind of
problems. hence selection must be based on the user requirement rather
than the pros and crons of the frameworks.
That's why I say that ADB provides good - and growing - support for code
generation from schema, while clearly stating that JiBX does not.
Lets say, there is an web service published and some one wants to
access this service.
ADB scenario.
if he do not have any classes written and want to generate every thing
from the scratch (i.e only giving some arguments to wsdl2java tool)
adb is the only option. (of course xmlbeans and jaxbri can be used
alternatively)
jibx Senario,
if he has written some java classes and want to map the incoming xml
stream to these classes only option is jibx.
When considering above case, comparing jibx and ADB is useless. since
advantage of one is disadvantage of other since these two try to
address different problems.
"It's great that Axis2 offers a choice between these data-binding
frameworks, because there's no single best choice for all needs."
On the other hand if you think of main two methods commonly used in
developing web services are.
1. contract first approach.
i.e first we develop wsdl and them generate code accordingly.
(ADB,xmlbeans jaxbri fallen into this categories)
2. code first.
i.e we have java services written and want to publish them as web
services. java2wsdl address this scenario.
For jibx I think it is in between. it is something like contract
first, code first and then map.
I agree you with that this is also a new approach option.
Through the Jibx2Wsdl tool JiBX provides excellent support for a
code-first approach to service development, far superior (at least from
my experience) to Java2Wsdl. It does not currently provide good support
for code generation from schema, as discussed in the article and
repeated above. I'm actually working on that area now, and in a month or
so expect to provide quality code and binding generation from schema. I
don't know whether that support will ever be integrated into the Axis2
Wsdl2Java tool, because I find Wsdl2Java very difficult to work with.
I thought this was all clearly spelled out in the article, especially
the Summary at the end. Hope this makes things clearer.
- Dennis
please correct me I have misunderstood any thing.
Thanks,
Amila.
On 7/28/07, *Dennis Sosnoski* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
The article has now been updated with the changes discussed in this
thread and the one with Deepal. I'll add a link to the article in
the docs.
- Dennis
Dennis Sosnoski wrote:
> Hi Amila,
>
> Amila Suriarachchi wrote:
>>
>>
>> On 7/27/07, *Dennis Sosnoski* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
>> <mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:
>>
>> My devWorks article comparing ADB, XMLBeans, and JiBX data
binding
>> with
>> Axis2 has now been published:
>> http://www.ibm.com/developerworks/webservices/library/ws-java3
>>
<http://www.ibm.com/developerworks/webservices/library/ws-java3
<http://www.ibm.com/developerworks/webservices/library/ws-java3>> I
>> *am*
>> the primary developer for JiBX, but tried to give a fair
>> representation
>> of all three frameworks in the article. It also includes
full sample
>> code, for both the current 1.2 release and the in-progress 1.3
>> release.
>>
>>
>> First of all I would really thank you to writing this article,
since
>> this would help a new person to relay understand the things and
>> getting started. And also It would be nice this article base on
Axis
>> 1.3 release.
>
> Thanks! Unfortunately, the article is based mainly on the 1.2
release
> since it was submitted for publication two months ago. I did update
> the code to include samples for Axis2 1.3, and added a sidebar
on the
> ADB and XMLBeans sections discussing the problems which were present
> in 1.2 (which I argued strongly in favor of correcting at the time
> with a 1.2.1 release) but fixed in 1.3.
>
>>
>> I would like to express my ideas regarding some of the things you
>> have mentioned about the ADB.
>>
>> 1. On the down side, the ADB unwrapped support is still somewhat
>> unstable
>>
>> see the wsdls in the these locations [1],[2] . I could generate the
>> code for all wsdls
>> (i.e doc/litwrap, doc/litbare, rpc/lit Axis2 1.3 RC2) with ADB
>> unwrapping and invoked sucessfully. So ADB fully support the
>> unwrapping for all those scenarios.
>
> You're right, with the 1.3 release coming the comment about ADB
> unwrapped support being somewhat unstable no longer applies.
I'll ask
> to have that removed from the Summary.
>
>>
>> 2. ADB also offers some enhanced features not currently available
>> with the other data-binding frameworks, including automatic
>> attachment handling.
>>
>> better you would have included this part in conclusion as well.
since
>> this is a really distinguish feature.
>
> True for now, though I'm planning to add attachment handling for
JiBX
> soon. But I'll add this to the Summary.
>
>>
>> 3. In the current Axis2 1.2 release, these limitations include
schema
>> features, such as compositors with |maxOccurs="unbounded"|, schema
>> definitions with |attributeFormDefault="qualified"|, and some
similar
>> variations
>>
>> All these problems are solved in Axis2 1.3 RC2. ADB now supports,
>> minOccurs, maxOcuurs full in Sequence and Chioce level and
>> attributeFormDefault='qualified' as well.
>> And also it has the follwing featues as well
>> 1. Union,list, restriction (pattern,enumeration) type support
>> 2. QName support to attributes and elements,
>> 3. Complex type extensions hence polymorphysum
>> 4. AttributeGroup, Group references support,
>>
>> if you come across any issues regarding these please log a jira.
>
> I added the sidebar as the article went to publication, stating
that
> the unwrapping issues have been corrected in Axis2 1.3. The article
> was written before these problems were corrected, and it's too much
> effort for me to completely rewrite it based on the 1.3 code - but
> even now the 1.2 release is the latest full release available.
>
>>
>> 4, ADB code is usable only for Axis2 Web services
>>
>> Although it is not impossible to use ADB in ther web services (You
>> can run the ADB generated code by adding axis2-adb.jar
>> axi2-kernal.jar and AXIOM jars to class path. can create the
ADB bean
>> objects by parsing the stream reader to parse method and serialize
>> using serilize method. please see[3]) this is not straight
forward as
>> other data binding frameworks like jibx,xmlbeans and jaxbri.
>>
>> On the other hand When someone choosing a databinding framwork
to use
>> with axis2 this should not be an issue.
>
> I agree - so presumably you don't object to my saying that "ADB code
> is usable only for Axis2 Web services", right? :-)
>
>>
>>
>> Anyway if you do some Axis2 traning (which is really good in
>> promoting Axis2) better if you prefer to use Axis2 1.3 (which will
>> release soon) rather than Axis2 1.2. Axis2 will provides better
full
>> stack support (i.e security, RM and addressing) with relevant
Rampart
>> and sandesha modules and other features than Axis2 1.2.
>> So using Axis2 1.3 would give a better user impression regarding
>> Axis2 than Axis2 1.2 which is good for Axis2.
>
> I agree completely, and I've already revised my sample code to work
> with 1.3. I did have bad experiences trying to use 1.2 for training
> purposes, since (1) many of the features I used in my samples were
> broken, as discussed in the article, and (2) the lack of Rampart
> support for weeks following the 1.2 release meant no WS-Security
> handling could be demonstrated. I ended up using 1.1.1 for
classes in
> April and May because of these issues. Fortunately, 1.3 looks like
> it'll be much more solid than 1.2 - it's done well with everything
> I've tried so far, though I haven't tested WS-Security handling with
> the current Rampart builds yet.
>
> - Dennis
>
>>
>> thanks,
>> Amila.
>>
>> [1]
>>
http://131.107.72.15/SoapWsdl%5FBaseDataTypes%5FXmlFormatter%5FService%5FIndigo/
>>
>> [2]
>>
http://131.107.72.15/SoapWsdl%5FComplexDataTypes%5FXmlFormatter%5FService%5FIndigo/
>> <
http://131.107.72.15/SoapWsdl%5FComplexDataTypes%5FXmlFormatter%5FService%5FIndigo/>
>>
>> [3] http://wso2.org/library/2068
>>
>>
>> While I'm promoting my own stuff, I'll also mention that I'm
>> planning a
>> trip to Australia in early September for on-site consulting and
>> training
>> visits (see the Axis2 training course outline:
>> http://www.sosnoski.com/companys/axis2class.html), and will
>> follow-up
>> with another trip to the U.S. later in the (northern
hemisphere)
>> fall.
>> Visits to other parts of the world can also be arranged...
email me
>> directly if interested.
>>
>> - Dennis
>>
>> --
>> Dennis M. Sosnoski
>> SOA and Web Services in Java
>> Axis2 Training and Consulting
>> http://www.sosnoski.com - http://www.sosnoski.co.nz
>> Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117
>>
>>
>>
>>
---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
>> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
>> For additional commands, e-mail:
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
>>
>>
>>
>>
>> --
>> Amila Suriarachchi,
>> WSO2 Inc.
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
--
Amila Suriarachchi,
WSO2 Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
