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...
Related
I am new to wso2 and its very confusing. I'm developing a web application using authorization Provider: WSO2 Identity Server (IS)
I am looking for minimum configuration on the wso2 side so the simple way is to use SOAP call AuthenticationAdmin services https://host:port/services/AuthenticationAdmin?wsdl
I couldn't find much about the interaction between the authorization server and the resource server and how should it look like.
How to configure spring-security, maybe there is some sample I can look at
You can find more information about the concepts of the OAuth here. You find how to work with OAuth in WSO2 IS also. You can also refer to the white paper
Here is a blog about how to secure Spring Boot based web application using OpenID Connect. This blog includes a sample
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 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.
I have a requirement to connect Mule ESB with Hybris. I didnt find Hybris connector provided by Mule( Also didnt find sample examples as well). This is the 1st time going to try Mule with Hybris..Please let me know the steps or efficient procedural way to connect Hybris.
Is the hybris URL enough to connect?. Please suggest me with your thoughts to implement. Thanks in advance.
Hybris has many ways to integrate with their platform. If you have a login you can access their docs which details examples of integration with the platform including JMS and the Platform Web Services.
There is no connector supplied by Mule, but you can access their Platform Web Services which are implemented with a HTTP Restful API using the Mule http transport or by building your own connector using the Mule DevKit.
The hybris wiki has pages dedicated to most of the endpoints and the request/response formats. You can view this here if you have a login: https://wiki.hybris.com/display/release5/WebService+API+-+Reference
Also, in your hybris installation there are a bunch of examples in /bin/ext-platform-optional/platformwebservices/src...
and /bin/ext-platform-optional/platformwebservices/testsrc which show the actual web service implementations and their test cases using Jersey client.
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/