TNAPS 3 Architecture

Introduction into architecture basics of TNAPS 3 Application Server for .NET / Mono and Java.

Transcript

1. Architecture Cross-platform Application Server for Mono and .NET
2. Basics TNAPS 3 uses the following main concepts: 1. Component 2. Application (App) 3. Instance 4. Library Library contains all Components and Apps that you can use. Every App uses one or many Components to run. So, you have to intall everything you need into the Library first, then create Instance of the App you need to launch and execute it. TNAPS allows to create as many Instances of App as you need. For example, it can be the same CRM application, but hosted on different ports, using different datasources and serving different clients. For every Instance you launch TNAPS executes separate process, so all Instances work independently. App Component Component Library Instance Running App Executed by TNAPS in separate process Instance of an App from Library with configured settings (port, db, etc.)
3. Library Every TNAPS installation creates a repository for components and applications called TNAPS Library. Every component and application gets stored there before actually being used. TNAPS Library greatly resembles standard libraries of magazines. Each component or application is installed into Library and is stored in multiple versions, just like standard book library store magazine issues. Each time a new version of the component is published it is downloaded and added to the Library along with previous versions. All older applications using previous versions of the component are still fully functional. Usually you do not need to access library manually. But Library is a directory and can be viewed. However, you should edit it only using TNAPS Management Center. Here are library locations: Windows c:\ProgramData\tn\server\lib Linux/MacOSX /usr/share/tn/server/lib App 1.0 Component 1.0 App 1.1 App 1.2 Component 1.1 Component 1.2 TNAPS Library contains all versions of every application and component. Just like a standart library with magazines it keeps tracking of older versions of components, so apps that use them would operate normally.
4. Component In TNAPS everything begins with the Component. The Component is the only part of TNAPS that stores and accesses the executable logic of the application. TNAPS Studio, Visual Studio, Eclipse, or any other IDE allows the development of components. Component can be hosted by .NET / Mono environment or by Java Virtual Machine like OpenJDK or OracleJDK. TNAPS provides API for both environments and special message transport layer allows components from .NET to communicate with Java components within one app. TNAPS comes with a set of default components that are most often used in every server application. For example, Hosting Component provides functionality to expose other components interface as RESTful API or SOAP services. Component is not just a set of .NET Assemblies and .JAR files, but an actual package that contains binary resources and all other assets that the component logic uses during execution. Component DLLs or JARs (Business Logic) Binary resources (images, data, etc) Dependency info (what components it depends from) Component is a package that contains executable logic, references to depended components and any arbitary resources that component may require during execution.
5. Application Each Application in TNAPS is a composition of components linked together like building blocks to construct the required business logic. Within applications there are components called “root components” that are executed right after launch of the application. Those root components reference other components and call them when needed. Example In the scheme to the right there is a sample CRM App that can build reports about customers. The entry point (root component) is Host Provider. This component opens port and exposes Report Builder component interface to the whole world through REST or SOAP. When Report Builder receives request it calls DB component for customer data from database and uses PDF Generator component to build PDF report based on database data. Considering Host Provider, DB and PDF Generator components are standart ones, developers task is only to create Report Builder component and call dependent component actions. DB Host Provider PDF Generator Report Builder CRM App
6. Package Apps and Components for TNAPS are distributed in the form of package files with .tnpak extension. Package contains all the information and data to deploy app or component into TNAPS Library. Every software vendor who create component or app for distribution signs resulting package and provides it to the customers. TNAPS uses signature to verify package consistency and vendor credentials. When the end-user installs component or application into the library TNAPS checks whether all of the dependent components (with exact versions) are presented in the library. Dependent component packages can also be included into the application package. So that every time users installs application all required components are installed automatically. Component / App Package vendor compile and sign end-user download TNAPS Library install into
7. Instance It is the actuall running application in TNAPS. Once App is installed in the Library it can be used to create Instances for launching. Configuration Instance is defined by its Configuration. Every time the instance is created it gets the default configuration from the App. Later on this configuration can be changed to satisfy the desired behavior of the App. For example, creating two instance from the same App and giving them different hosting ports and datasources to use. Execution When TNAPS gets request to execute instance it launches separate process for it. So every running Instance is completely independent and can not interfere with eachother. Moreover, in case of any problems within instance, TNAPS core process would continue to function properly. App Instance1 Instance2 Library config config DB1 DB2
8. TNAPS Core .NET / Mono Framework Application Hosting Message Transport .NET Adapter Java Adapter .NET Component .NET Component Java Component Java Component JVM The core level of TNAPS uses .NET / Mono for hosting. On top of it resides Application hosting engine. TNAPS launches separate process for each App Instance. The following slides would explain architecture in details. Architecture Summary
9. Managing TNAPS TNAPS has web-based management interface called Management Center. It is available after TNAPS launch: http://localhost:9095/tnaps/console Management Center provides a frontend for TNAPS REST API. This API contains many end- points for managing different aspects of TNAPS. Of course, all of the REST API methods can be called directly - via curl For example the following request returns JSON with all of the components installed into Library. TNAPS Management Center REST API User > curl http://localhost:9095/tnaps/library/components/names. json ["HostProvider","binarycalculator","currencymonitor"]
10. Product Page http://tncor.com/en/tnaps Get more information, samples and downloads