• Post Reply Bookmark Topic Watch Topic
  • New Topic

Relationship between WSDL and service  RSS feed

 
Sameer Parihar
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello all

Very recently I stumbled upon something that I did not expect probably because of my lack of knowledge.

We are hitting a web service developed by a third party and during QA phase we were given end point URL for the web service and told that we need to call "process" operation. So, we just did "?wsdl" to the end point URL and got the WSDL and generated client artifacts from the WSDL and the handshake worked for the "process" method. Everything is fine till here.

QA END Point URL - https://xxxxqa.corp.com/xxxx-ear-xxxx-ejb-1.0-SNAPSHOT/xxxxService.

Did "?wsdl" to get the following WSDL URL - https://xxxxqa.corp.com/xxxx-ear-xxxx-ejb-1.0-SNAPSHOT/xxxxService?wsdl.


Now, when we were gearing up for production movement, we were told that end point for production is different, and we need to call the same method "process".

Production end point URL (notice that qa text is not absent) - https://xxxx.corp.com/xxxx-ear-xxxx-ejb-1.0-SNAPSHOT/xxxxService.

So, we assumed that everything is going to be the same so just used the QA generated artifacts and used production WSDL URL to call method "process".

But, the "process" method was no where in the web service definition (production WSDL). We reported to them and they replied that just change the end point URL in QA WSDL and you are good to go. You should be able to call "process" method.


That indeed is true. We just changed the end point URL in QA WSDL and even though the production WSDL URL does not have any "process" method, the call went successful.

We are still not sure how it worked and why. The resolved production WSDL URL does not show any process method and yet we are able to make a successful call. Can someone please clarify what is going on here ?








 
Karthik Shiraly
Bartender
Posts: 1210
25
Android C++ Java Linux PHP Python
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Sameer, a warm welcome to CodeRanch!

From the description, it seems to me that "Production_url?wsdl" serves just a dummy WSDL.
"QA_url?wsdl" is the true WSDL which is used by their own service implementation (which is listening on the production endpoint URL), as well as your WS client.
So protocol wise, there isn't any actual inconsistency between server and client.
Since they seem to be aware of this, I guess it's done deliberately. Perhaps a security by obscurity thing, like they don't want random people on the internet getting their production WSDL and making requests.
 
Sameer Parihar
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Karthik.

It amuses me now. Is's production_url?wsdl pointing to the production end point ? How is it not possible that it is not pointing to the production end point.

Also would you please let me know what you meant by "QA_url?wsdl" is the true wsdl ? How would have they made production endpoint to use qa_url?wsdl ?
 
Karthik Shiraly
Bartender
Posts: 1210
25
Android C++ Java Linux PHP Python
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is "production_url?wsdl" pointing to the production end point ? How is it not possible that it is not pointing to the production end point?

If I'm correct in my guess that the WSDL served from "production_url?wsdl" is a dummy, then the <soap:address> endpoint URL in it too can be any random garbage URL, is it not?
It could even be the actual production endpoint, but if anybody generates a WS client from that dummy "production_url?wsdl", they certainly won't be able to call "process()" against that endpoint.

what you meant by "QA_url?wsdl" is the true wsdl ? How would have they made production endpoint to use "qa_url?wsdl" ?

The process of developing a WSDL web service by the provider company's developer goes like this (in a top down approach):
  • Developer writes a WSDL file.


  • Developer generates server side java classes from that WSDL file using some framework's generator.
    This is similar to how you generated client classes, but because you didn't have their original WSDL file, you had to get it from "qa_url?wsdl".


  • Developer publishes that service at "qa_url" as well as "production_url" endpoints.


  • "qa_url?wsdl" is configured to serve the exact same WSDL file that the developer used.
    This is what I meant by "true WSDL". It's an exact copy of the original WSDL file used by the service developers themselves


  • "product_url?wsdl" is configured to output a dummy WSDL file with a dummy endpoint.
    I believe this is possible with all frameworks, including Axis and CXF.
    After all, it's just a HTTP URL, and can be configured or intercepted to serve any garbage content.


  • Regarding your second question, "?wsdl" URLs are meant only to help client side developers generate WS clients.
    The server side developer does not "use" any "?wsdl" URL to develop their services. They directly use the WSDL files they wrote.


  •  
    Sameer Parihar
    Greenhorn
    Posts: 4
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    If I'm correct in my guess that the WSDL served from "production_url?wsdl" is a dummy, then the <soap:address> endpoint URL in it too can be any random garbage URL, is it not?


    No it is not. This "production_url?wsdl" is actually pointing to correct production endpoint. And certainly, if I generate WS clients from "production_url?wsdl", there is not going to be "process" method in the generated artifacts, so you are correct.


    I guess I have never developed a web service before so I failed to think what they might have done.

    "product_url?wsdl" is configured to output a dummy WSDL file with a dummy endpoint.
    I believe this is possible with all frameworks, including Axis and CXF.


    I would like to do it my self for the sake of understanding and knowledge . But is it really common enough practice that the frameworks do have this as a feature to disguise ? Also, would they have been able to do this had they opted for bottom up approach (starting with java classes and generate WSDL) ? I would like to know what to search on google to understand what needs to be done to configure 'production_url?wsdl' to output a dummy WSDL
     
    Karthik Shiraly
    Bartender
    Posts: 1210
    25
    Android C++ Java Linux PHP Python
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I have never developed a web service before so I failed to think what they might have done.

    Start by writing a simple JAX-WS service. I think it'll clarify many things for you, most importantly that the WSDL file is just a specification, the WSDL URL is just documentation for clients and once server/client classes are generated from them, they are not really required by the service or client for actual WS communication.
    If you want something realistic, download that WSDL you're already using from "qa_url?wsdl" and generate server side artifacts.
    Service implementation can just be some println statements.

    is it really common enough practice

    Since my experience with B2B web services is almost nil, I can't really say if it's a common practice. But then frameworks in any domain will always have obscure features which are hardly used.

    would they have been able to do this had they opted for bottom up approach

    Sure. It's important to understand that a "?wsdl" URL is just documentation served from a HTTP URL.
    Think of it as a web page, where you can serve any sensible or nonsensical content.
    It just so happens that most of the time it serves the correct WSDL content, but that's not mandatory.
    Whether a WSDL was written first or generated last from java classes has no connection to what is served from a "?wsdl" URL.

    what to search on google to understand

    - If you're using some framework like Axis, search for "<framework> disable WSDL URL" or "<framework> intercept WSDL URL"
    - If a web service is hosted in a servlet container or application server, then any HTTP URL can be intercepted using a "java web application filter" (search for that if you're not familiar with web app filters), or intercepted in a front end proxy server (like nginx/apache).
     
    Sameer Parihar
    Greenhorn
    Posts: 4
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I am so glad you replied to each question. Thanks a bunch.
     
    It is sorta covered in the JavaRanch Style Guide.
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!