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: axis-user@ws.apache.org > Cc: axis-dev@ws.apache.org > 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
