we've been looking at the web server side of things so far now let's switch back to the client side and uh learn about WS import which is a tool we use to generate client stubs previously we did a WS import early in this tutorial Series where we used a free external web service and of you know visal associated with it that was available online it was just a random choice but now we will switch to our own web service and write a client for the web service that we have written which is the testmart web service you already taken a look at the Ws import utility that comes with the jdk when you run WS import with the visal URL it creates some handy classes which are called stubs that hide the the web service calling complexity for you which just call a method on this generated class and then that class does the complete web service call and gives you the response as a return type so the stops have one method for every web service operation so calling any web service operation making any web service call is literally as simple as calling a method on that generated class there are a few things you can do while WS importing that uh helps you customize how the tool generates these stubs for you so we'll take a look at some of those options now so open the command prompt and navigate to a temporary folder any folder will do we're just using this to generate the classes and then will copy to our Eclipse workbench uh we already seen the basic command it's WS import options and the Vistal the options here is optional there are configuration options which change the way WS import behaves but at the very minimum you need to enter the location of the Vistal the location could be a web address like HTTP some web application.com webservice question mark wizd or it could be a local file on the file system both would work but I would definitely recommend using the first approach right using an external URL whenever possible so make sure whenever possible you use an external HTTP visal URL as an input to WS import rather than using a local file URL we'll take a look at why in the next tutorial I'll copy the visit URL for our test Mar service and run WS import now the tool passes the visal and generates all the necessary types so here it is generated two directories containing the classes this is because of the two package names now let's say you save the visual file on your hard drive and run WS import do you think that'll work well let me save the file here I'll save the visal file to a local directory which is the same directory that I'm running uh WS Import in it's the same directory that I'm already in so I'll run WS import product catalog. Vistal notice that it's still works now why am I mentioning this the reason is that the Vistal file the file that I've saved locally just now is not the complete web service definition it's only a part of the web service definition if you remember the visl file refers to types which are in a separate XS file so I didn't save those now I just saved the visist file but WS import is actually smart enough to detect that right it starts with your local visal file but then if there is any references to xsd files which are in HTTP locations it looks that up in their right HTTP locations now let's take a look at some import options you already seen the directory option-d that lets you specify the output directory where you want the generated classes to go and we've seen the dash keep option which lets WS import to save the source files by default WS UT deletes all the Java files after it compiles them but if you use the dash keep it saves the Java files also and then you have the- S and the directory DD lets you specify the directory Dory where you want the class files to be saved and- s directory specifies where you want the source. Java files to be saved as you can imagine if you use the- S option it'll automatically turn on the keep flag there are a couple of U other obvious options here you have Dash verbos which makes the tool give more detailed output and then the dash qu which gives little output these two do not have any effect on the output classes themselves they just the console output that gets generated when the Tool runs now let's take a look at a couple of options that do affect the output classes there is a-p package name now take a look at the output classes that it's generated by default they're in the package ar. kosic javab brains because that's the package that I wrote the web service in of course I did some overrides uh I specified the package name com. testmart and all those have gone to the com. testmart package basically it's the package that the web service belongs to right so what initially happened was when I deployed the web service the package was picked up into the vidil as name spaces when the visil was generated now when I'm running a WS import that is again automatically getting picked up as package names by the wsimport output so it's all linked but if you need to override this during the WSM boort you can change the package name of the generated classes by using the dash P option for example if I use wsimport DP uh let's say ar. kosic do generated as the package name right so the classes will all be over here the tool forces all the packages uh to be off the specified package name next let's take a look at the dasb parameter now every program that generates Java code carries with it kind of like an implicit responsibility the responsibility that the code that it generates has to compile as we've seen WS import generates Java code and it compiles it so can this tool the Ws import tool guarantee that the code that generates will compile fine well unfortunately doesn't provide that guarantee uh we'll take a look at the code that ws import generates later but as you can imagine it uses a lot of names as type names same as what is used in the Vistal right the class names that it generates it copies the names from the type names in the Vistal so an XS type name becomes a corresponding generated class name now in some areas Java is stricter when it comes to names than xsd xsd is a bit more forgiving so when you run into cases like that we have a problem because some names that might be valid in xsd might not be valid on the Java side so when WS import generates the code using those names the resultant code will be generated the Java files will be generated but when it tries to compile them you get a compile error the result in code will not compile so like I said the common problem is with the type names you can have multiple schema types that use the same name but when they end up on the Java side when they get converted to corresponding Java classes if they end up being in the same package well that's a compiler error the compiler is going to complain So to avoid this problem you can use what are called as binding files so binding files are XML files that let you specify custom overwrites to the way the code is generated by WS import you can override certain names you can override certain ways in which the code is generated I'll not be going into the details of binding files but I do encourage you to look them up you can do things like configuring a specific xsd type to have a specific Java class name of your choice instead of the default xist type name you write all these uh overrides in an XML file which is The Binding file and and then you supply that to wsimport with this dasb option so you say wsimport DB your uh binding file name and then your visal file as usual and there are a lot of customizations you can do here the- P option we saw before let's you customize just the package name but this dasb option lets you customize a whole lot more and it's very handy when you have you know Troublesome Vis files like this which leads to Java classes which don't compile okay so in the next tutorial we're going to take a look at two more options related to the wsdl location that you should definitely know about they address a specific problem in the way the Java client works and we'll understand what that is see you in the next tutorial and thanks for watching