What is the correct approach to expose an existing SOAP webservice?

[#1]

Hi ,

I am working on one sample ,where I need to call a currency converter webservice.For the I have created two proxies

1)CurrencyConvertorSOAPMock : Used to expose 'currencyconverter' webservice (pass through proxy)

2)currencyconversion : Used to fetch the value from URI and prepare SOAP request.It will call above proxy to get SOAP response.

First of all, is it a valid scenario ? If not please suggest me.

Here I am sending the code.currencyconversion-rev2-2017-03-24.zip

currencyconvertorsoapmock-rev1-2017-03-24.zip

[DChiesa]

In a simple scenario with Apigee Edge there are 3 actors: the client, the proxy, and the backend service. I have labeled these in the following diagram with 1, 2, and 3 , respectively.

You have described a CurrencyConverterSOAPMock, which I think is an API proxy. I suppose there is some currencyConverter SOAP Service running "somewhere" that this proxy sits in front of. As I understand, your CurrencyConverterSOAPMock is a passthrough. (Why is it called "mock"? It seems to be a facade, not a mock.) .

OK, and you have an additional proxy in your design, which is called "currencyconversion". I think this is the thing that does the REST-to-SOAP conversion. So your picture looks like this:

You asked, "is it a valid scenario?"

And the answer is, Yes.

You might want to do this, implement two distinct proxies, in order to track analytics independently. What I mean is, if you put a pass-through facade in front of the SOAP service, you immediately get analytics data on who is calling that service, how often, and what the trend looks like over time.

Like this:

But I think this is valuable, only if other clients of the SOAP service call the new facade. In other words, it's valuable only if you have this picture:

You have clients speaking REST to the SOAP-to-REST proxy, and you also may have clients that speak SOAP, and they invoke the SOAP facade directly. In this case, the analytics for the SOAP facade (2b) would reflect ALL traffic going through that proxy whether it originates from the SOAP-to-REST proxy (2a) or from an external SOAP client (1b).

If you don't have native SOAP clients connecting, then I might suggest that you combine the capabilities of the two proxies into 1 proxy, so that your diagram looks more like the very first one I showed here. It's simpler.