Test and deploy a service
A service is ready when its HTTP contract and business outcomes work in its intended runtime. Compiling it, publishing a port or creating a request is only one part of that evidence.
Test a contract through its public interface
For each operation, specify the status, representation and subsequent state you expect. Test both a successful path and a refused or invalid request. For asynchronous work, read the created resource until a terminal state or a bounded test deadline.
The delivery example suggests this small checklist:
Scenario |
Evidence |
|---|---|
Valid library request |
|
Unsupported destination |
Created resource reaches |
Empty business fields |
Failure state without courier assignment |
Forged progress through PUT |
|
Duplicate slug |
|
Agent or process restart |
Behaviour matches the documented retention policy |
Treat the last row as a contract to design: this demonstration does not restore its in-memory state after restart.
Run the guide’s checks
From the documentation repository, the MAMS verifier compares download archives to sources, compiles projects and exercises their HTTP contracts. Source verification builds the pinned MAMS commit; the published-dependency check resolves released artifacts separately.
The custom counter example is included: its checks confirm the value, its self link and cache header, refusal of PUT, and unchanged state after the refused write. WebSub’s instructional snippets are not yet an end-to-end case in this checker; do not infer subscription reliability from a successful run of the other examples.
Package the service, then check readiness
Follow the deployment walkthrough to run the delivery service directly with Java or through Docker Compose. Maven launch, direct Java and container launch should expose the same resource contract.
The supplied Compose configuration binds the demonstration to the host loopback interface. Wait for a successful GET before starting a client. A container existing or a process running does not prove that routes and worker startup have completed.
Inside the Compose network, clients use http://delivery:9000. On the host they use the published address, http://localhost:9000. localhost inside a container identifies that container, not the host or a sibling service.
Decide what survives shutdown
This example stores resource state and history in memory. Decide what a longer-lived application must retain, how it recovers incomplete assignments, and what clients see during recovery. Authentication, public resource addresses and deduplicated submission also need application contracts; the example’s active method policy does not provide them automatically.
A deployment test should follow the service-generated Location and links from the actual client network. A hand-written URL can succeed while the advertised address is inaccessible.
Try it
Run the Java client against the packaged delivery service. Stop and restart the service, then read a previously created request. Explain the observed lifecycle before proposing persistence or retry behaviour.
The MAMS improvement notes (notes/mams-improvements.md) in the source repository distinguish implementation opportunities from example and verification gaps. They are maintainer planning material rather than additional reader prerequisites.
To run a MAMS system across a cluster of machines, with agents addressed by name, pools that scale with their load and agents that recover after a restart, see Deploy on Kubernetes with MAMS Infrastructure.