Principles of generating WSDL
- I have some basic high-level questions about WSDL, and issues with
trying to generate WSDL from within our application, as a service to
clients. I would appreciate some perspective on these issues, and any
resource materials that would help me get my arms around this.
Our application is an Enterprise Service Bus. It's designed to support
listeners on several HTTP and JMS ports, each of which can be configured
to expect XML messages of different types. In the case of the HTTP
listeners, the message is written to standard output on the request
stream (not in specific request parameters, or encoded in the URL).
They can expect messages from a schema derived from SOAP, or from
application-specific schemas. The listeners then use symbolic
information in the messages to determine concrete routing and
transformation steps. Depending on the message type, the client may be
waiting for a synchronous return, or not, in the case of an asynchronous
request. It's also possible that we may want to allow for the
possibility that the message is mime-encoded, to contain attachments in
addition to the XML message.
We haven't yet gotten into generating, or even writing, a set of WSDL
documents to represent the services available at these ports. I'm still
trying to grasp all of the issues involved with doing this.
I'm guessing it would be logical to configure our listeners, at least
the HTTP ones, to expect a "WSDL" parameter in a GET request, to allow
the generation of a WSDL document to send back to the client. I guess
this is logical, as the full WSDL specifies the URL for the service,
which the servlet can build dynamically. I don't know what's logical to
do about a similar feature for the JMS listeners.
Looking through the WSDL specification, I find myself a little confused
about exactly when you'd use any of the specific binding strategies
(SOAP, HTTP GET/POST, and MIME). It seems like certain cases could use
more than one strategy.