You are probably familiar with various management consoles that various application servers provide you with in order to manage your application. The problems that these UI consoles have are the problems that any UI has once the number of features starts to grow: they simply run out of space (most of the time the space available for displaying your app server console is a web page which is fixed in size). If you ever looked at Weblogic 10`s management console you probably noticed the 3-level menus that are trying to lock a developer onto the feature they need to change. Well, as I was saying in a previous post, this approach doesn`t scale because you will be running out of space. I wonder when will Weblogic`s management console have 7-level menus given the speed at which features are getting added to app servers.

One other problem that the an UI management console puts forward is that it makes a developer (a person that usually is fluent in a few scripting languages) use a UI which is wasteful. It is wasteful because it wastes one of your most precious resources: the fact that your developer is a developer and that developers are familiar with scripts. UI solutions reduce your developer to the level of an ordinary user whose knowledge about an app server is reduced to the knowledge of various entities managed by your app server (servers, connection pools, datasources, applications, JMS queues, etc…) and the knowledge of clicking along. A developer would probably be more productive if it could take a look at its operational environment, determine various tasks which occur often and script up a solution to solving these tasks rather than clicking away. This is a lot better when you are perfoming composite tasks like adding a connection pool, exposing it thru a data source, adding this datasource to various servers and re-starting the servers to load the datasource. It makes a lot more sense to put up a script solution if you have to carry out these tasks across a cluster for the simple reason that you may forget to carry out a task for servers (or worse, for a series of servers).

Another problem with UI management consoles is that the error factor is higher: it is possible to click on the wrong button - `Do you really want me to shut down this server?` - and that it takes a long time to carry out a task. This it the problem with humans, they are slow and error-prone.

Now a bit about the languages used for creating management scripts. Given that most of the tasks that would be scripted are variations on the same theme (repetition occurs pretty often when you are managing servers) it would make sense to use a language in which you could define templates easily. An OO language (such as Ruby) would probably make a lot of sense. ant is good (and Weblogic lets you admin your app server thru ant tasks) but ant can only go so much.

One last advice that I would have would be to avoid duplication of scripts. I am saying this because Weblogic lets you create scripts for managing your server both in Python and in ant. You should avoid duplication and settle for one language.

Moving from an UI-based management console to managing your app servers thru scripts is a pretty dangerous task. If you are not careful and don`t plan this move well you may end up with a lot more problems. Think about managing your servers thru scripts as of programming your operational environment, the same problems that programming poses will arise in managing your operational environment. Bloat-ware, feature-creep. code duplication, etc… may rise to haunt the way you manage your app servers if you don’t write your scripts carefully. You would be well advised to try to do your best to avoid such problems, because they are very hard to solve once they appear.
What makes them `coding` your environment very hard to solve is that the stakes are a lot higher in this case than for your typical code blunders: your operational environment will depend on the way you `coded` it and the costs of refactoring these management scripts are huge: your entire cluster could go down if you are not too careful. A developer with a lot of experience would probably be needed to supervise this exercise.
P.S. It would probably not be a bad idea if in addition to providing a JMX interface to your application for managing your application, a JMX interface that can be displayed in an app server`s management console, you could also provide an ant task which would carry out the same operation on the application deployed on the app server remotely. I am not sure if this is actually possible (I think that one good solution would be the app server exposing the JMX interface thru an ant task) but it would be pretty nifty.

P.P.S I wrote this post because I had nothing better to do. Take it with a ton of salt.

I was watching this presentation by Rod Johnson on infoq when I came across the part when Rod Johnson started talking about using dynamic languages in a Java application. The main reason that he gave for using dynamic languages in a Java app was that due to pushing the core business logic into domain objects the service layer becomes very thin, “script-like” as he called it. Rod saw an advantage of using dynamic languages (DLs) in implementing the service layer as a series of scripts, I interpret his take correctly.
This is an interesting proposition. I find it a bit off-the-wall and at the same time very timid, which is telling about how DLs are currently treated in the Java world. There is a bit of fear about using DLs, stemming mainly from the lack of exposure to them, like working with any other thing that you do not know you are bound to make mistakes and the fear that getting too involved with DLs may cause some very costly mistakes is present. At the same time you fear being left behind while the rest of the computing environment embarks on these popular DLs, you may be missing out on the next great thing (BTW, the next great thing is very rare). This could sum up the attitude that Java developers have towards DLs: DLs are pretty interesting things, too bad I don’t know how to work with them.
I decided to write this post in order to correct a misconception that most of the people writing about DLs have: that DLs are all about capabilities which are encapsulated in a language. I think that DLs are about their capabilities, but, just as importantly, about the workforce coding in such DLs and I find that scripting example put forward by Rod Johnson fits this statement.

One big problem that using a DL in a Java application is the exposure that the developers using it had to that DL. You will find that most developers will absorb a foreign language only so much, and will tend not to get too deep into it unless it applies heavily to their tasks. You will also find that getting to know well a DL requires quite a lot of effort, effort that most developers are not willing to put in. The correct use of a DL being related to the exposure to that DL it follows that you cannot really use a DL’s more sophisticated features and that you will also try to avoid developing complex constructs in a DL. The scripting example becomes very telling right now, because scripts are nimble little things which do a very small and simple task, I would say that this type of tasks can be coded by a regular Java developer in a language that it cannot master completely. I would even venture to say that because of high costs of adopting a DL DLs will never get beyond simple nimble things in the Java world. I am not so sure about coding the service layer in scripts though. Will the service layer dwindle in complexity to the point where you could script it up? I am not so sure, time will tell.

P.S. The costs for adopting a DL are the costs of adopting any language, in particular a domain-specific language (DSL). These costs are roll-back costs (you cannot roll-back a language out of an application so easily), training costs (the work-force needs to be trained in this language) and human resources costs (if you happen to choose a language which is not considered cool anymore you may end up having recruitment problems, who wants to work on something perceived as a dinosaur?)

This would explain why developers have the same reaction to DSLs as they have to DLs: a bit of fear laced with excitement.

P.S. 2 I wrote this post in a hurry, I think it shows thru.

Later Edit: It would be interesting to see that now with scripting languages moving into JEE applications whether JEE applications will be used by developers using scripting languages. If Rod was right in his assumption that the service layer could be script-ed up it is conceivable that a Java app could be picked by a Ruby shop that would modify its service layer as it fits its needs. I don’t see this happening because the Ruby people would have minimal control over the app in this case (in this scenario they would have control only over the service layer, even though in theory it is possible to plug Ruby business logic beans into the original Java app via Spring) and because it would require that the Ruby team has some exposure to a Java application deployment environment (Spring files, etc…). Again, it requires that a set of developers (Ruby developers in this case) has some exposure to the other language and environment (the Java application) with all the problems that this implies.
Later Edit 2: Today I read about an interesting case of scripting: JRuby GUI APIs. What I find interesting about coding GUI in Ruby is the fact that it lowers the barrier of entry to coding them to scripting, a coding style that is much closer to a graphic designer than your typical Swing event handlers. Who knows, maybe the future desktop designers will grok JRuby…