Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Announcing the Coadunation 1.0.1 Daemon Server

kdawson posted more than 6 years ago | from the lyra-will-be-pleased dept.

Java 13

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

cancel ×

13 comments

Sorry! There are no comments related to the filter you selected.

who cares? (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#21950722)

how is this front page? who gives a flying monkey care in the world about this?

Re:who cares? (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#21950910)

He got modded down for saying what we are all thinking, shame on you /.

Interesting...but niche? (4, Informative)

MrBigInThePants (624986) | more than 6 years ago | (#21950912)

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? (1, Insightful)

Anonymous Coward | more than 6 years ago | (#21951606)

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? (1)

MrBigInThePants (624986) | more than 6 years ago | (#21962598)

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??

Re:Interesting...but niche? (1)

illegalcortex (1007791) | more than 6 years ago | (#21960416)

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.

Weird (3, Funny)

rduke15 (721841) | more than 6 years ago | (#21951210)

"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 (1)

CoolGopher (142933) | more than 6 years ago | (#21951474)

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

Re:Weird (1)

jd (1658) | more than 6 years ago | (#21961748)

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

News? (2, Insightful)

kriss (4837) | more than 6 years ago | (#21951226)

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 (3, Insightful)

Aladrin (926209) | more than 6 years ago | (#21952380)

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 [coadunation.net]
"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 (5, Informative)

coadunation (1073252) | more than 6 years ago | (#21953646)

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 (0)

Anonymous Coward | more than 6 years ago | (#21985292)

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

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>