Architecture Overview

The light-4j is aimed towards microservices, and therefore has to achieve high throughput, low latency, light-weight and address a lot of cross-cutting concerns at the same time. It is based on Undertow Core Http server and depends on minimum third-party libraries.

The topics here are architectural considerations. In a nutshell, architecture is a type of design where the focus is quality attributes and wide(er) scope whereas design focuses on functional requirements and more localized concerns. There is another design section for detail-oriented decisions.

Here is a list of architecture decisions for the platform:

Designed for microservices that can be dockerized and deployed within containers.
Based on pure HTTP without JavaEE as it has too many problems and is declining.
Security first design with OAuth2 integration and distributed verification with the embedded distributed gateway.
The platform handles the coarse-grained authorization with scopes and fine-grained authorization with custom claims.
How to handle distributed [transactions][] in microservices.
All components are designed as plugins and the framework is easy to be extended and customized.
Can be integrated with existing applications to protect investment over the years for your organization.
Support client-side discovery without any gateway and proxy between service to service calls as they add too much overhead.
Service logs will be aggregated with ElasticSearch, LogStash and Kibana with monitoring and alerting.
Built-in CorrelationId and TraceabilityId to trace service to service calls in aggregated logs.
Designed for scalability so that you can have thousands of instances running at the same time.
Has its own dependency injection framework so that developers can avoid heavy Spring or Guice as they are bloated.
Elements of API platform form an eco-system.
API category and how to choose a framework to build your APIs.
What is a service mesh and why do we need it?
We cannot rely on network security for microservices given the dynamic environment and encrypted data. Firewall is killed by Cloud

Service Mesh Plus

In recent years, service mesh has begun to become popular, and a lot of organizations are trying to figure out how to adopt it in their microservices architecture. If you want to review the concept of the service mesh, please visit the service mesh introduction Service Mesh vs Service Mesh Plus One of our customers called light-4j service mesh plus as it is the next level of the natural evolution of service mesh. Read More »

Architecture Patterns

While working with our customers, we extracted the following patterns from user cases we encountered. The list is not exhaustive as this is a live document. Legacy Web App Consuming APIs More and more organizations are in the process of transforming their monolithic applications into microservices. Given the size of the monolith, it is not possible to make the transition overnight. A typical approach is to move some components out of the monolith and implement them as microservices. Read More »

Stages of API Adoption

In today’s IT strategy and architecture, APIs are the new frontier. No matter what industry you are in, doing business digitally is the way to go and APIs are an essential part of the digital transformation. As an API platform provider, we have worked with many companies that are building APIs and implementing API management. All of them seem to be traveling a similar path as the kinds of challenges they are facing are almost the same. Read More »

Service Collaboration

The recent trend in application architectures is to transition from monolithic applications to a microservices model. Software development teams are trying to develop a unified architecture that will work for most of the use cases in real world applications: online transactional, batch, IoT and big data processing pipelines. This transition without a good service interaction model will most likely result in chaos and a service landscape that’s hard to govern and maintain. Read More »

Fail Fast vs Fail Slow

Why microservices need to fail-fast instead of fail-slow Reserve resources When an error occurs, whether it is an exception or a validation error or not, the service should stop processing and return that error status to the consumer. This will reserve processing power for the server. Security concerns Another reason we don’t output too much info in the response is security concerns. If a hacker tries to explore your service, he/she will construct invalid requests and see what the response error is. Read More »

Eco System

Light is an eco-system that support microservices on the cloud. There are several types of the components as part of the platform. Cross-cutting concerns Audit Balance Body parser Client Cluster Config Consul Correlation Cors Dump Exception Handler Header Health Info Limit Mask Metrics Registry Sanitizer Security Server Service Status Switcher Traceability Utility Zookeeper light-session-4j Styles of interaction light-rest-4j light-graphql-4j light-hybrid-4j light-eventuate-4j light-saga-4j Web server Web socket Nodejs framework Infrastructure services light-portal(Marketplace) light-oauth2 light-config-server light-proxy Tool Chain light-codegen swagger-bundler Read More »

CQRS

Event Sourcing

light-eventuate-4j is an event-driven framework based on Event Sourcing and CQRS. Some people asked what is Event Sourcing or CQRS and this article will answer the question. Status Quo It is not how the universe works Single data model for both read and write Lose business critical information Event Sourcing Flexible data structure Easier to communicate with domain experts Expressive models Reports become painless Composing services becomes trivial Lightning fast on standard databases Easy to change database implementations Issues Eventual Consistency Event Upgrading Developers need deprogramming Read More »

SOA

Service-Oriented Architecture Read More »

Modular Monolith

For some people microservices is “the next big thing”, whereas for others it’s simply a lightweight evolution of the big service-oriented architectures that we saw 10 years ago “done right”. Microservices is by no means a silver bullet though, and the design thinking required to create a good microservices architecture is the same as that needed to create a well structured monolith. And this begs the question that if you can’t build a well-structured monolith, what makes you think microservices is the answer? Read More »

Serverless

Serverless is a hot topic in the software architecture world. We’re already seeing books, open source frameworks, plenty of vendor products, and even a conference dedicated to the subject. But what is Serverless and why is (or isn’t) it worth considering? To start we’ll look at the ‘what’ of Serverless where I try to remain as neutral as I can about the benefits and drawbacks of the approach - we’ll look at those topics later. Read More »

Service Mesh

A service mesh is a dedicated infrastructure layer for making service-to-service communication safe, fast, and reliable. Read More »

API Category

API Category - Choose the right framework for the right API type Read More »

API Gateway

API Gateway is embedded in light-4j framework Read More »

Integration Patterns

API Integration Pattern Read More »

JavaEE declining

Microservices - The final nail in the coffin for Java EE Read More »

Key Distribution

JWT Public Key Certification Distribution Read More »

Microservices Architecture

Microservice architecture, or simply microservices, is a distinctive method of developing software that has grown in popularity in recent years. In fact, even though there is not a whole lot out there on what it is and how to do it, for many developers, it has become a preferred way of creating enterprise applications. Thanks to its scalability, this architectural method is considered particularly ideal when you have to enable support for a range of platforms and devices—spanning web, mobile, Internet of Things, and wearables—or simply when you are not sure what kind of devices you will need to support in an increasingly cloudy future. Read More »

Microservices Monitoring

Microservices Monitoring Read More »

Microservices Security

Note: If this is your first time hearing about OAuth 2.0 or you want to get familiar with the grant types we are using, please read this article first. Everyone’s excited about microservices, but the actual implementation is sparse. Perhaps the reason is that people are unclear on how these services talk to one another. The most tricky thing is access management throughout a sea of independent services. While designing microservices, a big monolithic application is broken down into smaller services that can be independently developed and deployed. Read More »

Microservices Traceability

Microservices Traceability Read More »

Platform Ecosystem

Microservices Platform Read More »

Plugin Architecture

Plugin Architecture Read More »

Scalability and Performance

Microservices Scalability Read More »

Spring is bloated

Spring is bloated Read More »

Transaction Management

Transaction management in microservices architecture Read More »

Microservices Cross-cutting Concerns Options

There are three options to address cross-cutting concerns when deploying microservices on the cloud: Chassis, Service Mesh, and Hybrid, which combines both Chassis and Service Mesh. In the rest of the article, I will list the pros and cons of each option and give my recommendations. Before we move to the details, we need to clarify the cross-cutting concerns and what type of cross-cutting concern we need to address when deploying microservices. Read More »

Service Discovery

When introducing distributed microservices architecture to an organization, we need to decide if we want to leverage service registry and service discovery in the cloud. If the answer is yes, we need to choose between client-side discovery vs server-side discovery. Regardless of server-side or client-side discovery, the registration is the first step. It will connect to the control pane during the server startup and send the protocol, I.P. address, port number, and other health check parameters. Read More »

Client-Side Discovery

Here is an article that discusses the discovery patterns. You can learn what client-side vs server-side discovery is in the above article. Who is using client-side discovery In the Java world, most people are using Spring Boot to build their services with Netflix open source libraries(Eureka for service registry and Ribbon is a jar include inside consumer) Light-4j client-side discovery is derived from an RPC open-source platform motan. Read More »

Coarse-grained Authorization and Fine-grained Authorization

In Light, we are using OAuth 2.0 to authorize the client request to the service with JWT token that contains two different claims. Scopes Scopes work at the technical level to protect individual endpoints within the service, and we call it coarse-grained authorization. For example, you have a service that provides four endpoints to select, insert, update and delete a resource. You can define four scopes and sign them to four endpoints. Read More »

Business Handler

When using light-4j and its related frameworks, most developers are working on handlers, and most of these handlers are business handlers instead of middleware handlers. Business handlers are the ultimate handler in the request/response chain, and it is responsible for processing the request and producing the response by applying the business logic. When using other frameworks except for light-4j, you can leverage light-codegen to scaffold your project based on the specification(OpenAPI 3. Read More »

Middleware Handler

The light-4j and all related frameworks are trying to address all technical cross-cutting concerns for your applications so that developers won’t need to worry about these concerns in their business logic. This significantly increases the productivity of the developers compare with other frameworks developers need to mix in all cross-cutting concerns in the business logic through annotations or method invocations. In a request/response chain, request middleware handlers are injected between the client and buisness handlers and response middleware handlers are injected between the [business handlers][] and the client. Read More »

SWT vs JWT

In OAuth 2.0 RFC6749, the contents of tokens are opaque to clients and it is usually called simple web token(SWT). Most implementations choose UUID as SWT. This means that the client does not need to know anything about the content or structure of the token itself, if there is any. However, there is still a large amount of metadata that may be attached to a token, such as its current validity, approved scopes, and information about the context in which the token was issued. Read More »

Firewall

The traditional firewall is dead or at the very least dying. Cloud and hybrid environments, mobile access, and online applications have made it all but obsolete, experts say, and data center operators should be looking at replacing their firewalls with more granular security technologies. Applications and data used to live in data centers and be delivered from there to employees who were themselves on a corporate network with a desktop on a static IP address. Read More »