This project was done in collaboration with Siemens CT in Munich. The group is specialized in artificial intelligence algorithms for industrial applications.
Service and cloud oriented systems. Making sense of loosely coupled architectures for computational software
With the shift in the software industry to Service Oriented Architecture and more recently, into the Cloud, many principles and paradigms have become the norm in designing business applications. However, applying these same principles to scientific software remained a challenge to be undertaken. This project wished to tackle these problems by seeing how these concepts can be adapted to the Siemens Neural Networks software, SENN.
SENN is a C++ application developed at Siemens CT, dealing with the training of neural networks and neuro-fuzzy systems. Used for time series analysis and prediction in various application fields, SENN provides interface support for automating SENN processes used with other applications. This automating interface is done via a Tcl scripting engine integrated in SENN. One of the main assets of SENN is its wide range of applicability. SENN can be used for tackling multitudes of forecasting problems ranging from using SENN as a stock prediction tool to the use of SENN in embedded applications. This project aimed at producing a distributed infrastructure that could distribute neural network calculations over a wide network of machines.
How was a Service Oriented Architecture achieved?
In a system where it is desired that various modules exist in an independent and distributed manner, it is essential to maintain a loose coupling, from both a software (language and platform) and geographical perspective (different services lying on different machines). For that purpose creating an API for SENN and publishing it as a set of remote procedure calls was essential to provide it not as a computational software, but as a computational service. In a further step, it was essential to publish this computational service and make it available to the outside world. In an application built on a SOA paradigm, there is a middle-man via which Resource Publishing is achieved. In the final step, once resources were published, a client who wishes to hook up on the computational services, in this case the SENN computational cores, contacts the middle-man which is knowledgeable of the published resources in the system and facilitates for the client the process of Resource Acquisition. From a very high-level viewpoint, our application leveraged three major components, the Local Controller, the Client Controller and the Global Controller which take on the roles of resource publishers, resource acquirers and resource middle-man respectively.
Implementing the architecture described above was a key enabler to access resources both locally and remotely. Once the resources are exposed as remote services and access to them is organized remotely, then the system becomes indifferent to where these resources lie. Thus an installation of the SENN computational core and the enveloping Local Controller on infrastructure at TUM, or infrastructure leased through the cloud is enough to make use of remote offerings.
The use case for the developed system is now running ensemble runs for prediction algorithms. The resources are first aggregated with the Global Controller. Aftewards, an Ensemble Run client requests a certain number of computational runs which are then sent over the network to be performed remotely. The web interface in the graph is the client form with which the use interacts.