This article describes Symphony from a functional and structural point of view.

Functional

Symphony connects your application's client and many service processes through a message passing infrastructure. These messages generally consist of serialized initialization data and service function parameter lists.


Symphony Service Cloud

The advantage of Symphony is that it exposes your compute cluster as a homogeneous set of resources that can be dynamically provisioned with service processes. The client process does not need to worry about the specifics of finding hosts in the cluster and communicating with them. Symphony manages the deployment of the services, the scheduling of messages and the recovery of data due to failures.

Symphony does not provide Cloud Computing services. Symphony is intended to be used on private compute clusters where the objective is to minimize idle CPU's.

Structural

Symphony contains 7 major components developed mainly in C++ and running natively on Windows, Linux and Unix. These components include;

• Enterprise Grid Orchestrator (Partially emulated in DE) (EGO)
• Repository Server (RS)
• Management Console Server (PMC)
• Session Director (SD)
• Session Manager (SSM)
• Service Instance Manager (SIM)
• Symphony SDK Library (API)

Symphony Components

These components are connected primarily through a closed TCP/IP protocol. Components interact asynchronously and never poll for data. The SD and EGO have an open management interface implemented in WSDL to allow for customization and simpler access from different programming languages.

The EGO component forms a foundation for Symphony and is responsible for;

• Starting a stopping long running services like the SD, RS and PMC
• Managing and allocating compute resources for the SD and SSM
• Remotely starting and stopping processes on compute resources like the SSM and SIM
• Handling failover and recovery of processes

Platform's Load Sharing Facility (LSF) application can also use EGO resources shared with Symphony applications. With EGO, you no longer need a dedicated set of compute resources for each application.

The RS server stores and manages service binary packages for your application. Service packages are retreived and stored on the compute hosts on demand.

The PMC is a web server that supports the Symphony management console. It communicates via SOAP and JNI to the management API's on the other components.

The SD server controls application traffic. It is responsible for;

• Starting/stopping the SSM's
• Responding to management functions like registering an application and status queries

The SSM is started on demand by the SD, one per application. It manages client sessions and schedules task workload to the SIM's.

The SIM's are started on demand by the SSM and manage the service processes. The SIM gets task workload from the SSM and transfers the data to the service instances via a local TCP socket connection.

The SDK consists of two libraries packaged into one. One library links with your client process and communicates with the SD and SSM. The other library links with your service process and communicates with the SIM.