C＃将SOAP请求重定向到另一个Web服务？

Question

is it possible to build a web services (let's call it A) that can communicate with one or more webservices?

kind of a SOAP proxy?

the webservice A will build it's functions based on other web service in server B and C

so clients will just send request to A and A will know here to send the request to (B or C)

is it possible to build such app?

Answer 1

Don't know if I understand your question the way it was meant, but it's possible to add a service reference to your webservice. Which webservice to send the request to, you probably have to code ;-)

Answer 2

If I understand correctly, you have 3 components in your app :

• The client App
• A "frontend" web service "WS A"
• two other "backend" web services, "WS B" and "WS C"

by frontend, I mean the web service is the only one exposed to the client, in other words a "facade".

If this is correct, you can reference the "WS B" and "WS C" from the "WS A" project. The code in the "WS A" can act as a client to these web services. This is often called an SOA architecture (service oriented architecture), where each service provides a functionnality, and can communicate with each others.

Thinks starts to be a bit difficult when you have infrastructures requirements (like delegating the client credentials), but I think it's the cleanest way to achieve what you want.

Answer 3

It's definitely possible and it's not something that lives or is bound to SOAP Web Services as this is an application implementation concern. What you should be more concerned with is how you are going to go about doing it.

Using Data Transfer Objects

Having spent many years developing Web Services I believe the best approach in the design of your web services is to follow Martin Fowler's DTO pattern where you communicate using remote-service-specific DTO's using a client proxy (aka Service Gateway) to the Web Service (aka Service Interface). This 'message style' of web services is great from a Performance, SOA, re-usability point of view. Which forms the foundation of how my ServiceStack web services framework was built.

The WCF RPC Approach

Unfortunately this best-practices convention is effectively discouraged by Microsoft's WCF SOAP Web Services framework as they encourage you to develop API-specific RPC method calls by insisting you to use method signatures to define your web services. You can of course still develop 'message based' apis however it requires more effort to do so and is rarely demonstrated in their online tutorials. In my opinion this results in a client-specific API which encourages more remote method calls which as a result are less performant. At times I really wish Microsoft would follow well established practices as published by industry experts instead of their often primary motivation of catering for drag-n-drop developers.

Calling multiple Web Services Asynchronously

Going back to your original question you would define a web service that takes a request and if you're lucky that all your proxy web services share the same interface you should be able to use the same client proxy in a loop by changing the url for each service endpoint. I generally recommend that you fire each request off asynchronously (and join at the end) to speed up the execution time of your 'master web service'.