4.3 Modelling Concepts
The modelling concepts within the GigaSystemBuilder are largely based on the GigaSpaces concepts;
some of the names have been changed in GigaSystemBuilder and some GigaSpaces detail has been omitted.
The overall goal is to make the modelling more generic and more abstract - although GigaSystemBuilder is still quite specific to GigaSpaces;
it doesn't work on any other grid or cloud technology.
The aim is of modelling in GigaSystemBuilder is to help those without a great deal of GigaSpaces experience to still be able
to model and develop GigaSpaces systems. Each concept has its equivalent model object. This section describes each of the modelling
concepts and how its model object interacts or relates to other model objects.
4.3.1 The Application
|
The Application is essentially a top level container for all the model objects. An application can contain zero, one or many
processing units or jars.
4.3.2 The Processing Unit
|
The Processing Unit (PU) is borrowed from the GigaSpaces concept.
It is a self contained piece of work or process. It provides a way of organising the
application into logical components.
It is the modeller's responsibility to decide what Processing Units there are in an application.
On generation of the GigaSpaces system each Processing Unit will become a separate Eclipse project.
The PU is contained by the Application and contains most of the interesting things in a GigaSpaces project -
Spaces, Actions, Services, Service Calls, JavaBeans, Deployment Options and others.
4.3.3 The Jar
|
The Jar is similar to the Java Jar concept: it is a container of JavaBeans and other classes.
It is a self contained piece of work or process. It provides a way of organising the
application into logical components. Modellers must decide how they wish to organise the application between PUs and jars.
On generation of the GigaSpaces system, each Jar becomes a separated Eclipse project, containing the JavaBeans modelled in the jar.
The jar will be available to all the other Processing Units in the System. It becomes in effect a common location of JavaBean.
Like the PU, the jar is contained by the Application, and can contain normal Java classes and JavaBeans.
4.3.4 The Space
|
The Space is a GigaSpaces' concept. Understand GigaSpaces Spaces and you will understand this concept. Logically a space is a
shared repository for objects.
Spaces are contained within PU's. Spaces can contain (in the modelling sense!) LifeCycle events -
these are GigaSpaces 'filter' events.
4.3.5 Space Proxies
|
Applications read from and write to spaces using proxies that are created by GigaSystemBuilder.
These proxies come in two styles, local and remote, which refer to two different views of spaces.
A local proxy is a proxy that points to a specific space instance within the process/PU that will use the proxy.
A processingUnit created by GigaSystemBuilder contains one or more spaces.
Clients created by GigaSystemBuilder do not contain spaces.
Local proxies, therefore, may be used by processingUnits but not by clients.
A remote proxy is a proxy that points to a logical space composed of one or more physical spaces running
outside of the process/PU that will use the proxy.
Because GigaSystemBuilder clients cannot contain spaces, any proxies used by clients will necessarily be remote clients.
A Processing Unit (PU), however, may need to refer to
- a space that is embedded within it,
- or to the group of spaces of which its embedded space is a part,
- or to a remote space (which may be a group of space instances).
In the first case, you should use a local proxy. In the second and third cases, remote proxies would be used.
Proxies are available in the GsbSpaces file, in the project named <application>_GSBFramework,
'src' directory,
class com.gsb.core.GsbSpaces.
4.3.6 The Lifecycle Event
|
A Lifecycle Event represents a change in state of an entry within a space. The equivalent in GigaSpaces is a SpaceFilter.
We call them lifecycle events in GigaSystemBuilder to emphasis that these events are only triggered by changes in state of entries in
the space and operate on copies of the entries themselves.
The lifecycle event is a child of a space and there can be many Lifecycle Events in one space.
A lifecycle event must have a name; this turns into a method in the space's LifecycleEvent class.
These names must be unique across all the lifecycle events in a space.
A Lifecycle Event can have an associated JavaBean. In this case the event is triggered when the specified JavaBean is acted upon in
the space and the parameter passed to the lifecycle event method will be of that type.
If no JavaBean is specified then the event is triggered when any entry is acted upon,
and the type of the parameter passed to the method will be ISpaceFilterEntry.
A further filtering mechanism is the 'Operations' property, which allows the modeller to choose one or more operations for each Lifecycle Event.
The event is only triggered if the entry is acted upon by one of these operations. The operations are:
- before-read
- before-remove
- before-take
- before-update
- before-write
- after-read
- after-remove
- after-update
- after-write
There is a restriction in GigaSpaces that if the operations list contains before-write,
then the parameter passed to the method representing the event must be the ISpaceFilterEntry.
In GigaSystemBuilder, you do not need to worry about this.
The code generation creates a wrapper method that catches the ISpaceFilterEntry object and presents a proxy
for the implementation method that looks like the JavaBea.
In other words, the developer treats the before-write case just like the other cases.
4.3.7 The Selection Event
|
A Selection Event represents a lifecycle activity in a space. The Selection Event abstracts away the implementation details of the
GigaSpaces Selection Event components. For example the polling-container and notify container events are both represented by a Selection Event.
The Selection Event uses the 'style' property as a means of distinguishing between different event types.
The current set of styles are:
- Receiver : Like a queue where items are placed on a queue and then process and removed in turn.
This maps to a polling-container with SingleTake receive handler.
- Subscriber : Equivalent to a topic subscriber. This maps to a notify-container. If the update flag is set the event will be
triggered on updates.
An event must be triggered by a set of circumstances. The circumstances will involve a bean of some time. The TemplateBean property
allows the user to set the bean that will trigger the event. This property is presented as a drop-down showing all the possible
beans in the System. Simply select the required bean to set the TemplateBean
An event will normally result in an action occurring. So the Selection Event needs to be linked to an action.This property is also
presented as a drop-down showing all the possible actions in the System. Simple select the appropriate action that will become
the cause of this event
Container : Space
Contains : Not Applicable
4.3.8 The Action
|
An action represents a process or function.
In Java terms this is a method.
It takes an input and has a result, both which are defined as properties.
If the input is an existing object in the system (such as a JavaBean) then the 'InputObject' is used. If it is a simple
type then the 'Input' property should be used. Similarly for the result; use 'ResultObject' if the result is a JavaBean and 'Result'
for a simple type. These properties are used to determine the signature of the generated method.
The methods generated from the action are called implementation methods. They are where the implementation code is added by the
developer. Any code added in the implementation methods will not be altered during a re-generation of the system. If the input or
result of the action is altered then the generated method signature will alter but the implementation code itself will remain unchanged.
The action has two children; 'Other Input JavaBeans' and 'Other Result JavaBeans'. These can be set but will not change the
signature of the generated method. They are the more as a hint to the developer writing the implementation code
Container : Processing Unit
Contains : Other Input JavaBeans, Other Result JavaBeans.
4.3.9 The Service
|
The service is a remote process call from a client. It contains a list of business-methods which define the functionality of
the service. This along with the Service Call represents the Remoting concept in GigaSpaces.
A Business Method in a service can only return one result. The result is added as a property of the Business Method, either as
a Return Type (for simple types) or a Return Type Object (for JavaBeans). A Business Method can have many inputs or Parameters,
which are children of a Business Method. The type of Parameters can be also be set in two ways. Either as the Type (for simple types)
or as a Type Object (for JavaBeans).
In GigaSpaces the service needs to use a space as a transport medium. The Space property allows the modeller to specify which Space
to use. If no space is specified then the first space in the containg Processing Unit will be used. If there are no spaces defined
in the Processing Unit then a default Space will be created to use specificallty for the service
The generator will create a new class for each service, containing all the busines methods defined for that service.
Container : Processing Unit
Contains : Business Methods.
4.3.10 Service Invocation Routing
|
When a processingUnit that offers one or more remote services is to be deployed in a partitioned cluster (with more than one primary instance),
the modeller should indicate how invocations of the service by a client should be routed.
GigaSystemBuilder supports three options for routing service requests:
- Routed - This is the default.
Use it to invoke the service on a specific instance of the processingUnit based on routing information you supply.
Here are some situations in which this option should be used:
- The work done by the service is dependent on data that resides in the processingUnit's local space.
In this situation the service should be invoked on the instance of the processing unit that contains the needed data.
- The service will insert an entry or POJO passed to it by the client into its local space.
In this case the POJO class's routing scheme should be used to ensure that the POJO is written to the correct space.
You can specify the routing information explicitly, by setting the 'routing' flag on one of the parameters.
In this case, the parameter can be a simple object (Integer or String), or a complex object with one of its fields flagged
- i.e. with the 'routing' flag set.
If none of the parameters has the routing flag set, the GigaSystemBuilder tries to deduce a sensible routing.
This is only possible if there is precisely one parameter - then the rules are as if the 'routing' flag has been set on that parameter:
it can be a simple Object and its value determines the routing; or it can be a complex object with one of its fields having the routing flag set.
- Broadcast - Select this option when the work performed by the service should be performed by every instance of the processingUnit.
Here are some situations in which this option should be used:
- The processingUnits contain local spaces,
and the job of the service is to take some action on all of the objects in the local spaces.
- The processing units must produce intermediate results that will be collected and aggregated by the client.
This is the map-reduce use-case.
- The client requires that at least one processingUnit performs the work offered by the service,
and the possibility that more than one will perform the work either is not problematic
or is dealt with elsewhere in the application's (possibly the service's) logic.
- Random - Select this option when the work performed by the service should be done only once
and can be done equally well by any instance.
In this case, no indication is given to GigaSpaces about where to route to, and the request will be routed randomly.
4.3.11 Space-Based Collections
|
To build resilient services - which can survive one or more backups and keep functioning -
it is necessary to write key state information to a space.
For example, the key generation service needs to keep the last allocated key number for a particular entity - this is the state.
The way to preserve this in GigaSpaces is to write the state to a space that is backed up.
The level of assurance about the resiliency can be
determined by the number and location of the backups:
the more backups, and the more remote from the original space node, the more resilient the service will be.
GigaSystemBuilder provides support for this design pattern with Space-Based Collections.
In other words, it provides an extension of the Java Collections Framework that saves its state in Java spaces as implemented by GigaSpaces.
The advantage of this approach is that the service developer can use the collection in the same way as he or she is used to.
Under the covers, the Space-Based subclass keeps the space state up-to-date.
If the primary space and associated PU is taken down or crashes,
then the space/PU that is newly-elected primary will automatically take on the duties of the primary.
From the application programmer's point of view, there is no change to the operation of the service.
Currently two classes are implemented in this way: SpaceHashMap and SpaceDelayQueue.
The approach used in supporting these two classes will be extended to support other members of the Collections Framework
(e.g. LinkedBlockingQueue) and prossibly java.util.concurrent as well.
For the moderately brave, the implementation of the SpaceHashMap and SpaceDelayQueue classes is also available for you to extend to other classes.
To define a space-based collection, you need to specify
- the space name - the space where the state of the collection is stored.
Clearly, it would be nice if this space were local to the PU, and if supporting the service, in the same space as the service.
- the map name, which must be unique in the application for this type of collection;
the map name must be used in constructing the class
- the normal type parameters for the generic class -
for example, the types of template parameters 'K' and 'V' for the Space-based HashMap.
The map name is necessary because the space entry class includes this name as one of its fields.
For example, the SpaceHashMap stores instances of the 'SpaceMapEntry' class.
This has three fields - the key field, the value field and the mapName.
When the entry is written into the space, the mapName is set based on the declared name of the SpaceHashMap object.
When the SpaceHashMap reconstitutes its state from the space, it only reads entries where the mapName matches its name.
4.3.12 Developing Client Applications
|
The role of client applications is also discussed in the section on Start-of-Day Sequence.
Client applications are supported by modelled methods which start things for an application.
These featurs are typically used by 'clients', which are PUs that have no spaces or services,
so they cannot provide facilitiies for other PUs.
However, these modelling concepts can also be used by non-clients.
The two concepts are the 'pulse' and the 'startClient'.
They provide the ability to call business logic after all the start-of-day initialisation is complete.
If a client application is started using the OpenSpaces packaging, these methods take the place of the "main()" method of a Java application;
in the OpenSpaces startup sequence, you cannot use a main() method.
The startClient simply defines a method that is called once, in its own thread.
The pulse is a variation of this:
it can have an initial delay before the appication method is called;
and it can be repeated - so the 'pulse' is periodic.
In test programs, the repeated pulse can be used to feed objects into a space;
in live applications, it can perform cleanup and occasional 'alive' checks.
The 'pulse' and 'startClient' methods are both defined on a PU (i.e. as a 'child' of the PU in the Eclipse modeller).
The methods, and the handwritten implementation, end up in the 'impl' directory below the PU build area - e.g. "MyPU/impl" -
plus the path reflecting the package, which by default is "com/nte/gigasystembuilder/test".
The class is named "[[PUname]]_Actions.java"; for example, MyPU_Actions.java.
This is the same class that actions are placed in, so actions, pulses and startClient methods must have unique names -
they share the same namespace.
4.3.13 Deployment Options
|
GigaSystemBuilder supports modelled deployments.
The goal is to automatically build deployments of different sizes for different deployments environments and purposes.
You can specify the number of VMs per machine, the number of backups and partitions for a PU, and the number of backup cluster managers (GSM instances).
Although the amount of information used in building the deployment is small at present,
it is quite likely that this will increase with time.
The full story of deployments is this:
- There is always an eclipse deployment option - for running the application within Eclipse.
(Just to remind you of this fact, you cannot define a deployment option named 'eclipse' (case-insensitive)).
This creates an Eclipse project for each PU and then a DEBUG configuration for each project.
These deployments are automatically generated with 1 primary, no backups, un-partitioned, using the IntegratedProcessingUnitContainer.
Using the launch items, it is possible to set breakpoints in the business logic and the debug the running application by starting the various debug configurations.
- To specify a deployment to a non-Eclipse environment, you must specify a DeploymentOption object at the application level,
giving it a non-empty name. The name must be unique across all DeploymentOptions.
The modelling object is shown in the Eclipse modelling environment is DeploymentOption;
in XML or the OSM file, this becomes 'deploymentOption' (uncapitalised).
GigaSystemBuilder generates a deployment for each named DeploymentOption.
Deployment options can vary in the target environment (e.g. Cloud, Windows CLI) and the numbers of backup PUs and partitions, plus various other features.
- You can also specify a DeploymentOption object with an empty name.
This gives defaults for unspecified values.
- You can specify a PuDeploymentOption object at the PU level with a non-empty name.
This overrides the defaults specified at the top level for the deployment with this name.
If you define a PuDeploymentOption but there is no DeploymentOption with the same name at the application level,
GigaSystemBuilder issues a warning message and ignores that particular PuDeploymentOption.
- You can also specify a PuDeploymentOption with an empty name.
These give additional defaults, at both levels.
The application level default could be used to specify the number of backup cluster managers;
if you know in a certain deployment there will be three sites that can host a cluster manager,
you could specify backup cluster managers=2 in that deployment.
-
| 
