Middleware Matters

Hi Steve,

I wonder the same as well ;-)
interstingly enough, there has been a "middleware" software, well sort of an application server really, in the past that did just that: Brokat's Twister. While that company is long since gone (the software has somehow lifed on - I forget the name of the company), the idea was quite nice.

You could write server side components in either C++, TCL or Java. It even supported inheritance between the three, had a "common type system", all that we today now as .NET ;-)

Basically, they had performance or API-dependend stuff in C++ (like MQ Adapters, Database support) and the business logic in TCL.

Cheers,
Christian

Hi Steve,

Talking about server side scripting reminds me of when CORBA was all the hype and I wrote a server side CORBA based scripting language. It used CORBA's interface repository to perform dynamic type checking before making calls. Fun little project, ashame it didn't go anywhere.

I think the reason many scripting languages don't take off comes down to supported libraries. It becomes a lot more work to use a scripting language when it doesn't have a full library of tools. Now that scripting languages are moving to CLR and the JVM, it opens the way for them to use the much larger set of tools available.

JSR #292 is another interesting Java modification that adds a new jvm instruction to support dynamic calls in java specifically for scripting languages. It won't be in Java for a while, but good to see this type of work being done.

David.

Ok, Steve, you're a bright guy, and I'm obviously not, but I'm wondering what on earth you are on about!

Dynamic languages have been used from the outset for CGI and Web service development. Jython, Groovy, Ruby and even Perl has been integrated with or by the JVM, and .NET from the outset looked to run *anything* down to APL and Eiffel, oh and then there is Parrot waiting in the wings. The interesting question for me is why you would ever not want to use a 'scripting language' (hate that term) for 'server side developement' (hate that too)?

HUH??? Is this one of those linkbait blog comments???

*Everyone* uses scripting languages for server-side development. Almost no one uses C++... DUH.

In fact, Javascript as a server-side scripting language has had its day and is now passe. It used to be the tool of choice a decade or so ago when Netscape's web server was still enjoying mindshare.

Hi Paul,

My column already describes the fact that scripting has always been a part of CGI development. As for Web Services development, from my perspective, it's a lot like other middleware: yes, there's some scripting involved -- more so than in previous middleware spaces, I agree -- but the amount of scripting involved in my experience pales in comparison to how much Java and C# there is. YMMV, but from where I sit, it's just very much a Java/C#/C++ middleware world out there.

And like you, I don't understand it why "scripting" languages aren't used much. My column was just an attempt to explore some of the historical and cultural reasons why the language divide between the web world and the middleware world exists, and I definitely don't pretend to have all the answers. But the divide is definitely there.

Hi Jon,

The topic is about why scripting languages aren't used for *middleware* server development, not web server development.

Hey Steve,

I guess it's just the simple matter of "what is middleware" then ;)

Some of the most successful message processing projects I've been involved with have used informal pipelines of scripts, whereas some of the real clunkers optimised too early building on platforms and frameworks in Java or C++.

When it comes to scripting (v) compiled languages, Roberto hits the nail bang on the head when he contrasted the benefits to a developer in using a static typed as opposed to a dynamic typed language:

http://blogs.sun.com/roller/page/robc?entry=jungloid_mining

Paul

I sure do like good static, compile-time type checking. I like to have the compiler do as much error checking as possible, and it's hard to get that out of so-called dynamic languages. If you pick a decent class library (so you don't have to reinvent the wheel) you can get something up and running pretty quickly even in C++.

As a philosophical issue I'd like to resolve as much as possible at compile time for quality reasons; it's just less likely to break at runtime.

Hi Steve,

I'm wondering why you're starting/stopping with Javascript for your server-side scripting libraries. For some research into potential architectural evolution over here http://www.reach.ie/ I implemented both dynamic filter chains and service activators which would allow services to be implemented in BeanShell, JavaScript, Python and Ruby using the (admittedly, now ancient) Apache Bean Scripting Framework http://jakarta.apache.org/bsf/

BeanShell and JavaScript were the performance winners in my tests (confirming other sources), but from a practical point of view, Python or Ruby make things much more sane when trying to implement something useful (I grew to despise BeanShell as a "scripting" language in the process). Depending on the requirements and performance SLA's, I would have no problem deploying services and filters implemented in scripting languages in our production environment--unfortunately, we're not there yet.

Hopefully, with the new JSR, things like this will become a bit easier and much more common.

Cheers,

ast

BTW, the comment software is really annoying in that it "interprets" what you want linked, resulting in potentially invalid URLs. Apologoies for the reduced readability relating to the hyperlinks due to this problem.

Hi Andrew,

I'm not stopping with Javascript -- it's just that that's what Stefan's blog entry was talking about, so that's what I talked about here too.

I've looked at the BSF and I don't think it does what I want, since it's very focused on augmenting Java applications with scripting. (It's also quite old, as you mentioned.) I'd prefer that any underlying Java or C++ remained as hidden as possible, ideally completely hidden, so that dynamic language users deal with only their chosen language.

Hi Steve,

Good to hear you're not only dealing with JavaScript. BSF wasn't too hard to use, but it was the only way I could see to get multiple scripting languages into my prototype last year using JDK 1.4.x. I didn't want to do it one language at a time, and the JSR 223 wasn't ready.

I also agree that the dynamic languages should be as insulated as possible. In what ours did, there was a bridge layer which provided a few key abstractions: a message, ports and the service activator, then that was it. You read the messages from the port and processed them accordingly. The only thing I wasn't 100% happy with was that the script needed to register itself with the activator (this was the only Java object directly injected into the script engine). I was always going to go back and try and make that a little cleaner, but, for the prototype, it was only one extra line in the script and it meant that I didn't have to do any special-case processing within the application for lanaguage X. If you want to add some new one, you just write your service or filter in it, specify the name of the script file in the configuration settings and it just works.

I'm interested to see your solution in comparison. Is it available in Celtix yet?