Developers using Java on clients or in small projects may not believe that there is a fundamental problem with Java's robustness. People working with huge applications and application servers written in Java know about the problem but may doubt that it's possible to build something like an unbreakable Java architecture.

Developers using Java on clients or in small projects may not believe that there is a fundamental problem with Java's robustness. People working with huge applications and application servers written in Java know about the problem but may doubt that it's possible to build something like an unbreakable Java architecture.

Unbreakable Java: A Java Server That Never Goes Down. Developers using Java on clients or in small projects may not believe that there is a fundamental problem with Java's robustness. People working with huge applications and application servers written in Java know about the problem but may doubt that it's possible to build something like an unbreakable Java architecture.

Developers using Java on clients or in small projects may not believe that there is a fundamental problem with Java's robustness. People working with huge applications and application servers written in Java know about the problem but may doubt that it's possible to build something like an unbreakable Java architecture.

Unbreakable Java: A Java Server That Never Goes Down. Developers using Java on clients or in small projects may not believe that there is a fundamental problem with Java's robustness. People working with huge applications and application servers written in Java know about the problem but may doubt that it's possible to build something like an unbreakable Java architecture.

Great article.But...much of what your are doing can be already be done using non-proprietary technologies. I am talking about JINI and in particular about the JavaSpaces Service. Dispatching a process per request has already been proven using these technologies. For example you can build a Virtual Compute Server that can handle all your requests in different VMs (several companies have implemented this, we are one of them). Plus you get the dynamism of the VCS (Grid Engine). Obviously JavaSpaces is the shared memory that enables this construct. I think the best approach to the future of Application Servers is in the nature of the Rio Project ([visit link]). I can imagine Sun implementing the future version of their App Server on top of Rio. Ahhh...Rio is OSS! and JINI is almost OSS!

///Inside the VM, parallelism is implemented using threads with no separation regarding memory or other resources. In this respect Java has not changed since its invention in the early nineties///

I agree that ABAP's dispatcher is an excellent model for per-process isolation. Going further in Java, I would suggest adding a portable root jail to the API. This could allow chroot to isolate and/or run the I/O of native subprocesses through a Java SecurityManager, using a user mode filesystem mechanism. In this way you could secure a Java language service... a handy way of adding a final wrapper to the security provided by the JVM.

The thing that bugs me about some Java developers is how they take those concepts like multithreading and separated execution and try to rebuild it painfully with a Java infrastructure, when the VM is probably not the best place to do this.

For example, when the author talks about the ABAP's process model and how it should probably be rebuild with Java. The idea is basically: One process (or thread) per request, shared session data storage across requests - that sounds like the best place for a classic CGI environment to me. PHP would probably do a nice job, or Perl or anything.

So if you want those features, why not build on top of Apache, maybe communicate with the client via XML webservices? CGI calls to script interpreters would pretty much provide anything you could possibly needed, while offering customizable degrees of separation *for free* right in the webserver. Why not? Why spend millions to build another bloated Java application server (that may or may not some day be able to support the same kind of featureset that webserver architectures already have)?

This is nothing more than a cleverly disguised pimping of SAP'S netweaver app server.

First and foremost SAP I do not want to have to run your hacked up JVM. Is it a good idea, yea probably but implementing it is gonna be hard because of the closed nature of JVM.

No sys admin and or programmer in his right mind wants to work with or support some third party JVM.

All that being said what's up JBOSS developers? Is this a good idea? I most certainly trust your skill far and beyond anything these guys can produce.

///What's kind of funny is that the isolation so desired by the author is built in to .NET from the get go. They're called Application Domains, and they're used heavily in ASP.NET to isolate applications from one another, but have them remain inside a single OS process.///

There's more to applications domans than just this.

What's kind of funny is that the isolation so desired by the author is built in to .NET from the get go. They're called Application Domains, and they're used heavily in ASP.NET to isolate applications from one another, but have them remain inside a single OS process.

It was really fun reading this article as isolation as described in this article has been one of the founding principle of the Erlang VM. Erlang is a concurrency oriented langage created to support the development of robust scalable fault-tolerant applications.

I strongly recommand reading Joe Armstrong thesis. This is very enligthning regarding this topic and this is real world feedback:

[visit link]

Fortunately, Erlang has been designed from the ground-up for robustness. All feature of Erlang are designed to achieve the robustness goal (Concurrency model, functional programming, error handling, supervisor and worker mechanisms). This is precisely why it will be very difficul to achieve with Java, if even possible.
I hope this helps,

I have heard ABAP jokingly referred to as "German COBOL."

The article may also be downloaded at the SAP Developer Network in a more readable version. (You might need to register a user for SDN!)

[visit link]

Great story