Distributed Spring - Spring Enterprise Recipes: A Problem Solution Approach - page 386

public void handleNextCommand(String prompt) {
System.out.println(prompt);

String nextLine = JOptionPane.showInputDialog(null, prompt);
if (StringUtils.isEmpty(nextLine)) {
System.exit(1);
return;

}

log(nextLine);
if ((StringUtils.trim(nextLine).toUpperCase())
.startsWith(Commands.UPDATE.name())) {
update(nextLine);
return;

}
if ((StringUtils.trim(nextLine).toUpperCase())
.startsWith(Commands.DELETE.name())) {
delete(nextLine);
return;

}
if ((StringUtils.trim(nextLine).toUpperCase())
.startsWith(Commands.CREATE.name())) {
create(nextLine);
return;

}

if((StringUtils.trim(nextLine).toUpperCase()).startsWith(
Commands.LIST.name())) {
list();
return;

}
System.exit(1);

}

Terracotta Architecture and Deployment
The client code is simple, as well. It's basically a dumb loop waiting for input. The client reacts to
commands such as create First Last 12/02/78 . You can test it out, without Teracotta, if you like.
Simply run the class containing the public static void main(String [] args) method, as you would
any other main class. If you're using Maven, you may simply execute:

mvn exec:java

➥

-Dexec.mainClass=com.apress.springenterpriserecipes.distributedspring

You can imagine how the client would work with Terracotta. The data managed by the
CustomerService implementation is shared across a cluster. Changes to the data via an instance of
the CustomerConsole on one machine should propagate to other machines instantly, and issuing a
call to list() should reflect as much.
Let's dissect deployment. Terracotta is client/server architecture. The “server,” in this case, is
the one that contains the original working memory. It's what hands out deltas of changed memory to
other nodes in the cluster. Other nodes “fault” in that memory as they need it. To deploy a Terracotta