Comment Re:Can't do (Score 5, Informative) 13
Hey thanks for the feed back on the FAQ, will have to work on that. Just to set the record straight here though.
>>> "Yes Coadunation does allow the developer to implement threads." - No built-in support.
Yes there is complete support for standard threads, but it also has support of user based threads. This means that unlike an application server it can spawn a thread on demand or from the deployment file that is attached to a user. This means that daemons can access other containers and be successfully validated.
>>> There are times when this type of development is not appropriate or over complicates the matter;" - Having events was too complicated
Event programming is fully supported, but it is also possible to spawn a thread and listen on a port like a mail server for example and than have that thread access information beyond its own container. This is the case with the built in Tomcat daemon, that comes with the base install.
>>> "Yes clustering is supported, but not like an application servers. A cluster of Coadunation instances do not run as one system. They are instead bound together in a hierarchy, making it possible to access any daemon anywhere in a cluster." - Not much of a 'cluster' if you have to reference each server specifically.
Clustering of tomcat is supported as the default built in application server. This document section should have been updated a while ago, but Coadunation is a distributed daemon server environment, and thus each instance has to be aware of where it is in the environment so that information can be properly routed between the nodes.
>>> "Unfortunatly at this point no CORBA interceptors are available to authenticate the call on Coadunation." - That's a no.
As Coadunation is IIOP based CORBA is fully supported, and starting a CORBA object can be done. The only limitation is that at present the inbound thread would have to be manually sudo'd to attach it to a user thread so that it could access something on a container boundary.
>>>> "Coadunation does not however allow more than one endpoint per WSDL file." - If you can't handle a real WSDL, why bother? As most web service implementation generate their WSDL directly from the java interface, there would normally only ever be one end point per WSDL file. So I do not really see this as a limitation.
>>>> "Is UDDI suppoted? Not at this point there are plans to implement it." - Another no.
true, I hope to support it later this year.
>>>> There are a few 'yes'es here and there, but mostly it's a big negative. There's something to say for simplicity, but cutting features in a 'clustered' daemon doesn't seem to be a great idea.
Again, the FAQ documentation needs to be updated here, but Coadunation is a distributed environment, and not a Clustered environment, though as mentioned above the built in tomcat can be configure to cluster.
thanks for the feed back.
>>> "Yes Coadunation does allow the developer to implement threads." - No built-in support.
Yes there is complete support for standard threads, but it also has support of user based threads. This means that unlike an application server it can spawn a thread on demand or from the deployment file that is attached to a user. This means that daemons can access other containers and be successfully validated.
>>> There are times when this type of development is not appropriate or over complicates the matter;" - Having events was too complicated
Event programming is fully supported, but it is also possible to spawn a thread and listen on a port like a mail server for example and than have that thread access information beyond its own container. This is the case with the built in Tomcat daemon, that comes with the base install.
>>> "Yes clustering is supported, but not like an application servers. A cluster of Coadunation instances do not run as one system. They are instead bound together in a hierarchy, making it possible to access any daemon anywhere in a cluster." - Not much of a 'cluster' if you have to reference each server specifically.
Clustering of tomcat is supported as the default built in application server. This document section should have been updated a while ago, but Coadunation is a distributed daemon server environment, and thus each instance has to be aware of where it is in the environment so that information can be properly routed between the nodes.
>>> "Unfortunatly at this point no CORBA interceptors are available to authenticate the call on Coadunation." - That's a no.
As Coadunation is IIOP based CORBA is fully supported, and starting a CORBA object can be done. The only limitation is that at present the inbound thread would have to be manually sudo'd to attach it to a user thread so that it could access something on a container boundary.
>>>> "Coadunation does not however allow more than one endpoint per WSDL file." - If you can't handle a real WSDL, why bother? As most web service implementation generate their WSDL directly from the java interface, there would normally only ever be one end point per WSDL file. So I do not really see this as a limitation.
>>>> "Is UDDI suppoted? Not at this point there are plans to implement it." - Another no.
true, I hope to support it later this year.
>>>> There are a few 'yes'es here and there, but mostly it's a big negative. There's something to say for simplicity, but cutting features in a 'clustered' daemon doesn't seem to be a great idea.
Again, the FAQ documentation needs to be updated here, but Coadunation is a distributed environment, and not a Clustered environment, though as mentioned above the built in tomcat can be configure to cluster.
thanks for the feed back.
