Adapters are used to perform any necessary server-side logic, and to transfer and retrieve information from back-end systems to client applications and cloud services.
Each adapter has its own isolated sandbox, which runs without knowing about or interrupting other adapter sandboxes. Adapters can still communicate with one another by calling API which makes “adapter mashup” possible.
Adapters also support DevOps needs:
- You can “hot deploy” adapters, meaning deploy, undeploy, and redeploy them at run time. This capability lends great flexibility to the server-side development process.
- An adapter can have user-defined properties that can be configured by administration personnel, without redeploying the adapter. This feature lets you customize adapter behavior for different environments, for example development, testing, and production.
Benefits of using adapters
- Adapters support multiple integration technologies and back-end information systems.
Read-only and transactional capabilities
- Adapters support read-only and transactional access modes to back-end systems.
- Adapters use flexible authentication facilities to create connections with back-end systems.
- Adapters offer control over the identity of the connected user.
- Data that is retrieved from back-end applications is exposed in a uniform manner, regardless of the adapter type.
Benefits specific to Java adapters
- Ability to fully control the URL structure, the content types, the request and response headers, content and encoding
- Ability to test the adapter by using a 3rd-party tool such as Postman
- Easy and fast deployment to a running MobileFirst Server instance with no compromise on performance and no downtime
- Security integration with the Mobile Foundation security model with no additional customization, by using simple annotations in the source code
- If the format of the data is JSON then the MobileFirst Server keeps the data intact. Otherwise the MobileFirst Server automatically converts it to JSON.
- Alternatively you can provide XSL transformation to convert the data to JSON. In this case, the returned content type from the back-end must be XML. Then, you can use an XSLT to filter the data based on requirements.
- With an HTTP adapter, you can send GET or POST HTTP requests and retrieve data from the response headers and body. HTTP adapters work with RESTful and SOAP-based services, and can read structured HTTP sources such as RSS feeds.
- With an SQL adapter, you can communicate with any SQL data source. You can use plain SQL queries or stored procedures.
Java adapters are based on the JAX-RS 2.0 specification and are thus written in Java, and expose a full REST API to the client. In Java adapters, it is up to the developer to define the returned content and its format, as well as the URL structure of each resource. The only exception is if the client sending the request supports GZip, then the returned content encoding of the Java adapter is compressed by GZip. All operations on the returned content are done and owned by the developer.
The diagram below depicts how a mobile device can access any Java adapter from its REST endpoint. The REST interface is protected by the Mobile Foundation OAuth security filter, meaning that the client needs to obtain an access token to access the adapter resources. Each of the resources of the adapter has its own URL, so it is possible to protect Mobile Foundation endpoints using any firewall. The REST interface invokes the Java code (JAX-RS service) to handle incoming requests. The Java code can perform operations on the server by using the Java MobileFirst Server API. In addition, the Java code can connect to the enterprise system to fetch data, update data, or perform any other operation that the enterprise system exposes.
Tutorials to follow next▲
- Java Adapters
- Developing Adapters in Eclipse
- Testing and Debugging Adapters
- Adapter Grouping
- Server-side log collection
- Advanced Adapter Usage and Mashup
- Integrating with Cloudant
- Cloud Functions adapter
- Adapters for Watson cognitive services
- Adapter auto-generation
Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.