Guideline: Transforming Components |
This guideline explains how to transform logical components into physical components by selecting the technology that best implements each logical component.
Relationships
Related Elements | Detail Component Model
Main Description
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)
Table 1: Implementing Components Using the Sun J2EE Blueprint
More Information
Concepts | Component Logical and Physical Components Transformation
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.