I just curious, why we need worklight adapter to communicate with the database? Why not can't using direct ajax? Last time I'm using direct ajax it's not working at all. After I switch to worklight adapter it's running like charm? No problem at all. Why?
You did not provide any specific details about your scenario, like Where is that backend system located, if there is any security involved, what is the topology, etc... so why it's not working with AJAX is impossible to answer.
As for why use Worklight adapters, read:
http://javatechig.com/cross-platform/ibm-worklight/how-to-create-a-http-adapter-in-ibm-worlight
Adapters provide templated (adapter types) connectivity settings to various backend systems - HTTP, SOAP, SQL, JMS and so on
Adapters provide a means to auto-generate an adapter for WSDL and sap web services
Adapters can also be pure Java JAX-RS web apps, allow far greater flexibility and functionality (in MFP 7.0)
You must use Worklight adapters if you intend on using the unified push notifications support
Adapters must be used if you intend to utilize any of the Worklight security features (adapter-based, custom login module, device provisioning, custom provisioning and so on)
and so on
Related
Is it possible and allowable for MFP application to call web services directly without using adapters?
Yes. It's called making standard AJAX calls. Which means these calls will not benefit the features that are possible through MobileFirst (such as security, etc).
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
We are working with MobileFirst 7.0 version. We want to achieve authentication using adapter based authetication process. Earlier we used HTTP Adapter and it worked. But we changed it to Java Adapter and want to acheive authentcation with Java Adapter Based authetication.
My questions are :
Is it possible?
If yes, how can we move forward?
If not, what is the alternative of doing authentication usig Java Adapter?
There is some documentation covering your question.
Here are links to get you started:
Authentication concepts in MFP 7.0: https://developer.ibm.com/mobilefirstplatform/documentation/getting-started-7-0/authentication-security/authentication-concepts/
Adapters overview: https://developer.ibm.com/mobilefirstplatform/documentation/getting-started-7-0/server-side-development/adapter-framework-overview/
Java adapters: https://developer.ibm.com/mobilefirstplatform/documentation/getting-started-7-0/server-side-development/java-adapter/
Adapter-based authentication: https://developer.ibm.com/mobilefirstplatform/documentation/getting-started-7-0/authentication-security/adapter-based-authentication/
You need to use a JavaScript adapter.
Read the documentation.
Use OAuth.
I found this blog entry, and in particular the second video answered many questions.
OAuth Blog
In all cases I have ever seen we set up a Worklight security Realm and use adapter-based authentication to authenticate to that Realm. Our OAuth-protected resources then reference that realm.
In principle we could define realms that do not depend upon a JavaScript adapter for authentication, the MFP Security model is open to extension. In practice this is probably more work than you want to do. I find that the JavaScript model is itself quite extensible, as it can call down to Java code when something complex is needed.
i have two small questions about the mobilefirst- Server.
I found out, that the mobilefirst (or Worklight)-Server doesn't support PHP.
(IBM Worklight 6.0 - How to include a PHP file?)
Is that still so? Or is there any plan to include PHP?
Then I want to call RPG's with an Java-Adapter.
But I doesn't find any full example for calling a RPG.
Also I want to call RPG's with a Display File. Is that possible?
In the following article it sounds like it is easily possible:
http://www.it-zoom.de/dv-dialog/e/vom-greenscreen-zum-touchscreen-10865/
IBM MobileFirst server sits on top of a WebSphere Java EE based App Server. The MobileFirst Platform Adapter pattern is a server-side layer that provides abstraction to any generalized end-point; including PHP, SQL, SAP, whatever. So as long as your final endpoint is capable of acting as a "service", accepting HTTP requests, and producing JSON/XML responses, this pattern should work fine. The basic flow is:
mobile app client calls the MFP adapter
adapter calls the final endpoint (PHP/RPG in your case)
Endpoint responds with JSON/XML data
Adapter optionally converts response to JSON
Mobile client app receives and processes (displays) a consistent response from the adapter.
Hope this helps clarify the pattern for you.
PHP is a server-side HTML rendering technology. MobileFirst is (partly) for building hybrid mobile applications, which run on the client (mobile), so PHP wouldn't be relevant.
I'm not sure what an RPG is. Please can you specify the acronym in your question?
I am building an iOS and Android Apps using Worklight Framework, the worklight server will be protected by IBM Security Access Manager (ISAM) SSO, and therefore the Apps can only be reaching the worklight server after passing the Security challenges. I've found some docs about this integration and it works as intended.
But the apps also offers some features that doesn't required login, in which the Security Manager shouldn't intercept the adapter request to worklight server. The only workaround that suggested by IBM is to create a URL mapping junction in ISAM that defines the URLs that can access by public, and those which shall not. for example /worklight/public and /worklight/secured
But the URL pattern for all worklight adapter are /worklight/invoke?adapter=ADAPTER_NAME, so do we have a way to create a customized URL for public and secured adapter, for example:
/worklight/public/invoke
/worklight/secued/invoke
EDIT 1: Worklight Version 6.0
Thanks in advance.
Please mention the version of Worklight you are using.
One way to achieve this is to create and deploy the adapters in two different projects. That way the context root of both the adapters will be different. So, you'll have URLs such as
/Project1/invoke?... and Project2/invoke?... which you can apply to your filters.