Component-Based Architectures for Internet Systems -- A component-based architecture can help you manage the scale, complexity, and transitions of development projects. ++ Tags: Component-Based Development (CBD), Components, COM+, COM/DCOM, CORBA, Develo

Comment on this topic

The rapid pace of change in Web-based technologies poses difficult questions for the beleaguered CIO. You might ask, "Which technologies should I adopt and when?" If you wait too long for the market to decide on a long-term direction, you may lose customers to more advanced competitors. If you choose too soon, you risk selecting a dead-end technology. In this article, I consider how an effective component-based architecture provides an integration model for addressing these challenges.

Internet architectures
Effective corporate Internet applications separate client from server components. Client components constitute the GUI front end and run in standard browsers such as Netscape Navigator or Internet Explorer on a Web server. Server components run on an application server, provide business functionality to the client, and communicate with back-end databases. The application server supports a standard component model. This lets you assemble components by connecting the services through their interfaces.

Component standards
A standard component model includes definitions for the following:

How each component must make its services available to others.
How to connect one component to another.
Which common utility services can be assumed to be provided by the infrastructure supporting the component model.
How new components announce their availability to others.

In short, by supporting a particular component model, the application server provides a programming approach for developers to use that application server. Three particular component models currently dominate the market: COM+, CORBA, and Java/EJB.

The significance of a component-based approach
For distributed Web-based applications, an attractive architecture would be an n-tiered model that places business functionality in components residing on the middle tiers. There's a comfort factor here, in that many of the legacy systems of the past 10 years are based on the classic three-tier client-server architecture of which the new Web architectures are strongly reminiscent. There's the promise that well-designed previous generation systems might migrate to the Internet more easily than you had feared.

The keyword here is well-designed: unfortunately, as many of you are aware, a lot of those previous-generation systems were not well designed. Too often business, GUI, and data storage code was mashed and mixed in the scramble to meet a deadline or meet an implementation constraint. There's a strong imperative for good design in the Internet client-server domain, because the Internet is rapidly accelerating the availability of server-based components over heterogeneous networks to a global audience. If the rewards of this global marketplace are greater than before, then the consequences of failure resulting from poor design are correspondingly greater too. Table 1 provides further pointers on the significance of a component-based approach in achieving good design for Internet systems. In short, a component-based approach to Internet systems is more than simply deploying components to the middle tiers of an n-tier architecture. Clear component definitions and effective processes and architectures are often lacking, but essential. Let's look at the architectural issues a little more closely.

Internet systems	Component-Based Development
Raise the stakes for software quality: If the consequences of software errors, poor performance or excessive downtimes are serious for traditional development, they’re often catastrophic for Internet systems.	Specification standards, guidelines and rules are an order of magnitude more rigorous than those used in traditional development. A provisioning process for engineering of quality software.
Subject to rapid changes in business processes: businesses can change shape overnight.	Techniques that ensure: 1) Maximum adaptability, letting components be reused in "plug and play" fashion in different business contexts. 2) Maximum software maintainability, the effects of changes quickly localized.
Subject to demanding response times across vast numbers of users.	Correctly understood, a component is based on the notion of deployment flexibility. Techniques are applied so components can be deployed using technology appropriate to varying implementation constraints, ranging from hugely demanding peak periods through to quiet times.
Greatly increases the need for consistency of services, not merely within an enterprise, but also across different partner organizations. Requires a single organizational view presented to the global village.	Architectures that facilitate effective abstraction of reusable software. Aninterface-based approach that encourages consistency.
Fuel the need to reuse legacy software.	Techniques for wrapping and adapting of legacy software.
Much smaller windows of opportunity than traditional systems. They must be delivered in rapidly shrinking time-scales.	An assembly process for rapid solution delivery.

Table 1: The relevance of CBD to Internet systems--Internet systems and CBD share key similarities.

The application server
In figure 1, the application server provides a wide range of support for enterprise-scale systems. The application server is a platform for hosting distributed systems, and integrating different types of assets across the corporation. In particular, the application server provides a core set of services for coordinating transactions, security, and data management. As a result, an important part of the application server is its ability to handle transactions and deal with asynchronous communication across the pieces of a distributed system. This may be with application server-specific technologies, or via integration with existing transaction processing or message-oriented middleware solutions.

Figure 1: Enterprise Application Server--This provides a wide range of support for enterprise-scale systems.

Different kinds of application server technology are available from a variety of vendors. In some cases, they offer a rich set of services targeting a particular middleware. In other cases, they're aimed specifically at Internet-based applications, and provide robust Web server capabilities for supporting e-commerce applications. As a result, the choice of application server technology is a critical one, with many competing needs that must be considered in balanced fashion.

Why a CBD architecture?
CBD has the potential to remove the tight coupling of an application's parts and eases reuse of parts across different applications. The great promise is that application "islands" disappear: functionality and data are packaged as components, which are configured in network fashion to meet business needs. The assumption here is components are well designed. Good design, in turn, depends on the evolution of an effective architecture.

An effective architecture must provide an overall structure and set of rules for managing the scale and complexity inherent in enterprise software development. It must help achieve software interoperability, adaptability, and consistency of design. This means it increases the chances of achieving a good design; it's not a substitute for good design!

In particular, an effective architecture provides:

A way to see the conceptual and physical architecture of the system as a set of interacting pieces;
A design approach supporting distributed systems development and focusing on how the system should be partitioned for the greatest flexibility; and
A direct mapping from the system design into the underlying implementation technologies, supported by the application server.

The significance of interfaces
A component can be pictured as a black box where all interactions occur through a published interface written to the component standard. Components are like objects in that implementation is encapsulated. However, a component is unlike an object, in that encapsulation is guaranteed. (OO programming languages typically expose implementation dependencies, though this isn't true for components.) Yet more significantly, the implementation language can be anything you choose. It can be an object-oriented programming language (OOPL), or it can just as easily be a previous generation structured language like COBOL or PL1.

Without interfaces, CBD degenerates quickly into modular programming. If your approach to abstraction of interfaces is good enough, then a design is achieved so both business processes and underlying technology can change and adapt with minimal impact. This helps to de-couple the technology issues and allow for a renewed focus on accurate specification of adaptable business components. Traditional rigid approaches to analysis and design are unsuitable. An approach is required that can evolve as the technology changes. For example, though it's now common for business components to be deployed on the application server, it's possible for local business functionality to be deployed on the Web server. This possibility might increase with more powerful Web technologies.
Standard interfaces let components be replaced without impacting their consumers. Components evolve asynchronously as a result of their vendors' independence. Replacing an old component with a new component, without invalidating other components, is an important advantage. This is enabled through the encapsulation of components through their interfaces. Encapsulation allows a software system to evolve not only by adding new components, but also by replacing old ones. Legacy software becomes less of a problem because interfaces can be designed that effectively encapsulate legacy software. Migration to components can be done incrementally without losing the earlier investment in existing software.

Specification vs. implementation architecture
Architecture models are used to focus on different levels of granularity. There are two basic types of component architecture--specification and implementation -- used to answer different sets of questions.

Component Specification Architecture (CSA) operates at the logical level to expose interface dependencies and group interfaces into component specifications. A component specification is a description of the guaranteed behavior of the component, expressed in terms of interfaces. It may also include implementation constraints and executable constraints, which impose additional rules on every implementation or executable.

Component Implementation Architecture (CIA) works at the physical level to model how specifications are realized in terms of actual software components and to expose the dependencies between those components.

In actuality, there are several further sub-categories of implementation architecture. Software components are described here at source code level. Table 2 itemizes the main differences between specification and implementation architectures.

	Component Specification Architecture	Component Implementation Architecture
Content	component specifications, their interfaces, and any dependencies on other component specifications or interfaces	software components and how these components depend on one another, including dependencies on interfaces
Dependencies	dependencies are specification rules	dependencies are specification rules
Inter-Relationship	dependencies constrain how any implementation of the component is built	influences what is technically feasible in the component specification architecture

Table 2: Component Specification and Implementation Architecture characteristics--The two basic types of component architectures address different sets of issues.

Regardless of which architecture you begin with, you must consider both, since there's a dynamic interplay between the two architectures. Usage dependencies in the component implementation architecture are reviewed to determine whether they should be specification-level dependencies. The results are recorded in the CSA. Conversely, specification rules requiring that certain interfaces be invoked, restrict implementation possibilities, and may cause the CIA to change. Despite the restriction, this facilitates an important feature of CBD--the substitution of one consumed component by any other offering the requisite interfaces.

Component specification architecture
Mixed environments are inevitable in many large organizations. The ultimate distributed component environment for rapidly expanding Internet systems would allow solutions to be assembled from a mixture of COM+, CORBA, and Java/EJB-based technologies. Bridges between the three different technologies are now readily available. The CSA, however, provides the foundation for heterogeneous components to work smoothly together to service your business needs.

The CSA caters for both today's mix of technology environments and provides insurance for inevitable future technology changes. It defines the responsibilities and requirements for enterprise business components, regardless of technology in terms of component interfaces, component specifications, or their dependencies. A mapping is created and maintained for each technology used within the organization. The CSA is the foundation of a technically neutral strategy that complements the technologies described earlier and provides the higher-level integration model that's so badly needed in today's challenging and rapidly changing environments.

Each component in the CSA must offer its services through well-defined interfaces. Business components are abstracted into their own layer, ensuring the implementation independence that is so important for a component-based approach. This architecture helps close the all-too-prevalent gap between business process improvement and software engineering by delivering business capability through component interfaces to business processes. Conversely, the architecture also provides a framework for reuse and integration of existing software assets.

Architecture is a living artifact: it's not done once and then forgotten. The process of architecture is one of progressive refinement. The CSA may undergo considerable metamorphoses, as business changes occur, and as architects and project team members evolve their design ideas.

Architecture layering
Many organizations are adopting a layered architecture pattern in which reusability and stability increase downward through each layer, as shown in figure 2. It may sometimes be beneficial to compromise the layered structure in the face of implementation constraints. Within figure 2, boxes represent component specification, lolipops represent interfaces and arrowed lines represent usage dependencies from client to server components.

Figure 2: Component architecture layers--Reusability and stability increase downward through each layer.

User interface layer

The application assembly supports all facets of the application not supported by components. It typically supports the application's user interface. The application assembly is not usually a formal component itself, although there is nothing to stop it being so. It often runs on multiple client workstations, although its functionality could be distributed across multiple processors if required.
User interface controls provide user interface graphics and associated UI event handling, which are incorporated into window designs. For example, a hierarchical scrollable list or a histogram.

Business layer

Process components provide local business process functionality and persistence independent of the user interface. Persistence services may be further split into the technical infrastructure layer. The process component is invoked by the application/UI assembly software. A process component may be built for one application, in which case it's referred to as an "application component," not a particularly reusable component. It could be reused with alternative user interface designs. However, process components may provide significant reuse of local business rules (including sequencing logic) across applications running within the same business process (or part of a business process). For example, an underwriting or claims component.
Business domain components provide functionality and persistence needs across different business processes within the same domain or industry; for example, a policyholder component in the life insurance domain. Domains may be further layered according to commonality; for example finance components may provide interfaces used by
insurance components, which are, in turn, used by the life insurance components.
Business infrastructure components are used across different domains. For example, these include currency conversion services, address reformatting operations, and an organization calendar.

Technical infrastructure layer

These components provide technical services like error message handling, access control, security, and recovery. When there are complex data management issues, typically associated with existing databases, this layer may include persistence services to control data integrity and provide unified data services to the business components.

Project vs. enterprise architecture
Architecture models can answer questions about a single application or a set of applications in an enterprise. The distinction between project and enterprise architectures reflects this scoping issue. (Diagram notations are the same for both architectures.) A project component architecture provides an overview of the software parts from which the envisioned software is built, and describes how these parts inter-relate. The software parts may be encapsulated components, non-component assemblies, software packages, legacy systems, and utilities.

This architecture is needed early in a software development project to:

Identify opportunities for using or adapting pre-existing components.
Identify which new components can be shared or reused, so the requirements of other consumers can be considered.
Estimate project effort, elapsed time, and cost.
Establish a "big-picture" for analysts and developers to work with. This is particularly important where incremental development is undertaken, or where independent teams perform parallel work.
Plan provisioning strategy for a project.

Later on, the architecture is used to:

Decide how to distribute the components and their data stores across a computing network.
Guide the specification and internal design work.
Provide the high-level documentation necessary when the software is enhanced or corrected.

An enterprise component architecture models the component requirements for all the planned component-based applications. Individual project architectures should conform to the enterprise component architecture. The purpose of the Enterprise Component Architecture is to:

Describe a vision for the component-based software within an enterprise.
Understand how components relate to one another across projects.
Investigate and recommend standard patterns and mechanisms.
Plan provisioning strategies across projects.

At the enterprise level, the component provisioning strategy plans how the required components are going to be sourced, either through in-house build, or external acquisition. Dependencies declared on the enterprise architecture help determine the provisioning sequence. Conversely, the provisioning strategy may constrain the project architecture. For example, it may be corporate policy to use a certain software package for all personnel applications. At project level, provisioning strategy identifies opportunities for using or adapting pre-existing components to the needs of a specific application. It's also important to identify which new components can be shared or reused, so the requirements of other consumers can be considered.

The CSA in context
Internet systems divide into two major types: e-business and e-commerce applications, using the following definitions from Gartner Group:

e-commerce--Using the Internet, digital communications and IT applications to enable the buying/selling process.
e-business--The continuous optimization of an organization's value proposition and value chain position through the adoption of digital technology and the use of the Internet as the primary communications medium.

Let's consider the CSA in the context of e-business and e-commerce.

Upper levels of the CSA include large grained components such as customer relationship management (CRM) components, as well as smaller grained components such as product catalogs, shopping carts and credit card components. Often these components are particularly appropriate for e-commerce applications. Smaller grain components may be deployed on a Web server, though the larger grained ones would typically be deployed on an application server.

Lower levels of the CSA may also contain large-grained components, such as shipping logistics components, as well as smaller grained components, such as partnership components. These components are usually best for e-business applications and would typically be deployed on an application server.

As customer-facing applications become more integrated with the supply chain, many of the smaller-grained components required are appropriate to both e-commerce and e-business. Examples include tax calculation, foreign address formatting, and currency conversion components. These become increasingly necessary as business "goes global."

The component specifications of the CSA may be implemented in a variety of ways, as shown in figure 3. Some components that provide well-established functionality, such as shopping carts and credit card components, may be available for purchase from component suppliers. Others may be specialized using component frameworks. Adapters and wrappers may be used to access services of existing systems, databases and packages. Enterprise Application Integration (EAI) tools may be used to provide the required middleware.

Figure 3: Component architecture in context--Internet systems divide into two major types: e-business and e-commerce solutions.

The CSA provides the underpinning architecture for effective integration at the business level for these different technologies. As technology moves forward, this provides three big advantages:

Components can be deployed using different platforms according to implementation constraints and business needs. The target technology provides some form of deployment support to assist with this activity. With EJB, this is managed through the concept of a deployment descriptor, which is a description of the deployment-specific characteristics of the application that may vary from one installed instance of the system to another. The use of the deployment descriptor allows customization of application behavior at run time without having to change the software itself.
Component implementations may be replaced, providing the component specification remains the same, so today's legacy adapter can be replaced with tomorrow's new component.
Designing your components independently of the implementation, in an abstract way, puts you in a good position for supporting Web applications in mixed technologies (EJB or MTS).

Summary
An effective component-based architecture provides an integration model for implementation using Web-based technologies based upon component standards. The architecture forms a backbone for future distributed systems and, at the same time, provides a structure for addressing the design and provisioning issues so critical in developing enterprise solutions with the Internet.

COMPONENT ARCHITECTURE

Component-Based Architectures for Internet Systems

A component-based architecture can help you manage the scale, complexity, and transitions of development projects.

By Paul Allen

Component-Based Architectures for Internet Systems

No reader comments ... yet.

What do YOU think about this topic? Share your advice and thoughts using this form.

Your Name

REQUIRED : PUBLIC

Your E-Mail

REQUIRED : PRIVATE

Job, Company

OPTIONAL : PUBLIC

City, State, Country

OPTIONAL : PUBLIC

Your Web Site

OPTIONAL : PUBLIC

Your Comment

Please help everyone by keeping your comments on-topic, using clean language, and not defaming or making personal attacks.

Your e-mail address is required, but it will not be displayed to the public or given to anyone. See our Privacy Policy. Comments become visible after they pass our spam filter, and spammers and abusers are permanently blocked. Please report spam or abuse.

ARTICLE INFO

Print Edition: February 2000, Page 16

FREE ACCESS

MORE ADVISOR

Read the advanced guide to creating custom business database solutions with FileMaker software. Subscribe now to gain access to all the archives and downloads.

Learn the fundamentals of using FileMaker Pro software. Every issue gives you step-by-step instructions on creating the databases you need. Subscribe now!

Submit your tips, techniques and advice and let Advisor promote your business and build your career. Show the world what you know!