content:
Major Software Features Faced Component Programming Components Components Understanding Services Software Bus and Software Factory About the Author for this article
related information:
Software Quality Road (1): Software Quality Framework Software Quality Road (2): Software Quality Road (3): Test Drive Development Software Quality Road (4): Establishing a Core Framework
In the Linux area:
Tutorial Tools & Product Codes and Component Project Articles
Lin Xing (IAMLINX@21cn.com) March 2004
The main feature of large-scale software is mainly characterized by complexity. The more typical example is an integrated project. Software systems need to integrate a wide variety of hardware, legacy systems, and external interfaces. It may encounter different hardware interfaces, different operating systems, different languages, different platforms, different databases, different messages, different network media. These make the system becomes very complicated. Object-oriented technology is characterized by division of divisions and high collaboration between the objects. Such benefits are less code, and the system layout is reasonable and reused. However, when the number of objects increases, the relationship between the height coupling between the objects will make the system complex and difficult to understand. Previously, the method for this issue was to use the package (see the discussion of the object-oriented software development) as a container to organize objects, depending on the dependence between the objects will be converted to the dependence between the packets. This method sounds sense, but there will be difficult solutions in practice. The package is just a container. This means that the organization of the object can be arbitrary, and the design of the relying on the bag is depends on the dependence of the object. In addition, the design of the package is the same, lacks a unified style. The unified style is a large scale software design, as this can effectively improve the understandability of the system, this is very important. An abbreviation for component programming facing components is COP. COP is a supplement to OOP, helping to achieve a more excellent software structure. The particle size of the assembly can be large, requiring the specific application. There are several important concepts in COP: Services, service (service) is a set of interfaces for client programs. For example, verification and authorization services, task scheduling services. The service is an interface called each other in the system; component, component implements a set of services. In addition, components must meet specifications for containers, such as initialization, configuration, destruction. COP is the idea of organized code, especially both services and components. In the Spring framework mentioned below, the COP's idea is used, and the system is considered as one of the components, and the system builds are completed by defining collaboration between components (through service). The advantage of this is to isolate changes, reasonable division systems. The meaning of the frame is to define a way of organizational components. Understanding components provide a few articles that explain the components on my QCA website, you can access the following links: http://qca.cn/common/content.htm component is not a new concept, JavaBean specification and The EJB specification is a typical component. The feature of the component is that he defines a generic handling method. For example, JavaBean has the characteristics of the inner view, so you can achieve visualization of JavaBean through tools. The EJB specification defines some features in the enterprise service, so that the EJB container can add capacity to the EJB specification, such as transactions, persistence, pool, etc. Therefore, the components are in the introduction of the general specifications than the progress of the object. General specifications are often capable of adding new capabilities to components (just like discussed above), but also adds a limit to components, for example, you need to implement some of the EJBs. We will discuss some related issues of the component: the particle size of the particle size assembly of the component is related to the system's architecture. The particle size of the assembly is determined that the system's architecture is determined. In a small-scale software, the particle size of the possible components is small, which is equivalent to ordinary objects, but for a large-scale system, one component may include tens or even hundreds of objects. Therefore, a system using COP technology is required to correctly define the particle size of the component.
A preferred method of defining the particle size is to analyze the core process. In response to interface interface and implementation are the foundation of COP, there is no COP. The height abstraction characteristics of the interface allow each component to be independently extracted without affecting other parts of the system. The interface and implementation separation have several benefits: 1, decoupling between module / component / objects. 2, easy toggle implementation without modifying the client. 3. Users only need to understand the interface without having to understand the implementation details. 4, increase the possibility of reuse. IOC IOC is an abbreviation of Inversion of Control. Its principle is based on the Hollywood Principle of the OO Design: Don't access me, we will visit you. That is, all components are passive, all components initialization and calls are responsible for containers. The concept of IOC is explained in Brian Foote's thesis (http://www.laputan.org/drc/drc.html). There are several types of implementation of the IOC's discussion (http://qca.cn/common/ioc.htm) on the QCA website, including method-based (m) IOC based on method parameters, which passes components to each Method call; interface-based interface-based (i) IOC (commonly referred to as type 1), it uses interfaces to declare dependencies between components, such as serviceable, configurable; setter-based setter-based (s) IOC (commonly referred to as type 2), which uses the setter method to set the dependence between components; the constructor-based (c) IOC based on the constructor (commonly referred to as type 3). In the Inversion of Control Containers and The Dependency Injection Pattern (http://www.martinfowler.com/articles/injection.html) of (2004-1-24), call IOC mode is called a Dependency Injection mode . IOC is a basic principle of framework development. In open source software, many container frameworks use IOC ideas. For example, PicoContainer (http://www.picocontainer.org/) and Spring (http://www.springframework.org/) Components are contaminated in the first type of IOC, because components need to implement some specific interfaces, or from A class integration. This will make the components subject to some constraints (called Invasive), such as inconvenient transplants of components. Another situation is that the components need to be dependent on a particular container, and the most typical is EJB, and the component cannot be separated from the container alone, which also causes the component to be constrained. Both of these situations belong to component pollution. The ideal component is a component that is only focused on its own work, which does not have additional logic. However, most of the code currently is not in line with this standard. Therefore, there are currently some lightweight container frameworks in the open source software community, typically Picocontainer and Spring as mentioned above. Their positioning is to provide a unified mode of component management, and components can be used separately, or in another container, the container is only provided with some additional functions for components, and the component itself has no direct dependence.
Why do we say that the interface is better than inheriting, a very important reason is that the interface is more flexible, the component's dependence is weak, and the other practice is the use of some marked languages to achieve greater flexibility than the interface. . For example, based on XML-based configuration files, and attributes that will be introduced in J2SE1.5. Components' test components and containers are out of detachment provides a good environment for component testing. We discussed in the test section that is often troublesome, the reason is that the components contaminated above. For example, in the Spring framework, the component is a standard javabean, you can write code to set the component's properties and dependencies between the definition components (for automated test), or give this job to the Spring container (applicable Development and deployment). Component Test is an integrated test in the tested classification. Understanding services We discuss the problem of component particle size when discussing components. When the particle size of the component is not limited to a single object. In a plurality of objects constituting the components, some objects are in the interior of the component, not interacting with other components, and some objects need to interact with external components. The latter object is the role of the service. In the design mode, this design is called the FA? ADE mode. In the OO language, they are equivalent to the concept of interfaces. No matter how metaphor, the service enables contracts between components and components. This contract is stable (if the business needs are stable), there is no change as the interior of the component changes. It is also very easy to understand this. For a component that provides user authentication, a possible service authenticates and authorizes the user, as for the internal use of LDAP or relational database to store user information, there is no difference in service. There is a lot of benefits of this, one is that the components can exist in a stable manner, and the changes inside the component are not spread to the entire software system. Second, software design will turn to the service between key design components, and the implementation details of the components will hide, which not only helps designers to better grasp the global architecture of the software, but also contribute to the details of labor. The service is not a novel concept, RPC, IDL is similar technique. But we talk about the service side armor and ideas, do not involve specific technologies, this point similar to SOA and WebService is similar - SoA is a structural concept, and WebService is a suitable technology for implementing SOA. Stairway to Heaven - Service Oriented Architecture (http://www.enterpriseintegrationpatterns.com/docs/stairwaytoheaven.pdf) Discussed the problem that SOA needs attention, and proposes three stages of implementing SOA, the services discussed in this article The stage 3 discussed is also the most ideal stage. The service is best implemented as an interface. In principle, service can be any technology: JMS, WebService, RPC, or simple method call. However, for the stability of the service, we should not bind a service and specific technology, which increases the possibility of changes in the service. In the Java language, the interface is greatly flexible, so the interface is achieved as a normal Java interface is a good choice. However, if you do this, we may not use the remote call, the features such as the web service, but this is not tight, the following is the reason. The service adapter client can use the interface directly, or the normal interface service can be converted to a particular technology implemented service through the appropriate adapter.
As shown in the figure above, an ordinary interface converts to services related to specific technologies through adapter mode. In JMX technology, this approach is also adopted, and the JMX platform can convert a normal service port through an adapter to suit various protocols, such as HTTP, SOCK, SNMP, and the like. AOP technology helps the service helps AOP technology because there are many articles, we will no longer repeat, so the following content is assumed that you already have basic AOP concepts. A simple finishing of AOP on the QCA website. (Http://qca.cn/common/content.htm) AOP as the complement of OO technology, can handle the cross-cutting point of the system in an elegant manner. The service level is a great location for applying AOP:
In the above figure, we see an ordinary user registration service to add a wide variety of capabilities through AOP. AOP provides a few benefits, one is to add functions to all services through simple code, without writing code for each service, thereby greatly saving code quantity; second, separating cross-cutting points, so service only The core code improves the degree of modularization of the system; the last point is that the modular increase enables the increase or deletion of the service to the service, for example, the new ASPECT can be added to the user registration service. The service test service test belongs to the tested classification. The introduction of service concepts makes automated acceptance tests easy. In large-scale software design, business processes tend to collaborate in various components through service interfaces. So this is the focus of the test. Back to our previously discussed the granular problem, if you have written the test code is too cumbersome, indicating that the component's design granularity is too small. If the components have too big, you will find some test code to be written at all. The management of service management services is a relatively large topic. On the one hand, in a large-scale system, although the system can reduce the complexity of the system through the form of components and services, there are still many services, need to be managed; on the other hand, the service status, the availability of services requires monitoring and management, This is necessary for large-scale applications. Therefore, services require a management form. The purpose of JMX specification is also a unified management of various components. There are similar situations we have elaborated. JMX is divided into two parts: norms and remote interfaces. In J2SE1.5, JMX has been included in J2SE, and interested readers can refer to Sun's related documents. Software bus and software factory until now, software development remains in the handmade workshop stage. If the level of the manufacturing industry is related to the level of the steam, it is basically in the level of the vapor invented. With the development of software development technologies, software development will also be like manufacturing, step into the "Industrial" era. However, for software development, the machine is still code, but these code is used to replace the developer's encoding activity, he has higher productivity than manual encoding. We describe these high-yield "machines" into a modern software factory. So what is the software factory? To understand the software factory, we need to understand the concept of the software bus. COP only puts a systematic basis, to form a complete application, there is not enough light components and services, but also to organize components and services in an effective manner, some articles call this organizational code For Fabric, structural and organizational meaning. In our article, it is called a software bus. What is the software bus? Like the computer's bus, it is responsible for delivering information flow in each component, organizes each component to complete a specific task. The bus is an abstract concept, and the bus is also constructed by specific technologies. For example, a bus may be a piece of code, responsible for calling each component; bus can also be a message system, responsible for collecting and distributing messages; bus may also be a workflow system, responsible for system information; bus may be a JMX, Responsible for route messages to target components. However, regardless of the implementation of the bus, the bus characteristics is to organize the components in a loosely coupled manner. In this way, the bus itself and the components on the bus are loosely coupled, so that the components are hidden to the bus, that is, the services we have previously discussed and the service adapter should do.
For example, there are three possible implementations of software bus: Direct call / remote call / WebService, MOM, and workflows, depending on the feature of the application, different bus implementations can be used. For example, a bus primary is applicable to applications that are more clear processes, because the process is hard-coded, and there is a relatively troublesome. Workflow-based bus is suitable for process relatively flexible, requires complex branches and human interventions. MOM-based bus is suitable for large distributed, or isomeric applications, and cooperates with a loose manner between different applications. But no matter which bus implementation, components and services are constant, and changes in service adapters, MOM service adapters, and workforce-stream service adapters are different. The main job of MOM's service adapter is to translate the content in the message into Pojo, and call the service; and the service adapter of the workflow may be just a call based on the current workflow state. The system architecture thus formed is relatively stable, loosely coupled, whether it is a change in the assembly, or changes in the bus, as long as the standard for service and bus is stable, the overall software system is stable. The service and bus norms are the core competitiveness of the software organization, which is also the main purpose of the software bus. Patterns and Best Practices for Enterprise Integration (http://www.enterpriseintegrationPatterns.com/) Collects a large number of valuable messages related enterprise integration mode software factories develop on the basis of components and software bus, and according to components and The technical characteristics of the software bus define a range of management activities to increase development efficiency. Software Factory is an implementation of our defined software quality framework. For different software organizations, it is very important to define the composition of the software plant according to its own R & D feature. The specific content includes the selection of management practices, the accumulation of components, and the technical implementation of software bus. The first two practices recommended in this series are content of the management practical category, while the third practice is to establish the underlying support framework for establishing a software plant. The concept of software factory represents a new software development model. His advantage is to combine technology and management to improve productivity. About the author Lin Xing, is committed to studying agile theory and excellent software design ideas, and applies it to domestic software organizations. You can get more information by accessing www.qca.cn and www.qca.cn and www.qca.cn and www.qca.cn and www.qca.cn.
