I really hate to do that :-) but
*ME TOO*
Christian Seiler
InteRes GmbH
Rheinstrasse 44-46
64283 Darmstadt
Phone +496151 30740 18
Fax +496151 30740 11
-----Ursprüngliche Nachricht-----
Von: Paul Grillo [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 31. Oktober 2005 19:40
An: [email protected]
Betreff: RE: I give up (let's change the subject line, but try to be
constructive)
If you found a way to use classes generated by XMLBeans in Axis
Client/Server, I would certainly be interested in and very much
appreciate anything you could send me. And anything needed to ensure the
client generated stubs work as well.
-----Original Message-----
From: Nathaniel G. Auvil [mailto:[EMAIL PROTECTED]
Sent: Monday, October 31, 2005 12:57 PM
To: [email protected]
Subject: RE: I give up (let's change the subject line, but try to be
constructive)
We are using XMLBeans with Axis. I found a serializer and deserializer
on a website some time
ago. I can email them to you if you would like. I had to add a custom
ant task to modify the
server-config.wsdd to change to the XMLBeans serializer but it was no
big deal.
--- Paul Grillo <[EMAIL PROTECTED]> wrote:
Let me be more specific about the 2 areas that have troubled me since
I
was second in line of kicking off this long thread. I provide this as
input and food for thought.
As I mentioned previously, I have no axe to grind. I'm fairly well
aware
of tradeoffs with open source and no open source. We spend tons of
money on oracle and bea support, such as it is. There are no
guarantees
of help when you need it whether you pay for it or not. I also would
never blame or take Axis or any product like that to task for the fact
that WS_Profile and SOAP is a pain. It is a pain - but it has strong
advantages. REST, for example, is a good solution for some problems.
REST assured, however, that it could not possibly solve the problem I
had to solve which was to communicate with a .NET vendor and swap SOAP
messages of which certain elements were signed and encrypted and
depended on ws-addressing etc. AXIS 1.2/WSS4J solved this problem for
me very nicely, and I thank them.
I guess I would say I'm not giving up, I may (hope to) return. But
I've
got to solve a few of my own issues.
Okay, the 2 areas I would like to zero in on
1) AXIS 1 or AXIS2? 2 different projects? any Migration? Have I been
left to solve it for myself?
The move from Axis 1 to Axis 2 and the way it feels is a little
disconcerting. It seems to me (and has been pointed out) that most
energy is going into Axis2. Fine, but most deployments have and are
running in Axis 1. What bothers me is the feeling that I get that
Axis2
is the replacement, and yet there doesn't seem to be any easy
migration.
If you look at the migration blurb in Axis 2, it spends time telling
me
why Axis2 is better, but not how to migrate. It almost leaves me with
this feeling that I made a mistake going with Axis 1. I ask myself
are
these the same developes? Axis 1 and 2? Are they competing? So I'm
left with the feeling that I'm getting little help on Axis 1 because
the
efforts are toward Axis 2. And when I read Axis 2 doc, all I'm
hearing
is it is so much better than Axis 1. It's tough to swallow since I'm
sitting on at least one deployment of Axis 1. Am I now being told
that
I made a mistake? support is dwindling? move to Axis 2? Make all the
appropriate changes?
This plays into the overall uneasiness. You look for a commitment
from
the producers/developers to the users. Migration tools for version to
version. Make sure users have not been left hanging. Believe me it
makes you think twice when you choose any technology, open source or
not. I've been through this sort of thing with products that I've
spent
a lot of money on. I've worked with open source projects that were
absolutely committed to the users from version to version with respect
to backwards compatibility.
2) Please let me decide what technology I use for
serialization/deserialization, not the Web Services Framework.
I am in "total" agreement with Guy's # 3 suggestion attached below.
Then next issue is Serialization independence. I really need
serialization independence. It cannot be chosen or generated for me
by
the actual Web Services Framework I chooose, but should use mine.
My job within my company is to provide basic services to a number of
development teams, each of which provide solutions in a totally
different domain. I provide them with interfaces that enable our back
office services in any number of ways. These groups don't even really
know if or what network is involved.
In the context of Web Services, these groups only interface will be
related to the generated WSDL/XSD Objects. Given a request object
they
will gather the info from that object, call upon legacy systems or
whatever is needed to fulfill the request, then populate the response
object. I will provide my own internal service factory from which I
can
call upon these back office services and speak the language of our
XSD/Schema objects. To them, they are java objects, pure and simple.
What this means is these objects must not change. Translated, we need
to settle on a stable XSD schema and most importantly a stable set of
generated java objects.
so ... # 3 is of utmost importance. I do NOT want to tie this
dependency to my choice of AXIS or AXIS2 or whatever. I need the
ability
to use XMLBeans, or Castor, or I name it (not the SOAP framework) to
work with the framework.
Now at this very moment I'm looking at using XMLBeans. I see no easy
integration of this with either AXIS or AXIS2. AXIS 2 is moving in
that
direction, but does not have support for externally generated (using
scomp) XMLBeans. so for me ...
My "only" salvation here is serialization independence. Because with
independence, I can even roll my own. Then when/if Axis 2 supports my
chosen serialization objects I can trash my home grown solution, use
Axis 2, and there are no bumps in the road.
so .... I couldn't agree more with Guy's #3 point below..
A
-----Original Message-----
From: Guy Rixon [mailto:[EMAIL PROTECTED]
Sent: Monday, October 31, 2005 3:22 AM
To: [email protected]
Cc: [email protected]
Subject: RE: I give up
Three suggestions for improving the Axis experience:
1. More effort to documentation. The Axis 1 documents aren't yet
sufficient to
deal with use in a real project.
Just expanding some of the Javadoc comments would help. In fact,
providing or
expanding the package.html files would be good, and maybe more
palatable
than
reworking the xdocs. :)
If someone did want to work on the xdocs, the reference guide to WSDD
would be
a good place to start.
2. Improve the error reports. Currently, when Axis goes worng (more
commonly,
when it is misconfigured) the error reporting isn't sufficient to
diagnose the
problem. Alternatively, provide tools that can inspect the
configuration
of a
deployed service and explain what's wrong.
3. Provide an alternative to the current WSDL2Java to write stubs that
use an
external seralizer/deserializer mechanism (Castor, XMLbeans, JAXB). In
my
experience with Axis, the stubs are the valuable part and the Axis
XML-mapping
is redundant (duplicates mapping code we already have) unstable (bean
classes incompatible between Axis versions) and fragile. Hence the
move
to
XMLBeans in Axis 2, I guess...but maybe Axis 1 could be cleaned up
too?
What I have in mind is a stub-generation tool that takes a WSDL
contract, a
Java interface defining the API of the stub and a file of
class/element
mappings. It would generate stubs for which the API is entirely
defined
by the
author of the client, and which can be rebuild to the same contract in
the
next version of Axis 1; WSDL2Java can't provide this stability of
interface.
You could provide a separate tool for creating data-binding beans if
one
were
needed. This could generate the beans that WSDL2Java currently
produces.
It
would also need to generate the class/element mapping-file.
Guy Rixon [EMAIL PROTECTED]
Institute of Astronomy Tel: +44-1223-337542
Madingley Road, Cambridge, UK, CB3 0HA Fax:
+44-1223-337523
__________________________________
Start your day with Yahoo! - Make it your home page!
http://www.yahoo.com/r/hs
