1. Do you intend to replace the World Wide Web?
2. A number of SaaS enabling companies provide their own SaaS framework. Why is your framework superior to that of other SaaS enablers?
3. What benefits does using the GravityZoo Cloud OS provide us in general?
4. What benefits make the GravityZoo Cloud OS unique?
5. What do I need for transforming Software as a Product into Software as a Service?
6. Does the GravityZoo Client need an authentication infrastructure?
7. Does the GravityZoo backend have proprietary Database features? Or are hardware, OSs and GravityZoo the only components needed to run the GravityZoo Cloud OS?
8. Is it easy to develop an GravityZoo application that communicates with applications outside of the GravityZoo Cloud OS?
9. Can the REP protocol traverse NAT and most existing firewalls?
10. Could you give some existing/developing examples of the following features of GravityZoo Cloud OS for enterprise use?
11. Does GravityZoo have multi-tenancy mechanism?
12. What kind of customization could we do in your multi-tenancy mechanism? Could we customize, for example, the following items for each customer in your multi-tenancy mechanism?
13. What is your Licensing strategy?
14. What kind of impact do you expect the GravityZoo Cloud OS to have on the Open Source Community?
15. Is the GravityZoo Source code available to Public?
16. Where can I host my GravityZoo applications?
17. What does it cost me to deploy applications via the GravityZoo Cloud OS?
18. Send us your questions.


1. Do you intend to replace the World Wide Web?

No. We intend to Net-enable all those applications that are presently excluded from the Web. Allow them and of course others to turn these application into Software as a Service via The Net.

2. A number of SaaS enabling companies provide their own SaaS framework. Why is your framework superior to that of other SaaS enablers?

It has been the background of the GravityZoo team (ASP, B2B community and Software development experience) that made us realize that in order to provide the end-user genuine desktop alike usability and interactivity via a SaaS-model, required a new cutting-edge technology to be developed from scratch, leaving behind all the limitations these other SaaS solutions still carry along.

3. What benefits does using the GravityZoo Cloud OS provide us in general?

Because of some specific development choices, the GravityZoo Cloud OS can be deployed in many computing fields. Essential for this was the development of a new communication protocol which resulted among others in the GravityZoo Cloud OS being able to deliver capabilities such as Seamless Universal Roaming between client networks (e.g. WiFi networks); the usage of distributed processing power, applications and data; creating Ambient Intelligence & Ubiquitous Computing through the device awareness of the "intelligence" that now lives in the network instead of on each individual device.

4. What benefits make the GravityZoo Cloud OS unique?

There are many features that make the GravityZoo Cloud OS unique. An example of such unique features is "Split Horizon execution". The core concept of GravityZoo is that execution of the programming code primarily takes place in the backend. Only the objects necessary for the representation on the client are replicated bidirectional between the client and the backend. To enable certain applications to function in disconnected state and to save bandwidth on the client and processing power on the backend, we have developed "Split Horizon execution". This allows developers to execute certain parts of their application on the client, rather than on the backend. The moment the connectivity is restored a synchronization takes place.

5. What do I need for transforming Software as a Product into Software as a Service?

The GravityZoo Cloud OS will take care of all the complicated tasks at hand. The only thing you need to do is to adapt your existing stand-alone software to be hostable in the GravityZoo Cloud OS. In the most cases, there is only need to adapt the Graphical User Interface part of your software, so you can leave your business logic intact. the GravityZoo Cloud OS also provides the tools for hosting your applications.

6. Does the GravityZoo Client need an authentication infrastructure?

The client connects to the GravityZoo Could OS which uses the Authentication and Licensing Infrastructure (ALI), which consists of one or multiple Authentication and Licensing Servers (ALS). This ALI has the following tasks:

• Authentication and authorisation of clients and related data.
  
• Authentication and authorisation of users and related data.
  
• Authentication and authorisation of applications and related data.
  
• Distribution of crypto keys.
  
• Licensing enforcement.
  

the GravityZoo Cloud OS uses an advanced object database, called Central Object Store as primary storage. So you practically do not need any other database to store your data. the GravityZoo Cloud OS automatically stores all persistent data into this COS. The COS can be used for both traditional application data, which would otherwise be saved into a relational database, but also replaces traditional file storage. The COS can be used to replace traditional RDBs, but also traditional file based storage (The COS also supports accessing object attributes as a file and implements a virtual file system).

So do you need to arrange for a Database? The Framework provides a proprietary storage environment. Nevertheless it remains possible to use a traditional Database environment like Oracle to store data. Also, when you want to bring legacy applications to the GravityZoo Cloud OS and don’t want to redesign your database model, it is easy to connect most traditional RDBs (Oracle, MS SQL, MySQL, PostgreSQL and others) to the GravityZoo Cloud OS.

Essentially you only need hardware, an OS on this hardware (Windows, Linux, FreeBSD and MacOS X are supported on the server side) and GravityZoo.

8. Is it easy to develop an GravityZoo application that communicates with applications outside of the GravityZoo Cloud OS?

Yes, it is easy to interface to other applications/environments using industry standard or “defacto standards” like XML, SOAP, XML-RPC, SQL, etc. Also other protocols and most common shared libraries (Linux/UNIX shared objects, Windows DLLs) can be easily accessed from within the GravityZoo Cloud OS.

It is also possible to expose “GravityZoo Objects” to other applications using a set of standard protocols like SOAP or XML-RPC. This way, GravityZoo can also be used for SOA purposes, without a need for difficult interfaces.

9. Can the REP protocol traverse NAT and most existing firewalls?

Yes, REP uses both TCP for reliable transport and UDP for real-time transport, but it has the ability to do quite some fallbacks to “TCP only” mode and even HTTP or HTTPs tunnelling if needed. We’re currently also working on support for most common proxy servers.

REP creates a “clear channel” over the Internet, allowing communication between clients that are connected to the GravityZoo Cloud OS. The communication is controlled by the Authentication and Licensing infrastructure, to avoid abuse of the network. REP also implements encryption by default. Encryption is applied on a so called “run channel”, essentially, every application shared to a client uses a separate “run channel” and thus another key for the encryption.

REP is terminated on something called a REP router. A REP router is a piece of GravityZoo infrastructure that is deployed in the backend. Normally, a cluster of application servers is served by 2 REP routers. Those REP routers also serve for load balancing purposes.

REP routers do not need special hardware and can be installed on application servers for small setups. REP routers mesh with each other, so if one fails, another one takes over.

We also have an experimental embedded REP router, which can be loaded onto embedded devices like OpenWRT based access points. The benefit of having a small REP router in your network is that you can use this REP router for multicast-alike solutions in non-multicast environments.

10. Could you give me some existing/developing examples of the following features of GravityZoo Cloud OS for enterprise use?

• awareness of its environment
  
• split horizon execution
  
• communication between clients
  

Each item will be explained by providing an example.

Application being device aware:

A set-top-box enabled environment that also has to be accessible from normal desktops and in the end also from mobile devices. With GravityZoo, you exactly know what kind of client you have to deal with. What screen size do I have? What OS is this device running? What other capabilities are there available?

For applications that need to be available both on desktop computers, but also on mobile devices like smart phones GravityZoo knows what kind of hardware the device is using and can provide the application with sufficient resources to adapt to this new environment. It is very easy for the developer to adapt to this, this way; an application can automatically switch to another User Interface once it is being used on a mobile device rather than a desktop device.

Split horizon execution:

One of our clients uses GravityZoo to power a “narrowcasting” application, in which customized content can be shown on displays installed in pharmacies and in the near future in all kinds of other shopping outlets. Most displays are connected via existing broadband connections and UMTS and other broadband wireless solutions are on the horizon. Those kind of broadband connections are not 100% reliable. Split horizon ensures that the screens also can operate in a “disconnected state”, so the screens continue to play a basic playlist (without live content), even if the connection is lost.

Another client wants to use the technology for set-top-box domotica (turning lights on and off remotely, etc.) for a FTTH (fiber to the home) project. Basic functionality should be provided, even in the case of a problem with the connectivity.

Split horizon technology can also be used to save resources on the server side and to minimize the impact of network latency. The Development as a Service environment is a nice example of this. We’re using syntax highlighting which we process on the client rather than on the server. Another purpose is the upcoming 3D toolkit, this way, heavy 3D processing can be done on the client side rather than on the server, making better use of the graphical processing powers of the client.

In the future, we want to use the Split Horizon technology to power something we call the “GravityGrid”, in which you can define “closed user groups” that share their processing power for CPU intensive tasks like simulations, 3D rendering, etc.

Communication between clients:

Practically every project we’re currently involved in, involves some kind of communication between clients. The nice thing about GravityZoo is that this communication between clients comes practically for free. Communication between clients is done via Application instances, which are nothing more than persistent objects which define the way of communication between clients in the framework. Getting information from one client to another is very easy, you just need to share this object with this client and the information is available for the other client.

Some practical examples:

An instant messaging application uses shared objects to deliver messages to clients. Once a shared object gets manipulated, the application, which is also shared to the clients, gets notified. This notification can result in a popup being shown on the client. The development of such an application is extremely straight forward and does not involve the invention of any new messaging protocols.

The narrowcasting solution uses shared objects to deliver new content to the screens. In this case, it delivers it to an application running split-horizon between the backend and the client. Once the “content object” is updated, the shared application takes care that all content is synchronized and displayed on the screens.

11. Does GravityZoo have multi-tenancy mechanism?

Yes; the whole platform was designed to be “multi tenant”. The backend is designed to support a multi-ISV environment for example. This way, multi-tenancy can be implemented on the same hardware and software, without the need of an extra virtualization layer for example. The basic segmentation of the platform is: ISV - Application pool – Application - Application instance - User pool - User. Of course, this granularity can be further enhanced if needed, but in most cases it is not needed.

12. What kind of customization could we do in your multi-tenancy mechanism? Could we customize, for example, the following items for each customer in your multi-tenancy mechanism?

- table structures in DB (e.g. add new columns to a table for a certain customer) - user interface (e.g. change font sizes for a certain customer) - logic (e.g. add new alerts for a certain customer) – workflow (e.g. add a new form for a certain customer) - coordination with outer system (e.g. a certain customer needs coordination with some specific system of its own)

It is no problem to host multiple versions of the same application in the framework. Every application can either live in their own, isolated environment, or share some common things with other applications.

For the GravityZoo Cloud OS, an application that you have adapted to one of your customer is considered a separate application. But it is entirely possible for this application to have a common code base, with small tweaks for different users for example. This might involve different User Interface layouts, some adaptations in the database structure and queries and even external interfaces.

There are multiple ways you can implement this, for example:

• Adapt the classes you want to change by overriding them from the default application base. This way, you can keep core functionality in the base of the platform and only override it where necessary.
  
• Load specific data, like User Interface Look-and-feel from a configuration object (we say object, since files and objects are the same) or use a specific configuration object per client.
  
• Use a plug-in system; most GravityZoo applications can be dynamically extended by loading new “code objects” into a running application instance.
  

We will adopt a dual license strategy. If our technology is used for non-commercial purposes (i.e. free of charge) the use of the GravityZoo Cloud OS is free. If somebody is making money while using our technology than we just want our fair share. Most of our API implementations and client plug-ins are available via an Open Source and a commercial license.

14. What kind of impact do you expect the GravityZoo Cloud OS to have on the Open Source Community?

We expect to boost the development of Open Source Software as a Service and the use of the Open Source Operating Systems i.e. Linux. Furthermore the Open Source SaaS-applications will enhance the accessibility to a larger audience. With the GravityZoo Cloud OS download, installation, maintenance and upgrade of software becomes obsolete and thus free from complexity.

15. Is the GravityZoo Source code available to Public?

The source code of certain components is available to the public. Access to other parts of the code is restricted to selected Open Source community members, groups and projects. Anyone can apply for membership.

16. Where can I host my GravityZoo applications?

GravityZoo Cloud OS compliant applications can be easily hosted in the GravityZoo Backend. This Cloud OS can run on a single server, but also distributed on as many servers as you want. Additionally, GravityZoo offers a hosting service for GravityZoo applications. For more information about these services, please contact services@gravityzoo.com.

17. What does it cost to deploy applications via the GravityZoo Cloud OS?

The costs involved with deploying applications with the GravityZoo Cloud OS can be roughly divided into the following factors:

• Hosting costs, this is highly dependent on the amount of CPU and storage and bandwidth capacity you need.
  
• Licensing costs, if you’re using the GravityZoo Cloud OS for commercial purposes, you need to pay a low license fee per device per month. For more information on the license fee applicable for you, contact licensing@gravityzoo.com.
  
• Development costs, as in any development project, there are development costs involved. Since the GravityZoo Cloud OS employs a traditional development costs, those costs can be easily estimated.
  
• Professional Support Services; GravityZoo offers commercial professional support services for developers and operational services. For more information, you can contact support@gravityzoo.com.