XSD to Web Service

[Wm. Scott Miller]

I have to interact with a web service created by an external company. That
company doesn't have a WSDL. They have supplied me with a XSD and some
samples of both requests and responses to/from their web service. They are
using SOAP to package XML that adheres to the XSD they supplied. How do I
go about creating a client app in .NET to use the web service using what I
have? Is there a way to create a WSDL and/or proxy class to access the web
service and how do I go about creating that in .NET?

So far I've used XSD.exe to create a class file.

Scott

 

[Wm. Scott Miller]

FYI:

1. Use XSD.EXE to generate a class file.
2. Create a new webservice on local machine that mimics server interaction
using class file from XSD
3. Surf to webservice?WSDL to get WSDL file.
4. Modify WSDL to now point to external server address.
5. Generate your client app from modified WSDL.

 

[jhgonzales]

Scott,

Could you elaborate on how to "mimic server interaction" using the class file?

I actually, like you, have an xsd that I would like to create a web service
from. I was able to generate the class file, but is there any other way of
doing this. Say for example, the schema (xsd file) could change. I'd have to
create a new class file if that were to happen. How could I "dynamically"
incorporate the xsd into the web serivice? Any idea?

Thanks,
jhgonzales

 

[Wm. Scott Miller]

jhgonzales:

The "mimic server interaction" is simply creating a webservice that takes
the webservice's inputs and gives the webservice's outputs. EG if your
webservice takes an object for input and outputs an object, your webservice
would be a webmethod that does just that:

[WebMethod]
public response_type HelloWorld(request_type arg)
{
return null;
}

Once you have the webservice building without errors, just navigate to the
url of the webservice and add a ?WSDL to the end. Bingo. You got an WSDL
(some modifications needed e.g. URLs need changed to real URL of server).
If you are building the server and client, though, this mimicing is not
needed as your building the server which has the WSDL included already.

On your second issue, WSDL's are CONTRACTS. You have to think of them that
way. Contracts are not signed until both parties agree. Same is true with
webservices. Server and client must agree for interaction to occur. If you
keep changing the contract, that results in your server and client needing a
rewrite to talk. Rewrite means recompile. There is no way around a
recompile if you're going to change that XSD. The only "easy" solution I
can think of is to write a BAT file to automate the process. All your .NET
code can be compiled from the command line (ever worked with just the .NET
SDK?). So I'd write a BAT file to run my recompile and use VS to simply
allow me to make it pretty and use the nice GUI for the other stuff

Best advice I can give you is STOP PROGRAMMING UNTIL YOUR XSD IS ROCK SOLID.
If you don't follow this advice you will waste alot of time writting to hit
a moving target. If your XSD is designed properly, there shouldn't be any
changes needed (or *few* and *far* between...in which case the regeneration
of a class file for your XSD is not that big of a deal because it is now a
once in a blue moon occation). Additionally, if a change occurs in the
future, you can have different versions of your webservice running side by
side to support both old and new XSDs. This is similar to COM development.
This can be done until you have time to have all your clients rewritten to
the new interface. Here is the order of development for webservices:

1. Develop the contract
2. Develop the server
3. Develop client apps or distribute your WSDL so clients can be written by
others

You can combine 1 and 2 in VS by designing your server in the IDE. VS will
generate your WSDL using the classes you design and generate an XSD for them
as well (may need you to provide some hints). I would still recommend
designing your contract (not necessarily writting an entire XSD but the
contract should be set in stone before development starts). Using class
designing tools or using class designing techniques will help here. Think
of your webservice as sending objects across the line, not XML. You can use
a RDBMS tool, but classes and tables don't necessarily translate well
between each other. Tables hold data. Classes hold data and/or perform
operations. Classes are more like tables, triggers, contraints and/or
stored procedures from RDBMS wrapped up in one tight package, but each is
optional.

Good questions to flesh out the contract are:

What data needs to flow between my server and client?
What does my server need to do?
What do my clients need done for them by the server?

For a Math addition webservice the answers may be as follows:
What data needs to flow between my server and client?
Client will send in two float numbers and the server will send back
a single float value.
What does my server need to do?
Take the two floats supplied by the client, add them together, and
send back the result to the client.
What do my clients need done for them by the server?
They are too stupid to add two numbers together so the server must
do it for them.

As you can see by my example, I'm talking in objects, not XML and XSD.

Scott