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

1. Cross-platform Application Server for Mono and .NET
Architecture

2. Basics
Library
TNAPS 3 uses the following main concepts:
1. Component
2. Application (App) Component
3. Instance
4. Library App
Component
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 Instance of an App from
App you need to launch and execute it. Instance Library with configured
settings (port, db, etc.)
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
Running Executed by TNAPS in
different clients.
App separate process
For every Instance you launch TNAPS executes
separate process, so all Instances work
independently.

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 App 1.0 Component 1.0
application is installed into Library and is stored
in multiple versions, just like standard book App 1.1 Component 1.1
library store magazine issues.
Each time a new version of the component is App 1.2 Component 1.2
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 TNAPS Library contains all versions of
manually. But Library is a directory and can be every application and component. Just
viewed. However, you should edit it only using like a standart library with magazines it
TNAPS Management Center. Here are library keeps tracking of older versions of
locations: components, so apps that use them would
Windows operate normally.
c:ProgramDatatnserverlib
Linux/MacOSX
/usr/share/tn/server/lib

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 DLLs or JARs
application. TNAPS Studio, Visual Studio, Eclipse, or (Business Logic)
any other IDE allows the development of
components.
Component can be hosted by .NET / Mono Binary resources
environment or by Java Virtual Machine like Component (images, data,
OpenJDK or OracleJDK. TNAPS provides API for both etc)
environments and special message transport layer
allows components from .NET to communicate with
Java components within one app. Dependency info
TNAPS comes with a set of default components that (what
are most often used in every server application. For components
example, Hosting Component provides functionality it depends from)
to expose other components interface as RESTful
API or SOAP services. Component is a package that
Component is not just a set of .NET Assemblies and contains executable logic,
.JAR files, but an actual package that contains references to depended
binary resources and all other assets that the components and any arbitary
component logic uses during execution. resources that component may
require during execution.

5. Application
Each Application in TNAPS is a composition of CRM App
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 Host
needed. Provider
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. Report
This component opens port and exposes Report Builder
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 PDF
data. DB
Generator
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.

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.
compile and sign Component /
Every software vendor who create component
or app for distribution signs resulting package App Package
and provides it to the customers. TNAPS uses
vendor
signature to verify package consistency and
vendor credentials. download
When the end-user installs component or
install into
application into the library TNAPS checks TNAPS Library
whether all of the dependent components
(with exact versions) are presented in the
library. end-user
Dependent component packages can also be
included into the application package. So that
every time users installs application all required
components are installed automatically.

7. Instance Library
It is the actuall running application in TNAPS.
Once App is installed in the Library it can be
used to create Instances for launching. App
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 Instance1 Instance2
giving them different hosting ports and
datasources to use. config config
Execution
When TNAPS gets request to execute instance it
launches separate process for it. So every
running Instance is completely independent and DB1 DB2
can not interfere with eachother. Moreover, in
case of any problems within instance, TNAPS
core process would continue to function
properly.

8. Architecture Summary
.NET .NET Java Java
Component Component Component Component
.NET Adapter Java Adapter
Message Transport
The core level of TNAPS
uses .NET / Mono for
hosting. On top of it resides
Application hosting engine.
TNAPS launches separate Application Hosting
process for each App
Instance.
The following slides would TNAPS Core
explain architecture in
details.
.NET / Mono Framework JVM

9. Managing TNAPS
TNAPS has web-based management interface
called Management Center. It is available after
TNAPS launch:
TNAPS
http://localhost:9095/tnaps/console
Management
REST API
Center
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.
> curl http://localhost:9095/tnaps/library/components/names.
json User
["HostProvider","binarycalculator","currencymonitor"]

10. Product Page
http://tncor.com/en/tnaps
Get more information, samples and downloads