----- Original Message -----
From: "Christian Gross" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 26, 2002 2:00 AM
Subject: Re: Document style web services

> Having used both .NET and Axis I am afraid the issues you mention are
> probably related to the fact that you are under pressure to learn the
> technology and simply do not have the time to put a context to the
> situation.  While yes .NET will allow you to click, click and presto there
> are issues there as well.  It will hit you in the face once you upgrade to
> the next version of VS.NET.
 
What issues are they?  Are there incompatibilities in the 1.1 beta version of the .NET framework?  Or is it really the next VS version that will cause problems?  I would appreciate it if you could share your experiences.

>
> Now about Axis not being ready for usage, that is a bit incorrect.  I have
> used both .NET and Axis and can get them to play nicely.  And using the
> Java to WSDL to Java code generation route makes interoperability a piece
> of cake.
 
Are you using RPC-encoded or doc/literal?  I was originally using RPC-encoded from axis-generated WSDL, and .NET was talking to that nicely, except for one little bug in axis which gave me problems. (bug #14152).  It was then that I investigated generating the WSDL with .NET, and discovered the virtues of wrapped doc/lit, which I'm now committed to.  I then tried to get axis to generate wrapped doc/lit and everything went to shit, so I stuck to .NET and have not had any problems since.
 
> Now about having version problems and the likes, yes it can be
> problem at times.  But this can be controlled by taking it one step at a
> time and placing things in the correct directories.
>
> Christian Gross
>
> At 10:01 25/11/2002 +1000, you wrote:
> >Hi Tom
> >
> >I spent about a week playing around with axis to see why it wasn't working
> >for me, and simplifying test cases to find out the causes.  I did post a
> >couple of bug reports on bugzilla, but no-one has even commented on them
> >yet.  I really did want to stick with axis, but in the end I had to make a
> >decision which was expedient for my project, which was to generate the WSDL
> >using .NET.  I can't afford to spend the time investigating and writing bug
> >reports for axis when there is another solution which works perfectly for
> >me.
> >
> >I didn't report any of the other bugs primarily because they were too
> >numerous, and it takes a significant amount of time to write up a bug report
> >that is truly useful to the developer.  They were also quite fundamental, so
> >would be easily detected by anyone else creating even the simplest of
> >services.  This also makes me think they may have already been addressed in
> >the nightly builds.
> >
> >Nightly builds bring up a whole new area of gripes.  Firstly, it always
> >turns out to be a major pain, involving a fair amount of guesswork, to
> >upgrade to even a release version of axis.  This is because our project uses
> >jakarta projects such as torque (which btw we are now quite desperate to
> >abandon), and velocity, and each expects different versions of the commons
> >libraries, xerces and log4j.  The problem is that none of the jakarta jar
> >libraries contain any version information whatsoever, so it is always
> >guesswork to figure out which one is using the latest version, and very
> >often they are not even backwards-compatible.  Axis itself is no better in
> >this regard.  The jar file is always called axis.jar, with no version
> >suffix, and the manifest file never includes a version number either.  I am
> >not willing to use a nightly version of axis in production, and only use
> >beta versions of tools when there is no alternative.  What would be great is
> >if there were a CVS branch created after 1.0, which included only bug fixes
> >that are then released in "service packs".  I know this means more work for
> >you guys, but in the real world you can't expect companies to use nightly
> >builds unless they are heavily involved in the product's development like
> >Macromedia is.
> >
> >Even writing a response like this takes up valuable development time (which
> >I can afford at the moment because the server just kicked the bucket!).  I
> >don't apologise for not taking more time to contribute to axis, it's just a
> >reality.
> >
> >Martin
> >
> >
> >
> >----- Original Message -----
> >From: "Tom Jordahl" <
[EMAIL PROTECTED]>
> >To: <
[EMAIL PROTECTED]>
> >Sent: Saturday, November 23, 2002 5:53 AM
> >Subject: RE: Document style web services
> >
> >
> > >
> > > Martin,
> > >
> > > Can you please try Java2WSDL with the latest nightly build and report any
> >bugs you find in Bugzilla?
> > > We want this to work!  I hope you will find that the latest source fixes
> >most (all?) of the major problems.
> > >
> > > Thanks
> > > --
> > > Tom Jordahl
> > > Macromedia
> > >
> > >
> > > -----Original Message-----
> > > From: Martin Jericho [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, November 21, 2002 5:32 PM
> > > To:
[EMAIL PROTECTED]
> > > Subject: Re: Document style web services
> > >
> > >
> > > Dennis,
> > >
> > > My experience is that Java2WSDL in Axis 1.0 has too many bugs to generate
> > > document/literal style WSDL, but if you can generate it by some other
> >means,
> > > the WSDL2Java and bean marshalling seem to work fine.
> > >
> > > The reason you can't have multireferencing in document style calls is
> > > because the document is validated against the schema.  If you define the
> > > schema to allow IDs and REFs on every element, you can implement the
> > > multirefs yourself, but this would make your schema virtually unreadable,
> > > very complicated, and probably less robust.
> > >
> > > Martin Jericho
> > >
> > > ----- Original Message -----
> > > From: "Dennis Sosnoski" <
[EMAIL PROTECTED]>
> > > To: <
[EMAIL PROTECTED]>
> > > Sent: Friday, November 22, 2002 7:03 AM
> > > Subject: Re: Document style web services
> > >
> > >
> > > > Hi Anne,
> > > >
> > > > Does Axis support automatic marshalling of document-style messages? I
> > > > was under the impression it does not, which was why I suggested a
> > > > DataBindingProvider might be useful to add this support. I agree that
> > > > document-style is a better approach for the future, though I'd hardly
> > > > call it a "predominant consensus" at this point. AFAIK document style
> > > > interfaces are not as widely supported as RPC style, though, and I'm
> > > > surprised to see your statement that most SOAP implementations support
> > > > automatic marshalling for document style. Can you give me any figures
> > > > for this?
> > > >
> > > > As for "no problem building automatic serializers" I have to disagree. A
> > > > Schema definition does not, in general, provide enough information to
> > > > directly map to Java data structures. If you use an approach where the
> > > > data structures are either pre-generated from the Schema or constrained
> > > > to obey a predefined mapping to and from the Schema you can get around
> > > > this, but that's hardly automatic.
> > > >
> > > > I'm also puzzled by your statement that it's difficult handle
> > > > multi-referencing object structures using document style. Is there a
> > > > reason this can't be handled with ID/IDREF or key/keyref links?
> > > >
> > > > Thanks,
> > > >
> > > >   - Dennis
> > > >
> > > > Dennis M. Sosnoski
> > > > Enterprise Java, XML, and Web Services Support
> > > >
http://www.sosnoski.com
> > > >
> > > > Anne Thomas Manes wrote:
> > > >
> > > > >Dennis,
> > > > >
> > > > >This is a pretty antiquated view of document style. Document style is
> >no
> > > > >longer used just for XML messaging. Most SOAP implementations support
> > > > >automatic marshalling of both RPC-style and document-style messages. As
> > > long
> > > > >as you have a WSDL description of the message structure, there's no
> > > problem
> > > > >building automatic serializers.
> > > > >
> > > > >The predominant consensus in the industry at this point is to use
> > > > >document-style by default. Document style is much easier to validate,
> > > > >transform, and manipulate. The primary reason to consider using
> > > rpc/encoded
> > > > >is if you need to send multi-referencing object structures. SOAP
> >encoding
> > > > >does a really nice job marshalling these structures. It's much harded
> >to
> > > > >represent them using literal XML Schema. But if you're not using
> > > multi-refs,
> > > > >it's a better practice to use document-style.
> > > > >
> > > > >Regards,
> > > > >Anne
> > > > >
> > > > >
> > > > >
> > > > >>-----Original Message-----
> > > > >>From: Dennis Sosnoski [mailto:[EMAIL PROTECTED]]
> > > > >>Sent: Thursday, November 21, 2002 1:25 PM
> > > > >>To:
[EMAIL PROTECTED]
> > > > >>Subject: Re: Document style web services
> > > > >>
> > > > >>
> > > > >>Hi Matt,
> > > > >>
> > > > >>The whole point of document style is that your application gets passed
> > > > >>the XML message payload as XML document fragments. See the "message"
> > > > >>sample for an example of this. With a document style interface your
> > > > >>class would look like:
> > > > >>
> > > > >>public class SomeXMLService {
> > > > >>    public Element[] someXMLMethod(Element[] elems) {
> > > > >>        ...
> > > > >>    }
> > > > >>}
> > > > >>
> > > > >>If you want to convert the XML into objects you need to do it
> >yourself,
> > > > >>perhaps using a framework such as Castor (
http://www.castor.org). I
> >know
> > > > >>there's been some integration of Castor with Axis, though I think this
> > > > >>was for custom serialization with RPC style.
> > > > >>
> > > > >>This brings up an interesting point, though. Why not have a Java
> > > > >>DataBindingProvider as a replacement for the MsgProvider? This should
> > > > >>allow easy use of document style while converting seamlessly between
> >XML
> > > > >>and objects without the application needing any special code. I'm
> > > > >>looking into some data binding code currently, perhaps I'll see if I
> >can
> > > > >>work in this direction.
> > > > >>
> > > > >>  - Dennis
> > > > >>
> > > > >>Dennis M. Sosnoski
> > > > >>Enterprise Java, XML, and Web Services Support
> > > > >>http://www.sosnoski.com
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > >
> > > >
> > >
>
> Christian Gross
> Software Engineering Consultant
>
http://www.devspace.com
> North America: 1-450-675-4208
> Europe +41.1.701.1166
>
>

Reply via email to