The Back-End Developer
While it might seem like all the action in Web 2.0 applications is happening in the glitzy user interface part, the design and development of the back end is just as important. With its focus on sharing knowledge and data among users and systems, Web 2.0 introduces a requirement for reusable business services that provide well-defined interfaces that enable other systems to integrate with them.

An example scenario could be a developer who's working on a human resource application and has developed a piece of code that can fetch the address for a bunch of employees based on some parameter. This code might have been built originally for use in the payroll system. Then in the same company another developer is working on an application that promotes commuting to work. He might want to use the same functionality to get a list of people who are living close to each other and can commute to work together. He might then pick this piece of code and tie it to a set of geo-services he wrote using Google Maps APIs, for example, to display the data on a map component from a Web page.

We see that it is not enough anymore to just be a Java developer interested in writing a piece of logic that performs a specific functionality - you are now expected  to write code that is more granular and be able to expose it to outside consumption through such interfaces as Web services. Other developers might need to be able to tie these pieces of code into a series of other business components, some of them coming from other systems and maybe even other companies, all orchestrated into a single process flow often using standards such as BPEL to control the process flow.

This is where the back-end developer is transformed, no longer just a Java or .NET developer but an SOA developer.

SOA developers require an additional set of features on top of the traditional coding environment that will allow them to easily pick up parts of their code and expose those using standard Web services interfaces, and add a security layer as well. They would then like to get visual process flow designers that allow them to search repositories of services, add them into flows, then package and deploy the finalized process.

Another set of features they need revolve around adaptors for legacy systems and data transformation. These tools usually focus on XML and XSD design and manipulation to help tie and transfer data between various systems.

The Community Developer
This is a new type of developer who is unique to the Web 2.0 experience. This developer is responsible for adding Web 2.0 services to traditional applications. As an example, take an online shopping application and add a discussion forum to it where shoppers can discuss specific products. Another example would be adding tagging capabilities to the product catalog - to facilitate tag-based searching for similar and related products. Both types of services will add a level of loyalty and involvement for the end user with the specific application.

These types of services are usually not written from scratch by the developer. Instead the expectation here is to take an off-the-shelf solution for discussion, wiki, blog, tagging, or other types of Web 2.0 functions and integrate them into the core application. This is a new type of task and a new challenge to developers - one of integrating two different systems not just on the back end but also on the front end.

Developers would like an IDE that offers them easy access to a list of Web 2.0 services and the ease of drag-and-drop to allow them to hook the services into the user interface of their application, while the back-end service shares the same development environment they use for their core application.

Web 2.0 Tooling - Bringing It All Together
As we've seen, there are various developer types and technologies being used to build today's Web 2.0 applications. Successful Web 2.0 applications assimilate those developers and technologies into a complete solution - creating a new generation of composite applications.

Many of the development tools out there focus their features on a specific type of developer and a limited set of technologies. You can find tools that are tailored for the Web designer; others tailored for SOA developers; and yet others aimed at database developers, the Java developer, and other types of developers. Such a separation makes it hard to evolve traditional developers into Web 2.0 developers and increase their area of expertise.

Web 2.0 is not about islands of technologies; it's about the mashup of multiple technologies into a single application. To help developers become Web 2.0 developers, we should start looking for a truly integrated development environment, a tool that will facilitate the transition involved in becoming a Web 2.0 developer.

Is it too much to ask for a single tool that will provide functionality that covers more than one area of expertise? It shouldn't be so hard to find a tool that integrates functionality from various other tools into a single interface, working with a unified project structure, similar end-user gestures and a productive development experience.

Recent tool offering from vendors, such as Oracle and Microsoft, seem to indicate that indeed such a goal can be achieved. For example, Oracle JDeveloper integrates development features that span Java EE, SOA, database, and Web 2.0 services (see Figure 2).

What About the Framework?
Tools can get you just so far. At the end of the day, there are other factors to consider when choosing a development platform for your next Web 2.0 project. One key factor influencing the success of your project will be the framework or frameworks you'll use.

It's a rarity today to see developers constructing their project from scratch; in most cases they'll rely on frameworks to provide them with pre-packaged functionality to cover common infrastructure needs ranging from database access, through Web page flows, and all the way to rich user interface functionality.

The tricky part here is finding a solution that has all the parts working together - after all, your UI framework will need to have good integration with your controller layer and your database access layers. While traditional developers opt to choose a specific framework for each layer, the Web 2.0 way of thinking implies looking at the bigger picture and turning the attention to meta frameworks.

Meta frameworks aim to encapsulate the full range of functionality needed by the application developer into a cohesive solution. These frameworks are usually built on sub frameworks for each of the layers of the application architecture and add a solution for binding the various layers together into a coherent solution. The added value they offer is in plugging the holes between the various layers, enabling the complete flow of interaction from the SOA layer all the way to the user interface.

Examples of such frameworks include Oracle ADF, JBoss Seam, and Microsoft's .NET framework. These frameworks provide everything from AJAX-enabled components through advanced controllers, database interaction layer, and an SOA back-end engine that runs processes.

Choosing the right framework can substantially increase a development team's speed of delivery and save hours of frustration trying to solve integration problems.

Conclusion
Like previous technology innovations, the Web 2.0 generation of applications poses new challenges for application developers. The true Web 2.0 developer will be the one who will become proficient in a wide range of technologies and will adopt a big-picture view of their role. Having the right tools and the right framework at hand can help more developers make the jump to efficient Web 2.0 development.