My question is really about the difference between API Management in Bluemix and API Management on Cloud?
In the docs on Bluemix I can see
"This service includes API versioning, lifecycle management, and API usage analytics."
In the knowledge center about the Cloud version is says
"The API Management environment provides the following functions:
Manages the operations of the various servers in the API Management environment.
Provides the tools to interface with the various servers.
Provides analytic functions that collect and store information about APIs and API users.
Processes and manages security protocols and stores relevant user and appliance authentication data.
Provides assembly functions that enable APIs to integrate with various endpoints, such as databases or HTTP-based endpoints.".
So, is this the same?
according to the documentation it is the same service. The differences should be related to available pricing plans, on Bluemix there is just one pricing plan.
Related
On an on-premise we have option to call BAPI for CRUD operations. How can we achieve the same in SAP cloud environment. For example I am trying to find solution to post FI documents from external API into SAP Cloud, equivalent to bapi_acc_document_post in on-premise.
Thanks.
In Cloud Environment you can enable SAP API Business Hub to access APIs described in api.sap.com
There are several APIs available for different SAP Applications; for example check Journal Entry - Post (Asynchronous)
You can find a Business documentation describing the use cases from a functional perspective as well as technical informations (API Specs, WSDL, urls etc..)
I am reading about and then trying to use IBM Bluemix. I have seen some confusing statement about MBaaS support on Bluemix. Some sites mention that Bluemix is a PaaS, and some places say it supports MBaaS. I have basic doubts: does IBM support MBaaS? If yes, where can I find the full MBaaS features list for IBM Bluemix? I couldn't find it in IBM site.
You're correct: Bluemix is a PaaS. However as you probably know and as you can see here:
Mobile backend as a service (MBaaS) enables you to quickly integrate
your mobile apps with data and functions in security-rich, backend,
cloud storage. MBaaS is usually delivered through a set of custom
software development kits (SDKs) and application programming
interfaces (APIs). MBaaS can offer you full data synchronization, user
management, push notifications, integration with social networking
services, and file-handling.
A PaaS provides SDKs and APIs and for this reason it can support MBaaS. In Bluemix the MBaaS capabilities are provided by the MobileFirst platform. It is designed for building and enhancing multiplatform, enterprise-grade apps that can be native or hybrid – for Android, iOS, and Windows. You can get started here.
Yes, Bluemix Mobile supports a Mobile Backend as a Service.
Here are the current services that we have that support the MBaaS pattern and a bit of information about them (and here's a quick graphical view and some links for how to get started):
Mobile Client Access
This service enables you to secure your Mobile Application. You can add Facebook, Google, or custom authentication to your application.
Push Notifications
You can add the Push Notifications service to send push notifications to your app on Android and iOS.
Mobile Analytics (Beta)
The Mobile Analytics service enables you to gather crash and usage knowlege about customers using your mobile app.
Cloudant NoSQL DB
The Cloudant service is the IBM NoSQL database to store your data.
Object Storage
The Object Storage service is an unstructured cloud data store where you can store things like images or files.
Mobile Foundation
The catalog also includes the Mobile Foundation service which you can use to create a test environment before deploying or purchasing the on-premise software. This service is another way for enabling a developer to create a mobile channel.
You may have a look at this :
http://www.ibm.com/mobilefirst/mobile-backend-as-a-service/mbaas.html
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
What would be a good way to provide a non-trivial backend for mobile apps, regarding both the protocol used for communication, and the actual hosting?
Most backend platforms (such as parse.com) provides some basic API for performing trivial CRUD data operations, but if the server logic needs to be more complex than that, what would be a good strategy (preferably .NET/C#, secondarily JAVA, but not javascript or any custom scripting approached)? SOAP web services (for example WCF)?
Regarding hosting, I have looked at Azure and AppHarbor, but can't decide between the two. AppHarbor seems like the only place to co-locate the web server and a MongoDB instance in Northern Europe, as Azure (apparently) only provides MongoDB in a US region. Any suggestions?
Basically, what I'm interested in doing is setting up a WSO2 API Manager in multiple regions; such as Asia, US, and Europe. Some APIs will be deployed within datacenters in each region while other APIs will only be deployed within a particular region.
Ideally what I'd like to have is a single WSO2 API Store where I can see the APIs that are deployed across all regions (including those that are only available on servers in specific regions).
I don't want the API users to have to know about each of the API Managers or their stores in order to discover the available APIs. I'd rather they just knew about one of the API Manager stores (ideally the one in their region) and they could then find the available APIs and decide if they want to deal with the latency of using an API from a different region.
Thus, when an API is published using the API Manager Publisher in one region I'd like that API information to be federated to each of the API Manager Stores.
Is this possible? If so does any documentation exist on how to configure the API Managers to use API metadata federation?
If I understood your query correctly,this is possible via distributed clustered setup of WSO2 API Manager.
This blogpost will be help you to get initial understanding on how WSO2 API Manager[AM] designed for scalability.
For the moment,we are in the process of updating WSO2 AM documentation with API Manager deployment details in a distributed setup and those will be available in near future. Additionally this slideset would help to you as it is containing some deployment patterns which can be used for API Manager.
Thanks;