FAQ

Why a Java Server?
Being from an ISP background we saw the need for a platform intendant server environment in which web applications and daemons could interact seamlessly. This means that system administrators and developers will always be working in the same environment no mater what the platform.

Does it provide a common way of deploying daemons?
It does support a common way of deploying daemons. This is provided by supporting the concept of self contained daemons wrapped within deployment jars, and then described through meta file information. This is very similar to war file deployment for web applications.

Does it provide support for web applications?
Yes Coadunation can deploy a web application through support for an embedded version of tomcat.

Is SSO (Single Sign On) supported?
Yes Coadunation does provide single sign on.

Are containers supported?
Yes Coadunation does implement container support. Each daemon is wrapped within a container, and exposed via RMI or Local interface containers. There is also support for Web Service containers.

Is RMI supported?
Yes, it provides RMI over IIOP.

Is dynamic RMI stub code supported or will I have to link with the stub code?
Yes, Coadunation does support dynamic RMI stub code. As a result, all clients not running inside of Coadunation will have to setup the Java security manager correctly. If this is not an option, the stub code for server is stored within the client directory of the distribution once it is deployed.

Is CORBA supported?
Yes, CORBA is supported.

Are web services supported?
Yes, web services can be exposed, either directly via Coadunation or via the embedded Tomcat application server.

Is JNDI supported?
Yes, Coadunation does supply a JNDI implementation, that enables the lookup of Daemons, Data Sources and Data.

Are Remote interfaces supplied?
Yes, a daemon can be exposed via a remote interfaces.

Are Local interfaces supported?
Yes, local interfaces are supported for all exposed daemon interfaces.

Is Auto Deployment Supported?
Yes, all daemons and web applications will be deployed if they are placed in the deployment directory.

Is a deployment order supported?
Yes, this is supported in the following ways:

• First daemons are deployed in numerical and than alphabetical order. As a result a daemon thats named 0001-Name will start before a demon named 1000-Name.
• Secondly the daemon contents are deployed in order. This order is:
  • First: all MX beans are deployed in order they appear in the deployment file. The threads for each bean are started immediately after a bean is deployed.

    Once all MX beans and threads have bean deployed they are bound to the JNDI.

  • Second: the standard daemon beans are deployed in order of appears in the deployment file. The threads for each bean are started immediately after a bean is deployed.

    Once all daemon beans and threads have bean deployed they are bound to the JNDI.

  • Third: all web services are deployed in order of appearance.

Is an undeployment order supported
Yes, it is the inverse of the deployment process.

Are threads supported?
Yes, standard threads are supported within Coadunation daemons and there is the concept of User based threads. If a thread has to access something within another container, than the running thread has to be authorized. Because of this threads can be configured in the deployed file to start as a specific user?

Are thread pools supported?
Yes, Coadunation can start a thread pool for a daemon it is deploying.

Can I use IOC container frameworks inside of Coadunation?
Yes, can be done without a problem.

Are Data Sources Supported?
Yes, data sources are supported.

What form of logging does Coadunation support?
Coadunation provides Log4J support.

Does Coadunation Central Configuration?
Yes, central configuration is supported.

Is centralized user management supported?
Yes, centralized user management is supported.

Is a distributed environment?
Yes, Coadunation provides the ability to setup a distributed environment. This results in Coadunation instances being bound together and acting as leaves in a tree structure. This provides the ability to route information between nodes.

Does Coadunation provide a message service?
Yes Coadunation does provide a message service and it is fully aware of distributed environment allowing it to route messages between nodes.

Must Coadunation run as Root or Administrator
Coadunation requires access to privileged ports, for its DNS server and Mail Server. As a result of this the easist way to run it is either as root on unix or as Administrator on Windows.