Showing posts with label java. Show all posts
Showing posts with label java. Show all posts

Wednesday, May 13, 2015

Using Java Thread Pools

Here's a quick (and somewhat dirty) solution in Java to process a set of tasks in parallel. It does not require any third party libraries. Users can specify the tasks to be executed by implementing the Task interface. Then, a collection of Task instances can be passed to the TaskFarm.processInParallel method. This method will farm out the tasks to a thread pool and wait for them to finish. When all tasks have finished, it will gather their outputs, put them in another collection, and return it as the final outcome of the method invocation.
This solution also provides some control over the number of threads that will be employed to process the tasks. If a positive value is provided as the max argument, it will use a fixed thread pool with an unbounded queue to ensure that no more than 'max' tasks will be executed in parallel at any time. By specifying a non-positive value for the max argument, the caller can request the TaskFarm to use as many threads as needed.
If any of the Task instances throw an exception, the processInParallel method will also throw an exception.
package edu.ucsb.cs.eager;

import java.util.ArrayList;
import java.util.Collection;
import java.util.List;
import java.util.concurrent.*;

public class TaskFarm<T> {

    /**
     * Process a collection of tasks in parallel. Wait for all tasks to finish, and then
     * return all the results as a collection.
     *
     * @param tasks The collection of tasks to be processed
     * @param max Maximum number of parallel threads to employ (non-positive values
     *            indicate no upper limit on the thread count)
     * @return A collection of results
     * @throws Exception If at least one of the tasks fail to complete normally
     */
    public Collection<T> processInParallel(Collection<Task<T>> tasks, int max) throws Exception {
        ExecutorService exec;
        if (max <= 0) {
            exec = Executors.newCachedThreadPool();
        } else {
            exec = Executors.newFixedThreadPool(max);
        }

        try {
            List<Future<T>> futures = new ArrayList<>();

            // farm it out...
            for (Task t : tasks) {
                final Task task = t;
                Future f = exec.submit(new Callable<T>() {
                    @Override
                    public T call() throws Exception {
                        return task.process();
                    }
                });
                futures.add(f);
            }

            List<T> results = new ArrayList<>();

            // wait for the results
            for (Future f : futures) {
                results.add(f.get());
            }
            return results;
        } finally {
            exec.shutdownNow();
        }
    }

}

Wednesday, May 14, 2014

Java Code Analysis and Optimization with Soot

This is a quick shout out about the project Soot. If you're doing anything even remotely related to static analysis in Java, Soot is the way to go. It's simple, open source, well documented and extremely powerful. Soot can analyze any Java program (source or bytecode), and provide you with the control flow graph (CFG). Here's an example that shows how to construct the CFG for the main method of a class named MyClass.
SootClass c = Scene.v().loadClassAndSupport("MyClass");
c.setApplicationClass();
SootMethod m = c.getMethodByName("main");
Body b = m.retrieveActiveBody();
UnitGraph g = new BriefUnitGraph(b);
Once you get your hands on the CFG, you can walk it, search it and do anything else you would normally do with a graph data structure. 
Soot converts Java code into one of four intermediate representations (Jimple, Baf, Shimple and Grimp). These representations are designed to make it easier to analyze programs written in Java. For example, Jimple maps Java code from its typical stack-based model to a three-registers-based model. You can also make modifications/optimizations to the code and try out new ideas for compiler and runtime optimizations. Alternatively you can "tag" instructions with metadata which can be helpful in building new development tools with powerful code visualization capabilities.
Soot also provides a set of APIs for performing data flow analysis. These APIs can help you to code anything from live variable analysis to very busy expression analysis and more. And finally, Soot can also be invoked from the command-line without having to write any extension code.
So if you have any cool new ideas related to program analysis or optimization, grab the latest version of Soot. Whatever it is that you're trying to do, I'm sure Soot can help you implement it.

Sunday, July 22, 2012

Handling I/O in Java

Handling input/output or I/O is one of the most common situations that programmers have to deal with. If you are writing a real world application, then you have to write a considerable amount of code to handle I/O regardless of the programming language or platform you’re going to use. Interestingly I/O plays a major role even in some of the simplest programs we can write. Even to write a standard ‘Hello World’ program in a language like Java or C, you need to know how to output characters to a console.
However, most developers often tend to ignore the importance and significance of I/O when writing code. Developers generally have an API level understanding of how to perform I/O operations using their main stream programming language. But they do not possess an in-depth understanding of how I/O works in the underlying system or how it can affect the performance and stability of the programs they write. Java developers in particular believe that knowing how to use the standard I/O API of Java is sufficient to write applications of good quality. Their lack of understanding on limitations and performance bottlenecks of the standard I/O API is astonishing. Most Java developers don’t have a firm grip on I/O coding best practices, third party I/O libraries available or relatively new concepts like NIO.
Last week I gave a talk at JAVA Colombo, the Sri Lankan JUG, trying to address some of the above issues. I started by giving a brief overview on I/O and I/O APIs in Java. I also introduced the NIO API and gave a short live demonstration of it comparing its performance to the standard I/O API of Java. Finally I discussed some of the best practices, patterns and anti-patterns related to writing I/O related code in Java. Full slide deck is now available on-line. Feel free to go through it send in your feedback.

Wednesday, March 7, 2012

Introducing JAVA Colombo: The Sri Lankan Java User Group

Sri Lanka is home to a large number of Java developers. Hundreds of Sri Lankan programmers are involved in writing Java code for various open source and proprietary projects. Unfortunately though, we haven’t had the notion of a strong Java developer community in Sri Lanka up until now. However starting from next week that’s about to change. We are starting JAVA Colombo, a Java User Group (JUG) for all Java developers in Sri Lanka. JAVA Colombo will serve as a regular meeting place as well as a knowledge sharing hub for any Java programmer interested in taking part. We intend to have regular meetups and other educational events in and around Colombo to help developers learn and connect.
Our first official meetup will be held on 15th of March 2012 at 6pm at WSO2 premises. This will be a great opportunity for Sri Lankan Java developers to meet each other and have a taste of the JUG experience. To make the meetup even more interesting we are also planning to have an expert panel discussion on the topic “Secure Coding with Java”.
If you are a Java programmer or a Java enthusiast and you wish to become a part of this effort, please sign up today at meetup.com.

Thursday, November 11, 2010

ASF Says "It's On"

As most of you know there's an ensuing battle between the Apache Software Foundation (ASF) and Oracle over Java and Apache Harmony. The roots of this conflict go all the way back to the time when Java was mainly driven by Sun Microsystems. However with ASF getting re-elected as a ratified JCP executive committee member, things are starting to take an interesting turn. A couple of days back ASF made a bold statement indicating that they are going to vote down the upcoming Java SE 7, which Oracle is pushing forward so hard. ASF is also urging other JCP members to back ASF on this. ASF has indicated that they are not afraid to terminate their ties with JCP if needed. This is pretty huge for a group that maintains an overwhelming number of world class Java projects including Tomcat, Maven, Geronimo, Ant and Derby. (I also happen to be a committer for a couple of Java projects at ASF)
There are currently so many news articles on the web covering this conflict end-to-end. I found the news report from The Register to be quite interesting and amusing at the same time. Here's a little excerpt:
Oracle was forced to eat crow and congratulate ASF for its near unanimous election back onto the JCP's SE and EE executive committee. It was an election that saw its own nominee - the little-known-outside-Oracle-circles Hologic - soundly rejected by JCP members.
Congratulating ASF, Oracle's spokesperson on Java SE, Henrik Ståhl, claimed Oracle still respected ASF and wanted to work with the group. "Our disagreement around TCK licensing does in no way lower our respect for and desire to continue to work with Apache," Ståhl said here.
On Tuesday, the ASF told Ståhl and Oracle just exactly where they could shove their "respect" with a statement saying it is walking out of the JCP unless Harmony gets a license.
Another interesting news report is available on IT World.

Thursday, November 4, 2010

Taming the Java Garbage Collector

Tuning the garbage collection in JVM is one of those things that developers often tend to ignore and overlook. But if done properly, it can save you hundreds of megabytes worth precious memory, without making a significant impact on the application performance. Also GC tuning becomes an absolute necessity in certain applications due to various QoS requirements such as real-time processing, low response time and high throughput. So today I'm going to discuss a little bit about GC in JVM and how to properly tune up GC for best application performance. My discussion is entirely focused on Java 5 and 6, so if you are using an older JVM you are at the wrong place.
Before we jump into the discussion on GC tuning we need to have a basic understanding on the various concepts associated with GC. So here goes...
What is garbage collection?
Garbage collection is the process of finding objects which are no longer reachable from references in the executing code, and reclaiming the memory occupied by such objects. An object which is reachable by at least one reference in the executing code is considered to be 'live'. Objects which cannot be reached by any references are called 'dead' objects. So the process of garbage collection can be also defined as the process of finding dead objects in the memory and reclaiming the memory used by them. In general, a garbage collector is responsible for 3 tasks:
  1. Allocating memory for new objects
  2. Ensuring that any referenced objects (live objects) remain in memory
  3. Recovering memory used by objects that are no longer reachable (dead objects)
The following characteristics govern the notion of a 'good' garbage collector:
  • Safe (never reclaims a live object)
  • Comprehensive (a dead object does not remain unclaimed for more than a small number of collection cycles)
  • Efficient (does not introduce too long pauses)
  • Defragmentation (does not leave the memory fragments all over the place)
  • Scalable (allocation and deallocation scales well in multithreaded systems)
It is not possible and necessary for a garbage collector to display all these desirable characteristics at once. Usually each garbage collector has its own strengths and weaknesses.
GC Classification
Garbage collectors can be classified based on a number of factors.
Serial vs Parallel:
In serial collection only one collection occurs at a time (even with multiple CPU cores). In parallel collection, the task of collection is divided into subtasks and executed in parallel, possibly on multiple CPUs. This speeds up collection but is more complex and leads to potential fragmentation.
Stop-the-world vs Concurrent:
Stop-the-world collectors suspend the entire application during collections. Concurrent collectors run concurrently with the application (there could be occasional stop-the-world collections). With concurrent collection, freeze times are shorter but it has to operate on the objects which are being used by the running application. This adds more overhead on the collector and requires more CPU power and heap.
Compacting vs Non-compacting vs Copying:
Compacting collectors arrange all the live objects together in contiguous memory blocks. Then the remaining space can be considered free. This way the collection is slow but the allocations are faster. Non-compacting collectors free dead objects in-place. This leads to faster collections but also a recipe for fragmentation. Copying collectors copy (in contrast to moving) all the live objects to a different area in the memory. Then the source area can be considered free. This leads to slower and expensive collections but provides better allocation performance.
Generational Collection
Modern garbage collectors follow a scheme known as 'generational collection'. With this approach, the heap memory is allocated to two or more regions known as generations. A generation is a block of memory which contains objects of a certain age. In many implementations there are two generations, one for young (new and reasonably new) objects and one for old objects. Young generation is usually much smaller compared to the old generation. Generational collection allows employing different GC algorithms in different generations. This enables selecting a suitable algorithm based on the maturity of the objects.
Generational collection makes use of an interesting characteristic of applications, often referred to as the "generational hypothesis". This hypothesis states:
  • Most allocated objects are not referenced for long (they die young - sometimes also stated as infant mortality)
  • Few references from older objects to younger objects exist
Based on this hypothesis, modern garbage collectors run collections on the young generation frequently. This is fast and efficient because the young generation is small and likely to contain many dead objects. Objects that survive some number of young generation collections are moved (tenured) to the old generation. Because old generation is much larger, its occupancy grows very slowly. Therefore old generation collections are infrequent. But when they do occur, they tend to take a much longer time to complete.
In new HotSpot JVMs, the garbage collector divides the heap into 3 generations:
  • Young generation - contains newly allocated objects
  • Old generation - objects that has survived some number of young gen collections and some very large objects that were directly allocated in old gen
  • Permanent generation (perm gen) - contains classes, methods and associated descriptors which are managed by the JVM
The young generation is further divided into 3 regions. The larger division is known as the Eden. This is where almost all the new object allocations take place (under special circumstances, large objects may get allocated in the old generation). The other smaller spaces are known as survivor spaces. One of the survivor spaces are always kept empty until the next young generation collection.
When an old generation fills up a full collection (major collection) is performed. All generations are collected during a full collection. First the young generation is collected using the young generation collection algorithm. Then the old generation collection algorithm is run on the old generation and permanent generation. If compaction occurs, each generation is compacted separately. During a full collection if the old generation is too full to accept tenured objects from the young generation, the old generation collection algorithm is run on the entire heap (except with CMS collector).
Available Garbage Collectors
HotSpot JVM contains 3 garbage collectors:
  1. Serial collector
  2. Parallel collector
  3. Concurrent mark-sweep collector
In addition to that there is a special enhanced version of the parallel collector known as the parallel compacting collector. Let's see how each of these collectors work.
Serial Collector (Mark-Sweep-Compact collector)
This is the collector used by default on Java HotSpot client JVM. It is a serial, stop-the-world, copying collector. Because it is serial and operates in the stop-the-world mode it is not a very efficient collector.
Young generation collection:
  • Live objects in Eden are copied to the empty survivor space (objects that won't fit are directly copied to the old generation)
  • Live objects in the occupied survivor space are copied to the empty survivor space (relatively old objects are copied to old generation)
  • If the free survivor space becomes full during the process, remaining live objects in Eden and occupied survivor space are tenured
  • At this point Eden and the occupied survivor space contains only dead objects and so can be considered empty - The previously free survivor space contains some live objects
  • The two survivor spaces switch roles
Old/Permanent generation collection:
  • A two phase Mark-and-sweep algorithm is used to clean up dead objects
  • After that a sliding compaction (live objects are slided towards the beginning of the generation) is performed to compact the generations
Parallel Collector (Throughput Collector)
This is very similar to the serial collector in many ways. In fact the only notable difference is that parallel collector uses multiple threads to perform the young generation collection. Other than that it uses the same algorithms as the serial collector. The number of threads used for collection is equal to the number of CPUs available. Because of the parallel collection feature, this collector usually results in much shorter pauses and higher application throughput. However note that the old generation collection is still carried out using a single thread in serial fashion. This is the default collector used in Java HotSpot server JVM.
Parallel Compacting Collector
This is an enhanced version of the parallel collector. It uses multiple threads to perform the old generation collection as well. The old generation collection divides the generations into regions and operate on individual regions in parallel. The algorithm used for old generation collection is also slightly different from what's used in serial and parallel collectors.
Concurrent Mark-Sweep Collector (CMS Collector)
While the parallel collectors give prominence to application throughput, this collector gives prominence to low response time. It uses the same young generation collection algorithm as the parallel collectors. But the old generation collection is performed concurrently with the application instead of going to stop-the-world mode (at least most of the time). A collection cycle starts with a short pause known as the initial mark. This identifies the initial set of live objects directly reachable from the application code. Then during the concurrent marking phase, collector marks all live objects transitively reachable from the initially marked set. Because this happens concurrently with the application not all live objects get marked up. To handle this, the application stops again for a second pause for the remark phase. Remark phase is often run using multiple threads for efficiency. After this marking process a concurrent sweep phase is initiated.
CMS collector is not a compacting collector. Therefore it uses a set of free-lists when it comes to allocation. Therefore the allocation overhead is higher. Also CMS collector is best suited for large heaps. Because collection happens concurrently, the old generation will continue to grow even during collection. So the heap should be large enough to accommodate that growth. Another issue with CMS is floating garbage. That is objects considered as live may become garbage towards the end of the collection cycle. These will not get immediately cleaned up but will definitely get cleaned up during the next collection cycle. CMS collector requires lot of CPU power as well.
Unlike other collectors, CMS collector does not wait till the old generation becomes full to start a collection. Instead it starts collecting early so it can avoid old generation getting filled up to the capacity. If the old generation gets filled up before CMS kicks in, it resorts to the serial stop-the-world collection mode used by serial and parallel collectors. To avoid this CMS uses some statistics regarding previous collection times and the time taken to fill up the old generation. CMS also kicks in if the old generation occupancy exceeds a predefined threshold known as the initiating occupancy fraction. This is a configurable parameter and defaults to 68%.
There is a special mode of operation for the CMS collector known as the incremental mode. In the incremental mode, concurrent collection cycles are broken down into smaller chunks. Therefore during a concurrent collection cycle, the collector will suspend itself to give full CPU to the running application. This in turns reduces the impact of long concurrent collection phases. This mode is particularly useful in cases where the number of CPUs is small.
Selecting the Appropriate Collector
Most of the time JVM is smart enough to select the right collector for the situation by analyzing the system configuration (see the next section). But since the JVM has no knowledge of the application requirements, sometimes the JVM chosen collector will not be good enough. When it comes to manually selecting a collector for an application, there are no hard and fast rules that say a particular collector is suitable for a given scenario. So there are only a set of general guidelines and recommendations. Most of the time they will work, but there could be exceptions. Hope you find them useful:
  • Serial collector is the collector of choice for most applications that run on client-style machines and do not have low pause requirements. On modern hardware this collector can handle a wide range of applications with heaps as small as 64MB.
  • If the application has a small data set select the serial collector.
  • If the application has no low pause requirements and runs on a machine with a single CPU select the serial collector.
  • Parallel collector is best for applications that run on machines with multiple CPUs and do not have low pause requirements.
  • If application throughput is the main consideration and slightly longer pauses are acceptable select the parallel collector.
  • The parallel compacting collector can be used in almost any scenario where the parallel collector seems suitable. In fact the parallel compacting collector is almost always preferred over the parallel collector. However with this collector a single application can hog the CPU for an extended period of time. Therefore it's not very suitable in cases where multiple JVMs reside on a single large machine.
  • CMS collector should be the collector of choice whenever there is a requirement for low pauses and low response time. However this collector makes use of lot of CPU resources. Therefore impact on CPU usage must be carefully evaluated. Usually applications that have large sets of long-lived data (a large old generation), which run on machines with multiple CPUs, tend to benefit from this collector. Web servers and most interactive applications often fall into the category of CMS benefactors.
  • If it is needed to run an application with low pause requirements on a machine which doesn't have too many CPU resources, consider using the CMS incremental mode.
Note: Command line options needed to enable different collectors are given at the end of the post
Ergonomics
Modern JVMs has the ability to select a suitable garbage collector, heap size and JVM type by looking at the host platform and the OS. In addition to that, a new way of dynamically tuning memory management has been introduced to the parallel collectors. This way, a user can specify the desired behavior and the collector dynamically tunes the sizes of the heap regions in an attempt to achieve the requested behavior. The combination of platform-dependent default selections and dynamic GC tuning is referred to as ergonomics.
The ergonomics default selections are done based on the 'class' of the machine. A machine is considered to be server-class if it has:
  • 2 or more processors
  • 2 GB or more physical memory
This applies to all platforms except for 32-bit machines running Windows.
If the machine is classified as non server-class, ergonomics will choose the following settings:
  • HotSpot client JVM
  • serial collector
  • initial heap size of 4 MB
  • maximum heap size of 64 MB
For server-class machines it is slightly complicated. However in general it is something like:
  • HotSpot server JVM
  • parallel collector
  • initial heap size of 1/64 th of physical memory
  • maximum heap size of 1/4 th of physical memory under an upper limit of 1 GB
One can run the HotSpot client JVM on a server-class machine by explicitly enabling the -client command line option. In that case ergonomics will select the serial collector. Also when the collector selected by ergonomics is not the parallel collector the initial heap size and maximum heap size will be 4MB and 64MB respectively.
Sizing the Heap
There are lots of options available when it comes to sizing the heap, its regions and generations. Most of the time we don't have to meddle with these settings, but there could be exceptional situations where we have to tune them up to obtain optimal performance and avoid out of memory errors. The most common settings related to heap size are the initial heap size and maximum heap size which are set by -Xms and -Xmx command line options respectively. If you set a lower value to the initial heap size than the maximum heap size, JVM will try to start with a heap of initial size and then grow the heap as and when required. If you set equal values to both parameters, JVM will start with the specified maximum heap size.
Another important parameter is the NewRatio value which governs the ratio between the old generation size and young generation size. On most server class systems this defaults to 8. That means the old generation is 8 times larger than the young generation. If the application tends to do lot of new allocations then reducing this ratio to a reasonable value may not be a bad idea. Reducing this ratio will generally result in less minor collections. The size of the young generation can be further controlled by the NewSize and MaxNewSize options.
We can get the JVM to dynamically grow or shrink the generations based on how they are utilized by setting the MinHeapFreeRatio and MaxHeapFreeRatio parameters. These parameters try to impose some restrictions on the amount of free heap space in each generation. If the free space percentage in a given generation is about to drop below the MinHeapFreeRatio, JVM will expand the generation to meet the lower limit. Similarly generations will be contracted if the free space percentage crosses the MaxHeapRatio.
Command Line Options
Collector selection
  • Serial collector: -XX:+UseSerialGC
  • Parallel collector: -XX:+UseParallelGC
  • Parallel compacting collector: -XX:+UseParallelOldGC (combine with -XX:+UseParallelGC)
  • CMS collector: -XX:+UseConcMarkSweepGC
Parallel collector settings
  • Parallel GC thread count: -XX:ParallelGCThreads=n
  • Desired maximum pause length: -XX:MaxGCPauseMilis=n
  • Throughput (percentage of CPU time spent on application - defaults to 99): -XX:GCTimeRatio=n
CMS collector settings
  • Enable incremental mode: -XX:+CMSIncrementalMode
  • Parallel GC thread count: -XX:+ParallelGCThreads=n
  • Old gen occupancy threshold that triggers collections: -XX:CMSInitiatingOccupancyFraction=n
Heap sizing options
  • Initial size: -Xms
  • Maximum size: -Xmx
  • Initial size of the new generation: -XX:NewSize=n
  • Maximum size of the perm gen space: -XX:MaxPermSize=n
  • Ratio between old and new generation sizes: -XX:NewRatio=n
Debug options
  • Print basic GC info: -XX:+PrintGC
  • Print verbose GC info: -XX:+PrintGCDetails
  • Print details with time: -XX:+PrintGCTimeStamps
References

Thursday, October 23, 2008

MOINC - The Future Web Services!!!

As Web services continue to become the dominant paradigm in the arena of distributed computing, more and more people around the world are starting to get interested in improving the performance and scalability achievable from Web services deployments. An enterprise grade Web services deployment must be high available and scalable in order for it to be useful to the clients and provide a competitive advantage for the service provider. Due to this reason it has become a must for the Web services middleware providers to support high availability and scalability via general techniques such as clustering.

Me and some of my colleagues recently started a venture to explore the potential of grid computing as a means of improving the availability and scalability of Web services deployments. Our plan is to design and develop a complete open source Java Web services deployment platform which makes use of grid computing as the basis for clustering. This exciting concept is a brain child of one of our lecturers at the Department of Computer Science and Engineering, Dr. Sanjiva Weerawarana, who also happens to be the chairman and CEO of WSO2. This research project focuses on not only improving the scalability of Web services deployments via grid computing but also putting the much wasted electrical energy to good use by getting idling computers to do some useful work.

We have named the project 'MOINC' which stands for Mora Open Infrastructure for Network Computing. (If you are confused what 'Mora' is all about it's a little nick name for the University of Moratuwa. 'Mora' also means shark in Sinhala.) So far we have managed to successfully complete the requirements gathering and design phases of this massive R&D effort. We have identified four components in our target platform and four groups of undergrads are working on implementing the components. The four components are;
  • MOINC Server
  • MOINC Client Agent
  • MOINC Server Manager
  • Thisara Communication Framework
You can learn more about our project and its four main components from our official website. You will also find links to our design documents, proposals, specifications and SVN repositories there. We recently released the 0.1-alpha version of the Thisara messaging framework which is one of the four components of the MOINC platform. You can download the binaries from our website too.

Wednesday, June 11, 2008

WSO2 WSAS 2.3 Released

The WSO2 WSAS team is pleased to announce the release of the WSO2 WSAS 2.3. WSO2 WSAS is an enterprise ready Web services engine powered by Apache Axis2 release under the Apache Software License 2.0.

This release can be downloaded from;
http://wso2.org/projects/wsas/java


From the WSO2 WSAS 2.3 - Release Note - 10th June 2008

WSO2 WSAS is an enterprise ready Web services engine powered by Apache Axis2 which offers a complete middleware solution. It is a lightweight, high performing platform for Service Oriented Architectures, enabling business logic and applications.

Bringing together a number of Apache Web services projects, WSO2 WSAS provides a secure, transactional and reliable runtime for deploying and managing Web services.


Key Features

* Data services support - Expose you enterprise data as a services in a jiffy
* WSAS IDE - Eclipse IDE integration
* Clustering support for High Availability & High Scalability
* Full support for WS-Security, WS-Trust, WS-Policy and WS-Secure Conversation and XKMS
* EJB service provider support - Expose your EJBs as services
* Axis1 backward compatibility - Deploy Axis1 services on WSAS & Engage advanced WS-* protocols in front of legacy services
* JMX & Web interface based monitoring and management
* WS-* & REST support
* GUI, command line & IDE based tools for Web service development


New Features In This Release

* Improved interoperability
* Improved Data Services support
* Various bug fixes to Apache Axis2, Apache Rampart & WSAS
* WSO2 Mercury Integration - A new WS-RM Implementation


Data Services - Bringing Enterprise Data to Web

* Service enable data locked in relational databases, CSV & Excel files in no time
* Zero code. Simple descriptor file describes the data to service mapping
* Controlled access to your data
* Customizable XML output
* Benefit from REST & WS-* support
* Built-in Connection pooling support
* Supports exposing Stored procedures & functions
* Built-in caching
* Throttling - to ensure your database is never overloaded.
* Easy configuration via graphical console
* Test your services via Try-it tool


Training

WSO2 Inc. offers a variety of professional Training Programs, including

training on general Web services as well as WSO2 WSAS, Apache Axis2, Data Services and a number of other products.

For additional support information please refer to
http://wso2.com/training/course-catalog/


Support

WSO2 Inc. offers a variety of development and production support programs, ranging from Web-based support up through normal business hours, to premium 24x7 phone support.

For additional support information please refer to http://wso2.com/support/

For more information on WSO2 WSAS, visit the WSO2 Oxygen Tank (http://wso2.org)