Designing the Components of an Application or Service

Component Types

An examination of most business solutions based on a layered component model
reveals several common component types. Figure 2.1 shows these component types
in one comprehensive illustration.
Note: The term component is used in the sense of a piece or part of the overall solution. This
includes compiled software components, such as Microsoft .NET assemblies, and other
software artifacts such as Web pages and Microsoft® BizTalk® Server Orchestration schedules.
Although the list of component types shown in Figure 2.1 is not exhaustive, it
represents the common kinds of software components found in most distributed
solutions. These component types are described in depth throughout the remainder
of this chapter.

Figure 2.1

The component types identified in the sample scenario design are:
1. User interface (UI) components. Most solutions need to provide a way for users
to interact with the application. In the retail application example, a Web site lets
customers view products and submit orders, and an application based on the
Microsoft Windows® operating system lets sales representatives enter order data
for customers who have telephoned the company. User interfaces are implemented
using Windows Forms, Microsoft ASP.NET pages, controls, or any other
technology you use to render and format data for users and to acquire and
validate data coming in from them.

2. User process components. In many cases, a user interaction with the system
follows a predictable process. For example, in the retail application you could
implement a procedure for viewing product data that has the user select a
category from a list of available product categories and then select an individual
product in the chosen category to view its details. Similarly, when the user
makes a purchase, the interaction follows a predictable process of gathering data
from the user, in which the user first supplies details of the products to be purchased,
then provides payment details, and then enters delivery details. To help
synchronize and orchestrate these user interactions, it can be useful to drive the
process using separate user process components. This way the process flow and
state management logic is not hard-coded in the user interface elements themselves,
and the same basic user interaction “engine” can be reused by multiple
user interfaces.

3. Business workflows. After the required data is collected by a user process, the
data can be used to perform a business process. For example, after the product,
payment, and delivery details are submitted to the retail application, the process
of taking payment and arranging delivery can begin. Many business processes
involve multiple steps that must be performed in the correct order and orchestrated.
For example, the retail system would need to calculate the total value of
the order, validate the credit card details, process the credit card payment, and
arrange delivery of the goods. This process could take an indeterminate amount
of time to complete, so the required tasks and the data required to perform them
would have to be managed. Business workflows define and coordinate longrunning,
multi-step business processes, and they can be implemented using
business process management tools such as BizTalk Server Orchestration.

4. Business components. Regardless of whether a business process consists of a
single step or an orchestrated workflow, your application will probably require
components that implement business rules and perform business tasks. For
example, in the retail application, you would need to implement the functionality
that calculates the total price of the goods ordered and adds the appropriate
delivery charge. Business components implement the business logic of the
application.

5. Service agents. When a business component needs to use functionality provided
in an external service, you may need to provide some code to manage the semantics
of communicating with that particular service. For example, the business
components of the retail application described earlier could use a service agent
to manage communication with the credit card authorization service, and use a
second service agent to handle conversations with the courier service. Service
agents isolate the idiosyncrasies of calling diverse services from your application,
and can provide additional services, such as basic mapping between the
format of the data exposed by the service and the format your application
requires.

6. Service interfaces. To expose business logic as a service, you must create service
interfaces that support the communication contracts (message-based communication,
formats, protocols, security, exceptions, and so on) its different consumers
require. For example, the credit card authorization service must expose a service
interface that describes the functionality offered by the service and the required
communication semantics for calling it. Service interfaces are sometimes referred
to as business facades.

7. Data access logic components. Most applications and services will need to
access a data store at some point during a business process. For example, the
retail application needs to retrieve product data from a database to display
product details to the user, and it needs to insert order details into the database
when a user places an order. It makes sense to abstract the logic necessary to
access data in a separate layer of data access logic components. Doing so centralizes
data access functionality and makes it easier to configure and maintain.

8. Business entity components: Most applications require data to be passed between
components. For example, in the retail application a list of products must
be passed from the data access logic components to the user interface components
so that the product list can be displayed to the users. The data is used to
represent real-world business entities, such as products or orders. The business
entities that are used internally in the application are usually data structures,
such as DataSets, DataReaders, or Extensible Markup Language (XML) streams,
but they can also be implemented using custom object-oriented classes that
represent the real-world entities your application has to work with, such as a
product or an order.

9. Components for security, operational management, and communication: Your
application will probably also use components to perform exception management,
to authorize users to perform certain tasks, and to communicate with other
services and applications. These components are discussed in detail in Chapter 3,
“Security, Operational Management, and Communications Policies.”