# Multi-service deployment

xly is not a single Spring Boot WAR — it's a small constellation of
independently runnable services that share a database, share the
metadata layer, and communicate through JMS.

## The runnable services

| Service | Module | Role | Default port (dev profile) |
|---|---|---|---|
| **xlyEntry** | `xlyEntry/` | Main back-end runtime + the framework's own admin (BACK). Hosts `BusinessBaseController` and the `/business/*` API. | 8080 (dev), 8597 (deployed dev) |
| **xlyApi** | `xlyApi/` | Web-facing UI WAR — static assets + Thymeleaf templates + browser-facing endpoints. Different context-path. | 8080 with context `/xlyApi` (dev) |
| **xlyInterface** | `xlyInterface/` | External-integration service — third-party APIs, webhooks, file imports. | configured per environment |
| **xlyPlc** | `xlyPlc/` | Shop-floor PLC bridge ([Slice 6](../../slices/06-hardware.md)). | one per press-model deployment |
| **xlyFace** | `xlyFace/` | Face-recognition (ArcSoft SDK). Niche; commented-out for many deployments. | configured per environment |

Each has its own `application.yml` + several `application-<profile>.yml`
files. The active profile is selected at startup via
`-Dspring.profiles.active=…`.

## Disabled in `settings.gradle`

```
//include 'xlyErpTask'
//include 'xlyRxtx'
//include 'xlyFile'
```

Three modules are present on disk but excluded from the active build:

- `xlyErpTask` — long-running background tasks. Disabled likely because
  the same scheduling now runs inside `xlyEntry` / `xlyFlow` via
  Quartz.
- `xlyRxtx` — native serial-port library. Disabled when xlyPlc doesn't
  need direct serial access (some press models use TCP/Ethernet
  instead).
- `xlyFile` — older file-management module, superseded by Aliyun OSS
  integration in `xlyPlatFileUpload`.

A maintainer cleaning up the codebase should consider whether to delete
these or keep them as historical reference. They take up disk space but
do not affect the build.

## Plat* family

The `xlyPlat*` modules (`xlyPlatMerchantController`, `xlyPlatUserService`,
`xlyPlatPayService`, `xlyPlatMarketingService`, `xlyPlatCainiaoWaybillSevice`,
`xlyPlatSmsService`, `xlyPlatReportForm`, `xlyPlatFileUpload`,
`xlyPlatJmsConsumer`/`Productor`, `xlyPlatTask`, `xlyPlatWebsocket`,
`xlyPlatConstant`) are the **B2B printing-platform layer** —
out-of-scope for this wiki. The `plat_*` tables those modules write to
are empty in this dev DB; see the [recon report's §5](../../../recon/REPORT.md).

## How services find each other

Three communication channels:

1. **Shared database** — every service reads/writes the same MySQL
   schema. Most cross-service "communication" is implicit through
   shared tables.
2. **JMS (ActiveMQ + RocketMQ)** — fanout for events that affect
   multiple services. Cache invalidation
   ([cache invalidation on metadata change](cache-invalidation.md))
   uses this channel.
3. **HTTP REST** — for synchronous calls (e.g., xlyApi calling xlyEntry's
   `/business/*` endpoints).

There is no service registry / discovery mechanism beyond the
`application-<profile>.yml` files, which hardcode peer URLs per
environment.

## URL routing in deployed environments

The dev URLs `http://118.178.19.35:8597` (BACK) and
`http://118.178.19.35:8598` (FROUNT) suggest:

- 8597 is **xlyEntry** with context `/xlyEntry/` (confirmed observed
  from network traces in [Slice 1](../../slices/01-hello-world.md)).
- 8598 is likely **xlyApi** or another front-of-house service.

Both are likely behind an nginx / reverse proxy in production, with
URL paths cross-routed based on path or hostname. The exact routing
config lives in the deployment environment, not the codebase.

## Profile permutations

`application-saas.yml`, `application-linux.yml`, `application-win.yml`,
`application-15S.yml`, `application-S10.yml`, `application-pro.yml`,
`application-T0.yml`, `application-T1.yml`, … cover combinations of:

- Operating system (linux / win)
- Customer category (saas, 15S, S10, …)
- Environment (dev, pro)
- Press-model (for xlyPlc)

A given deployment selects exactly one profile per service. The
mapping from "this customer" → "these profiles" lives in deployment
ops documentation, not the codebase.

## Open: production URL routing

The exact nginx / reverse-proxy config that maps 8597 / 8598 to
context-paths and back-ends would be useful here. It's not in the
codebase repo — it lives with the deployment scripts. A maintainer
chapter to add when those scripts are available.