Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Introduction


The SOAJS controller is the main gateway for the SOAJS cloud services. It is designed to:

  • handle the awareness among the micro-services
  • monitor the health of all the registered services
  • redirecting the requests into the appropriate services
  • decrypt cookies from logged in members requests

In the previous examples, a request to a particular service must be sent to the port that that service is listening to.

However, the controller alleviates this issue. Instead of worrying about ensuring the correctness of the service port number,

it is sufficient to direct the request to the controller's port number, while specifying the name of the service and the API being called.

Service Exploration


Installing the Controller

Controller Installation
# go to soajs directory
cd /opt/soajs/node_modules/

# install soajs.controller
npm install soajs.controller

# go to controller directory
cd soajs.controller


# export necessary environment variables
export SOAJS_PROFILE=/opt/soajs/node_modules/soajs.utilities/data/getStarted/profile.js
export SOAJS_ENV=test
export SOAJS_SRVIP=127.0.0.1
# start the service
node .

The controller runs and listens on port 4000. Its maintenance port is 5000.

The controller can be accessed, from the local machine, using the following URL http://127.0.0.1:4000.

Perform a heartbeat check on the controller to monitor its status:

Controller Heartbeat
curl -X GET "http://127.0.0.1:5000/heartbeat"

The following response indicates a healthy functioning of the controller.

Controller Status
{"result":true,"ts":1425054123486,"service": {"service":"CONTROLLER","type":"rest","route":"/heartbeat"}}

Using the Controller

Previously, when calling a service API, a request should contain the port of the service, followed by the API's name.

A problem might arise when the number of services increases.

The controller alleviates this problem by aggregating all the calls targeting the services registered, and then redirecting each call to the destined service.

Consider an example where a call is made to the testGet API of the example01 service. The service listens on port 4010.

The following code snippet lists two requests. The first requests directly calls the service using its port.

The second request, on the other hand, calls the service and its API, through the controller, where the latter takes care of redirecting the request to the destined API.

Controller Heartbeat
# Direct request to the example01 service
CURL -X GET "http://127.0.0.1:4010/testGet?firstName=John&lastName=Doe"
# Indirect request to the example01 service through the controller
CURL -X GET "http://127.0.0.1:4000/example01/testGet?firstName=John&lastName=Doe"

Both commands invoke the same API of the same service. However, the controller alleviates the problem of memorizing the port number of each service.

Evidently, the controller has much more important and delicate tasks than solely redirecting calls to their appropriate services.

For further information, the Controller section provides detailed explanation about this service and its tasks.

  • No labels

0 Comments

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account.