Re: Document style web services

[Dennis Sosnoski]

I'd personally disagree with this assessment of Axis as "not ready for prime time", but I can understand the frustrations. There's definitely a steep learning curve involved in using Axis, and I agree that the developers need to focus more on improving usability and performance, as well as bug fixes and documentation. As Martin said, nightly builds can also be traumatic. I've run into a number of problems trying to use the nightlys, and have basically dropped back to just working with the GA release 1.0 as a result.

On the good side, I haven't seen any problems with Axis 1.0 stability once you have a service deployed. It also provides enormous flexibility and extensibility, and in my experience developers can quickly get past the initial learning curve with some mentoring. I suppose the choice of Axis vs. GLUE or other commerical alternatives really depends on how much you intend to do with the software (if it's just a small project, the Axis learning curve may be costly) and how important it is to you to have the source available.

- Dennis

Dennis M. Sosnoski
Enterprise Java, XML, and Web Services Support
http://www.sosnoski.com

Martin Gee wrote:

Hi Martin,

I'm catching the tail end of this thread (sorry if this is a repeat). I
find Axis valuable and the news thread has good information, but have
made the same conclusion that AXIS is not ready for prime time. Maybe
consider a production ready WS product http://www.themindelectric.com/
Has free version too.

Cheers,
Martin


-----Original Message-----
From: Martin Jericho [mailto:[EMAIL PROTECTED]] Sent: Sunday, November 24, 2002 5:02 PM
To: [EMAIL PROTECTED]
Subject: Re: Document style web services

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