Practice
Computing Applications Developing and integrating enterprise components and services

Lessons Learned from a Nationwide Cbd Promotion Project

Posted
  1. Introduction
  2. Technologies Applied and to be Developed
  3. Essence of Having a Common Component Reference Model
  4. Methodology and Tools
  5. Other Activities in the Asian Region
  6. References
  7. Author
  8. Figures





To increase reuse and interchange of components among companies, it is important to extract a common functionality and behavior among family members of a business sector.


Architectures and Component Platforms. In the past three years, approximately 40 CBD projects were supported by the CIP program, producing a large number of COTS components. In order to effectively share components among organizations, the components from different vendors must be interoperable. However, component platforms are not interoperable with current CBD technology; EJB beans are not interoperable with COM components. Since the CIP project is to promote the reuse of components as much as possible at national level, we had to decide the certain component platforms and architectures on which components are developed and interoperate. EJB and COM/DCOM platforms were chosen for the CIP project.

Attracting Industry for Active Participation. One of the key success factors in the CIP project was to draw a large number of active participants from the industry sector. This is because COTS components would be developed and utilized by them. To increase reuse and interchange of components among companies, it is important to extract a common functionality and behavior among family members of a business sector. To accomplish this, each development project was conducted by a team of members from at least three different companies. One of these participating companies must be the potential client company that will utilize the developed components to build its own applications. In this way, we were able draw active industry participation.

Developing Standard Domain Models. Standardization on domain models is an essential prerequisite for successful development of shared components. Hence, we organized a few standardization working groups to model standard business process and functionality in each business sector. Initially, working groups on finance and manufacturing were active. A major problem in modeling the common business process was that participating companies were not willing to share their domain knowledge and experience acquired through projects over several years. Participating companies demanded some form of reward on providing their domain knowledge. Hence, research organizations and official software promotion agencies are now developing a new pricing and valuing system for components. It is expected that a substantial portion of the component license fee goes to the companies that provided domain knowledge in designing components.

Since components are meant to be reused by many organizations in same business sector, component developers must extract and implement the commonality among the relevant companies (family members). Participating companies presented their own requirement specifications, but an immediate problem encountered in modeling commonality and variability was the lack of standard terms and expressions in the set of requirement specifications. Different words and expressions are used for the same meaning, and different meanings are used for the same expression. Hence, it was unavoidable to normalize those requirement specifications by developing a glossary of standard terms before identifying commonality, which most developers found quite time consuming but essential.

Distribution of Components. During the first two years of the CIP project, participating companies developed a large number of commercial components. A component distribution system was developed in order to register and distribute newly developed components. To allow effective searches for correct components, we defined a template for specifying components, which includes component categories, ID, names, functional description, both provided and required interfaces, customization instruction, persistence requirements, and example client code. New components were documented in this standard specification form and submitted for certification and registration.

In order to manage a large number of components effectively, we defined a standard classification scheme. The classification of the CIP was based on six different views: domain, granularity, abstraction degree, generality, language, and platform, and each component was assigned a unique identification number according to the classification standards. We also found that selecting the correct COTS components is not a straightforward task but a task requiring careful inspection and testing of functional maturity and architectural conformance.





Join the Discussion (0)

Become a Member or Sign In to Post a Comment

The Latest from CACM

Shape the Future of Computing

ACM encourages its members to take a direct hand in shaping the future of the association. There are more ways than ever to get involved.

Get Involved

Communications of the ACM (CACM) is now a fully Open Access publication.

By opening CACM to the world, we hope to increase engagement among the broader computer science community and encourage non-members to discover the rich resources ACM has to offer.

Learn More