I'm exploring the use of the WSO2 API Manager for our legacy API, which is currently SOAP based. IDeally, I'd like to expose a RESTful interface to our customers and have API Manager convert that to a SOAP request that gets passed to our legacy system. Searching the WSO2 site, I see there's some way to do this using XSLT transformations, but only when using the WSo2 ESB product.
Is there a way to handle this transformation in the API Manager? How? If not, could I somehow take advantage of the ESB product and combine it with the API Manager product? Or is that overkill?
Thanks!
REST to SOAP conversion is a standout feature of the WSO2 ESB. To learn more about it look at the sample given at [1]. The Payload Factory Mediator used in this sample is a much newer type of mediator than the XSLT Mediator and is also more efficient in handling SOAP messages than XSLT Mediator.
The WSO2 API Manager is a platform for publishing, managing and governing APIs. The WSO2 API Manager is built using the componentalized Carbon framework, for which almost all components of the WSO2 ESB are utilized. Therefore technically all that can be done with the WSO2 ESB can be done by the WSO2 API Manager; however without the help of the GUI found in the WSO2 ESB; you will have to use the source view of the configuration which is xml based. But ofcourse to navigate around this obstacle you can always download the WSO2 ESB product (which is also free and open-source) and create all the necessary mediation sequences using the GUI and copy-n-paste the configuration from the WSO2 ESB to the WSO2 API Manager and you are done.
In my opinion it is the WSO2 ESB that you need. In your case I presume you just have one or a few SOAP APIs which you need to expose as REST APIs; you are looking more at the REST-SOAP conversion feature rather than the ability to manage hundreds of APIs. If you do not need the core functionalities of the API Manager such as publishing APIs, versioning, authenticating consumers, throttling based on policies, and monitoring API usage (for a complete list of features look at the product homepage at [2]), then you really do not want the API Manager. But if you have the API Management requirements you can go with WSO2 API Manager. I don't think you should go with the WSO2 API Manager just because you foresee some kind of API Management requirements coming ahead.
Using both the WSO2 ESB fronted by the WSO2 API Manager is also a solution. WSO2 even recommends this architecture if you are performing heavy mediation in the mediation layer. You can even start with the WSO2 ESB alone and later when the proper requirements come, decide to front it with the WSO2 API Manager. Fronting the WSO2 ESB with the WSO2 API Manager is a breeze.
[1] http://docs.wso2.org/wiki/display/ESB403/Sample+800+Introduction+to+REST+API
[2] http://wso2.com/products/api-manager/
Related
We have got the requirement of migrating Production environment of Datapower to WSO2. I never worked on Migration. Can anyone please let me know what would be the procedure of migrating the complete Datapower environment and also I want to know whether we can migrate only OAuth security feature of datapower to WSO2 ESB ?
Thankyou in advance !
The short answer is; No, you can't!
There are literally no common ground between DataPower and WSO2 ESB nor are there any objects that would be similar or usable between the two.
WSO2 ESB is a chunky Java server implementation while DataPower is a firmware based Appliance using configuration only.
Not sure what you mean with the OAuth security feature but, again, that is a purpose built hardware based solution in DataPower, hardened and secure, and it has no equivalent in WSO2 ESB so you will need to build your own solution for OAuth, either as a separate Java servlet/app or build it as a WSO2 plugin.
You will need to document all the services in DataPower and then build them one by one manually in WSO2 ESB.
You will also (most likely) find that many of DataPower's functions can't easily be built in WSO2 ESB...
I'm working on a Java project, using SparkJava framework. I made REST web services, and now I'm trying to place WSO2 API Manager in front of my services.
The problem is that I don't know how to import the backend service description into WSO2 API MANAGER. I saw that this is often done with WADL, but in WSO2 APIM documentation (v2.5.0) there is nothing about this.
My goal is to generate some file which contains my Backend service description (I don't know what format should it be, or what tool must I use to do this), and be able to import it in WSO2 API MANAGER as my API documentation.
Is there a way to do this ?
WADL was used sometime back, but now the common and the standard and way of representing a RESTful API is swagger/OAS.
In WSO2 APIM there are several ways you can create a proxy API for your backend service.
1) If you already have a swagger/OAS spec for your backend service, you can import it to APIM.
2) Create API from the scratch. In this approach, you can define resources and there parameters/headers etc. using the publisher UI.
We successfully launch Wso2 API management solution. One of the main functionality of our project is to orchestrate several simple API and make one Meta API. Then we want to publish this Meta API into Wso2 API Management Publisher and make it available to use.
Is any solution to this requirement?
You can do this. If I understand you correct, you only want to publish the meta api as a managed api. Other simple apis won't be published. If so, things are pretty easy.
WSO2 API Manager uses Apache Synapse as the mediation engine (which is used by WSO2 ESB too). This allows to do the chaining. Please go through the following articles.
http://wso2.com/library/articles/2014/03/batch-api-api-chaining-scenario/
https://docs.wso2.com/display/ESB470/Service+Chaining+Example
http://wso2.com/library/articles/2012/09/get-cup-coffee-wso2-way/
I am experimenting with Mule API management these days. What I come to know is we can deploy our API to one of these:
A Mule Runtime
An API Gateway
In the documentation, it is said that we should go with option 1 when we want to separate out the implementation of your API from the orchestration. What does it mean?
Can any one please explain in detail?
Policy management from API Platform and analytics generation can be achieved only by using a correctly configured API Gateway, which is a superset of Mule EE (current version is API Gateway 2.1.0 which contains Mule EE 3.7.2).
Depending on your architecture you may have different solutions.
For example:
Proxy running on API Gateway, implementation API running somewhere
else (eg. Mule EE/CE, Tomcat, cobol server, etc)
Proxy and implementation API running on the same API Gateway
Implementation API
managed directly from API Platform without using the autogenerated
proxies.
HTH :-)
Not exactly sure what they mean there, because on this page: https://developer.mulesoft.com/docs/display/current/API+Gateway they also mention this:
Note that the API Gateway, because it acts as an orchestration layer
for services and APIs implemented elsewhere, is technology-agnostic.
You can proxy non-Mule services or APIs of any kind, as long as they
expose HTTP/HTTPS, VM, Jetty, or APIkit Router endpoints. You can also
proxy APIs that you design and build with API Designer and APIkit to
the API Gateway to separate the orchestration from the implementation
of those APIs.
So both methods technically allow you to separate API from orchestration, as your API gateway application could simply proxy another Mule application elsewhere that performs the orchestration. But my understanding of the two options are:
The API gateway is a limited offering that allows you to use a subset of Mule's connectors, transports and modules such as ApiKit and HTTP, it allows you to expose and API then use http to connect to whatever backend systems you want as a proxy and perform the orchestration in the API layer.
By using the Mule runtime operation, it gives you much more flexibility and allows you to compose as many applications as you want using the full range of connectors etc. and separate out the different aspects of your applications into as many layers as you want as separately deployable entities that you can deploy to on-premise standalone instances or Cloudhub etc.
#Ryan answer is more or less on the mark, however if you do choose the Mule ESB offering you will loose out on the API Management and governance functionality that API gateway provides OOTB.
These include
Lets you enforce runtime policies and collect data for analytics
Applies policies to APIs or endpoints around security, throttling,
rate limiting, and more
Extends PingFederate to serve as identity management and OAuth
provider for your APIs
Lets you require or restrict certain behaviors in a few simple steps
Lets you add or remove policies at runtime with no API downtime
Manages access to your API by issuing contract keys
Monitors the API to confirm it is meeting all contract terms
Ensures compliance with service level agreements (SLAs)
In my opinion go with API Gateway/Manager if your API will be consumed my third party developers with whom you might not have too many interactions (think public API's) else Mule ESB should be good.
You should be able to migrate from Mule ESB to API Manager (and vice versa) also easily if you need to, so I do not think you will get locked into your decision
PS: Content copied from here
I would like to know if deploying APIs designed using RAML and API-kit in the studio on Mule Enterprise Server for ESB ver. 3.6 is a good idea?
Our organization is interested in using Mule ESB 3.6 for integrations and we thought of recommending using RAML and API-kit for REST API design and development. We are not interested in any Gateway features but would like to leverage RAML for API definition.
Has anyone experienced any issues if we go for a Mule ESB 3.6 Enterprise and deploy these REST APIs designed using API-Kit and RAML there? Is this design approach specifically meant for the API Gateway which is part of the Mule Any-point API Product offering?
API Gateway (AGW) is a superset of Mule EE. RAML and APIKit are not tightly coupled to API Gateway or Mule ESB but can work in either of them. In the case of AGW, APIKit comes bundled with it, while with Mule ESB you have to provide the jar yourself or develop your APIKit project on Mule Studio (using the APIKit Mule Studio plugin) and export the project from Mule Studio when ready.
The advantage of using AGW is that you can develop your APIKit project as usual, and then be able to apply-unapply high end policies to it at runtime (OAuth security, XML Threat protection, IP Blacklisting, etc, etc).
I have used this REST API using RAML for my client. They didn't face any issues and it's working perfectly. And it's easy to implement.
I see no problem in doing what you are suggesting. Gateway and such are services build on top of Mule and RAML technologies -- if you choose not to use them you'll just lose the features they offer but again RAML, Mule, and APIkit work just fine on their own!
In latest version of mule brought many features like api auto discovery and there is no separate gateway and runtime they have been combined together as a single component.
Api auto discovery allows us to apply policies on top of original implementation api.
you can create proxy for the original implementation and policies can be applied on the proxy layer which is in gateway.