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
Related
Here is the situation :
I have a partner service outside of my network. This service is a legacy one, using soap. My internal app needs to fetch data from this service but I don't wan't to work with soap/json. My first reflex is to expose this service on my internal API gateway to consume it but ...
My gateway can of course manage transformation Rest/soap but I want to avoid doing transformation on the gateway as it is resources and time expensive.
I think of a facade component inside my network but this component will have to access public network directly and I feel this is not right.
What can I do ? Isn't it an anti pattern to get out of my network by another door than the gateway ?
there are two type of gateway
1- API gateway : which is for clients and users who need to use your APIs
2- Service gateway : in SOA or MSA your services should not call external services directly (for security reasons and also for decoupling them from each other , maybe one of them working with REST and other one working with SOAP which is your case) rather you should use something which called integration services (integration frameworks) or ESBs (enterprise service bus).
Your problem is you want to use your API gateway instead of service gateway.
Keep your API gateway for your clients but if your services need to call external services use an integration framework or a service bus.
One of the most main features of these tools is that they can convert protocols together for example they have convertors to convert SOAP to REST , it means you call it by REST but it will convert your call to SOAP and call the external service ( you just should config it to which protocol it should convert ).
And also there are many ready to use connectors in them which can connect your service bus to other applications and services like DBs, messaging platforms , linkedIn , ...... .
There are many ready to use ESBs like Apache camel , Mule ESB and .... .
The services(let’s call them Service A, Service B) behind the gateway are all deployed on the same machine/server. In other words, all these apps are deployed on the same tomcat instance.
What kind of security needs to be added to secure calls from gateway to service A ? I understand we can implement spring security for service A and service B as well but wanted to avoid that since gateway is already doing so and evaluate if there is a simpler approach to this.
Can internal api calls be secured with any firewall rule?
Service A and service B only host rest endpoints.
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.
Soap service in wso2 esb can be created in two ways one way is via creating a custom proxy service and another way is by creating a API. by using custom proxy and Api we can create the soap service so i want to understand when do i create custom proxy and when do i create API.
Use a proxy service if you need to :
consume JMS messages (JMS Proxy)
consume files (VFS Proxy)
receive SOAP messages (publish a webService with it's WSDL)
Use an API if you need to publish a REST service (generaly, you want to send XML or JSON to such a service)
Have a look there : https://docs.wso2.com/display/ESB490/Creating+APIs
That is depend on your requirement. If you want to expose your service as a REST service (i.e expose via HTTP methods get/post/put/delete) you can use API's. Similarly if you want to expose your service as a web-service you can use proxies.
You can also proxy a REST service via proxy.
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.