WebSphere Application Server & Liberty

WebSphere Application Server & Liberty

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

Going beyond OpenAPI: MicroProfile meets API Connect - Part 1 - Why

By Emily Jiang posted Tue February 28, 2023 06:33 PM

  

Authors: Emily Jiang (Cloud Native Architect, IBM App Runtimes), Chris Phillips (Global Lead Architect, IBM Integration)

When producing applications in your environment it is not uncommon to have the gateway layer separated out from the application layer. This provides discrete separation between the components. This article will go through how easy it is to configure API Connect as the gateway for Open Liberty and the benefits it will provide. Let's first define what Application and Gateway should be responsible for.

Role of the Application and MicroProfile API

Ideally, the application should only focus on the business logic whereas the Quality of Service should be either very easy to be implemented or defer to infrastructure components. At this point, I would like to mention one cloud native API standard, MicroProfile. MicroProfile offers the following capabilities for creating Cloud-Native Applications.

  • Fault Tolerance: provides a number of annotations to apply to your Cloud-Native applications such as Retry, Timeout, CircuitBreaker, Bulkhead, Fallback.

    • `@Retry` is used in the situation where it is unstable and sometimes it does not work. This is like you switch off/on your devices to make it work.

    • `@Timeout` is normally used in the mission-critical operations where you want to control the maximum of response time.

    • `@Bulkhead` limits the number of concurrent requests. The resources waiting for a response are limited.

    • `@Fallback` is very important to be used for the operation that you don’t want to ever send a failure as a response.

  • OpenAPI: offers a mechanism to document cloud-native application resources and also expose an endpoint http://host:port/openapi and http://host:port/openapi/ui. MicroProfile OpenAPI works automatically for Jakarta RESTful Web Services without needing to do anything. If you want to add more documentation, you can use the annotations provided by MicroProfile OpenAPI.

  • Security: MicroProfile JWT defines a mechanism to utilise JWT by adding two extra claims, upn and groups, which is to carry the information about the user names and its access group so that Cloud-Native applications can be easily secured.  MicroProfile JWT ustilizes the two popular security framework: OpenID Connect and OAuth 2.0. It then provides an easy way to pass the token and access token mechanism.

With the MicroProfile programming model, the applications can focus on their business logics while achieving a number of essential QoS. 

Role of the Gateway

Whereas the application is responsible for providing the business function the gateway is used to provide common patterns required by many applications or bringing together multiple applications to provide a new facility. Below we get through the most common facilities the gateway can provide and the advantages they bring to an Open Liberty application.

  • Application and User Identification and Authorization: When consumer applications call APIs it is recommended that the application is identified. By putting this logic in the Gateway Layer it can be applied to multiple applications with no impact to the application team. 

  • Pattern-ization: A single pattern can be applied to multiple downstream services by reuse.

      • Encryption (M)TLS/SSL/JWT: The best form of security in my opinion is MTLS when using the correct cypher suites. By using a Gateway a single team can be responsible for keeping all the signed certificates used for upstream communication. Downstream communication can use self signed certificates that can be managed by the applications themself. 

      • Analytics and Audit: Enterprises say they wish they could track all analytics and audits of all request. By enabling this in the gateway as part of the standard pattern old and new applications can meet this requirement with zero code changes.

      • Service Discovery: The challenges with building new downstream services is to allow them to be found by the correct audience. By using a Gateway with a shared Developer portal we can automatically publish specification and allow consumers to quickly get started.

  • Protocol and Data Format  Conversions: New protocols are continually being developed and asked for by consumers. However implementing these new protocols or changing data formats in the application is expensive across a whole estate. The gateway can translate the new protocols or data formats to the original protocol or data formats, meaning no code changes are required.

Conclusion

Where possible, application can concentrate on the business logics while the shared resources security reusable info handled by gateway. In this way, the application can stay lean and boundary is clear so that the developers don't need to worry about the security as it can be easily handled by gateway.

Are you wondering how to do it? Read Part 2 to find out!

0 comments
40 views

Permalink