Examples

Applies to Milo 1.2.0-SNAPSHOT. Source baseline 7faaf4f05, 2026-10-04.

Use First server and First client for the smallest complete programs. The source examples below demonstrate larger workflows and share a server with a richer address space.

Run the examples

Use JDK 17 and import the pinned source checkout as a Maven project. Resolve its dependencies, then run the selected class's main method from the client-examples module in an IDE. The source instructions describe the entry points; Contributing links the build prerequisites.

Most entries use ClientExampleRunner, which starts ExampleServer at opc.tcp://localhost:12686/milo, establishes mutual certificate trust for that pair, runs the client, disconnects, shuts down the server, and releases shared resources. ExampleServer binds every network interface on port 12686, including an unsecured anonymous endpoint and fixed demonstration credentials. Run examples only on a trusted host or network, or behind a firewall. Run one example at a time so ports do not conflict. Example trust is only a local demonstration; an application must provision and validate trust itself.

The runner stores example keys and trust material under the JVM temporary directory in client/security and server/security. Set the JVM option -Djava.io.tmpdir=<dir> to a dedicated directory for an isolated run. Trust added by the runner persists there across runs. Remove that directory only after the process has stopped. Keep production identities elsewhere. The runner terminates the JVM, so use it as a standalone process, not inside an application that hosts other Milo components.

The listed local results were checked by launching each class from the command line with a resolved classpath and an isolated temporary directory. The source reproduction tools linked below record the exact launch arguments and inspect output as well as exit status.

Check the expected results below and the log for service or operation failures. At this baseline the runner can exit with status zero after logging an error, so exit status alone does not establish success. For a port conflict, stop the other example. For an external server, check its advertised address, policy, identity, and trust instead of accepting any certificate.

Client learning path

Start with the first seven examples in order. Reverse Connect, GDS, and Alias Names are optional extensions. Each guide explains results, errors, and ownership in more detail.

Task	Runnable example	Guide
Connect and read	ReadExample	Reading
Browse	BrowseExample	Browsing
Write	WriteExample	Writing
Subscribe to values	SubscriptionDataExample	Subscriptions
Call a method	MethodExample	Methods
Receive events	SubscriptionEventExample	Subscriptions
Read and write custom types	ReadWriteCustomDataTypeNodeExample	Data types
Reverse Connect	ReverseConnectExample	Reverse Connect
GDS Pull	GdsPullExample	GDS client
Find aliases	AliasNamesExample	Alias Names

The first seven entries use the local example server. Read prints start time, running state, and current time. Browse lists the server's address space. Write reports ten successful Int32 writes. The value subscription receives current-time notifications, the Method example prints sqrt(16)=4.0, the event subscription receives event fields, and the custom-type example decodes a structure before and after a write. Compare these results with the operation status checks in the topic guides. Several examples hard-code namespace index 2 for ExampleServer; applications must resolve their server's namespace URI instead.

Reverse Connect owns its own local server and listener and prints a connected endpoint, state, and current time. Alias Names resolves Demo.%, reads a resolved target, and reports category information from the optional verbose Method. GDS Pull requires the external setup below.

Server learning path

ExampleServer starts the server and its namespaces. Read the following components in order to see how application behavior fits together:

1. ExampleNamespace: Variables, references, types, and filters.
2. DeviceNamespace and DeviceSamplingGroup: device data and sampling.
3. SqrtMethod: a Method handler.
4. GenerateEventMethod: generating an event.
5. AlarmConditionsNamespace: Condition behavior.

These are components of the example server, not separate standalone programs. The Server SDK hub gives the guide's reading order.

The source module and reproduction checks contain the complete programs, fixtures, and validation tools.

External-server examples

• Prosys history read
• Legacy dictionary discovery

These source references assume a particular external address space; they are not portable launch configurations:

Reference	Required setup and expected result
Prosys history read	A history-enabled ns=3;s=Counter at opc.tcp://localhost:53530/OPCUA/SimulationServer, with client/server trust provisioned. The example prints historical DataValues or an operation error. It reads one response and ignores any continuation point; disconnect releases the Session's resources. Use Historical access for continuation-point handling.
Legacy dictionary discovery	A server exposing a legacy DataTypeDictionary and ns=3;s=Demo.WorkOrder.WorkOrderVariable. Its hard-coded opc.tcp://10.211.55.3:48010 address is an author environment, so adapt it. The example selects SecurityPolicy.None and prints the decoded structure. See Data types for the extra dictionary module and current DataTypeDefinition approach.
GDS Pull	A configured GDS with certificate management, mutual trust, and an account authorized to register/sign. Configure gds.endpoint, gds.username, and gds.password in the JVM launch settings; the defaults target opc.tcp://localhost:58810/GlobalDiscoveryServer and are demonstration credentials. The example finds or registers an application and requests a certificate for a throwaway key pair. It polls up to 30 times at two-second intervals (roughly 60 seconds), prints the issued certificate, and does not install that identity. It does replace selected local trust lists under java.io.tmpdir/client/security/gds/pki. Approve the GDS certificate in that directory; the generic runner logs a different client/security/pki path. Application records and signing requests remain in the GDS, so arrange their cleanup there and local trust-directory cleanup after the run. See GDS client for workflow ownership.

The guide's history, dictionary/encoding, and GDS behavior is checked with local fixtures. Those checks do not establish interoperability with a vendor product or a particular GDS deployment. Verify the named server version, model, returned statuses, paging, certificate approval, and cleanup in your deployment. The public demo server details are maintained in the repository README.