[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 608
  • Last Modified:

Understanding WSDL

Source:  http://www.tutorialspoint.com/wsdl/wsdl_example.htm

Content of HelloService.wsdl file
-----------------------------------------
 
<definitions name="HelloService"
   targetNamespace="http://www.examples.com/wsdl/HelloService.wsdl"
   xmlns="http://schemas.xmlsoap.org/wsdl/"
   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
   xmlns:tns="http://www.examples.com/wsdl/HelloService.wsdl"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 
   <message name="SayHelloRequest">
      <part name="firstName" type="xsd:string"/>
   </message>
   <message name="SayHelloResponse">
      <part name="greeting" type="xsd:string"/>
   </message>

   <portType name="Hello_PortType">
      <operation name="sayHello">
         <input message="tns:SayHelloRequest"/>
         <output message="tns:SayHelloResponse"/>
      </operation>
   </portType>

   <binding name="Hello_Binding" type="tns:Hello_PortType">
   <soap:binding style="rpc"
      transport="http://schemas.xmlsoap.org/soap/http"/>
   <operation name="sayHello">
      <soap:operation soapAction="sayHello"/>
      <input>
         <soap:body
            encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
            namespace="urn:examples:helloservice"
            use="encoded"/>
      </input>
      <output>
         <soap:body
            encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
            namespace="urn:examples:helloservice"
            use="encoded"/>
      </output>
   </operation>
   </binding>

   <service name="Hello_Service">
      <documentation>WSDL File for HelloService</documentation>
      <port binding="tns:Hello_Binding" name="Hello_Port">
         <soap:address
            location="http://www.examples.com/SayHello/">
      </port>
   </service>
</definitions>

Open in new window



Q1:  see the above WSDL . I see we have defined
targetNamespace="http://www.examples.com/wsdl/HelloService.wsdl"
xmlns:tns="http://www.examples.com/wsdl/HelloService.wsdl"

My question is , do I need to keep them same value  always ?

Alternatively , Is this below also acceptable ?
targetNamespace="http://www.anything.com"
xmlns:tns="http://www.something.com"

0
cofactor
Asked:
cofactor
  • 12
  • 9
  • 2
1 Solution
 
objectsCommented:
you can specify whatever you want, just make sure its unique

http://oreilly.com/catalog/webservess/chapter/ch06.html
0
 
cofactorAuthor Commented:
>>>you can specify whatever you want, just make sure its unique

Ok ...so you support this is also valid  though they carry different values.

targetNamespace="http://www.anything.com"
xmlns:tns="http://www.something.com"

Ok . fine .

We know ,the following  elements are in  tns namespace because they got a tns  prefix like this ..
<portType name="Hello_PortType">
      <operation name="sayHello">
         <input message="tns:SayHelloRequest"/>
         <output message="tns:SayHelloResponse"/>

      </operation>
   </portType>


Similarly , how do I find which elelment goes to targetNamespace  here ?

As you see we have now defined two different  namespace i.e  targetNamespace  and xmlns:tns . how do I find which elelment goes to targetNamespace   here ?

is there any prefiix targetNamespace   also ?  
0
 
objectsCommented:
no, I meant the targetNamespace needs to be unique
the value of targetNamespace and xmlns:tns should be the same
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
cofactorAuthor Commented:
>>>the value of targetNamespace and xmlns:tns should be the same
Thanks . That answer my question.

Here is two more doubts in this same WSDL.

Q2:
<message name="SayHelloRequest">
      <part name="firstName" type="xsd:string"/>
   </message>
   <message name="SayHelloResponse">
      <part name="greeting" type="xsd:string"/>
   </message>

When we generate the java code from this WSDL . Are these messages SayHelloRequest and SayHelloResponse becomes the java class name  ?
 

Q3:

see the messages again
   <portType name="Hello_PortType">
      <operation name="sayHello">
      <input message="  tns:SayHelloRequest"/>
      <output message="tns:SayHelloResponse"/>    
</operation>
   </portType>

The tns prefix is missing in the message definition here . Why ?
see  this ..
<message name="SayHelloRequest">      
<part name="firstName" type="xsd:string"/>
  </message>
  <message name="SayHelloResponse">      
<part name="greeting" type="xsd:string"/>
 </message>


Can we modify the above message definition to include tns this way ?

<message name="tns:SayHelloRequest">      
<part name="firstName" type="xsd:string"/>
   </message>
  <message name="tns:SayHelloResponse">      
<part name="greeting" type="xsd:string"/>
   </message>


   
N.B:points increased
0
 
colr__Commented:
Q2 - if you are using JAXB, then yes
Q3 - they are both the same, by specifying targetNamespace you are explicitly setting the default namespace, which the message elements belong to. So the answer would be yes
0
 
cofactorAuthor Commented:
>>>if you are using JAXB, then yes

I'll be using WSDL2Java tool provided by Axis 2 . Does that use JAXB ?
0
 
colr__Commented:
I don't think it uses JAXB, however I'd be surprised if the Axis generated classes were not also named the same as the message name as defiend in the WSDL.
0
 
cofactorAuthor Commented:
>>>I don't think it uses JAXB
Yup. I see JAXB is not in the list .

WSDL2java has this option
 
-d <databinding>   Valid databinding(s) are adb, xmlbeans, jibx and jaxbri (Default: adb).
Source:    http://axis.apache.org/axis2/java/core/docs/reference.html
0
 
cofactorAuthor Commented:
Here is some more doubts . I dont find concrete answers to these.

Q4:
Please look at the same WSDL . We have..

<portType name="Hello_PortType">
   <operation name="sayHello">
      <input message="tns:SayHelloRequest"/>
      <output message="tns:SayHelloResponse"/>
   </operation>
</portType>

How does portType  is maaped in java world ?  Shall we get the Class name Hello_PortType  after a WSDL2Java execution  . What this Class mean ? What  is this Class ?

Q5:

Please see the location attribute

<service name="Hello_Service">
      <documentation>WSDL File for HelloService</documentation>
      <port binding="tns:Hello_Binding" name="Hello_Port">
         <soap:address
            location="http://localhost:8080/soap/servlet/rpcrouter"/>      </port>
 </service>

Can we specify any location I wish ? OR   It has to be from the server path ?

Q6:

How do we recognise the service name "Hello_Service"  in java world ? Will it be the Service Skeleton class ?

<service name="Hello_Service">
      <documentation>WSDL File for HelloService</documentation>
      <port binding="tns:Hello_Binding" name="Hello_Port">
         <soap:address
            location="http://localhost:8080/soap/servlet/rpcrouter"/>      </port>
   </service>

0
 
cofactorAuthor Commented:
points increased to 400
0
 
colr__Commented:
Q4 - the port type is the implementation class of the web service. This is not a java-implementation, it provides the implementation details of the web service within the WSDL. Think of this is a 'port' to the web service, not any particular methods, but the web service itself. With that in mind, you would have code something like the following:

       
Hello_ServiceService service = new Hello_ServiceService();
        Hello_ServiceSEI port = service.getHello_ServicePort();

Open in new window


then once you have the port object, you can call methods relating to specific methods:

       
port.sayHello();

Open in new window


Q5 - doesnt have to be the server where the wsdl comes from, but typically will. IT is for listing ALL the locations where the endpoint can be found, so could be a list of endpoints.

Q6 - this is the first line of code in my answer to Q4 above - the service is where you get the port from.

Note that the class names Ive listed above may be slightly different, but it will be along those lines. It's usually easy enough to find the class you are looking for as the word 'Service' will be appended to the of the service class typically. And within the servic class there will be overloaded getXXXport() methods.
0
 
cofactorAuthor Commented:
I have gone through your comments. have some queries on your comments.

>>> the port type is the implementation class of the web service. This is not a java-implementation,

Does that suggest that we wont see any generated class with name  Hello_PortType ?

I'm bit confused to see that operation are kept  under <portType name="Hello_PortType">  BUT  NOT  under  <service name="Hello_Service">

My expectation was ,  operation are service methods and so they should be under service i.e <service name="Hello_Service"> .  Do you know why its  not as per expectation ?




>>>>doesnt have to be the server where the wsdl comes from, but typically will.

Does that mean I can put  anything in location field ?

Say , for example say I put google.com  in the location field

<soap:address location="http://google.com:8080/soap/servlet/rpcrouter"/>

Definitely  google.com is not in my server path .  Will this updated location  still work for my service ?

>>>It's usually easy enough to find the class you are looking for as the word 'Service' will be >>appended to the of the service class typically.

Is this a client ( Stub ) class or  a Skeleton class   you are talking about  here?  You know,from a given WSDL you can generate a Service Skeleton  or a Client Stub  or  both. Which one you point here ?

 
0
 
colr__Commented:
Sorry, my bad - the binding section provides the implementation specifics, NOT the portType section. We use the word imlpementation here completly seperatly from java though. Think of the client - he views the wsdl and doesnt know about any java/c# supporting it. As far as he is concerned, the implementation details (i.e. the specifics of the web service) are available in the binding section.

The portType presents the web service as a set of named operations. These named operations correspond to methods in your java-implementation class. There will be a Hello_PortType interface that has a method for each one of your operations.

The service section is about the endpoints, NOT the operations. Think of it this way:

service - describes the service endpoint only
binding - provides the 'implementation' details of this service. It also lists the operations as it provides implementation details for these too - encoding used etc.
portType - akin to a java interface, defines the operations available
0
 
colr__Commented:
As for the server part, it's to provide details to clients of where the web service is available. You can have the web service deployed to more than one location in a production environment, so you could list all of them so the client has alterbatives if it finds one isnt available. This section is also used by tools that automate client generation - such tools hard code the url given into the generated client as the ednpoint location.
0
 
cofactorAuthor Commented:
>>>binding - provides the 'implementation' details of this service.
 <soap:binding style="rpc"
      transport="http://schemas.xmlsoap.org/soap/http"/>
   .................................
         <soap:body
            encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
            namespace="urn:examples:helloservice"
            use="encoded"/>


what other transport protocol I can write in the above apart from http  ?
transport="http://schemas.xmlsoap.org/soap/http"/>



>>>such tools hard code the url given into the generated client as the ednpoint location.
I dont get you . My question was simple .. I'm reposting here.
Q5:
Please see the location attribute ..
<service name="Hello_Service">
      <documentation>WSDL File for HelloService</documentation>
      <port binding="tns:Hello_Binding" name="Hello_Port">
         <soap:address
            location="http://localhost:8080/soap/servlet/rpcrouter"/>      </port>
 </service>

Can we specify any location I wish ? OR   It has to be from the server path ?
If you say it need NOT be a server path , then I could hard code the url anything I like ..right ?  For example, I could hard code there say
<soap:address location="http://google.com:8080/soap/servlet/rpcrouter"/>
Is this ok ?
0
 
colr__Commented:
You can also use smtp as the protocol. The location can be anything, provided you have an endpoint there! The point I was making is that you can deploy the exact same endpoint to a number of locations - you would list EACH of these locations in the service address section. You cant specify google.com as you dont have an endpoint at that address, so it would be invalid.
0
 
cofactorAuthor Commented:
>>>The location can be anything, provided you have an endpoint there!

How do I Test I have an endpoint there ?  


0
 
colr__Commented:
I dont understand what you mean - you will only have an endpoint there if you put one there, so why would you need to test this? The deployer should know where he has deployed the endpoint. So there wouldnt be any point in testing against google.com unless you have access to the google.com domain and are able to deploy your endpoint there!

If you want to test that the url is correct and it is up and running, then simply put the address into a browser and you should get back a response (a simple web page that lists the operations available).
0
 
cofactorAuthor Commented:
>>>I dont understand what you mean  
I'm getting confused  location  vs  endpoint  ..Are they same thing ?

Let me ask you other way around...couple of very simple questions to get this information straight..

(Assume, I DONT have access to google.com domain) .  

Can I keep any url  I like in service and client's location field ?

service:
Service location <soap:address  location="http://google.com:8080/soap/servlet/rpcrouter"/>  

Client
Client of this service also using the  same url : http://google.com:8080/soap/servlet/rpcrouter  to connect  .

Will  he able to connect ?  YES /NO


If your answer is "YES" ,  I have no issue.
If your answer is "NO" ,   then the question is  why ? And what is the constraint I should remember while putting the value for the location field ?
0
 
cofactorAuthor Commented:
comments please
0
 
colr__Commented:
I've already answered that - the answer is NO, you cant use just anythnig in the location field - it has to be the address where your web service is deployed! Both the wsdl on the server and the client will use this address, and it MUST be the valid address where you are hosting the web service.

The 'location' is the address at which youur web service is available - otherwise known as the 'endpoint address'.

The reason the answre is NO is because it is the location of the endpoint. If you have deployed your web service at that location, then that is where it is, it isnt somewhere else?!?!?

Think of it this way - if I put a package for you in the kitchen, then tell you it is in the bathroom, will you find it? No - the same goes for the web service, it is accessed and so is only available through the address where you deploy the web service - a URL.

The only constraint you need to remember is that the location is where you have put the web service!

I cant honestly make it any simplere than that. If you are struggling with this basic concept, I suggest you need to do some more reading on the basics of web services.
0
 
cofactorAuthor Commented:
>>>>I've already answered that - the answer is NO, you cant use just anythnig in the location field

Excellent.  I'm just ok with this.

The confusion started because you made a contradictory comment earlier as follows ....
doesnt have to be the server where the wsdl comes from, but typically will.
The location can be anything,


Well, Anyway, confusion is cleared now. Thanks.
0
 
colr__Commented:
Thanks ;)

I should point out though, that when I said this - "doesnt have to be the server where the wsdl comes from, but typically will", this is still actually correct and not contradictory.

It it possible to deploy the exact same web service in multiple locations and on different servers/domains. In such a case you would have a list of addresses where the web service is available - each of these addresses can then be listed in all of the wsdl's.

tbh you can probably ignore this intracacy though, it's an exotic setup if you are just starting out with web services.
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

  • 12
  • 9
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now