Hi Arthur and thanks for the response as well - so just as I thought ...
Axis for example
uses the WSDL file to generate appropriate stubs for invoking a service
(based on
the binding). My pt was along the same lines, that without prior
knowledge of the remote
service, parsing the incoming WSDL file the client should be able to
determine the binding
type and to take appropriate actions to invoke it - SOAP or REST or
whatever else.
Do you agree?
Arthur Ryman wrote:
Demetris,
Sagara is correct. WSDL 2.0 lets you describe a Web service abstractly
by defining its <interface>. You then define one or more <binding>s
for it to describe the concrete protocol used to invoke it.
There is a binding types for SOAP:/ http://www.w3.org/ns/wsdl/soap/
REST uses the HTTP binding: /http://www.w3.org/ns/wsdl/http/
These are described in Part 2 of the spec. [1]
-- Arthur
[1] http://www.w3.org/TR/wsdl20-adjuncts/
On Mon, May 3, 2010 at 12:56 AM, Demetris <[email protected]
<mailto:[email protected]>> wrote:
Hi Sagara,
sorry if my original posting was a bit confusing. You are indeed
providing some good information below and in fact
I am aware of most of it. To say it in simpler terms, if a client
is retrieving WSDL files from a set of remote sites
without knowing if what they describe is a deployed service is a
SOAP service or a REST service, can the
client know by inspecting the WSDL document such a type? My
feeling (and as you may be suggesting below)
that this is not a reliable method to find such a difference as
descriptions of these services may yield identical
WSDL documents. Is this correct? But I do see that SOAP
descriptions usually carry either a SOAPAction
or a soap operation tag - is this always the case or not?
Thanks again
Sagara Gunathunga wrote:
I' m not sure what is the exact problem you have here,
basically WSDL 2.0 Interface is used to describe abstract
interface of a service (contract) and it's common for both
SOAP and REST. WSDL 2.0 Binding component describe how to
access above interface using a concrete protocol like SOAP ,
HTTP etc.
Following link [1] describe WSDL 2.0 SOAP 1.1 binding that
can be used to provide required details in order to access the
service using SAOP 1.1 protocol , WSDL 2.0 HTTP binding [2]
describe details required to access the service using HTTP
protocol ( REST ) , in WSDL level this is the mechanism to
describe REST and SOAP services, I guess this make sense.
BTW each WS engine use their own techniques to distinguish
SOAP and REST invocations at run time , As an example Axis2
basically assume absence of SAOP structure in a incoming
message as a REST invocation. But this is not relevant to WSDL
description .
[1] -
http://www.w3.org/TR/2007/NOTE-wsdl20-soap11-binding-20070626/
[2] -
http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626/#http-binding
Thanks,
On Sun, May 2, 2010 at 9:34 AM, Demetris <[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>> wrote:
Hi all,
what is (or are) the particular and specific difference
between
a SOAP serv WSDL 2.0
description and a REST serv WSDL 2.0 description that will
make a
parser (or a flag
setter) distinguish between the two? Would the existance of the
keyword 'soap' in the former
case be such an indisputable evidence? The ports may be?
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
For additional commands, e-mail:
[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
--
Sagara Gunathunga
Blog - http://ssagara.blogspot.com
Web - http://people.apache.org/~sagara/
<http://people.apache.org/%7Esagara/>
<http://people.apache.org/%7Esagara/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
<mailto:[email protected]>
For additional commands, e-mail: [email protected]
<mailto:[email protected]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
