Some ideas for implementing componentized business systems

"Href =" http://goo.gl/cXS2d ">Componentization The concept of business system architecture is said to have been put forward for more than 20 years, but it has not been convincing yet. Componentized Business System (Note: Componentization = Modular). About Business Components What is it, what it looks like, how to achieve it, and what kind of vision? Everyone has made a lot of thoughts and discussions.
Read Community Some of the contents, coupled with the communication and discussion with colleagues at ordinary times, have produced some ideas on the Implementation of componentized business systems. Next, let me talk about my thoughts. You are welcome to come to the discussion.
I think Business Components There is a consensus that each business component is relatively independent and can be assembled and pluggable.
The running of each component only depends on the platform or container, and the coupling between the component and the component is not saved. At the same time, components and components are not absolutely independent. After components are assembled, they can interact with other components in the business. For example, sales components and financial components, the completion of a sales business will certainly produce one or more financial services, such as the issuance of sales invoices and a new payable or cash bank accounting. For example, when procurement and inventory management are put forward, do you need to first check whether the warehouse has inventory? If this warehouse does not exist, can I transfer data from another warehouse? Wait ......, Such business scenarios cannot be exhausted, and users of different sizes in different industries have different business processes.
That is to say, the interaction between components has non-standard and non-exhaustive characteristics in the business. This is a headache. Please write down it for now and discuss it later.
In addition, my understanding is as follows: Componentization Is a concept between modularization and application system integration. Componentization Modular, different applications, an article in the community Article Well written. At the end of this article, componentization is different from modularization. Citation: Modular development is different fromComponent developmentModular development is only logically split, physically (developed systemCodeGenerally, there is no real isolation. Everything is only in the document. The difference between componentization and application integration is also mentioned in the article. Citation: The ear or war is deployed on an enterprise application. Note that the EJB specification clearly states that the Enterprise JavaBeans architecture is a architecture for the development and deployment of component-based (distributed) business applications (EJB 2. X and 3. the only difference between X is 2. X has distributed ),They have their own application domains and are isolated from each other (in simple terms, they have their own independent session management ).. Net also has its own application domain concept.
According to the above description, combined Componentization Place it between modularity and application integration. Componentization should be more independent than modularization, but more closely integrated than application integration. Based on the analysis in the article mentioned above, the citation is as follows: Application-based Deployment causes three isolation problems:InterAction (Interface) Isolation,ProgramAccess isolationAndData isolation . Let's take a look at the differences between componentization, modularization, and application integration to better understand the location of componentization.

	User interaction (Interface)	Program access	Data
Modular	Unified	Direct access between modules	Unified Storage
Application	Independent	Open external access interface	Independent

Componentization Since they are between the two, how should we locate these three aspects and implement them?
1. Interface Interaction
I think user interaction should be unified because Componentization The various business components are eventually assembled into the same set of enterprise applications. As a user operation interface, the UI must look uniform rather than independent. This is similar to the modular implementation of various systems. Although it belongs to different modules, the user interface is always used. In addition, I think the development and deployment should be separated according to different components.
As a result, the contradiction arises. To make it look uniform, you must develop it separately and deploy it separately. First, how can we ensure that the interface styles developed by different development teams are consistent. Secondly, what measures should be used for separate deployment to integrate into an interface?
To address the first problem, we can imitate the experience of modular development. A little more complicated: Use a unified UI tool for development; a little simpler: it can also be based on conventions. As for UI integration, we may need a portal component.
2. program access
This problem is quite tangled.
Based on the premise that "components only rely on the platform to run, but do not rely on other components to run", interactions between components cannot be directly accessed as modular. What about open access interfaces like application integration?
I don't think so. Why? Let's look at the scenario of system integration. A company already has a set of systems in a certain business area, and now it wants another system in other business areas. When the two systems interact with each other in terms of business, developers of the two systems are found to develop solutions, perform secondary development, and open interfaces to each other to modify programs to call each other. From this we can see that this solution is a helpless solution from the very beginning. It is doomed that the two parties to be combined are not close enough. Secondly, open access interfaces have certain security risks. In addition, the problem we left behind is:"The interaction between components has the non-standard and non-exhaustive characteristics in the business. ." Is this integration solution not suitable for our components? First of all, there will be such frequent and complex interactions between components. We need closer integration, or seamless integration. In addition, when developing components, we cannot anticipate so many other components that they expect to get from us. We cannot prepare so many service interfaces for them first.
What kind of solution is there between modularization and application integration for inter-program access? Where is the balance point? I have an idea that is not clear yet. Let's take a picture here.
Let's talk about the general solution first. the general idea is that most people (including me) may think of introducing the bus, or similar to the main board and slot, plug our components into the bus, and combine the components with the bus, use the bus to interact with other components. This can indeed achieve interaction and communication, but I always feel that this solution is not the best, and the combination of components is not close enough, there are still issues that we cannot exhaust which services need to be provided to the bus for other components to call. In addition, since it is a bus, there is a bandwidth problem, when the business peak, the interaction between components is frequent, it is bound to be congested, resulting in efficiency problems.
I think we need more flexible and direct assembly.
How can we create a "adhesive layer" or "glue layer? The "glue layer" is responsible for interaction and bonding between components. Component Assembly is often compared to building blocks or puzzles. But in fact, we cannot define a clear size and enough slots or interfaces in advance like building blocks and puzzles, the actual shapes of our components are flexible, with different shapes and sizes. For the combination of such shapes and bodies, I think it is more appropriate to use strong "glue" to bond. When we select two components and want to combine them for use, we apply a "glue" in the middle to bond them. "glue" is actually a conductor, as the medium for information transmission, it calls programs and transmits data in two components. A component may interact with multiple components. We add "glue" to each component to combine them so that each component has a separate combination medium, instead of using the unique bus. In this way, the combination is more flexible and the interaction is more direct.
As for the implementation of the glue layer, some technical breakthroughs may be required. Further research is required. Currently, dynamic languages such as Python and Ruby are considered. There are issues such as transaction control, synchronous Asynchronization, and concurrency control, which need further research.
In addition, the introduction of the glue layer may have some impact on personnel layout. Not only are there development teams responsible for various component development, but also implementation teams responsible for glue combinations (this implementation team seems to have a high technical threshold, we may need to consider creating a tool to lower the technical threshold of this team so that we can focus as much on the business as possible and less on the technology. Of course, for components that are often combined, We will accumulate the "glue" code between them for reuse ).
3. Data
Between modularization and system integration. I think the business data of each component should be stored separately, and most data autonomy can be achieved on each component database. This part of autonomous data includes business data and metadata. As for primary data, we consider using redundancy to distribute the data to various business components synchronously by introducing the primary data component. Note: here we call it "primary data component" instead of "Primary Data Bus", which means its position in the system is similar to that of other components.
Query and statistical analysis. A simple query involves only the data in this component. You can directly query the databases in this component to obtain the data. For cross-component data queries, reports, and reports, consider data extraction into the Bi component and use the Bi component for analysis.
I simply drew a layout chart of a system based on business components, and also mentioned the container.

1-N containers can be deployed in each container.Business ComponentsContainers can have multiple containers (Note: containers are equivalent to physical servers, and one physical server can have multiple containers ). The program calls between components are bonded through the glue layer to interact with components in the container or other containers. (if it is difficult to draw a picture on the glue diagram, it will not be painted ). These components include our functional permission components, data permission components, primary data management components, and other components that are commonly called system-level components. In addition, there must be an exit for the user, and a portal component must be deployed on a container. The portal component adds otherBusiness ComponentsTo provide consistent human-computer interaction entrances and exits.
The above are just some ideas, but they have not yet formed a practical solution. Here we will first release a brick. It is best for everyone to brainstorm and get a piece of jade back.
 
The organization that provides this document is the oecp community. More blog articles can be viewed in the oecp community. You are welcome to repost the attachment of this document. However, you are not allowed to change the content or copyright of this article without the permission of the author. The copyright belongs to the oecp community.