Re: Thoughts on a polyglot app server?
Maybe this? http://immutant.org/news/2011/11/01/announcing/ Am 01.11.2011 um 21:48 schrieb Jason Toy: Any more plans or ideas on this? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Thoughts on a polyglot app server?
They announced it today: http://immutant.org/news/2011/11/01/announcing/ -Original Message- From: Jason Toy jason...@gmail.com Sender: clojure@googlegroups.com Date: Tue, 1 Nov 2011 13:48:54 To: Clojureclojure@googlegroups.com Reply-To: clojure@googlegroups.com Subject: Re: Thoughts on a polyglot app server? Any more plans or ideas on this? On Sep 29, 1:48 pm, Jim jcrossl...@gmail.com wrote: The TorqueBox[1] team is toying with the idea of exposing to Clojure the abstractions we currently expose to Ruby. We're looking for feedback from you guys to see what you use now to solve these problems, what you'd like to see in a possible Clojure App Server, and if you might actually use it. If you're not familiar with TorqueBox: it's an application server for Ruby apps, allowing you to run them on top of JBossAS[2]. But it goes to great lengths to preserve the typical Ruby development experience, e.g. no war files or XML. In addition, it provides the following enterprisey features to Ruby, built-in: * asynchronous processing (with futures) * scheduled jobs * XA transactions * companion services (daemons) * distributed caching * messaging (via JMS) Coming from a Ruby background, all of the above were pain points for us. Do these same pain points exist for Clojure apps? TorqueBox also supports clustering, which allows load balancing of the web component as well as cache distribution and horizontal scaling of async tasks, scheduled jobs, and services. Clojure has built in async processing and futures, but they use an in VM thread pool, correct? How would you scale that? A common TorqueBox idiom is to leverage Ruby in the web tier and Java in the services/data tier. Are there any Ring-based frameworks that make Clojure more appealing than Ruby in the web tier? Or does integrating a Ruby web app with a colocated Clojure service make more sense? It should be fairly easy to loosely couple them via messaging. Speaking of which, if you are using Clojure to process data generated by other apps/languages, how is that data communicated? Would language agnostic messaging be useful here? How do you currently run production code (web apps or otherwise)? We'd love to open a dialog about these and other things. Any feedback you care to share is appreciated, either here, or in #torquebox on Freenode. Toby Crawley and I will be in Raleigh for Clojure/conj as well, so we look forward to meeting you there! Thanks! [1]:http://torquebox.org/ [2]:http://www.jboss.org/jbossas -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Thoughts on a polyglot app server?
The TorqueBox[1] team is toying with the idea of exposing to Clojure the abstractions we currently expose to Ruby. We're looking for feedback from you guys to see what you use now to solve these problems, what you'd like to see in a possible Clojure App Server, and if you might actually use it. If you're not familiar with TorqueBox: it's an application server for Ruby apps, allowing you to run them on top of JBossAS[2]. But it goes to great lengths to preserve the typical Ruby development experience, e.g. no war files or XML. In addition, it provides the following enterprisey features to Ruby, built-in: * asynchronous processing (with futures) * scheduled jobs * XA transactions * companion services (daemons) * distributed caching * messaging (via JMS) Coming from a Ruby background, all of the above were pain points for us. Do these same pain points exist for Clojure apps? TorqueBox also supports clustering, which allows load balancing of the web component as well as cache distribution and horizontal scaling of async tasks, scheduled jobs, and services. Clojure has built in async processing and futures, but they use an in VM thread pool, correct? How would you scale that? A common TorqueBox idiom is to leverage Ruby in the web tier and Java in the services/data tier. Are there any Ring-based frameworks that make Clojure more appealing than Ruby in the web tier? Or does integrating a Ruby web app with a colocated Clojure service make more sense? It should be fairly easy to loosely couple them via messaging. Speaking of which, if you are using Clojure to process data generated by other apps/languages, how is that data communicated? Would language agnostic messaging be useful here? How do you currently run production code (web apps or otherwise)? We'd love to open a dialog about these and other things. Any feedback you care to share is appreciated, either here, or in #torquebox on Freenode. Toby Crawley and I will be in Raleigh for Clojure/conj as well, so we look forward to meeting you there! Thanks! [1]: http://torquebox.org/ [2]: http://www.jboss.org/jbossas -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Thoughts on a polyglot app server?
On Thu, Sep 29, 2011 at 13:48, Jim jcrossl...@gmail.com wrote:
The TorqueBox[1] team is toying with the idea of exposing to Clojure
the abstractions we currently expose to Ruby. We're looking for
feedback from you guys to see what you use now to solve these
problems, what you'd like to see in a possible Clojure App Server,
and if you might actually use it.
Well, we would be seriously interested in it at Puppet Labs. At the
moment we have a pile of Ruby code, and are using Clojure in some
newer parts of the overall project. The move toward Clojure is
motivated by the scale and especially parallel operation benefits that
it brings to the table.
The obvious attraction is that TorqueBox would bring an integrated
layer below our Ruby and Clojure code; we would have the same services
available to both, exposing coherent interfaces between the parts, and
would also allow more intimacy around Java interop and cross-language
direct calling.
In terms of Clojure integration, comments around what we care about:
* asynchronous processing (with futures)
Ideally we would want something compatible with Clojure futures, but
if you offer (eg) bounded thread pools then having compatible syntax
would be a win. Right now we can get away with the default unbounded
pool size, but the choice would be awesome.
* scheduled jobs
* XA transactions
* companion services (daemons)
Being able to bring these up in Clojure also would be awesome.
* distributed caching
External memcache compatibility would be a big win here, for us right
now, but isn't long term essential.
* messaging (via JMS)
We currently use ActiveMQ to provide STOMP services for MCollective,
and for some internal queue needs. AMQP/JMS messaging would be
valuable, especially if it can interoperate with ActiveMQ, or supports
easy broker clustering, but not essential.
Access to configuring those things from Clojure would be valuable.
On the client side we use clamq (https://github.com/sbtourist/clamq)
to wrap up interactions with the queue service; having that, or
something with similar abstractions, would be valuable. We especially
like the model of a queue consumer as an infinite lazy sequence.
In addition to those features, having a working and supported Ring
adapter free as part of the distribution would be of great value.
That is approximately the Ruby Rack feature, and means we can drop
whatever front-end we want in place.
I have not looked at JBossAS, but having a pleasant way to cooperate
with lein project descriptions, or support an uber{war,jar} for
getting our application in place, would be awesome.
Coming from a Ruby background, all of the above were pain points for
us. Do these same pain points exist for Clojure apps?
Aside from futures, all of those have been, or are, pain points for us
getting bootstrapped in our Clojure project.
TorqueBox also supports clustering, which allows load balancing of the
web component as well as cache distribution and horizontal scaling of
async tasks, scheduled jobs, and services. Clojure has built in async
processing and futures, but they use an in VM thread pool, correct?
How would you scale that?
More or less the same way, as near as I can tell.
A common TorqueBox idiom is to leverage Ruby in the web tier and Java
in the services/data tier. Are there any Ring-based frameworks that
make Clojure more appealing than Ruby in the web tier?
From our point of view, Clothesline is an Erlang WebMachine clone and
has been awesome for getting our RESTful service working nicely. It
decomposes the process of correct HTTP request handling effectively.
For strictly user-facing design we are mostly interested in richer
client side code, so having something focused more on good API than on
easy click-refresh page design makes that kind of moot.
Or does integrating a Ruby web app with a colocated Clojure service
make more sense? It should be fairly easy to loosely couple them via
messaging.
We expect to be doing both of those things over the next year or so.
Speaking of which, if you are using Clojure to process data generated
by other apps/languages, how is that data communicated? Would language
agnostic messaging be useful here?
We encode to JSON, which is sufficiently rich, as well as sufficiently
feature poor, that it hits a good balance. We can express and
document interfaces well between components around those basic
structures, and that in turn makes it easy to get interoperability and
third party developer support built in effectively.
From where we sit the three things that would be convenient are:
1. REST API for messaging which accepts JSON. (I see HornetQ delivers :)
2. Built in JSON encoding and decoding in the message queue wrapper.
3. Clojure multimethod-like dispatch on messages.
For 3, right now we have a structure { command: some name here,
... }, and dispatch on that top level command key (and, possible, a
version tag) to our top level handler. Being able
