http://people.apache.org/~hughesj/woden/WodenWSDL2Processor_WE12.pdf
This is a sample WSDL 2.0 file:
service has binding, binding has interface, interface has operations, operation has input and output (and fault)
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:description targetNamespace="http://new.webservice.namespace" xmlns:wsdl="http://www.w3.org/ns/wsdl" xmlns:wsoap="http://www.w3.org/ns/wsdl/soap" xmlns:whttp="http://www.w3.org/ns/wsdl/http" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://new.webservice.namespace">
<wsdl:types>
<xs:schema targetNamespace="http://new.webservice.namespace" elementFormDefault="qualified">
<xs:element name="NewMessageRequest" type="xs:string"/>
<xs:element name="NewMessageResponse" type="xs:string"/>
</xs:schema>
</wsdl:types>
<wsdl:interface name="NewInterface">
<wsdl:operation name="NewOperation" pattern="http://www.w3.org/ns/wsdl/in-out">
<wsdl:input messageLabel="In" element="tns:NewMessageRequest"/>
<wsdl:output messageLabel="Out" element="tns:NewMessageResponse"/>
</wsdl:operation>
</wsdl:interface>
<wsdl:binding name="NewBinding" interface="tns:NewInterface" type="http://www.w3.org/ns/wsdl/soap" wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/">
<wsdl:operation ref="tns:NewOperation" wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response/"/>
</wsdl:binding>
<wsdl:service name="NewService" interface="tns:NewInterface">
<wsdl:endpoint name="NewEndpoint" binding="tns:NewBinding"/>
</wsdl:service>
</wsdl:description>
This is the same service in WSDL 1.1 - notice the verbosity compared to 2.0:
service has binding, binding has porttype, porttype has operations, operation has message... what a mess!
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:tns="http://new.webservice.namespace" targetNamespace="http://new.webservice.namespace">
<wsdl:types>
<xs:schema targetNamespace="http://new.webservice.namespace" elementFormDefault="qualified"/>
</wsdl:types>
<wsdl:message name="NewMessageRequest">
<wsdl:part name="parameter" type="xs:string"/>
</wsdl:message>
<wsdl:message name="NewMessageResponse">
<wsdl:part name="parameter" type="xs:string"/>
</wsdl:message>
<wsdl:portType name="NewPortType">
<wsdl:operation name="NewOperation">
<wsdl:input message="tns:NewMessageRequest"/>
<wsdl:output message="tns:NewMessageResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="NewBinding" type="tns:NewPortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="NewOperation">
<soap:operation soapAction="urn:#NewOperation"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="NewService">
<wsdl:port name="NewPort" binding="tns:NewBinding">
<soap:address location="No Target Adress"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
I hate WSDL, and the whole XML paraphernalia created to implement distributed computing around the XML paradigm.
I am trying to understand why I hate this entire technology.
Being a Java developer, I like the extreme coherence of Data and Interfaces definitions implemented in Java:
if you break something, you will immediately notice at design time.
With XML and WSDL, you always have the impression of handling a wobbly jellyfish, overly complex and redundant, leaving open holes for ambiguity and crappy implementations.
In fact, in my own experience AXIS2, SOAPUI and Clientgen operate differently, a WSDL which works with the first 2 doesn't work in Clientgen.... CRAP!
http://en.wikipedia.org/wiki/Web_Services_Description_Language
In a WSDL you have DEFINITIONS of public services.
NAMESPACES are used to make names less ambiguous, and should regarded as packages. Their syntax in reality is obscure and ambiguous.
SERVICES are exposed in the service URL; http://host:port/WEB_CONTEXT_ROOT/service
A SERVICE is associated to a BINDING, which defines the protocol (SOAP) and the way to pass arguments (DOCUMENT).
in the BINDING you MAY redefine OPERATIONS, but they are already defined in the PORT TYPE.
OPERATIONS are associated at times with SOAP ACTION.
A PORT TYPE is a misnomer, in WSDL 2.0 it is called INTERFACE, which is what it actually is. It defines OPERATIONS (=method) and their MESSAGES (=parameters).
In TYPES there is the type definition of method parameters.
So all in all you have a very complex and articulated document to do very simple stuff:
defining ENDPOINTS, PROTOCOL, PUBLIC INTERFACES, DATA TYPES
Why all this could not be done in a simpler way....finally leaving the developer to rely on automated tools.... EJB 2.0 reloaded.... we already know that it will all end up in a EJB 3.0 where AT LAST the good stuff is done.... so why not do it since the beginning...
Let's look in Wikipedia the changes made in WSDL 2.0:
- Removal of message constructs
EXACTLY! There should be only OPERATIONS. MESSAGES are useless indirection.
- PortTypes renamed to interfaces
PortTypes are simply a list of Operations... so... call it Interface, no?
- Ports renamed to endpoints.
In fact it simply defines a URL for the Service
Furthermore, some definitions - like endpoint - have been inlined in WSDL 2.0, making the document more compact and readable.
WSDL 2.0 is barely tolerable, WDSL 1.0 is simply outrageous, my grand mother could have done a better job.
UNFORTUNATELY OSB 3.0 doesn't seem to recognize this WSDL 2.0 format, when I try to import the WSLD it complains about:
1 comment:
Explicit promotion ;)
For desperate Java developpers that have to request SOAP web-services, there is a new API available in a early version : http://soap-dust.sourceforge.net/
It fits in one jar.
It does not require to generate a bunch of Java code before requesting the web-service.
Until SOAP is definitely deprecated, this may be helpfull.
Post a Comment