The technique you use to transform logical components into physical components depends on whether you are
going to build or reuse the target physical component.
-
For components to be implemented using commercial off-the-shelf (COTS) products, map the logical components to
the appropriate products or packages.
-
For components to be built, identify the approach to implementation by defining the physical components. Use
patterns or other assets to help in this definition.
A logical component can be implemented by more than one physical component. However,
most projects only have one physical representation of a logical component for ease of maintenance, due to the skills
needed in each implementation technology.
Transformation using products and
packages
For components to be implemented using commercial off-the-shelf (COTS) products, map the logical components to the
appropriate products or packages.
Perform some or all of the following tasks:
-
Collect information on COTS products from vendor Web sites and product literature.
-
Develop a list of weighted capabilities for competing products. For example, create a matrix of required
features and products, and place a mark next to each product that supports the feature.
-
Request information from vendors. You can often download information from the vendor's Web site or request
information packs.
-
Evaluate capabilities to meet requirements. The responsibilities listed for each component are the requirements
that the product must support, so you can easily verify which products match the requirements.
-
Conclude which of the candidate products are most appropriate. Capture the evaluation as architectural
decisions.
-
Request proposals from vendors for complex products. For products that require customization, you may need to
establish a whole stream of work involving hiring subject matter experts and procuring hardware and software.
The amount of time needed for this may be significant.
-
Validate and circulate recommendations to stakeholders to review. This should include a cost-benefit analysis
that evaluates the benefits of buying a product rather than building one from scratch.
-
Implement the selected product. Once the product has been selected and procured, plan its actual implementation
into the rest of the project work.
Most software vendors offer advice and guidance on how to implement their products in a variety of business and
technical environments. For example, IBM has its Patterns for e-business
(P4eB) that describe a step-by-step process for:
-
Selecting a business pattern
-
Selecting an application pattern
-
Reviewing the runtime patterns
-
Reviewing product mappings
The last step is to correlate real products with one or more runtime nodes. Both the IBM P4eB Web site(http://www.ibm.com/developerworks/patterns) and
[ADAMS01] show each runtime pattern with products that have been tested in that capacity. The product mappings are
oriented toward a particular platform, although it is more likely the enterprise will have a variety of platforms
involved in the network. In this case, it is a matter of mixing and matching.
Circumstances in which you may be unable to use COTS products or packages include:
-
COTS products do not satisfy the responsibilities that the components have, or cannot meet all of the
functional and non-functional requirements.
-
The enterprise has a general policy to build rather than buy or customize packages. For example, some companies
prefer to avoid vendor dependencies.
-
This is a new or niche business area for which no COTS products yet exist.
When any of the above apply, there is usually no choice but to build the components from the ground-up.
Transformation of developed components
Ideally, logical components are independent of technology, and can be implemented in one or more ways. In practice,
each technology brings its own idiosyncrasies. You now must do some work to interpret these differences and implement
the component. Here are some issues that may arise during implementation when you build components [CHEESMAN00].
-
How do the logical operations and signatures map to the chosen implementation language?
-
How does the implementation language handle exception handling? Does it have built-in support, or do you need
to create it?
-
Does the implementation language support interfaces in the way that you have specified them, or do you need to
simulate them?
-
Is component composition supported?
-
What is the correspondence between logical components in the different layers and actual implementation level
components?
-
How is transaction handling managed?
-
How is persistence controlled?
-
Are there implementation details in integrating with existing systems that need to be addressed? For example,
perhaps specific adapters have to be built.
Many
vendors produce technology patterns that describe how to use their products. IBM®, Sun®, and Microsoft® all provide
advice and guidance on their Web sites. Use these patterns to help select how to implement particular components. For
example, Sun produces a set of J2EE blueprints (see http://java.sun.com/blueprints/patterns/index.html) that show how to apply J2EE
components. The table below shows a mapping of components from the different layers to these J2EE
components.
Layer
|
Description
|
J2EE
Equivalent
|
Dialogue
Control
|
Management
of dialogue with the user.
|
HTML,
Java Servlets, Java Server Pages, JavaBeans.
|
Business
Process
|
Flow
and state aspects of use cases.
|
Session
EJBs and/or HttpSession.
|
Business
Service
|
Implements
the business object model and other business rules. Contains the core business logic.
|
Session
and entity EJBs.
|
Technical
Component
|
Technical
services the components may require.
|
Servlet
engine and EJB container, JDBC, and Java Connectors.
|
Middleware
Component
|
Provides
the technical services for the components in a runtime environment.
|
Vendor
J2EE platforms (for example, WebSphere Application Server, BEA WebLogic, and so on)
|
Table1: Implementing Components Using the Sun
J2EE Blueprint
|