Thread: Using Multiple Services Within one Application

Some times, it is necessary to have multiple developers to work on single Symphony integration project. In the same time, Symphony DE can not simulate real Symphony "full-scale" mode -- This happens in reality, e.g. box access, network location, testing data access, etc. In this case, developers will need to work on a single grid -- same application but different copies of service code.

The first thing you may think of is duplication of the application, the problem with that is you need to manage your resources (cores), also, you will need 1 SSM slot for each application. They can both turn out to be difficult in some resource scarce environments.

This actually not only apply to development environment, but also in real production. Depends on application team's preference, some like to have single application but different service modules.

For these cases, have multiple services in one single application and differentiate them by session types can be very helpful. Here is how you do it:

1, Create multiple service source code and compile into multiple service binaries. In Symphony, each service is just a stand-along executable with a "main" entry, you just need to modify your source code and Makefile a bit to achieve this.

2, Add multiple <Service> </Service> sections in your application profile

3, Add multiple <SessionType></SessionType> in your application profile, each session type refers to a service defined in #2

4, Deploy your service module and register your application profile

5, Run your client to use different services by using different session types

The following are the steps I used to create multiple service sample with CPP sampleApp sample code shipped with SymphonyDE4.1. I was using RedHat4, gcc 3.4.4, 64bit compiler but in compliled in 32bit mode.

1, Sandbox root: /DE41/4.1/samples/CPP/SampleApp, all subsequent steps refer this as root directory. You can find this directory in your DE package.

2, create multiple services:
-- cd Service
-- cp SampleService.cpp SampleService_1.cpp
-- cp SampleService.cpp SampleService_2.cpp
-- modify onInvoke in SampleService.cpp/SampleService_1.cpp/SampleService_2.cpp, put different output messages for each service. (cpp files can be found in the attached zip file)
-- Modify the Makefile to build 3 services (attached Makefile in zip)

3, Modify the xml file to include multiple services and session types, I call them:
-- SessionTypes: Service, Service_1, Service_2
-- Services: SampleService, SampleService_1, SampleService_2
The xml file is also attached here

4, Build, Deploy and register:
-- make from root
-- cd Output
-- tar cvf SampleServiceCPP.tar SampleServiceCPP SampleServiceCPP_1 SampleServiceCPP_2
-- soamdeploy add SampleServiceCPP -p SampleServiceCPP.tar -c /SampleApplications/SOASamples
-- soamreg ../SampleApp.xml


5, Modify your Synclient.cpp to use different session types and test:

...
attributes.setSessionType("Service");
...

Test:
...
you sent : Hello Grid !!
we SampleService replied : Hello Client !!
...

...
attributes.setSessionType("Service_1");
...

Test:
...
you sent : Hello Grid !!
we SampleService_1 replied : Hello Client !!
...

...
attributes.setSessionType("Service_2");
...

Test:
...
you sent : Hello Grid !!
we SampleService_2 replied : Hello Client !!
...



In the end, there are some notes on the behavior change:

Usually Symphony keeps service instances for one application for a while, provided the host is allocated to that application. (There is configuration to change minimal service and etc, which is not in this article's scope).

When there are multiple services for one application, Symphony will need to switch among different service executables, in my sample's case, they are namingly:
-- SampleSericeCPP
-- SampleServiceCPP_1
-- SampleServiceCPP_2

When a switching happens, Symphony can either shutdown the service it needs to switch from, or keep it "stand-by". E.g. Host A is running SampleServiceCPP now, then it is asked to serve SampleServiceCPP_1, Symphony will either shutdown SampleServiceCPP before start SampleServiceCPP_1 or simply put SampleServiceCPP "stand-by" for future uses.

The pros and cons are obvious:

Standby: if you have big code in SessionEnter or ServiceCreate, better put them as standby. This will save you a lot on startup, but will waste the memory.

Shutdown: If you do not do much in SessionEnter or ServiceCreate, this is the clean way.

To config this put maxOtherInstances into the service configuration, e.g.

...
<Service default="false" description="The Sample Service" maxOtherInstances="2" name="SampleService_1" packageName="SampleServiceCPP">
...

The default value of this is 0.



Hope this is helpful.