To make the architectural principles tangible, this section provides a practical illustration of the conceptual shift required when decomposing a traditional service into multiple, fine-grained microservices. This walkthrough demonstrates the core MSA concepts of decomposition and composition using the source’s hands-on examples.

Decomposition of a Monolithic Service Consider a single, monolithic service responsible for all four CRUD (Create, Read, Update, Delete) operations for a user profile. In a traditional SOA or monolithic approach, one class (ProfileResource.java in the source example) would act as the single entry point, handling every request and calling the appropriate business logic.

Adhering to the microservice principle of “one business task per module,” this single service would be decomposed. The responsibilities of the single class are distributed among new, more focused roles:

• End User: The entity that initiates a request.
• Application Controller: A lightweight component that receives the user’s request and forwards it to the appropriate Resource Manager. It does not contain business logic itself.
• Resource Manager: A specialized service that performs the actual job. There would be separate managers for adding, updating, and deleting users, each representing a distinct microservice.

This conceptual refactoring—distributing the total responsibility of one class among several others—embodies the architectural shift from a coarse-grained service to a collection of fine-grained, single-purpose microservices.

Composition of Heterogeneous Services A key advantage of MSA is the ability to build applications by composing independent, technologically distinct services. The source material illustrates this by outlining an application that consumes three different web services to deliver a consolidated result:

1. A custom REST API built by the development team.
2. A public SOAP web service (a GeoIP service).
3. A public REST API (a country information service).

In this architectural concept, the main application acts as an orchestrator. It first calls the custom REST service to get an initial piece of data. The output from this service is then used as the input to call the public SOAP service. Finally, a different piece of the output is used to call the second public REST API. The application consolidates the information from all three independent sources to produce a final, comprehensive output. This demonstrates how a single microservice application can leverage a heterogeneous mix of services—both internal and external, REST and SOAP—to fulfill a complex business requirement.