Announcing the Coadunation 1.0.1 Daemon Server

coadunation writes "After more than a year's worth of development, the Coadunation project is proud to announce the first official version of the Coadunation Java-based daemon server, version 1.0.1. Coadunation enables developers to quickly and easily develop daemons, web applications, distributed applications, manage distributed services, etc. We hope to follow this release by a web site overhaul in the next two weeks, that will replace the corporate facade with a community-based Web site."

Comments

Interesting...but niche?

[MrBigInThePants]

Java Architect, large pant wearing psychopath here.

My first thought was web-app + quartz, so what - why should I care? The examples given (creating a email server??) are not that great either, considering only niche devs would be doing anything remotely like this. In my own, quite varied, experience the only time I (or others) have had need of a "daemon" is as a small part of a wider web app and we would just use quartz job initiated java code, JBPM or something similar.

Having said this, it appears to support clustering and other snazzy features. ("it apppears" is used because I never trust the claims of OS devs or their user's opnions of products - the bar is so low nowadays) The possibilities for distributed computing is quite compelling also.

I guess, in the highly unlikely event I should ever work on such a project, the main draw card for me would be that it just rolled out and clustered with minimal fuss and bother (Not an OS strong point...), was very lightweight and could plug easily into a range of security environments (or at least the one I was using!).

So what is my point? Cool tech, but appears very niche to me. The only reason I find myself having to point that out is because it talks a lot about app servers and how it compares.

Re:Interesting...but niche?

[Anonymous Coward]

I'm just wondering...if you wanted to build a chat server who's users were users that had already authenticated against your web site, would this be a better example of the technology?

Re:Interesting...but niche?

[illegalcortex]

Interesting...but niche? Considering the story has been up for 15 hours and has only 7 comments (8 now), one of which is from someone on the project, I'd have to say your point is proven.

Re:Interesting...but niche?

[MrBigInThePants]

That would be an application. You could come up with hundreds like it.

But is that a mainstream killer app? Very few people build chat servers AFAIK? (apart from students learning client server programming! :) )

I guess that is my point: "Where is the mainstream usage killer app example?"

Does it exist??

Weird

[rduke15]

"We hope to follow this release by a web site over hall in the next two weeks"

Never seen a web site over a hall before. Would it be displayed on some giant screen?

Re:Weird

[CoolGopher]

Yeah, they're working on hauling the giant screen over right now.

Re:Weird

[jd]

I think the plan is to use The Blinkenlights Project and every hall they can find in a one mile radius.

News?

[kriss]

Nothing truly original, nothing really noteworthy. I can see this on freshmeat, but - as others have stated - front page material?

If your software is good, you probably don't need to plug it on slashdot yourself in the first place.

Can't do

[Aladrin]

The FAQ page reads like a list of things it -can't- do and why some of that's great. (Simplicity)

http://www.coadunation.net/faq.php
"Yes Coadunation does allow the developer to implement threads." - No built-in support.

There are times when this type of development is not appropriate or over complicates the matter;" - Having events was too complicated

"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.

"Unfortunatly at this point no CORBA interceptors are available to authenticate the call on Coadunation." - That's a no.

"Coadunation does not however allow more than one endpoint per WSDL file." - If you can't handle a real WSDL, why bother?

"Is UDDI suppoted? Not at this point there are plans to implement it." - Another no.

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.

Re:Can't do

[coadunation]

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.

Re:Can't do

[Anonymous Coward]

>>>> "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.

Actually, you're not correct about that. Many complex SOAP implementations have multiple service definitions per WSDL, and in those cases having multiple endpoints is not uncommon. If you go anywhere near a big software shop using SOAP and tell them that you can't do multiple endpoints, they will tell you exactly what GP said ... either support the actual spec, or don't support it at all. Seriously, this is a real issue, at least in the big-corp market ...