Hey gang,
Time for my two cents. We've been using Axis 1.2 alpha builds since
November '03 to build WS-I compliant document literal web services. How is
this possible? Here's our cookbook:
1) Create XML schema in Altova XMLSpy that defines the datatypes that the
web service is to exchange.
2) Define a second XML schema in XMLSpy that defines "Request and Response"
types for each operation you wish to define. This second schema imports and
references that types defined in schema #1, thereby "wrapping" your
datatypes in additional request and response elements.
3) Create document literal WSDL in XMLSpy that imports schema #2, referring
to the Request and Response types in the WSDL message parts.
4) Run WSDL through a WS-I conformance test tool such as Mindreef SOAPScope.
5) Run Axis 1.2 alpha WSDL2Java, either by command line invocation or as an
Ant task on the valid WS-I compliant WSDL.
An example:
java org.apache.axis.wsdl.WSDL2Java -o .\build\wsdl2java-output -a -s -t -T
1.2 .\resources\MyDocLiteralService.wsdl
6) Take WSDL2Java deploy.wsdd deployment descriptor and paste it into a
server-config.wsdd. Compile code, deploy service.
Some notes:
a) Why the two schemas? Well, we don't like defining "Request and Response
wrapping" types in the same schemas we use to define our core domain
datatypes. We use the two separate schemas to abstract the SOAP
request/response wrappers from their payloads.
b) To <wsdlFile> or not to <wsdlFile>? It's a trade off either way. If
you DO choose to specify your own <wsdlFile> in the deployment descriptor,
you then have to worry about the following:
- Included schemas cannot be referenced on a local file system, as they
most likely were during WSDL2Java processing. You must not actually host
your schemas somewhere and refer to the with URLs.
- Endpoint location URLs need to be modified per deployment, since you
don't want your production WSDL to reference localhost:8080.
If you do NOT choose to specify your own <wsdlFile> Axis will include all of
your nice, neat XML datatypes defined in multiple schemas DIRECTLY into your
WSDL <types> element when it autogenerates the WSDL. If this is not a
showstopper for you, the Axis autogenerated WSDL might possibly be invalid
or not WS-I compliant - make sure you inspect it carefully.
Either method creates a burden for us developers.
c) Target namespaces: we've had success defining the WSDL + domain schema +
wrapping schema in either the same target namespace, or each in their own
namespaces. It's up to you.
d) Namespace to package mapping: this is a skill acquired through trial and
error. To have WSDL2Java generate code in specific packages, you need to
specify namespace to package mappings. We automate the whole mess through
Ant by specifying a mapping file:
<axis-wsdl2java
all="true"
output="${app.build}/wsdl2java-output/"
verbose="true"
serverside="true"
testcase="true"
noWrapped="true"
namespacemappingfile="${app.build}/properties/nsmappings.properties"
typemappingversion="1.2"
url="/resources/MyDocLiteralService.wsdl"/>
In any case, since you are essentially generating the Java types (read:
JavaBeans, value objects, whatever you call them) you will need your web
service implementation to work with from your schemas, you will have to have
some logical manner of taking the generated code and including it into your
codebase. We're paranoid that some developer is going to regenerate from
WSDL and hose our existing codebase, so our build scripts dump WSDL2Java
output into a neutral directory for us to manually copy into our src tree.
<philosophy>
To me, document literal services implies a whole new way of thinking about
web services - both from the development perspective and the architecture
perspective. No longer are we using java2wsdl to simply provide a RMI over
http - the mentality of "take your Java class and expose it as a web
service" should be combated wherever encountered.
The WS-I religion is based around coarse-grained "document oriented" web
services. I hand a web service a document, and it hands me one back after
performing some processing (not necessarily synchronously, either - it is
possible to do asynchronous SOAP messaging over HTTP!). If you think of it
from that perspective, your entire mentality towards what problems they can
actually solve changes - in addition to how you build them.
</philosophy>
Hope this helps guys. Pass it on.
-Jon
-----Original Message-----
From: Marepalli, Somesh [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 16, 2004 9:25 AM
To: [EMAIL PROTECTED]
Subject: RE: Doc/Literal support in axis
If you have taken the pains to hand craft a WSDL and make it WS-I
compliant, you might as well specify it in the .wsdd file with the
<wsdlFile> tag. That way, you can override the generation of the WSDL
from service by Axis...
-----Original Message-----
From: David Bell [mailto:[EMAIL PROTECTED]
Sent: Monday, March 15, 2004 6:35 PM
To: [EMAIL PROTECTED]
Subject: RE: Doc/Literal support in axis
We are using doc/literal support as well in Axis 1.1.
To cater for compatible implementations (Axis, JAX-RPC, .net) we have
defined the WSDL outside of the tools - it is handcranked to define the
contract and then separate groups can build their own clients and
servers using whatever technology they want (as long as it works !).
The downside is that the WSDL handed back by the service, when you
query it, is not (unsurprisingly) either WS-I compliant, or acceptable
to most of the tools, so code does not generate properly - I guess this
concurs with other folks experiences.
- David
--
David Bell
Sun ONE Solution Design Consultant
Professional Services
Sun Microsystems Tel : +44 7876 396719
Java House Fax : +44 1252 420126
Guillemont Park
Minley Road email : [EMAIL PROTECTED]
Blackwater
Camberley
GU17 9QG
