Shulou(Shulou.com)06/01 Report--

This article shows you what application deployment methods big data reporting tools have, the content is concise and easy to understand, it can definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

Before we answer this question, let's take a look at what forms the reporting tools have so far. Although most of the domestic reporting tools are developed in java language and their functions are basically the same, there are still differences in form.

The difference is that some manufacturers always position the report as a general tool middleware product. Because of its characteristics, it is relatively simple and flexible for integrators to integrate with their own products or projects. This is also a position that most integrators want.

In addition, some manufacturers, unwilling to earn only the money of the tools, want to package the report into a general platform, which can earn not only the money of the tools, but also part of the platform. The advantage of this form is that some end-users with simple needs can use it directly. The disadvantage is that many projects are highly customized, and the unified platform is basically unusable, and the integration will be a headache, because I don't know how to deploy the integration because I am given an extra system.

Now that we understand the product shape, let's take a look at how the reporting tools can be deployed. To sum up, there are two types: integrated deployment and stand-alone deployment. Explain the following two modes first:

Integrated deployment is to embed the report into the existing system, exist in the form of modules, and uniformly use the platform functions such as login, organizational structure, permissions and so on. If the integration deployment is subdivided, there are two cases: in-depth integration and report integration as a service.

In-depth integration is to put the report and the existing system together, physically in a single application.

And service-based integration, the report will be separated from the existing system, deployment, physically is two (or more) applications, report service interface (usually url) is called by other system integration, popular that is to hang the report link in other systems.

As a service integration, it actually involves the independent deployment of reporting tools. Independent deployment can also be seen from the literal meaning that * *, * * reports are separate from other applications, and they are independent, deployed separately, and do not interfere with each other. If you need to call their resources, you will use cross-system linked calls.

So, which deployment method is suitable for the above two types of reporting tools?

Positioning as middleware is suitable for seamless integration, because their positioning is for development-oriented integrator users to be integrated, whether for products or projects, reports can be embedded into the system.

The advantage is obvious, like a nail, which piece of wood is nailed to, it belongs to the board, as a whole is not separated, unified management and maintenance. In addition, the integration is also relatively simple, take java products as an example, basically copy some jar files, and then place or merge some configuration files, and then complete.

The only drawback is that the report must be consistent with the existing system development language.

Can't middleware products be invoked as a report service? In fact, some manufacturers also take this into account for their customers, in addition to providing middleware reporting tools, they will also bring a simple reporting platform, not as a selling point, free to use, or even open source, to facilitate rapid development.

Basically, reports made into the platform can only be deployed independently, because such products basically do not provide a mode of module split and integration (even if provided individually, they will charge high fees as customized services). It is also very troublesome to "dismantle" yourself. I don't think I can understand it.

Advantages have been mentioned at the beginning of the article, can quickly have a complete system, especially the simple requirements of end-users like it, the product also appears to be more functional, more dazzling.

However, it is best for this kind of product to be deployed and used independently. When it comes to cross-system calls, almost all of them need to adapt to unified authentication, organizational structure synchronization, permission synchronization, and so on. This work takes a lot of effort. In general, it is to provide a bunch of interfaces for self-implementation. For the integrator, the integration is a big worry.

To sum up, different products have different adaptation scenarios. When we choose, we should decide what we want according to our own situation. If it is a middleware requirement, do not require the platform function, which is superfluous and cumbersome when embedded in integration. If it is a complete system requirement, then do not consider embedded integration, but also from the overall consideration of the system, you can choose a perfect platform or transformation based on the open source platform.

The above content is what are the application deployment methods of big data reporting tools? have you learned the knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.