Web service interface

I want to add a web services interface to an existing server application. The set of services to be expanded is unknown at compile time and can change over the life of the server.

Technically speaking, all server / web service endpoints will be on Windows.

In our server application, the user will be able to register workflows as "web services called". This will create a WSDL that defines this particular workflow service.

For the calling endpoint, I'm thinking of an HttpModule that accepts an incoming web service request, unpacks the request and converts the XML datatypes to our server "domain", calls the server, and finally converts the server outputs back to XML to return an HTTP connection.

It makes sense?

Critical comments are welcome.

+2


source to share


3 answers


I ended up creating a C # class that implements the IHttpHandler interface. The implementation maintains the WSDL of services exposed from our application and accepts SOAP messages to invoke the services. In the end, most of the work went on to convert SOAP types to our types and vice versa.



0


source


In fact, you are writing your own WS engine. Obviously doable, but quite a lot of work to get right from scratch. I think if you find any open source implementation, then adaptation should be possible.

Rather dirtier alternative, but one I've seen in a different context is to use the WS symbolic interface



String call( String workkFlowName, String payload)

      

The payload and response are strings containing any XML. Thus, the caller must expose the schemas for these XML. From a client's perspective, the amount of coding effort is not much different. I think your coding efforts will be greatly improved.

+2


source


The HttpModule, which accepts an incoming web service request, unpacks the request and transforms the XML data types into our "domain" server applications, calls the server, and finally converts the server outputs back to XML to return over an http connection.

This is what all web services do (eg Metro, Axis). So I don't see your problem. What are your concerns about this approach?

The downside for the client is that I understand the availability of your services may change over time. So you should consider a way of informing the client if a service is available (other than getting a timeout error because there isn't one), for example. WS-ResourceLifetime or UUDI .

+1


source







All Articles