Hands-On Cloud：Native Microservices with Jakarta EE
上QQ阅读APP看书，第一时间看更新
上一章目录下一章

MicroProfile

MicroProfile.io is an open source community specification for Enterprise Java microservices, and it aims at optimizing Enterprise Java for a microservice architecture.

The delay in the release of the new version of Java EE, and the rapid change of the technological scenario (which is increasingly oriented toward cloud platforms and microservice architectures), have pushed a community of individuals, organizations, and vendors collaborating within an open source (Eclipse) project to bring microservice features to the Enterprise Java community.

Some of the major players in the history of the Java EE platform are involved in this project, such as Payara, Fujitsu, Tomitribe, IBM, Red Hat, Hammock, SmartBear, Hazelcast, and Oracle to name a few.

The project is based on the idea of extending the main features of the Java EE with new specifications essential to meeting the requirements of the new technological context.

 At the time of writing this book, the project is at version 1.3, and is composed of the specifications shown below:

 

As mentioned previously, in addition to the specifications relating to CDI, JSONP, and JAX-RS used to expose the API via RESTful web services in JSON format, there are a number of new specifications such as configuration, fault tolerance, JSON Web Tokens (JWTs), metrics, health checks, JWT propagation, OpenTracing, OpenAPI, and the REST client that are able to allow the realization of microservices in cloud environments.

In the following chapters, we will analyze in detail these specifications, with examples of code that will allow us to understand their purposes well. For now, let's have a quick introduction to the objectives of each of these new specifications, based on the descriptions that are given in their GitHub repositories:

  • Config: A common feature, not strictly related to cloud or microservice architecture, is the ability of the applications to be configured based on the running environment. Usually they use properties files in different formats, but the request is to have the opportunity to update the configuration properties without the need to rebuild and repackage the application. Also, the changed values should be retrieved by the client without the need to redeploy and restart the application. This requirement is extremely important for microservices running in a cloud environment. The MicroProfile Config specification defines the way to implement this concept.
  • REST client: This specification defines how to invoke RESTful services over the HTTP protocol. The REST client implementation outlines a continuity with Java EE/Jakarta EE, suggesting the use of JAX-RS 2.0 specifications in order to give the ability to reuse code written in tradition Java EE applications.
  • Fault tolerance: One of the most important features required in cloud and microservice environments is resiliency to failure. This specification defines a way to provide different strategies to drive the execution and the result of computation implemented by the code; for example, providing fall backs and an alternative result when code execution fails due to unexpected exceptions. Retry strategies, bulkheads, and circuit breakers are enterprise integration patterns that you should implement to adhere to this specification.
  • Metrics: In a distributed environment such as a Platform as a Service (PaaS), it is essential to retrieve metrics related to the execution environment. Usually, companies use agents that shadow the complexity to retrieve this information. In the past, the Java Management Extension (JMX) was implemented for this purpose. This specification extends JMX and defines another two main aspects, as follows:
    • A standard way for MicroProfile servers to expose monitoring data to management agents
    • A standard Java API that applications should use to expose their telemetry data to operations teams
  • OpenAPI: The main goal of this specification is to define a standard Java API that implements the OpenAPI version 3 specification defined here: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md. The applications should adhere to this specification to expose their API documentation.
  • JWT propagation: The most used technology in microservice architecture is the RESTful web service as compared to the HTTP protocol, and so the security of the APIs exposed must be guaranteed. The RESTful architecture services should be stateless—this means that any security state associated with a client is sent to the requested service every time a new request is performed. The security context is always recreated and the systems must perform both authentication and authorization validation on every request. The principal security protocols are based on security tokens—OAuth2, WS-Federation, OpenID Connect, WS-Trust, and Security Assertion Markup Language (SAML) are the main ones. The target technologies of JWT propagation specification are based on standards defined by OAuth2, JWT, and OpenID Connect.
  • OpenTracing: The microservice usually runs in distributed system environments, so it's extremely important to trace requests in order to rebuild the execution flow of the code. This specification defines APIs that describe how incoming and outgoing requests should be traced by an OpenTracing-compliant Tracer Object. They also set the way to access a configured Tracer Object.
  • Health check: The monitoring of the production infrastructure is a key point of the operation teams—it's important to always know the state of a node in order to react quickly if there are issues. These APIs describe the rules for determining the state of a node. In a PaaS health check specifications could be used to determine whether a node needs to be discarded and replaced by another instance using automatic mechanisms, reducing the out-of-service time.

One of the main goals of these specifications is the compatibility with the well-known cloud platforms, such as, Kubernetes.

It is expected that MicroProfile 2.0 will align all APIs to Java EE 8 in order to obtain a set of features, as shown below:

 

At this moment, there are some products that have already passed the Technology Compatibility Kit (TCK) tests of the JSRs described before, or that are in the in progress state.

The main products are as follows:

You can find the updated list of the MicroProfile implementation at the Eclipse MicroProfile Wiki (https://wiki.eclipse.org/MicroProfile/Implementation).

So, now we have a great community, that of MicroProfile.io that is building a Java EE on steroids. But, how will Java EE evolve, and how will the new features made available by MicroProfile be included in it?

The evolution of Java EE is Jakarta EE.

上一章目录下一章