Business component development practices for enterprise applications

Author: Anders James

What is a business component under an enterprise application?

First, this is a component, which means it needs to run in the container. Therefore, it does not include any middleware service and is identified by the container in a certain structure (file structure or compression format; secondly, this is a business component, that is, providing application services, rather than non-technical services. Third, this is an enterprise application, which includes functions and services in the business, you can understand it as an API. Technically (in J2EE), it includes: Ui resources (JSF, JSP, JS, CSS, etc.), applications (Java) resources and configuration files, database table definitions, initialization data, and stored procedures.

Why do we need business components for enterprise applications?

The component technology has been put forward for more than 20 years. Why should I introduce enterprise application business components? Because the existing component technology does not support the component requirements in the enterprise application environment, J2EE EJB does not support and. Net DLL does not support.

As mentioned above, an enterprise application usually includes an interactive interface, application code, and database structure, while EJB or DLL only supports application code, not the interactive interface and database structure.

If not, is the J2EE ear or war a component? The answer is no. the ear or war is deployed on an enterprise application. Note that the EJB specification clearly states: 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 independent session management ).. Net also has its own application domain concept.

Furthermore, application-based Deployment causes three isolation problems:InterAction (Interface) Isolation,Program access isolationAndData isolation(Note that these three problems correspond to the three technical content of the enterprise application service component respectively ). Interaction isolation makes enterprise users have to access different interfaces. Code Access Isolation leads to point-to-point integration and various non-functional problems such as performance, transactions, and asynchronous processing, data Isolation leads to Data Validity and consistency issues. All of these causes maintenance problems.

To solve these problems, major vendors have proposed various solutions: portal to solve the problem of interactive isolation, and ESB to solve the problem of code access isolation, and uses the so-called information service to solve the data Isolation Problem.

Can osgi or SCA meet the requirements? The answer is no. osgi was initially developed not for enterprise applications, but has matured over the past few years and is evolving towards enterprise applications. The Enterprise Edition (draft) launched in September has just proposed solutions for program access problems, such as remote services and transaction management. The Regulations on interactive isolation have not yet provided corresponding solutions, only equinox of eclipse proposed the interface extension point mechanism, but this cannot solve the problem of B/S environment, and there is no solution to the problem of data isolation. SCA is oriented to enterprise applications from the very beginning, but it does not solve the problems of interaction isolation and data isolation.

In addition, for industry ISVs, in addition to these problems faced by enterprise users, they also face other problems. After all, enterprise users only face their own needs, while industry ISVs face the needs of multiple enterprise users and the maintenance problems brought about by customization, in particular, the isolation of Business and Technology (that is, how to maintain a stable upgrade of the technology used to build business components ).

Component container

Since the business components of enterprise applications cannot be supported by the existing component technologies, a new component container is required (of course, as a common developer, we cannot create an open standard component system or maintain a private one independently ). The new component container fully uses the existing middleware technology and adds some new content, including:

1. Component framework, identifying components, component (File) structures, and various technical artifacts.
2. The technical framework provides business-independent technical support to facilitate stable technical upgrade and switch.
3. Running containers using existing middleware technologies, including tomcat, application servers, and database services;
4. Tools, including packaging and deployment tools.

Regarding data isolation, various solutions are mentioned in EIP. The shared database method is used here, that is, each component shares a database, each component only provides database definitions and initial data (like EJB/osgi, the runtime environment is provided by the container ).

Component relationship

There are two types of component relationships: dependency and linkage. Dependencies have been widely recognized in the existing component technology, while linkages are newly created (certainly not the first one, but different people have different names ).

The difference between linkage and dependency is that if component B is associated with component A, component B can run without component A and provide corresponding functions.

Three different technical artifacts (that is, three isolation issues) have different characteristics, as shown below:

1. UI resources (interaction isolation Issues). Dependency refers to the embedding, referencing, and replacement of UI resources, and linkage refers to the addition of UI resources.

2. Application (program access isolation), dependency refers to API/model dependency, linkage refers to messages (traditional messages and JMS messages) and SPI implementation. Both dependency and interaction involve non-functional requirements, including Asynchronization, transaction control, and service time limit.

3. database resources (Data isolation) are dependent on foreign key associations and cascade operations without obvious association relationships.

Here, you need to pay attention to application dependencies and linkages

1. There is a business mismatch problem between SPI and API.

Although component A depends on component B, it does not mean that the services provided by component B fully match the requirements of component. Sometimes the data required by component A requires the composition of multiple APIs of component B. For convenience of development or performance problems required by component, A new interface may be written to component A in component B. Note that this interface is not an API of component B and is only applicable to component.

2. Use SPI integration as much as possible

The SPI integration method is relative to the API integration method. The API integration method is that component B directly calls the APIs and models of other components. In the SPI integration mode (similar to dependency inversion), component B defines the interfaces and models required by component A or the glue layer code.

This is especially evident for ISVs in the industry. For enterprise users, dependency is clear. component A depends on/is linked to component B, but for ISVs in the industry, it is faced with customization issues. Although component A depends on/is linked to component B, however, in a customized project, because the customer already has system C, component A needs to depend on/interact with the customer's existing system C. In this case, the SPI mode is used.

In the open source world, SPI is widely used. Many frameworks define the interfaces required by the framework and provide the glue code for different class libraries to be compatible (with the same function.

Both EJB, osgi, and SCA do not support SPI integration.

3. Dependency and linkage non-functional requirements.

In fact, non-functional requirements exist only during integration. Taking transaction management as an example, except for a few examples, most transactions can only be determined in the processing process (note that EJB is defined on the API in this respect, this design is not suitable for requirements), while the API of component A needs to be called asynchronously in Case 1, and it is common to be called synchronously in Case 2. Even the osgi specification is not processed in this respect.

Customization of components

Customization is only effective for ISVs in the industry. For enterprise users, unless they are faced with different business models, legal regulations, and accounting systems in different countries, there is a need for customization, even so, ISVs and enterprise users have different solutions to the same problem.

Since we have developed the original application in componentized mode, the application customization problem is transformed into the component customization problem. Similarly, application customization means are transformed into component customization means.

Component Framework

After a long time, someone said: this is not to package the UI, Java, and database in the East and East. Then, this is the business component of an enterprise application, what's new? It's not just modular development. It's always the same for everyone. Why bother with a strange term.

Yes, it is to integrate the UI, Java, and database. Many development teams have a set of technical frameworks mentioned in component containers, and there are countless open-source businesses in running containers, the packaging and deployment tools are countless.

This is indeed what we often call modular development. However, modular development is different from component development. modular development only performs logic splitting, while physical (developed system code) is not physically isolated, everything is in the document.

We need something to do. Only a real component framework can implement componentized Development (like the osgi framework ): we need an interface extension framework similar to Equinox to support UI resource dependencies and linkages. We need an integration framework to support application dependencies and linkages, solve all kinds of problems (Business mismatch, SPI integration, and various non-functional requirements). We need a packaging and Deployment Tool (similar to spring DM) provides deployment of UI resources, applications, and database definition resources (Spring DM provides deployment capabilities based on Web Resources ).

Other problems

Component applications that adopt the B/S environment under J2EE still face a problem, that is, the existing servlet specification only allows one web. XML does not support defining private filters and servlets for components. However, this problem is not very serious. The existing technical framework already supports a simple web. XML, and the new servlet specification has allowed multiple web. XML.

Distributed deployment and cluster deployment are not a problem. There are many methods and technologies based on applications, so there is also a method based on components.