Ross,
Ok, let me try to rephrase my point. Your WSDL+XSD (let's assume HTTP
binding using doc/lit) defines the document oriented messaging exchange
contract that your service adheres to.
Now implement that service with Perl.
Or C#.
Or Java.
You're a Java developer, and naturally you're used to modeling your data
types with Java classes. But in the SOAP Web Service based SOA world the
programming language you're implementing the service with is just a means to
end. The value of the SOAP Web Service lies in the documents that are being
exchanged, not in how the service is implemented. Is it not a logical
conclusion then to be focused primarily on modeling the documents that
you're exchanging?
I fundamentally disagree that it is now or ever will be a good idea to be
building SOAP Web Services from the programming language that you are
implementing them in outward. Doing so, even if the toolkits allow for it
to be done in an interoperable way, will lead developers to think of SOAP
Web Services as just another distributed OO technology - a mentality which
WS-I and the various working groups are decidedly trying to do away with.
Modeling the documents to be exchanged first, in my experience, leads to
coarser grained services - because it emphasizes that you are dealing with
XML message exchange patterns. This will hopefully lead to applications
using and consuming services in a much more loosely coupled way. Building
from the Java out, in my experience, leads to extremely fine grained
services and tight couplings between the apps using and consuming them.
How can Axis help?
XML <-> Java Binding engine pluggability would be a huge help. I'd like to
see an SPI that various binding engine providers could implement. The only
problem with this, as Jim Murphy pointed out, is that this has vast
implications on the WSDL2Java and Java2WSDL emitters - they would have to be
pluggable as well. Not sure if that's reasonable given that Axis leverages
IBM's WSDL4J. How is the JAX-RPC 2.0/JAXB 2.0 consortium addressing this
with their reference impl? Are they allowing for pluggable JAXB impls
only - or are they building such an SPI into JAX-RPC 2.0? Darned JCP... no
public visibility. :(
-Jon
-----Original Message-----
From: Yakulis, Ross (Ross) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 12, 2004 3:09 PM
To: [EMAIL PROTECTED]
Subject: RE: Best Practices?
But assume you use a java interface or class, the tools should warn you that
what you did is not compatible outside of the Java realm. Maybe there
should be an option to check for compatibility or not? What about
the -WSIBP option that generates wsdl for the WS-I BP and gives you errors
if your interface contains types that
do not map to xml types? As Anne says "...error impedance mismatch on java
type.."
or something :)
Ross
-----Original Message-----
From: Anne Thomas Manes [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 12, 2004 12:00 PM
To: [EMAIL PROTECTED]
Subject: RE: Best Practices?
Okay -- so you've already defined your interface. But if that interface
contains Java-specific types that don't map well to XML Schema types, then
you can't directly expose your current interface. You'll need to build a
wrapper.
There is an impedance mismatch between Java types and XML types. It's
something that we just have to deal with. When defining Web service
interfaces, you need to define the input and output messages in terms of XML
types.
My take-away from Ross's comments is that we need better tools for defining
an interface in terms of XML types. I agree with Ross that developers
shouldn't need to write WSDL definitions by hand. They should be generated
by tools. But that doesn't mean that they should be generated from Java
code. You should be using an XML Schema editing and modeling tool.
Anne
-----Original Message-----
From: Miller, Janet [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 12, 2004 1:58 PM
To: [EMAIL PROTECTED]
Subject: RE: Best Practices?
But many people already have a service in use internally that they would
like to expose to the outside world.
They have already decided what that service was supposed to do, the
arguments, etc before coding it during their initial development process.
Jan
-----Original Message-----
From: Pridemore, Russell (MAN-Corporate) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 12, 2004 1:39 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Best Practices?
I'm fairly new to web-services (and axis), but am a seasoned programmer.
Comparing web-services to other technologies, CORBA for instance, you always
started with the interface definition, never the code. I personally don't
find WSDL to be all that difficult to work with, even by hand, and there are
tools to help create it, as Anne has pointed out.
I guess my point is that how are you going to begin coding something before
deciding what it is supposed to do, what arguments it will require, etc.?
Personal tastes aside, the interface seems like the obvious place to start.
If WSDL is a burden to work with, that's not a criticism of Axis.
My $.02,
Russ
-----Original Message-----
From: Yakulis, Ross (Ross) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 12, 2004 1:30 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Best Practices?
Exactly, that is why Jonathan Anderson is on the wrong track. He describes
what he currently has to do. The real question is in the long run what is
the right way to do things and push for that and get Axis to migrate in that
direction. I personally still believe that writing wsdl files is for the
birds and should be avoided. Ultimately, only tools should be generating
wsdl files, scans for rare cases. If web services are not easy to create
and deploy they are generally not much better that their predecessors.
Ross
-----Original Message-----
From: Davanum Srinivas [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 12, 2004 10:14 AM
To: [EMAIL PROTECTED]
Subject: Re: Best Practices?
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]
> >
> >
> >
> >
> >
>
>
