3.2 HelloCloud - PUs, Services and Business Logic
The previous section covered getting started with a new CloudTran Project.
In this section, we build the "HelloCloud" application.
This consists of a PU (Processing Unit - a container for data and code to process the data), a service and a service operation.
3.2.1 Modelling Properties
|
Remember from the previous section, Hello.osm is the model file, which we use to design the application.
To start adding to the model, double-click on the .osm file in the Package Explorer window.
This will open the file in a specialised CloudTran editor.
You can expand the model by clicking on the 'platform...' icon and press '→' (Right Arrow) a couple of times:
The various model objects here are as follows:
- The first line, the 'platform:...', is some Eclipse Modelling hieroglyphic representing the file. You can't change its structure or add content.
- The second line represents the overall application. This is the root node of the XML file for the model,
so you cannot add any peers (there are no 'Add...' operations on the 'platform:...' operation).
The details of the application are defined by its children and their descendants.
- The Coordinator line represents a node (in GigaSpaces parlance, a 'Processing Unit' or 'PU')
that holds centralised services that need to exist in one place.
The Coordinator model object is created with the initial model.
Don't create a second Coordinator - only one is allowed.
Out of the box, the Coordinator PU deals with start-up management, cluster-wide unique key generation
and some aspects of transaction control.
You can add your own central services in here if you want.
We don't need to do that - like most applications, we'll provide the service on distributed (i.e. not centralised) PU.
Right-click on the Coordinator model object and open up the properties view.
The properties view show detailed attributes of modelled elements;
when you click on a modelled element in the OSM view, the attributes for the element are shown in the properties view.
For the coordinator, this shows three properties.
The first two, the 'Jar Global imports' (Java imports) and the Java package, you can enter values for.
The uid is read-only and is automatically generated when you build the application.
For this example, and in general, you do not need to change any properties on the coordinator.
3.2.2 The Mysteries of Model Editing
|
If you're not used to it, there are a couple of tricks to editing a model in Eclipse.
The first is, how do you get focus into the right-hand side of a line in the property view? It can be awkward if there's a drop-down there.
Our approach now is to left-click on the left-hand side: that then brings focus to the right-hand side.
Then you can just type (without repositioning via the cursor to the RHS).
We need to change the Application name to 'HelloCloud', so left-click on the Application element in the model window,
then left-click on the 'Name' property's label.
Another convenience is that to navigate in the model view you can use the arrow keys.
Up-arrow and down-arrow move focus up and down a line;
right-arrow opens up sub-elements if there are any and left-arrow closes them.
You can also use the Delete key in the model view to delete objects, and use Ctrl-Z and Ctrl-Y for Edit-Undo and Edit-Redo.
3.2.3 Adding A Processing Unit
|
Now we are going to add elements to the Application so we can do some processing.
The first is called a Processing unit or (PU).
This is a home for data and processing - a processing container with a separate address space to all other PUs.
You can think of it as a Java Virtual Machine (JVM) on steroids: in addition to normal JVM facilities it can
-
have one or more backups, so operations can be quickly recovered if a machine goes down
-
scale out so that large datasets or intensive processing can be partitioned across many machines.
If you know GigaSpaces, you may expect that you have to define a 'space'
(a data bucket).
Although you can do this, it is not necessary: if a PU does not have a modelled space, CloudTran creates one automatically.
When we introduce new modelling terms, we will point you to the detailed reference for it.
For example, here are the links to the application and
PU.
Within a PU, you can model data classes and entities (data classes with special properties).
You can also model specialised processing objects.
In our example, we are going to have one PU for the client and another for the server.
You add a PU by right-clicking on the application:
Change the name of the new PU to "Server". Then add a
service, with a
business method and a
parameter so the model looks like this:
The service is a group of business operations - called 'business methods' in CloudTran. This is similar to the structure for web services.
You only need to change the name attribute in each of these model objects - the defaults for all the other attributes are OK.
3.2.4 Adding Another Processing Unit
|
Now we need to create the Client PU - we need to a program to run against the server, and a JVM to put it in.
You have to go back to the Application model object and add the Client PU as a child there.
The other thing we need to do is to kick off the program when the system is initialised.
(You've got to start somewhere!)
To do that, we add a pulse modelling element in the Client;
this declares a method that
the CloudTran infrastructure will call at the right time - at least once everything has initialised.
In this case, we specify that want to wait 100ms before the first call, and then 2 second after that -
the times are in milliseconds.
3.2.5 Building the Application
|
Now you can build the application by right-clicking on the '.osm' file.
This will probably get an error:
This is what happens if you forget to configure the GigaSpaces home directory - as described here.
Once you do that (set the location of GigaSpaces home), things should start working and we see some changes on the LHS:
Some of the new files we can ignore. The ones of interet are:
- builtinTypes.txt A list of the types you can use on data fields
- JavaFilesReport.txt A list of the generated Java files, in particular listing those files and methods that you need to implement.
- HelloCloud_Client The Eclipse project for the Client. We'll edit this next.
- HelloCloud_CoordinatorPU The Eclipse project for the Coordinator PU. You don't need to worry about this for now.
- HelloCloud_CtFramework The 'Framework' is the Eclipse project for the common library,
which is code that must be accessed from all PUs. For example, instances of data classes will be passed between nodes, so
data classes normally end up in here.
- HelloCloud_Server The Eclipse project for the Server.
3.2.6 Adding Implementation Code
|
If you run the application now, it will do ... nothing. We need to add some implementation code. The JavaFilesReport.txt
tells us what we need to do in its first section which lists the implemntation file and the methods to be implemented.
Impl Files by Name
--------------------------------------------------------------------------
Client_Actions.java C:\HelloCloudWS\HelloCloud_Client\impl\
com\cloudtran\example\hellocloud\client\Client_Actions.java
void callCloud()
HelloService.java C:\HelloCloudWS\HelloCloud_Server\impl\
com\cloudtran\example\hellocloud\server\HelloService.java
void sayHello( String message )
(These lines are shown split after 'impl/' - they're not really like this in the file.)
These lines show the workspace location, the project (e.g. HelloCloud_Client) and the source directory, which will always be 'impl'.
Then comes the fully-qualified class name for the file, with '\' or '/' instead of '.'.
On the next line is the name of the method you need to implement - so let's look at callCloud().
The ClientActions.java class is divided into three parts:
- Regenerated methods, that are always rewritten. Any changes you make here are overwritten on the next build.
- Implementation methods. These have code areas bracketed by comments.
The code you write here to implement business logic is preserved when you rebuild.
- Additional code, at the very end of the file.. These are fields and methods that you may need to implement business logic.
Whatever you write here is preserved as is across builds.
Find the callCoud() method in here. Now, how do we call the service method?
This is where the framework comes in.
By the time this method is called, all the other PUs have started up and you can make calls to the service.
Your starting point to call a service is 'CtProxies', which is in CtFramework project, org.cloudtran.core.
If you type in "CtProxies." into callCoud(), you get this:
This shows that HelloService has an inner class in the proxies, and this has the sayHello() method on it:
if you call this method, it makes a remote call to the service.
The final service method call looks like this:
The other end to implement is the service method, which (from JavaFilesReport.txt) is in the Server project, impl folder:
And our implementation just prints a message:
3.2.7 Running The Application
|
You're now ready to run the application. In the 'out-of-the-box' configuration, this will product a lot of debug trace.
If you interested in catching everything to review later, set the Eclipse configuration to allow run consoles to catch
all the console output. This is done via the config page
Windows / Preferences / Run-Debug / Console
and un-checking "Limit console output".
When CloudTran builds the application, it always build Eclipse launchers for the runnable projects -
this will exclude the Framework and the original project.
So in HelloCloud we get three launchers for the CoordinatorPU, Server and Client.
Click on each project in the left-hand window in turn and then click Run.
You don't have to start them in a particular order,
because CloudTran will wait until the necessary partitions have started before starting the application.
If you haven't done debugging in Eclipse before, you will have some fun figuring out how to work the console controls.
To start with, use the 'Pin console' button to stop the console changing all the time as each line is written.
Then use "Select console" to select the Server console.
Eventually (after a few seconds) you should
something like this.
17:27:45.595.473 Coh 0 2-thread-2 ple.hellocloud.server.HelloService sayHello : >>>>> Entry (depth=1)
17:27:45.595.737 Coh 0 2-thread-2 ple.hellocloud.server.HelloService sayHello : message=Good day, Sunshine
Cloud says: Good day, Sunshine!
17:27:45.596.026 Coh 0 2-thread-2 ple.hellocloud.server.HelloService sayHello : <<<<< Exit (depth=0)
17:27:47.601.316 Coh 0 2-thread-3 ple.hellocloud.server.HelloService sayHello : >>>>> Entry (depth=1)
17:27:47.601.576 Coh 0 2-thread-3 ple.hellocloud.server.HelloService sayHello : message=Good day, Sunshine
Cloud says: Good day, Sunshine!
17:27:47.601.874 Coh 0 2-thread-3 ple.hellocloud.server.HelloService sayHello : <<<<< Exit (depth=0)
TRTRTRTRTRTRTR time-based flushing at 1265736468765
17:27:49.608.788 Coh 0 2-thread-2 ple.hellocloud.server.HelloService sayHello : >>>>> Entry (depth=1)
17:27:49.609.053 Coh 0 2-thread-2 ple.hellocloud.server.HelloService sayHello : message=Good day, Sunshine
Cloud says: Good day, Sunshine!
17:27:49.609.319 Coh 0 2-thread-2 ple.hellocloud.server.HelloService sayHello : <<<<< Exit (depth=0)
| 
