Using wadm in Sun Java System Web Server 7.0 (part I)

          As you may have noticed, the Sun Java System Web Server 7.0 came out with a revamped command-line interface that incorporates a scripting
This scripting framework is based on JACL a java-vm implementation of the TCL language. During the start of 7.0 effort, multiple
languages were evaluated to provide the scripting solution that we wanted. The Application server even had their own home grown
solution called asadmin that provided a very skeletal interface to command invocation (I wouldn't call that a language yet.)
We were looking for the following features so as to make the use of our scripting interface painless for the users.

Our needs...

  1. We needed to provide the same kind of interface both as stand-alone command line and also asexposed to scripting with in the language environment. This meant that the language needed to be as close to the shell scripting syntax as possible.
            This was high priority also because we recognized that most of our customers were sysadmins who will be more familiar with
            the shell scripting    environment than with any other language.

     2. Most of our enterprise customers have home-grown solutions that rely on configuration files and shell scripts to achieve large scale clustering.
          Attention was paid to the mouldability of the language to emulate these systems so that the barrier of entry would be low for our
          scripting framework.

     3. We needed a powerful system that ran on top of JVM, (did not have the resources to create or adapt any new language
           to the jvm platform)

     4. A system that would allow us to hammer out simple scripts for simple tasks, and also keep its cool on complex tasks was felt to be
           the need of the hour (especially because our largest customers had to write very complex solutions to maintain their farms) We also
           wanted to support only a single language since having multiple languages would fragment the users and the community using the wadm.
           We evaluated the following based on these guiding principles.

Languages we looked at

\* scheme (jscheme)
\* python (jython)
\* ruby (jruby)
\* perl
\* shell (various _sh)
\* asadmin
\* groovy
\* beanshell
\* javascript (rhino)

The first one we looked at was asadmin, one because we had lots of in-house expertise on it, and second, it was already being used in
one of the sister products. Sadly it fell far short of most of the requirements.

The various shells like bash,zsh,ksh,csh started out as favorites because they had the shell syntax (well, they are the shells). but did not
make it due to the unavailability of a jvm implementation.

The same was true of perl.

python was a hot favorite of AppServer folks but did not make the grade because it made exchange of simple scripts needlessly difficult
(the indentations have a way of getting lost when you copy/paste your scripts to or from emails or web pages). Its strict philosophy was
also a slight turn off.

groovy was very interesting since it took the pain out of using the java libraries but that very same feature worked against it. While it may
be very comfortable to pick up for developers who are used to the java syntax and API, we were not very sure that the sysadmins were
going to do like it. If possible we wanted to hide the jvm underneath at least for common tasks.

The same was true of beanshell too.

The javascript offered a better perspective compared to the above two. It also had the advantage that we were associated with the
early javascript implementation (when it was the Mocha) and later we had even carried it as a server side scripting solution. It had a
'discover the features as you use' feel to it. It was obviously well suited for doing smaller scripts. Looking at its large scale features to
manage complexity,
       It had a very open prototype based inheritance which was much easier to use than many other languages, Allowed
all the features of dynamic languages including redefining the methods and classes at run time, It is very clean, and easy to maintain.
       It even allows continuations to be stored and used. JavaScript was in consideration until the last moment, and so was Ruby.

Looking at ruby, There are immediate benefits arising out of its support of open classes just like javascript, and interesting abstractions
like co-routines, interesting uses of objects and iterators, mixins etc.
       It also has a very clean and consistent syntax. Stitching up small languages for use in configurations and other server farm administration
tasks are also pretty easy in this ruby.

was also ruled out as it was markedly different from the shell/perl world that our end users are in currently.

Then we evaluated jacl (TCL), some of the things that we immediately attracted us were,
        1) It had the closest to the shell syntax that we can find on top of a jvm.
        2) Language with the fewest number of rules (right there with scheme) It has a simple primitive, the command. no special cases
             any where, and another simple data structure the list.
        3) Very high redesign capabilities (You can create your own language with it) Macros if you need them, create your own
             primitives, redefine syntax etc.
        4) Interesting and few primitives (even lower than scheme) means you can pick it up in half an hour.
        5) max late binding to be found any where.
        6) Availability of an existing vm based language so that we can utilize java api's in a pinch.
        7) an existing event driven model that may come in handy
        8) clean code with consistent interface.

While comparing with the rest of the finalist languages, Ruby and JavaScript, The negatives with TCL
(as far as we were concerned) were

1) Richness of syntax.
           Ruby has a much richer syntax than either JavaScript or TCL, though we were not sure if it should be considered a virtue
           for the audience we were targeting.
2) No built in OO, but this could be rectified the same way it is done in CommonLisp/Scheme if necessary, since the language
           allows itself to be extended quite heavily (incrTcl being an example).
3) Absence of interesting things like closures, continuations etc. (These cant be done in tcl even by extending it, while both ruby
           and javascript provided them)

Considering all the three, the main deficiency was 3, but considering other advantages, we decided to go for TCL
(or jacl - its jvm implementation.) the clinching argument was that the command lines would look exactly same in a stand alone
mode and within the jacl environment.


Any plans to introduce JACL as the admin script interface to the Java Application Server as well?

Posted by Patrick Finnegan on August 21, 2007 at 08:45 AM IST #

It would be cool if GlassFish adopts the WADM Jacl interface. But I do not know if they are considering it. (I will be willing to help if Application Server is considering a similar interface :) )

Posted by rahul on August 21, 2007 at 09:14 AM IST #

Any plans to introduce JACL as the admin script interface to the Java Application Server as well?

Posted by Patrick Finnegan on August 21, 2007 at 09:28 AM IST #

Yes, we are considering adding JACL in Sun Java System Application Server's CLI. Thanks Rahul for this writeup. I will definitely take your offer in adding this in asadmin.
Stay tuned...

Posted by Jane on August 21, 2007 at 03:27 PM IST #

For those interested in all things Tcl,
see Note that the
Tcl 2007 conference is set for the last
week in September in New Orleans.
Conference information is provided at that website
(see the link on the upper right side of the page).

Ron Fox
Tcl 2007 program chair.

Posted by Ron Fox on August 21, 2007 at 06:01 PM IST #

"No built in OO, but this could be rectified the same way it is done in CommonLisp"

You mean by having a complete, built-in OO system in the ANSI spec?

Posted by cody on August 23, 2007 at 04:21 PM IST #

Hmm, You missed on what I meant by a long way :) . The way it is done in lisp is to have a language that does not have to bend backwards to admit a paradigm that was not in vogue when it was designed. It is malleable. (This is why I said CL/Scheme :) )

As far as I am concerned, the value of having that object system in the spec is relevant only when there are multiple implementations. For us it is not (because we are an implementation not a spec).

TCL gives us that malleability, and the number of object systems that have been implemented in TCL is quite close to the number that have been implemented in Scheme.

Posted by rahul on August 23, 2007 at 04:35 PM IST #

Is Jacl capable to write Web 2.0 applications like PHP? Any API to use MYSQL with Jacl?

Posted by Charlie on August 30, 2007 at 01:49 PM IST #

See (aejaks) a framework for web2.0 applications with jacl.
Jacl gives you complete access to any java classes and objects in your system. Thus you can use your JDBC drivers for MySQL (and others) directly from jacl.

Posted by rahul on August 30, 2007 at 02:33 PM IST #

See getJVMinfo_proc.tcl at the following link for an example of JDBC usage.

See for an overview of how Jacl is used with WebSphere.

Posted by Patrick on August 30, 2007 at 06:46 PM IST #

Post a Comment:
  • HTML Syntax: NOT allowed



« July 2016