Using Web 2.0 architecture for a more flexible enterprise

Dynamic managed elements

Stephen B. Morris (stephenbjm@yahoo.com), CTO, Omey Communications

Stephen Morris is the CTO of Omey Communications in Ireland. For the past 20 years, Stephen has worked for some of the world's largest networking companies on a wide range of software projects, including J2EE/J2SE-based network management systems, billing applications, porting and developing SNMP entities, network device technologies, and GSM mobile networking applications. He is the author of Network Management, MIBs and MPLS: Principles, Design and Implementation (Prentice Hall PTR, 2003), as well as several articles on network management and other topics for InformIT and OnJava.com.

Summary: Web 2.0 repositories can help you create a flexible software architecture, which can easily be plugged into Web 2.0 communities and extranets. Creating a fluid system that also works in accordance with requirements for modifiability, performance, security, scalability, and reusability can be challenging. In this article, learn techniques to help ensure your Enterprise Web 2.0 architecture meets your quality requirements.

Date: 10 Jul 2007
Level: Introductory
Comments:

The drive to automate

Companies need to control costs while at the same time providing more services. As a result, they're driven to automate enterprise operations. IT administration budgets are under pressure, and even this business-critical area is now being outsourced. Service density is increasing, and the level of interconnection between services is also growing.

With increasingly wide geographic dispersion, most organizations are finding they have an unexpected need for Enterprise Web 2.0. This service, or set of services, can make it easier to aggregate key content, provide for collaboration between geographically separate groups, and achieve business-critical aims, such as multiteam design and development efforts, contract bidding, and corporate reorganizations.

In this article, you look at the architectural aspects of Enterprise Web 2.0 deployment and explore a management-centric approach. You will also find out ways to make Web 2.0 architecture more reliable than its predecessors by simplifying the major components. Learn about additional techniques, such as adding manageability and inversion of control, to provide complex and dynamic component relationships, helping both users and system administrators. Web 2.0 users see business services, and Web 2.0 IT administrators see manageable technology elements, giving each group a clear view of the enterprise.

Software architecture quality attributes

Successful enterprise architectures must have a range of quality attributes. It helps to define these attributes up front. The attribute set then forms a blueprint that guides the phases of analysis, design, coding, deployment, maintenance, update, and so on. The architecture lives on as a vision of what the end result should be. Typical quality attributes include (but are not limited to) the following:

Modifiability. Ease with which the underlying software can be modified
Availability. Extent to which the architecture makes possible defined levels of uptime (for example, no more than 5 minutes of downtime per year)
Performance. Architecture's measurable service levels
Security. Architecture's defined security benchmark
Scalability. Extent to which the architecture can grow in both user levels and number of services supplied
Reusability. Ability to incorporate the architecture in part or whole into a new architecture

Architectures aren't abstract entities—you can visualize them in different ways, including the system's physical environment, the module decomposition view, the process view, the client-server view, the code view, and the layered view. Each view shows one or more of the required quality attributes.

An additional quality attribute is manageability: the extent to which an architecture simplifies automated management. The elements of Enterprise Web 2.0 provide a compelling platform for manageability.

Enterprise Web 2.0 elements

Enterprise Web 2.0 promises a range of capabilities not present in Web 1.0. This article discusses key Web 2.0 capabilities, including:

Content aggregation
Community support
Collaborative self-publishing
Asynchronous content update
Rich clients (enhanced browsers)
Loose business process interaction and manipulation

Products that fulfill some or all of these are already available, including IBM® WebSphere® Portal software and Sun Java™ System Portal Server.

You can see these Web 2.0 capabilities in Figure 1.

Figure 1. Enterprise Web 2.0 capabilities in action

The left side of Figure 1 illustrates a community of users. This is a loose collection of users who come together for a short- or long-term effort. Community members can collaborate together using their rich-client tools. These tools let users incorporate multiple streams of data and perform online content editing from a range of intranet (and possibly external) data sources. This client-editing capability requires a new generation of browser technology.

The middle of Figure 1 illustrates much of the software that makes Web 2.0 a reality. Aggregation facilities combine content from Web sites, databases, and other sources. This data is then presented to the rich clients, which combine the supplied content as compound data: data that can include any and all formats, such as audio, video, and so on.

Another important data source (not shown in Figure 1) is semantic search data. This function is included in the aggregation function in Figure 1; its purpose is to present only data that is semantically relevant. Rich clients request such data and render it as part of their compound documents.

Rich-client documents can be saved to a persistent medium as new documents or as part of the data from which they originated. The area of data origination is illustrated at right in Figure 1. It's important to understand that Enterprise Web 2.0 data sources aren't necessarily static databases—data can come from traditional databases; static or dynamic Web pages; and business processes, such as Business Process Execution Language (BPEL) servers.

Portlets can form the basis of Web 2.0 client facilities. This format is particularly useful for asynchronous updates—another feature of the middle part of Figure 1. Asynchronous updates let data changes propagate to the clients in a Web 2.0 environment.

The Enterprise Web 2.0 architecture includes at least three physical or logical layers. Where does manageability fit into this picture?

Manageability as an architectural quality attribute

For an architecture to be manageable, it must be able to provide:

Automation of the operation of key elements
Ease in configuration of key elements
Fault resistance
Ease in measuring performance
Alignment of services with defined metrics
System security

Given that the Enterprise Web 2.0 clients are collaborating, aggregating content, and manipulating complex documents, a robust platform is required. Supporting manageability helps you provide such a platform. Consider what providing manageability means in Figure 1.

The elements at the right in Figure 1 operate in optimal fashion when they're managed: Web/BPEL servers and database engines need to be properly configured, balanced, and monitored for good performance. If you measure performance, then it's easier to know when to upgrade or add new hardware. If service-level agreements exist (for example, no more than 20 minutes of downtime per year), then it's important to continuously collect data on uptime. If any private data is stored in the systems at right in Figure 1, then the more easily you can secure it, the better.

Providing manageability may require multiple additional complex systems. The "how" of manageability isn't as important as "why." It makes sense to try to make management facilities as usable as possible.

In the next section, we look at Web 2.0 elements and the enhancements provided by embracing manageability.

Content and software repositories

In Web 2.0, repositories come in two flavors: content (data) and software facilities. In Figure 1, data repositories are on the right. Software repositories provide a means for storing the tools and middleware that form the Web 2.0 computing infrastructure. Software repositories are optional elements and aren't shown in Figure 1; they provide a means for deploying the Web 2.0 tools.

Web 2.0 communities in the enterprise

The community concept is perhaps the most novel element of Web 2.0. Such communities reflect an organization's ability to help groups of disparate and geographically dispersed users come together for a project, collaborate, produce a deliverable, and then disband. How does manageability affect the community concept?

Community management operations include the creation, addition, and deletion of users; and, at some later date, the deletion of the community. Some important communities, once formed, might never be destroyed (for example, a community like HR-updates-to-staff). A manageable architecture simplifies these management operations.

Fault resistance in a community relates more to the handling of downstream faults (faults in a data source). A possible fault condition could be a community that becomes too large to fulfill its original purpose.

Extranets: an old solution in a new guise

Extranets have traditionally been deployed between partner organizations that need to share resources at a distance. For example, a software supplier may provide code on a contract basis to another organization. One of the partners can set up an extranet so they can share resources such as machines, software, individual expertise, and so on.

In the context of Web 2.0, extranets may be constructed as restricted communities. Such communities require stringent security arrangements; for example, it may be undesirable or even illegal to share certain intranet data with external partners. Such considerations make a strong case for Web 2.0 manageability.

Dumbing down Web 2.0 software components

Earlier, the Manageability section defined providing manageability as a freestanding set of quality attributes. Unfortunately, this rarely happens in system design. In enterprise architecture, management facilities are generally added after the main design and development is complete. The late addition of key elements generally results in solutions that are difficult to manage. It doesn't have to be this way!

Defining manageability requirements up front along with other architectural quality attributes provides an interesting opportunity: Management facilities can be decoupled from other Web 2.0 artifacts. In effect, Web 2.0 software components can be intentionally dumbed down because they don't have to contain compile-time management software.

One open source tool that already uses this technique is the Apache Java 2 Platform, Enterprise Edition (J2EE) reference application server Geronimo. This tool is built in such a way that components can be configured by dependency injection to provide support for required management operations. Geronimo's components are built to accommodate dynamic management requests. This allows for a more flexible management model.

This also demonstrates the power of an architectural approach: The required quality attributes act as a constant reminder to those who build the system. It also allows for an improved separation of concerns in the finished system.

Summary

Organizations constantly strive to reduce IT costs. Outsourcing can take you part of the way, but may make it harder for geographically dispersed groups to get together and deliver on short-term projects. Web 2.0 (or Web 3.0 as Enterprise Web 2.0 is sometimes called) can provide an elegant solution to the needs of highly dispersed organizations.

Software architecture quality attributes provide a powerful statement of what an architecture seeks to achieve. Traditionally, architects have used a wide range of views to try to ensure that the required quality attributes are achieved. Manageability is an architectural quality attribute that receives little attention. Augmenting the architecture of Enterprise Web 2.0 with manageability attributes adds configurability, fault resistance, the ability to measure performance, security enforcement, and more.

You can apply these manageability attributes to the major artifacts that form Enterprise Web 2.0, such as repositories and communities. Providing manageability as a key architectural quality attribute paves the way for easier deployment and operation of Web 2.0.

Perhaps the most unexpected benefit of Enterprise Web 2.0 manageability is the scope it provides for dumbing down constituent software elements. The Apache Geronimo project provides a model for this technique with its support for dependency injection and inversion of control. This approach gives you a more flexible management model than has traditionally been the case. As a result, you'll find that Enterprise Web 2.0 lends itself particularly well to architecture-level manageability.

Resources

Learn