|
|
|
|---|---|---|
|
Home| Sanos| Documents| Links| Contact| Search| |
By Bjarne Hansen
jbox.dk is our contribution to the emerging wave against unnecessary complexity in IT systems as we know - and implement - them in the IT industry today. The site will be devoted to articles, presentations, discussions, and specific software components related to this topic.
To many, complexity is an inevitable aspect of IT systems if they are handling complex business processes. With good help from marketing people, consultants, and analyst, we all seem to convince ourselves - and our customers - that we need more and more complex systems to handle the business problems organizations are facing today.
Most people agree, that the focus of the implementation of business solutions is about solving business problems - not technology. Yet, the general approach to building IT systems today seem to compare to that of engineers building a huge bridge by simply adding more and more concrete - an approach left by engineers years ago...
Recently, quite a lot of authors, speakers, and even analysts have started to question if we are on the right track. Installing more and more complex products to solve problems that we don't really know if we have, just seem to bury us in self inflicted technology problems. Instead of simplifying the development process thus requiring less skilled developers, as many product vendors claim if we use their products, we just seem to need more and more highly skilled people to install, configure, use, and operate systems based on all these products.
Minimalism, fighting complexity, and realizing that many "strategic" products are mere commodities are becoming a valid subjects for discussion in articles, talks, analyst reports, and on the web. The discussion is going on at several levels: hardware, operating systems, databases, application servers, integration products, e-business platforms, the development process, deployment, and operations.
This jbox site is a result of the discussions we have had among ourselves based on real world project experience and observations on general trends in the IT industry.
One of the specific discussions we had, was: Given the Java platform - how much support do you really need from an operating system below? The answer was quite surprising: If you consider only Java server applications, the requirements of the underlying OS are actually quite limited. This of course, is due to the fact that the Java VM and the associated libraries are written with portability in mind.
The result of this discussion was that Michael created the sanos kernel. Basically, the sanos kernel is a minimalistic OS implementing "just-enough" features to run Java server based applications using a standard Java VM.
Of course, since sanos is a small OS kernel in its own right, it can execute programs written in other languages such as C or C++ using the small API set of sanos. More information on sanos can be found in the dedicated sanos section of this site.
So how does sanos relate to the concept we call a jbox?
Well, as stated on the home page, a jbox is a Java based server appliance able to run on a wide range of PC based hardware architectures, such as rack mounted servers, cubes, blade servers, embedded systems, and ordinary PC's. This basically is achieved if you install the sanos kernel with a standard Java VM.
Why is this interesting? It is, when we look at the properties usually associated with appliances. A general appliance is something you connect to power and start using - you don't expect a lot of installation, configuration and maintenance to be associated with owning and operating it. Similar for server appliances, a server appliance would be defined as something you connect to power and the network and then start using whatever functionality it provides.
Wouldn't that be a nice behaviour for application server running traditional business applications?
A great example of this behaviour is the broadband routers you buy today for you DSL line at home. Connect it to power and the home network, and in a few minutes you are fully connected to the Internet. Of course you can configure a lot of aspects of a broadband router, but if you choose to do so it will often happen through a simple web based interface. This means that the broadband router itself contains a small web server and the web application for administrative tasks. As simple as that!
Traditionally, this type of appliance/embedded development is associated with great cost, since server appliances contains special hardware thus requiring development to be done in "exotic" variations of C or assembler using expensive development tools and/or libraries. Also, the numbers of skilled developers able to develop such solutions are scarce.
The jbox solution targets the problems associated with appliance/embedded development outlined above by allowing your solution to be developed and tested - using Java - on any computer platform using your favorite development tool.
Fine, a simple and minimalistic kernel allowing us to develop server appliances using Java. This will hardly solve problems related to implementing and executing large scalable business applications? The answer is: It might!
Today, various clustering techniques are used to achieve scalability and stability for large-scale business applications. Clustering solutions are designed to be transparent to developers, but in reality they pose several restrictions on how solutions can be developed and deployed. Also, implementing a clustered solution often introduces a new level of complexity that tends to compromise the actual stability of the solution.
Another approach to building scalable and stable solutions would be to architect solutions to have a distributed nature instead of relying clustering solutions outside the application itself.
In such a scenario an application would be able to be distributed across a number of identical Java execution nodes acting as application processors. The ideal result would be that the complete solution would then scale by the number of nodes executing the application and stability be achieved by the fact that a certain number of execution nodes would always be available to handle requests.
A brilliant example of a large scale system built using a distributed architecture supporting scalability by the number of processing nodes (boxes) is the well known search engine Google.
The architecture of the Google indexing and search engine is built around a distributed model with several nodes executing their specific part of indexing or search tasks. This architecture allows the Google system to scale as the number of pages on the World Wide Web increases without resolving to exotic hardware solutions, instead they will merely add more low cost processing nodes. For a more comprehensive presentation of the Google search engine please refer to "The Anatomy of a Search Engine".
The above approach should be compared to that of previous search engines like AltaVista who was used as show cases for hardware vendors showing the power of their most prestigious new products.
Many will argue, that examples like Google are hard to use as templates for success in developing general large scale business systems as the software architecture is custom built for the specific solution - an approach that will be extremely expensive in the context of general solutions.
Fair enough, without a reusable foundation for this type of solutions the cost of developing such applications would be excessive.
When developing general business systems today we also rely on a certain foundation of functionality helping developers achieving the business goals of the applications they are developing. For the Java platform this typically involves application servers providing a J2EE execution environment along with other framework components.
To support the distributed architecture model we need to suggest a foundation for enterprise Java applications that provides the support for implementing distributed solutions without incurring an unreasonable overhead on the development efforts.
What would be the characteristics of a framework forming the foundation for distributed applications? To answer this lets take look at other types of (Java) frameworks for inspiration.
A few commonly known distributed frameworks/architectures are:
Jini and JXTA are different yet they are based on a set of core ideas sharing some the same characteristics.
First of all, for nodes in a distributed environment to become aware of each other and the services provided by them a lookup or discovery mechanism is defined. This is fundamental in an environment where we can't rely on a system administrator to configure the relationships between servers, applications, and services.
Next, some mechanism for communicating between to services is defined. For Jini this specifically means that methods on objects implementing a specific service can be invoked using RMI, while JXTA uses a communication mechanism based on messages.
Jini defines other core services like leasing, transactions, and events to support the implementation of distributed services. JXTA on the other hand defines services for establishing pipes between peers.
Both technologies also address issues like security in order to make sure that this apparent anarchistic communication between different processes can happen in a secure way.
JavaSpaces addresses the issue of providing access from distributed applications/services to a shared set of objects (state). This is of course important in the context of general business applications as the most common task for these applications is to modify state based on a given set of business rules.
The above technologies, outlines some of the services - or framework support, if you like - needed in order to provide a common foundation for building a distributed computing platform.
Formulated in the context of jbox this gives us the following high-level description of the distributed jbox platform:
Establishing a collection of jbox nodes is simple. With the sanos kernel and perhaps a small boot loader a new jbox can be established in matter of minutes. When a new jbox is started it should publish its availability for the software distribution mechanism to know about it and thus being able to assign new tasks to it.
The software distribution mechanism itself needs to be able to operate as a distributed application so no single point of failure is associated with this part of the framework. Managing software packages and their assignment should be possible to handle using a simple web based interface.
Binding to services does not need to be very different from what is known from J2EE applications today. Through JNDI applications will be able to bind to services located on other jbox instances.
Handling access to distributed (stateful) objects need some work because of location and performance issues but some initial work has already been done in this area.
The idea is based around a model comparable to J2EE container managed persistence, where the framework controls access to objects as well as persistence. To address performance issue the concept is based on heavy usage of cached objects, which then requires a distributed cache for objects to be consistent across servers. More information on this topic will be available as we get further into the process.
But wait a minute - the above does not sound very minimalistic! Hmmm, the above description of a distributed framework is not simple, and distributed computing rarely is, but hopefully we will be able to demonstrate that there are simple, understandable, and solid ways of constructing the software components that realize the above concept.
One of the core objectives of jbox.dk is to discuss and demonstrate, that simple solutions are often the best way to handle development and architectural challenges.
For articles, presentations and whitepapers on these topics are refer to the documents section of this web site.
Since jbox.dk, the articles, presentations, whitepapers, and especially the software, is purely created in out-of-office hours out of interest of the topic we apologies for the infrequent updates to this site.
Best regards,