Lean Versus Agile

Both Lean and Agile software development aim to improve the quality of the software (as perceived by the customer) as well as the productivity of the software development process. They both value (and even welcome) the changes in requirements that will almost certainly occur over the course of the project. They both place the highest value on delivering software that meets the customer’s real needs (not the initial perceived customer needs).

The difference is in the underlying perspective and philosophy…the mindset.

Agile mostly concerns itself with the specific practice of developing software and the project management that surrounds that software development. Agile methods do not generally concern themselves with the surrounding business context in which the software development is taking place.

Lean principles, on the other hand, can be applied to any scope, from the specific practice of developing software to the entire enterprise where software development is just one small part. It is even common in Lean manufacturing to go outside the company and include suppliers in the scope of Lean process improvement. The larger the scope, the larger the potential benefits. Most Lean efforts start out small and expand their scope over time, realizing more and more benefits in the process. In any case, it can be safely said that Lean views all Agile methodologies as valid supporting practices.

The primary focus of Agile software development is on close customer collaboration and the rapid delivery of working software as early as possible. Lean sees that as worthwhile, but its primarily focus is on the elimination of waste in the context of what the customer values.

A key Lean tool for detecting and eliminating waste is the value stream map (VSM). The VSM is a map-like diagram of all activities that take place from beginning to end—for example, from when the customer requests a new feature to when that new feature is delivered to the customer. Each step is then identified as value-added (from the customer’s perspective), non value- added, or non-value-added but necessary.

Finally, Agile has a fair number of formal methodologies, whereas Lean has no formal methodologies. Lean, instead, has a toolkit of recommended practices from which to choose. In fact, when implementing Lean software development, it is quite common to pick a lightweight Agile methodology as a starting point and begin applying other Lean tools (such as VSM) from there.

Lean Software Development

Eliminate Waste

Defects → defects
This one is easy. A defect is a defect, whether you’re talking about manufacturing a physical product or developing software. Defects cause expensive rework, which is always non-valueadded waste. The focus in a Lean environment is on preventing defects, whereas traditional development focuses on finding defects after they have already occurred. Defects are especially expensive when detected late.

In Lean, when a defect is found, the response is to find the root cause of the defect and make changes that will ensure the defect cannot recur. In software development, this means having a suite of automated tests that prevent defects from slipping into the software undetected. When a defect does slip through, a new test is created to detect that defect so that it cannot pass through undetected again.

Overproduction → extra features
Every line of code costs money. Over the lifetime of the software, the cost of writing the code is probably the smallest cost. The code must also be designed, documented, and maintained (changed, enhanced, debugged, etc.). This means that a cadre of current and future team members must repeatedly read and understand the code. The presence of the code must be taken into account in each future product change or enhancement.

The 80/20 rule applies in most software products: 80% of the user’s real needs are provided by 20% of the product’s features. This means the other 80% of a product’s features are rarely (or never) used. At the XP 2002 Conference, the Standish Group reported that 45% of features were never used and that only 20% of features were used often or always. In fact, a 2001 paper titled “Improving Software Investments through Requirements Validation” (IEEE 26th Software Engineering Workshop) found that in 400 projects examined over a period of 15 years, less than 5% of the code was actually useful or used!

Transportation → handoffs
If you have worked on large projects, this might sound familiar:
1. Analysts create a document containing all of the product’s requirements and hand it off to the architects.
2. Architects take the requirements and create the product design, which they hand off to the programmers.
3. The programmers write the code to implement the design and pass the results to the QA testers.
4. The QA testers validate the resulting product against the requirements.

This is a classic Waterfall process that is replete with handoffs. A tremendous amount of knowledge is lost through each handoff simply because it is not possible to record everything that was learned, discovered, created, and known in a written form. A large amount of tacit knowledge is not passed on.

This means that the architects won’t understand the requirements as deeply as the analysts, and that the programmers will not understand the design as well as the architects. This incomplete understanding will lead to errors and omissions, which will require costly rework to correct.

Even worse, the knowledge loss is compounded with each handoff. For example, if you assume that 50% of the knowledge is lost in each handoff, the programmers only receive 25% of the original knowledge, losing a whopping 75% in only two handoffs! Try to avoid handoffs whenever possible.

Inventory → partially completed work
Simply stated, partially completed work is anything that has been started but not finished. This could be requirements (features) that haven’t been coded, or code that hasn’t been tested, documented, and deployed, or bugs that haven’t been fixed. Rather than letting partially done work build up in queues, the Lean approach uses single-piece flow to take a feature through to deployment as rapidly as possible.
A feature is not complete until it is potentially deployable (other constraints may not allow actual deployment as often as we would like), fully documented, tested, and error-free.

(Over) processing → unneeded processes
Unneeded processes are pure waste. They get in the way of productivity without adding any value. They include procedures that accomplish nothing and documents that no one reads. They also include manual tasks that could be automated and procedures that make simple tasks hard.

Build Quality in
One of Taiichi Ohno’s key manufacturing insights was that you cannot inspect a product for quality at the end of a production line. That approach detects problems, but it does nothing to correct them. Instead, each step in the process should be mistake-proof and self-inspecting.

When a problem is detected, the entire assembly line stops until the root cause of the problem is found and corrected (so that it cannot occur again).

A famous example is the New United Motor Manufacturing, Inc. (NUMMI) automobile factory, a joint venture between Toyota and General Motors. Toyota told workers simply to do good work and to stop the line whenever something prevented them from doing their jobs. It took nearly a month to produce the first vehicle, but since each problem was solved once permanently the plant quickly became a leader in quality and productivity in the U.S.

Traditional software development has followed the same pattern as traditional U.S. car manufacturing: let defects slip through and get caught later by QA inspections. The Lean approach is to mistake-proof your code by writing tests as you code the features. These tests prevent subsequent changes to the code from introducing undetected defects.

Create Knowledge
The point here is not to forget the lessons you have learned. Obviously, making the same mistakes over again or relearning how something works is a waste of time and effort. And it’s not just you, your coworkers shouldn’t have to learn something you have already figured out. Find ways to record your team’s knowledge so that you can easily locate it the next time you need it. It’s hard to be specific about this because what makes sense and what will work for you is highly dependent upon the context. However, it is generally best to store a given piece of knowledge closest to its source.

Defer Commitment
The best decisions are made when you have the most information available. If you don’t have to make a particular decision now, wait until later when you have more knowledge and information. But don’t wait too long, either lack of a decision should not hold up other aspects of the project.

Deliver Fast
Software development is an abstract endeavor. Yet most of us (including our customers) work best when dealing with concrete things. When we can see, touch, and feel something, it becomes real, and our brains can more easily think about what works and what doesn’t. Our imaginations can dream of features or capabilities that we didn’t realize we needed.

This is why software requirements are so volatile. The Waterfall approach would have you waiting until the end of the project to get customer feedback based on the actual use of the software, and that is why the Waterfall process is so prone to failure. “Deliver fast” means developing features in small batches that are delivered to the customer quickly, in short iterations. These features can be implemented and delivered before the associated requirements can change. This means that the customer has an opportunity to use these features (which are now concrete) to provide feedback that can change the other requirements before they are implemented.

The completion of each short iteration provides an opportunity to change and reprioritize the requirements based on real feedback and use. The end result is a product that more closely meets the real needs of the customer, while simultaneously eliminating the tremendous amount of waste and rework created by the requirements churn—truly a win-win situation.

Respect People
This is a lofty altruism that is also the down-home truth. As Mary and Tom Poppendieck said in Implementing Lean Software Development, “Engaged, thinking people provide the most sustainable competitive advantage.”

Respect for people means trusting them to know the best way to do their jobs, engaging them to expose flaws in the current process, and encouraging them to find ways to improve their jobs and the surrounding processes. Respect for people means recognizing them for their accomplishments and actively soliciting their advice. Don’t waste your most valuable resource—the minds of your team members!

Optimize the Whole
This is an important part of Lean thinking no matter where Lean is being applied, and Lean software development is no exception. Whenever you optimize a local process, you are almost always doing so at the expense of the whole value stream (this is suboptimizing). If you don’t have control over the entire value stream, you may be forced to suboptimize a piece of it. In general, though, you should always attempt to include as much of the value stream as you can when you try to optimize a process.

The Lean Success Story

It is only recently that the Lean principles have been applied to software development. In the beginning it all started with Lean manufacturing (some 40 to 60 years ago, depending on when you start the clock). Of course, it wasn’t called Lean back then. It was the Toyota Production System, or Just-In-Time manufacturing. James Womack, Daniel Jones, and Daniel Roos coined the term “Lean” in their 1990 book, The Machine That Changed the World (Harper Perennial).

Lean is a mindset, a way of thinking about how to deliver value to the customer more quickly by finding and eliminating waste (the impediments to quality and productivity). This philosophy is expressed in a set of principles that have proven remarkably applicable to a wide range of business activities. The Lean principles have been used successfully in areas as diverse as the supply chain, the office, engineering, and (of course) software development.

A Whirlwind History of Lean

To really appreciate the emergence of Lean production and its derivatives, you have to
understand what it was replacing (or competing with): mass production.

Henry Ford popularized mass production (which had itself replaced craft production) with the
assembly-line manufacture of the Model T in 1913. Mass production is used to produce large
quantities of goods at a low unit cost. It divides the manufacturing process into small steps that can be carried out by unskilled workers, and it relies on the use of high-precision machinery and standardized, interchangeable parts.

The drawback of mass production is its inflexibility. Since a mass production assembly line is
so expensive to set up (and difficult to alter), it is only economical if it is going to produce large
quantities of the same thing.

In 1945, in post-war Japan, the president of Toyota Motor Company, Kiichiro Toyoda, said
that the Japanese automobile industry would not survive if it did not “catch up with America
in three years.” This did not happen within three years (the Japanese automobile industry
survived anyway), but it did lead to the creation of the Toyota Production System by Taiichi
Ohno.

Taiichi Ohno realized that the American mass production system would not work in Japan.
The domestic automobile market was too small and there was a significant demand for variety

in automobiles, from small economical cars to larger, luxury cars—a poor fit for mass
production. Out of necessity, Taiichi Ohno experimented with many ideas and techniques that
eventually evolved into the Toyota Production System.

Taiichi Ohno described the Toyota Production System as “a system for the absolute elimination of waste.” He wasn’t kidding. By the early 1990s, Toyota was 60% more productive with 50% fewer defects than its non-Lean competitors. According to Ohno, this striking advantage rested on two pillars: Just-In-Time and autonomation.

Just-In-Time
In the 1950s, a Japanese delegation from Toyota visited American businesses to study their
methods. They visited Ford Motor Company, the industry leader, but they were not impressed.

They were particularly appalled by the large amounts of inventory and the unevenness of the
amount of work performed in different parts of the factory.

However, when they visited an American supermarket, they were impressed with the way in
which products were reordered and restocked only after customers purchased them. This pull system inspired Taiichi Ohno to create Just-In-Time, which strives to keep inventories at each manufacturing step as low as possible (preferably zero). It is about providing the right material, in the right amount, at the right time, and in the right place.

According to Ohno, inventory is waste that costs the company money. Even worse, inventory
hides problems in the production system. This includes problems such as inadequate capacity,
inflexible equipment, and unreliable equipment. A major contribution of a Just-In-Time
system is that it exposes the causes of inventory-keeping so that they can be addressed.

Autonomation (Jidoka)
Autonomation is a combination of the words autonomous and automation. It describes
machines that automate a process but are also intelligent enough to know when something is
wrong and stop immediately. This kind of machine can run unattended (autonomously) while
providing workers with full confidence that it is operating flawlessly. It doesn’t have to be
monitored, and it needs human attention only when it stops.

When it detects an abnormal condition, the machine will stop itself and a worker will halt the
production line. This focuses everyone’s attention on finding the root cause of the problem
and fixing it so that it will not recur. In this way, autonomation prevents the production of
defective components that would otherwise disrupt the production line or result in more costly rework at a later stage.

Waste (Muda)
The overarching goal of Lean production (or any form of Lean) is to deliver value to the
customer more quickly, and the primary way to do this is to find and eliminate waste. On the
surface this may seem like a simple thing, but exactly what is and what is not waste isn’t always obvious. Shigeo Shingo, who codeveloped the Toyota Production System with Taiichi Ohno, identified seven kinds of waste

DOTWIMP: THE SEVEN DEADLY WASTES
Lean has some pretty strict views on waste. Shigeo Shingo identified seven types of waste that are easily remembered by using the acronym DOTWIMP:

Defects
This is perhaps the most obvious type of waste. Lean focuses on preventing defects instead of
the traditional “find and fix” mentality.

Overproduction
Producing more than is needed, or producing it before it is needed. It is often visible as the
storage of materials.

Transportation
The unnecessary movement of parts between processes. When you move material and parts
between factories, work cells, desks, or machines, no value is created.

Waiting
People or parts waiting for the next production step.

Inventory
All material, work-in-progress, and finished products that are not being processed. Inventory
beyond the bare minimum consumes productive floor space and delays the identification of
problems (if you’ve got plenty of spares, there’s no incentive to fix quality-related problems).

Motion
People or equipment moving or walking more than is needed to perform the processing.

Processing
Overprocessing beyond the standard required by the customer. This adds additional cost
without adding additional value.

Additional eighth waste: underutilization of people
This is often cited as an additional type of waste beyond the original seven, and it refers to the
underutilization of the worker’s creativity and resourcefulness.

A key Lean activity is to break down a process into a map of its individual steps and identify
which steps add value and which steps do not—the waste. This is known as a value stream
map. The goal, then, is to eliminate the waste (muda) and improve the value-added steps
(kaizen). The waste is further subdivided into two categories: non-value-added but necessary
(given the current state of the system), and pure waste. Pure waste is easy to deal with—it can be eliminated immediately.

So, there are two key Lean skills: knowing what the customer values, and knowing how to
spot waste.

Lean Principles

Taiichi Ohno started with Just-In-Time and autonomation, the two pillars of the Toyota
Production System. Modern-day Lean has settled on five principles and a wide array of
practices that have been distilled from the Toyota Production System and the experiences of
other companies that have followed Toyota’s lead. These five principles are identified as Value, Value Stream, Flow, Pull, and Perfection:

Value
Value is defined by the customer. What does the customer value in the product? You have
to understand what is and what is not value in the eye of the customer in order to map
the value stream.

Value stream
Once you know what the customer values in your product, you can create a value stream
map that identifies the series of steps required to produce the product. Each step is

categorized as either value-added, non-value-added but necessary, or non-value-added
waste.

Flow
The production process must be designed to flow continuously. If the value chain stops
moving forward (for any reason), waste is occurring.

Pull
Let customer orders pull product (value). This pull cascades back through the value stream
and ensures that nothing is made before it is needed, thus eliminating most in-process
inventory.

Perfection
Strive for perfection by continually identifying and removing waste.

New Features and Enhancements in Spring 3.0

If you have been using the Spring Framework for some time, you will be aware that Spring has undergone two major revisions: Spring 2.0, released in October 2006, and Spring 2.5, released in November 2007. It is now time for a third overhaul resulting in Spring 3.0.

Java 5

The entire framework code has been revised to take advantage of Java 5 features like generics, varargs and other language improvements. SpringSource done best to still keep the code backwards compatible. and now have consistent use of generic Collections and Maps, consistent use of generic FactoryBeans, and also consistent resolution of bridge methods in the Spring AOP API. Generic ApplicationListeners automatically receive specific event types only. All callback interfaces such as TransactionCallback and HibernateCallback declare a generic result value now. Overall, the Spring core codebase is now freshly revised and optimized for Java 5.

Spring's TaskExecutor abstraction has been updated for close integration with Java 5's java.util.concurrent facilities. Spring provide first-class support for Callables and Futures now, as well as ExecutorService adapters, ThreadFactory integration, etc. This has been aligned with JSR-236 (Concurrency Utilities for Java EE 6) as far as possible. Furthermore, Spring provide support for asynchronous method invocations through the use of the new @Async annotation (or EJB 3.1's @Asynchronous annotation).

Overview of new features

This is a list of new features for Spring 3.0. We will cover these features in more detail later in this section.

• Spring Expression Language
• IoC enhancements/Java based bean metadata
• General-purpose type conversion system and field formatting system
• Object to XML mapping functionality (OXM) moved from Spring Web Services project
• Comprehensive REST support
• @MVC additions
• Declarative model validation
• Early support for Java EE 6
• Embedded database support

Core APIs updated for Java 5

BeanFactory interface returns typed bean instances as far as possible:

• T getBean(Class requiredType)
• T getBean(String name, Class requiredType)
• Map getBeansOfType(Class type)

Spring's TaskExecutor interface now extends java.util.concurrent.Executor:
• extended AsyncTaskExecutor supports standard Callables with Futures

New Java 5 based converter API and SPI:

• stateless ConversionService and Converters
• superseding standard JDK PropertyEditors
Typed ApplicationListener

Spring Expression Language

Spring introduces an expression language which is similar to Unified EL in its syntax but offers significantly more features. The expression language can be used when defining XML and Annotation based bean definitions and also serves as the foundation for expression language support across the Spring portfolio.

The Spring Expression Language was created to provide the Spring community a single, well supported expression language that can be used across all the products in the Spring portfolio. Its language features are driven by the requirements of the projects in the Spring portfolio, including tooling requirements for code completion support within the Eclipse based SpringSource Tool Suite. The following is an example of how the Expression Language can be used to configure some properties of a database setup

This functionality is also available if you prefer to configure your components using annotations:

The Inversion of Control (IoC) container

Some core features from the JavaConfig project have been added to the Spring Framework now. This means that the following annotations are now directly supported:

• @Configuration

• @Bean
• @DependsOn
• @Primary
• @Lazy
• @Import
• @ImportResource
• @Value

Here is an example of a Java class providing basic configuration using the new JavaConfig features:

To get this to work you need to add the following component scanning entry in your minimal application context XML file.

Or you can bootstrap a @Configuration class directly using AnnotationConfigApplicationContext:

Defining bean metadata within components
@Bean annotated methods are also supported inside Spring components. They contribute a factory bean definition to the container.

General purpose type conversion system and field formatting system
A general purpose type conversion system has been introduced. The system is currently used by SpEL for type conversion, and may also be used by a Spring Container and DataBinder when binding bean property values.
In addition, a formatter SPI has been introduced for formatting field values.

This SPI provides a simpler and more robust alternative to JavaBean PropertyEditors for use in client environments such as Spring MVC.

The Data Tier

Object to XML mapping functionality (OXM) from the Spring Web Services project has been moved to the core Spring Framework now. The functionality is found in the org.springframework.oxm package

The Web Tier

The most exciting new feature for the Web Tier is the support for building RESTful web services and web applications. There are also some new annotations that can be used in any web application. Comprehensive REST support Server-side support for building RESTful applications has been provided as an extension of the existing annotation driven MVC web framework.

Client-side support is provided by the RestTemplate class in the spirit of other template classes such as JdbcTemplate and JmsTemplate. Both server and client side REST functionality make use of HttpConverters to facilitate the conversion between objects and their representation in HTTP requests and responses.

The MarshallingHttpMessageConverter uses the Object to XML mapping functionality mentioned earlier.

@MVC additions
A mvc namespace has been introduced that greatly simplifies Spring MVC configuration. Additional annotations such as @CookieValue and @RequestHeaders have been added.

Declarative model validation
Several validation enhancements, including JSR 303 support that uses Hibernate Validator as the default provider.

Early support for Java EE 6
Spring provide support for asynchronous method invocations through the use of the new @Async annotation (or EJB 3.1's @Asynchronous annotation).
JSR 303, JSF 2.0, JPA 2.0, etc

Support for embedded databases
Convenient support for embedded Java database engines, including HSQL, H2, and Derby, is now provided.

What's New in Java EE 6

Java EE 6 just got released yesterday, here is everything you need to know about, in brief.

A look back: Java EE 5 was a remarkable step towards a mature, widely deployed, well supported server-side development platform. EJB 3.0 was re-engineered to ease, the Entity Bean model was stripped and replaced by JPA as the persistence paradigm, JSF was introduced as the standard presentation tier framework and JAX-WS 2.0 replaced JAX-RPC as the SOAP web services API. The focus of Java EE 5 was squarely on reducing complexity by embracing the concepts of annotations, POJO programming, zero-configuration systems.

Overview

Java EE 6 is next big step in the journey towards the idea of a “simple, streamlined and well-integrated platform”. Java EE 6 includes a rich paradigm of innovations best reflected in the technologies that comprise the platform including brand new APIs like WebBeans 1.0 and JAX-RS 1.1, JPA 2.0 or even mature APIs like Servlet 3.0, EJB 3.1

JSR 316: JavaTM Platform, Enterprise Edition 6 (Java EE 6) Specification.

Let’s give each one of the features a brief look:

Pruning

Pruning the Dead meat: The Java EE platform is gainging weight since it’s initial launch in 1999. The idea now is to cut the dead (least used) stuff off. Java EE 6 begins the essential process of carefully pruning  APIs to make the platform more lightweight and to make room for healthier growth. Few APIs that are chopped off and why:

• JAX-RPC — JAX-RPC was an early attempt at modeling SOAP web services as RPC calls. Web services are now much more robust, feature-rich and popular JAX-WS API effectively supercedes JAX-RPC.
• JAXR – JAXR is for interfacing with UDDI registries. Unfortunately, UDDI is not widely used.
• EJB 2.x Entity Beans CMP — The complex, heavyweight model replaced by the popular, lightweight, POJO based JPA persistence model.
• Java EE Application Deployment — JSR 88 was an attempt at developing deployment tools that work across application servers. Unfortunately, this API has never got popular, and never gained much vendor support.
• Java EE Management – Application server management tools that work in a cross-vendor manner. Like JSR 88, the idea never paved off.

“Pruning” an API essentially means that an application server vendor need not support these technologies, what this doesn’t mean is that you cannot support those APIs, few larger vendors will probably continue supporting them atleast for some time.

What is the biggest  major criticism of Java EE? Its simply too large. The fact is, majority of Java web applications do not utilize/leverage   the full Java EE stack. So why is that stuff still in there?

Profiles are designed to address this issue. Profiles are essentially sub-sets of Java EE APIs geared towards a particular class of applications in mind. For example, the proposed Java EE Web Profile will only include APIs that are likely to be used in most Java web applications. The idea isn’t new,  Java ME supports the idea of Profiles already.

Although Java EE 6 defines the rules for creating new Profiles through separate JSRs, only one Profile, the Web Profile is included in platform this time. Detailed chart of Profiles can be found at Sun’s documentation.

Web Beans 1.0:

WebBeans is perhaps the most groundbreaking API developed in the Java EE 6 time-frame. WebBeans fills a number of gaps in Java EE. Although WebBeans is inspired by Seam, Google Guice as well as Spring, it does not directly mirror any of them. Indeed, WebBeans adds a number of unique innovations of its own. Here’s brief on it:

• WebBeans unifies the JSF, JPA and EJB 3 programming models to truly feel like a single, well-integrated platform.
• WebBeans implicitly manages the life-cycle of all registered components in appropriate contexts.
• WebBeans brings a robust set of dependency injection features to the platform in a completely type-safe and Java-centric way.
• WebBeans enhances the Java EE Interceptor model by adding the ability to bind interceptors to annotations instead of having to bind interceptors to target object classes themselves.

WebBeans adds a lot of other very cool features that pave way to nextgen web applications.

Read More: Detailed Spec for Web Beans

JSF 2.0:

JSF appears to be holding ground in the Web UI layer. However, there are a number of valid concerns around the usability and robustness of JSF. JSF 2.0 meets these concerns, and adds all new graded stuff:

• JSF formally adds Facelets as a view technology, simplified page authoring. Facelets are usually written with XHTML markup language. This allows Facelets pages to be portable across diverse development platforms.
• JSF 2.0 brings Java EE 5 style annotation-driven configuration to the table via annotations such as @ManagedBean and @ManagedProperty. (reduction of faces-config.xml file).
• JSF 2.0 changes the JSF life-cycle to account for AJAX with concept of partial page processing to handle AJAX events.
• Built-in capability to handle resources such as images, JavaScript files, CSS and the like, capability to refer to resources via logical names, grouping resources into libraries and versioning.
• Templating: You can create a page that acts as a template for other pages in an application.
• Composite Components: a new feature in JSF that makes it easy to create customized JSF components. You can create composite components by using JSF page markup, other JSF UI components, or both
• Support for Events

Read More: JSF 2.0 Detailed Spec

EJB 3.1:

EJB 3.0 was relatively well-received by the community due to the ease it introduced. EJB 3.1 targets to continue the trend with groundbreaking new EJB 3.1 features:

• Business interfaces are now optional, even for Session Beans.
• EJB 3.1 adds the concept of Singleton Beans, thread-safe by default. Also, comes declarative concurrency controls for greater flexibility.
• Scheduling:  Cron-style scheduling comes to enterprise apps. This a significant addition to the existing limited-scope timer API.
• Async Session Bean Method calls: Using @Asynchronous annotation, you can even control the asynchronous EJB method via a handle to a java.util.concurrent.Future object.
• EJB Lite: A Web Profile based stripped down version. EJB Lite includes features like transactions and security, it does not include features like messaging, remoting and scheduling.
• Packaging becomes easy,  EJB in WAR files now possible.
• run an embedded EJB 3.1 container in Java SE environments such as JUnit tests
• utilize standardized global JNDI names for EJB

Read More: EJB 3.1 Detailed Spec

JPA 2.0:

Now, JPA has been officially separated from EJB as a distinct API in its own. JPA has been a success. It enjoys great adoption rates and first-class vendor support. JPA 2.0 aims to add to the trend by adding new features:

• JPA 2.0 adds a number of much needed ORM mapping enhancements such as the ability to model collections, maps and lists  via the @ElementCollection annotation and the ability to map unidirectional one-to-many relationships (JPA 1.0 only allowed bidirectional one-to-many relationships)
• EntityManager and Query APIs have been enhanced to support things like retrieving the first result (JPA 1.0 allowed the retrieval of a unique result), specifying the maximum size of query results, getting access to the underlying vendor-specific entity manager/query objects and pessimistic locking.
• JPQL has been enhanced with SQL-like CASE, NULLIF, COALESCE and like capabilities.
• JPA 2.0 adds a Criteria API. (The Criteria API in Hibernate or TopLink is essentially the object-oriented, type-safe, Java-centric equivalent of JPQL statements. This is a boon for use cases such as writing complex dynamic queries and avoiding runtime exceptions thrown while parsing JPQL.)
• JPA2 standardizes second level caching, provides standard JDBC properties, flexibility of specifying timeouts and more.

Read More: JPA 2.0 Detailed Spec

Servlet 3.0:

Servlet 3.0 changes have generated quite a bit of excitement and is likely to be very well-received by the community:

• Servlet 3.0 introduces annotations @WebServlet, @ServletFilter and @WebServletContextListener. (reduces web.xml  cofigs)
• web.xml fragments: The container now  looks for configuration in web.xml fragments anywhere in the web application classpath (such as the WEB-INF/classes directory or jars in the WEB-INF/lib directory) in addition to the web.xml file in WEB-INF directory.
• Programmatically add Servlets, Filters and Listeners through the ServletContext.
• Support for Asynchronous processing

Read More: Servlet 3.0 Detailed Spec

JAX-RS 1.1:

REST is increasingly gaining traction as an alternative web services development paradigm. We know of the advantages from REST vs. SOAP

Much like JAX-WS abstracts away the low-level details of the SOAP protocol, JAX-RS is designed to reduce REST development to POJO programming and annotation based configuration. Here is a high level view of JAX-RS:

• The @Path annotation determines the URL that a JAX-RS resource can be accessed, down to a method in a POJO.
• Annotations like @GET, @POST, @PUT and @DELETE are used to specify the HTTP method that is used to access a resource.
• Input from sources like URL query parameters, parts of the URL, cookie values and HTTP header values are mapped into variables via annotations like @QueryParam, @PathParam, @CookieParam and @HeaderParam respectively.
• The @Produces annotation tells JAX-RS what the content type of returned values are such as text/xml, text/json and the like.
• JAX-RS is integrated with Servlets, WebBeans and EJB.

Overall, JAX-RS has many other powerful features that make REST development a breeze, just like JAX-WS makes SOAP development almost transparent.

Read More: JAX-RS Detailed Spec

What’s More

We have covered the most important ones, Few we didn’t include are Enterprise Web services 1.3, JAX-WS 2.2, JAXB 2.2, XML Messaging and more. You can check them out at the official Java EE 6 Technologies page.

Source:
http://www.taranfx.com/blog/java-ee-6-features-overview

Java EE 6 has arrived!

Today is the official release day for Java EE 6.  It has been almost 10 years since the initial release of J2EE 1.2 which was released on December 17th, 1999.

Here is Java EE 6 Tutorial, Volume I
http://java.sun.com/javaee/6/docs/tutorial/doc/

The Java EE 6 platform includes the following new features:

• Profiles, configurations of the Java EE platform targeted at specific classes of applications. Specifically, the Java EE 6 platform introduces a Web Profile targeted at web applications, as well as a Full Profile that contains all Java EE technologies.
  
• New technologies, including the following:
  
  • Java API for RESTful Web Services (JAX-RS)
    
  • Contexts and Dependency Injection for the Java EE Platform (JSR-299), informally known as Web Beans
    
  • Java Authentication Service Provider Interface for Containers (JASPIC)
    
• New features for Enterprise JavaBeans^TM (EJB^TM) components
  
• New features for servlets
  
• New features for JavaServer^TM Faces components
  

Envisioning Next Generation of Web - The Semantic Web

The Semantic Web is an extension to the current Web, and started out as a vision of one of its creators, Tim Berners-Lee. He realized that one of the major shortcomings of the traditional Web is the fact that its information is mostly human-interpretable, not machine-interpretable.

To fully grasp this problem, consider the example of below picture, showing two very simple Web pages, each representing a mouse. You, the reader, will immediately notice that on the left Web page an animal is shown, and on the right page a computer accessory is shown. You do so by interpreting the image and using this knowledge to attach the correct interpretation to the word mouse in the sentence This is a mouse." In other words, the meaning or semantics of the word mouse is provided by you, the human reader, using contextual information (in this case, the accompanying image). For a machine, however, it is impossible to grasp what is on each page. In fact, a machine only detects two pages, each containing an image and a string. It does not know what is represented in the image; it cannot interpret the sentence, nor can it correctly distinguish and interpret the two occurrences of the word mouse." For a computer, the information contained in the page is readable, but not interpretable.

This problem is illustrated by the fact that all major search engines are mainly restricted to syntax-based search queries, as they are not able to grasp the semantics of the information on the Web. Also, for automated agents crawling the Web searching for relevant information, the lack of semantics is problematic. Imagine a shopping agent that searches for the cheapest 17-inch screen available. It will run into all kinds of problems related to the lack of semantics: when is something a (computer) screen, when are monitors also

screens, how different currencies are handled, what about promotions? The automated agent will fail miserably.

To overcome this problem of lack of semantics on the Web, Tim Berners- Lee envisioned the Semantic Web. He defined it as an extension of the current Web in which information is given a well defined meaning, better enabling computers and people to work in cooperation . The Semantic Web is thus considered as an additional layer on top of the current Web. To give information a well-defined meaning, the Semantic Web

relies on the use of ontologies. Intuitively, we can describe an ontology as the terminology used for concepts of a certain domain (e.g. mouse, cat, animal, reptile), and the relations that exist between these concepts (e.g., is a, eats). Our enhanced example page, representing a mouse with an ontology, is (schematically) depicted in this picture:

More formally, the term ontology is defined as a formal, explicit specification of a shared conceptualization of a domain of interest. In other words, ontologies form a formal and explicit representation of concepts and the relations between these concepts that can be distinguished in a particular domain. This explicit and formal specification allows machines to understand and interpret the information captured by an ontology, thus allowing automated processes to use this information (e.g. for reasoning, for crawling the Web, for performing search based on content).