Based on WSO2 Architecture blog posts
http://wso2.com/blogs/architecture/2013/05/a-pragmatic-approach-to-the-api-faade-pattern/
http://wso2.com/blogs/architecture/2013/05/implementing-an-api-faade-with-the-wso2-api-management-platform/
I tried to publish API, but exposed WSDL is direct link to back-end ESB.
I planned to expose to outer Internet just API Manager so all calls will be proxied through it. Access to ESB should be limited to internal services and not to public.
Did I something wrong in configuration or API Manager doesn't support this function?
I use WSO2 API Manager 1.4.0 and WSO2 ESB 4.7.0.
DO NOT expose the WSDL of ESB proxy service. The use case for exposing wsdl to allow users to get to know the service contract. You can host the wsdl in a separate location and provide that in the APIManager.
But i think, when we host a WSDL from APIManager, it's port bindings need to be changed according to the gateway node.SO,the requests will be routed via gateway..But that feature is not available in the released versions..We will consider that in the future release.
Related
I have a mule service, named IS, deployed on mule runtime and proxied on API gateway. I'd like to set up different policies to the IS and its proxy service. How can I do it?
My environment:
Mule runtime: 3.7.4
Mule API gateway: 2.1.1
The following are two valid and equally correct solutions that you can choose from, taking into account that your implementation API is a Mule app:
Create an API on API Platform
Solution A:
Configure the autogenerated proxy to use your implementation API URL
Deploy the proxy to a correctly configured API Gateway/Mule runtime
>= v3.8.0
Apply one or more policies to the tracked proxy
Solution B:
Add autodiscovery to your implementation API, using the same API
name and API version name than your already created API on API
Platform
Deploy the impl app to a correctly configured API
Gateway/Mule runtime >= v3.8.0
Apply one or more policies to the tracked implementation app
With solution A, you have to make sure that your implementation app is only accessible by the proxy app (eg with a firewall).
If your implementation API would not be a Mule app, then Solution B would not be possible.
We can create endpoint with a proxy or select Basic endpoint if you create your API outside API Manager, for example, you created the API using Mule ESB. You don’t need a proxy in this case. So policies will be applied to API. For more details go through the link.
https://docs.mulesoft.com/api-manager/setting-up-an-api-proxy
If you're using Mule runtime v3.8.x, and if the service is an HTTP/S listener, you can actually make it auto-discovered in the API Manager and have policies applied directly on it, even if the mule config is not generated using APIkit.
https://docs.mulesoft.com/api-manager/api-auto-discovery
Choose the flow that you want the API Manager to manage and apply policies.
Do note that you will need to have to right entitlement (API Gateway) in the Mule Runtime license and that it has the right Anypoint Platform Client ID/Secret pairs configured in the wrapper.conf. The IDs should be automatically configured if you've added the Mule Runtime server in the Anypoint Runtime Manager.
Here is my solution to apply policy to proxy service:
Create a new API using proxy service's url
Apply policy to API created in step1
Can anyone confirm this is the correct way?
Why do we have SOAP connect option while creating a connector when we already have a Web Service Consumer connector? We can configure a wsdl with Web Service Consumer and access a web service. What is the difference between the two options?
"Why do we have SOAP connect option" because MuleSoft want to provide a method for ISV to provide connectors to new and existing endpoints without Mulesoft themselves having to create them. Mulesoft Anypoint Platform success is built on the premise of connecting to anything and therefore SOAP Connect helps this.
Secondly connecting to a using WSDL location for consuming a soap web service involves a developer to know the service pretty well and therefore allowing error and interpretation errors but if you internally create a connector you can reduce implementation time and errors.
Thirdly on WSDL there are often many methods not applicable or and an enterprise does not want to consume and therefore a connector can filter these methods.
Connectors = Re-Use
Web Service Consumer connector = manual process
The Web Service Consumer is an existing connector that you can configure to point to a WSDL location for consuming a soap web service. SOAP Connect is a DevKit wizard that creates an Anypoint Connector that connects to a specific service, which can expose multiple WSDLs of the service.
With Web Service Consumer we have to call each API separately in separate flows. With SOAP Connect, you can package multiple WSDL files and API versions into a single connector, making the process of creating, maintaining and using a connector for SOAP APIs much faster and easier.
I have a query on a design hope you guys can clarify my doubt.
I have a specific requirement in which Mule is used just to expose the back end services in API gateway, backend services are written in Spring boot and other technology, all these services needs to be exposed in API gateway.
Is this a good practice to do that and if yes how can we do that?
I saw that in API manager we can create proxy layer on top of the services developed in Mule but is it possible to create proxies for the services developed in different technologies?
Absolutely ... For creating proxy service, it doesn't matter what type of technology does the backend service have.
It can create a proxy layer for any kind of backend service available either locally, in cloud or other remote location till the service url is accessible.
This proxy will create an additional layer hiding the actual url to the external world.
it doesn't matter what technology you are using for development as long as those are REST services and accessible to the cloudhub application. You can deploy those on-premise and can integrate your local runtime with cloudhub. Also, mule supports spring projects and you can directly configure your spring project/details inside mule.
What is the difference between a Proxy service and API service in wso2esb?
To expose my service I can give proxy URL and API URL then in which scenario both differs? and in which scenario I can use proxy and in which I can use API?
Please help me in understanding..,
An API has resources so it is suitable when you have to perform multiple operations like CRUD etc. then you can call particular resource which will be performing some particular operation.
A proxy service is suitable when you have to perform an isolated operation (single operation).
So, what you can do is, make an API for multiple operations and then create proxy services for each operation.
Moreover, API can be called as REST service and Proxy service is called as a soap service.
Use a proxy service to expose a SOAP web service
You can consume JMS messages or files with VFS, but since ESB 4.9.0 you can use inbound endpoints for that purpose
Use API to expose a REST service
We are publishing a SOAP service using WSO2 API Manager. I have a question regarding the service WSDL, when we specify the API WSDL URL it has the original end point address instead of the API Manager end point address, is there a way to have the published API with a WSDL having API Manager end point?
Yes, While creating an API you should provide the sample soap service wsdl (ex:SOAP WSDL - https://ws.cdyne.com/phoneverify/phoneverify.asmx?wsdl). after completing the design provide the production endpoint (ex: Production Endpoint -https://ws.cdyne.com/phoneverify/phoneverify.asmx) and published the api. Go to api store and there is an option to download the wsdl generated from apim. It is pointing to API Manager end point.
[1] https://docs.wso2.com/display/AM191/Invoke+an+API+using+a+SOAP+Client
[2] http://blog.rajkumarr.com/2015/08/how-to-expose-soap-services-as-soap-services-via-wso2-api-manager.html