I think factoring out the XML-Java Language binding into pluggable components would help - kinda like people are using Castor. I guess that means some WSDL generation parts need to be extensible too but...

I like XmlBeans for XML-Java-XML but I'm not sure its practical to add support for it to axis without a plugin architecture in place.

Jim

Davanum Srinivas wrote:

Let's twist this discussion on its head....
- Is there a list of bugs hiding in there somewhere? (bug reports)
- What would you do if you were to write/re-write parts of axis?
(enhancements requests)

If we can't create new bug reports / enchancements to tell axis
developers how axis should behave in the future (1.2 Final) then all
discussion is just water under the bridge.

thanks,
-- dims

On Wed, 12 May 2004 12:12:44 -0500, Joe Plautz <[EMAIL PROTECTED]> wrote:

Thanks for the advice! This is exactly what I've been looking for.

It almost seems that people end up using Axis inspite of itself. But, it's
just too dang easy to get something up and running. I imagine JWS files have
lead many people astray with their simplicity. If all services could work
like them, plus using user defined objects/type with little to no
configuration. The world would be a fabulous place.

I too have been not tying my service layer to my DAO layer. My reasons are
more personal preferrance then need. But, I can take my DAO and put it
behind something else with little changing except creating a new broker.

-Joe



----- Original Message -----
From: "Anderson Jonathan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 12, 2004 10:03 AM
Subject: RE: Best Practices?


I would venture to say that 80% of the complications and frustrations
implementing interoperable (WS-I compliant Doc/Literal) SOAP web services

on


Java platforms stem from the XML datatype to Java datatype binding

problem.


If you take the time to learn W3C XML Schema, you'll see the problem: it's
not an OO type system.  Therefore modeling your data types in Java and
expecting some automagic Java2WSDL utility to do all of the hard work to
generate your XML schema is naive, and it is unfortunate that so many OO
developers think this way.

I've encountered several approaches for dealing with this problem with
Axis - virtually all of them involve hand crafting your WSDL and XSD (with

a


WSDL/XSD IDE, of course) and generating a Java type system using ***a
particular Java XML binding engine***.  Using Axis's internal XML binding
engine is one of several options available to you.

For more info on the XML binding problem in Java, I defer to Dennis

Sosnoski


(www.sosnoski.com), a long-time XML deep thinker.  He first turned me onto
the XML data binding "problem" with his excellent articles (4 parts) on

the


issues over at IBM developerWorks.

http://www-106.ibm.com/developerworks/library/x-databdopt/index.html

If you're trying to use Axis's internal XML binding engine, here's some
advice:

http://marc.theaimsgroup.com/?l=axis-user&m=107945370506044&w=2

We've since moved away from this approach, and are currently using Axis's
Message Style services to pass the SOAP Request Body DOM straight to

Castor,


which unmarshalls the XML into a Castor generated type system.  We further
introduced a broker pattern to abstract the SOAP messaging layer from our
business layer, which currently is not tied to any XSD generated types.

Axis Message Style Service Implementation ->
Service Broker Layer (unmarshalls SOAP Request DOM via Castor, extracts

the


necessary information from Castor types - literally traversing the graph's
getters - to invoke Business Manager Layer, and catches Business

Exceptions


and maps them to proper SOAP Faults using AxisFault)->
Business Manager Layer (not tied to XSD types, but rather pure Java

business


domain types, invokes DAO layer as needed) ->
DAO Layer (a Spring/Hibernate layer to manage persistence for business
domain types)

The problem here is definitely managing and translating between the two

type


systems: Castor generated classes from XSD and non-generated Business

Domain


classes.

The alternative, however, is to just try to use the XSD generated type
system and persist that directly.  This is too big of a leap for us right
now, as our business layer doesn't "think" in pure XSD type terms.  You'll
probably encounter this a lot given how much legacy functionality people

are


trying to SOAP service enable.

Bottom line: implementing a WS-I compliant SOAP service in Java is not a
trivial thing.  There are two types of people building Web Services in

Java:


those who are extremely frustrated with the completely stupid state of the
Java based Web Services world right now and yet still trying very hard to

do


it right, and those who haven't grasped that world is in a completely

stupid


state right now.

-Jon

-----Original Message-----
From: Joe Plautz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 12, 2004 10:02 AM
To: [EMAIL PROTECTED]
Subject: Re: Best Practices?


My first attemps have started with a WSDL/Schema then I generate

everything.


I was able to find an example at W3.org and I just manipulate it to the

way


I need it. I thought this to be the best way at the time because of
interoperability.

From what I've been finding thus far there are no "Standard" practices,

just


"Accepted" practices. Starting with a class then using Java2WSDL and then
WSDL2Java seems to be the most common. But, it almost seems that this was
not the intention of the designers of Axis. Why use two steps when you can
use one? Creating a WSDL from scratch seems like the intended way, but is
not the most accepted way by the developers/users of Axis. Why write what
you can generate?

I know this isn't difficult earth shattering stuff, I'm just looking for

the


best way of doing this. So, when I start working with other people to

create


services, we're doing it the "right" way.

----- Original Message -----
From: "Dorner Thomas" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 12, 2004 7:01 AM
Subject: AW: Best Practices?


You are right - if you will do a interoperable webservice that deal with other clients (.Net ...) its better to go from the wsdl.

But when i use String, int and so on and i generate a wsdl by
java2wsdl, I hope the wsdl i get, depends on the standard spec.
for wsdl!????

So there should no problem to use the wsdl by other languages!???

Dont know how it looks with complex datatypes!????

Do you all write your own wsdl by hand????

Tomi

-----Ursprüngliche Nachricht-----
Von: David Cunningham [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 12. Mai 2004 13:14
An: [EMAIL PROTECTED]
Betreff: RE: Best Practices?


I disagree, the right way is to start with your WSDL and schema files. If you want any hope of being WS-I compliant or using doc/literal this is

your


best bet. As soon as you start with an interface, you start dealing Java
types that do not correlate to schema types very well. For example, if you
use: public List getStuff() or public String[] getStuff(), you will either
generate a WSDL file that can't be parsed properly by other consumers

(.NET,


Glue, etc) or be bound to Java collection types that have no chance of

being


parsed properly by .Net (without a lot of hacking around).

My recommendation, again personal preference, is always give thought to

the


XML that is going across the wire and what you are trying to send/receive
and in what structure. This is especially important when dealing with
doc/literal since you are sending a single document over the wire.

- david

-----Original Message-----
From: Dorner Thomas [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 12, 2004 2:03 AM
To: '[EMAIL PROTECTED]'
Subject: AW: Best Practices?

The right way is to write a interface which includes all the Methods your
webservice should offer.

Then you use java2wsdl to generate your wsdl. You have to correct your
parameternames in your auto generated wsdl, cause the the params looks

like


in0, in1, in2... .

Then you use wsdl2java to generate your stub, locator, skeleton, impl and
maybe a testclient.

Now you can implement and deploy your Service by unsing the addtional
generated .wsdd files.

Hope this helps you

Tomi

-----Ursprüngliche Nachricht-----
Von: Joe Plautz [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 11. Mai 2004 18:48
An: [EMAIL PROTECTED]
Betreff: Best Practices?


I'm a newbie looking for guidance in creating WebServices with Axis. I've gone through the documentation backwards and forwards and have come up

with


me own ways of doing things. I start with a WSDL that I create and use
WSDL2Java to generate the code and go from there. What I'm looking for is

a


best practices because I don't feel confident in the way I am going about
it.

Do most people start from a WSDL? Do people generate a WSDL from an
interface and go from there? Do people just create a class and a WSDD

file?


Or, do people use JWS files that accept a string and the string contains

xml


formated text?

If there are any sites that cover this information, please forward them on
to me.

Any help will be appreciated!!!

Thanks,
Joe Plautz
[EMAIL PROTECTED]








Reply via email to