Enterprise Service Bus requirements

??

Enterprise Service Bus requirements

 

Enterprzise Service Bus

 

1. Main Functions of ESB

ESB mainly solves the problem of mutual calls between multiple terminals and multiple systems, reduces coupling between systems, and adds maintainability.

2. Core requirements of ESB

The core requirements of ESB include service calling and data adaptation, service management, service security, and service monitoring.

2.1 service calling and data adaptation

Supports inter-system service calls. Inter-system data protocols are independent of each other. Through data adaptation, You can actively implement the transmission and conversion of system data and ESB data.

Supports a single service call and multiple service calls (combined service ).

 

2.2 Service Management

The service management function mainly includes service injection, publishing, version number control, and service information maintenance.

 

2.2.1 Service Attributes

The business system needs to communicate with other business systems. It is a service provided by the ESB platform for data interfaces. before using the service, the business system must note that, and within the validity period of the service.

 

2.2.2 service Injection

The service must be noted first to record the specific service description information.

The service is centrally managed by the Administrator. The functions of the Service include adding, modifying, deleting, and querying.

 

2.2.3 service announcement

After the service is published, you can provide external questions.

You can change the status of a service to determine whether to publish the service. You can also control the validity period of the service over time periods (this is mainly for the timeliness service provided by the platform to third-party companies ).

 

2.2.4 service Version Control

Supports the control of multiple versions of the same service.

Because of the development progress of the business system and other reasons, the data structure or data source of the data interface version number is different. The service version number is controlled by the Administrator. The version number name is filled by the Administrator. The service version can be added, modified, deleted, or queried.

 

2.2.5 service rule Cache

To improve the efficiency, when the system initializes, it reads the routing relationship from the database's routing relationship table and writes its routing relationship table information to the cache by defining the cache interface.

When the information of the routing relationship table changes, manually send a notification of the change to the cache, read the service routing relationship table again, and refresh the service routing cache.

 

2.2.6 Service Information Management

Service Information addition, deletion, modification, and query, and information classification management.

Service information classification can be a tree structure of multi-level classification structure.

 

2.3 protocol conversion

Data exchange between different business systems

Different business systems may use different protocols to transmit messages. The ESB platform provides different interface types to adapt to different entry protocols or egress. The protocol conversion is encapsulated within the ESB platform, you do not need to make any changes to the access system. The supported protocols include WebService and HTTP.

 

2.4 Service Security

Establish a sound security issue mechanism to ensure security.

The service data is used as the basis to form the data flow route required by the business system. Each request must be inferred whether the request is legal, otherwise, the response code indicates "do not agree with the request ". Authentication required for access requests.

2.4.1 verification process

Authorization Verification

Verify the validity of the URL parameter number _ LIC value. _ LIC and _ valid are generally provided by the service processor, which is equivalent to the user/password concept.

Signature Verification

Verify the validity of the URL signature number_sign value to prevent interception and tampering during data transmission. For the validation rules for the _ sign generation, see the following.

Business Data Verification

For specific service-level verification, read service route relationship Verification Based on the configuration of service routing rules.

 

 

 

2.5 service monitoring

Monitors the call of each service and writes monitoring logs to provide data support for future service call analysis and optimization.

Service monitoring records the attributes related to the scheduling process of each service, so that the system can be upgraded and transformed to provide reliable data analysis.

 

2.6 non-functional requirements

2.6.1 High Performance

Supports high-volume service call requests and establishes good caching and queue mechanisms.

Creates a high-performance data scheduling queue. Define a Job Scheduling Queue (list <workitem>) and use a new thread to allocate resources to avoid congestion. Visually set the number of waiting queues or the number of waiting queues to automatically adapt (auto ).

Set whether to enable the cache and set the cache lifecycle for different services. According to the scheduling conditions of the service, the data to be cached is recorded in a cache group (stored in hastable) type, which is conducive to improving the indexing efficiency.

 

2.6.2 scalability

It has good scalability and provides support for future function control.

 

2.6.3 maintainability

Provides visual and flexible configuration management.

Create an ESB console to control the functions of the entire ESB platform.

 

3. Common functional components

The ESB provides good support for unified service access. On the ESB, it further accesses and encapsulates many other general functional components, which can be developed less repeatedly by various systems.

3.1 system logs

3.1.1 business logs

Supports multi-system and multi-service, and actively performs table sharding based on the data volume (by month or by day ).

 

3.1.2 maintenance log

Supports multi-system and multi-service, and actively performs data sharding based on the data volume (monthly ).

 

3.1.3 Error Log

Supports multi-system error logging, and actively performs data sharding based on the data volume (by year ).

 

3.2 scheduled tasks

Allows you to schedule tasks driven by cycle time or specified time to trigger the running of specified services.

Supports visual Configuration Management of scheduled tasks.

For example:

Call the report service on the first day of every month to generate a monthly operation report.

 

3.3 Event Management

You can monitor the specified business type and trigger the specified service when a business occurs.

Supports visualized event configuration management.

For example:

When a new student archive is approved, the user calls the service and opens a member account for the student.

Collect the business requirements of various business systems, determine the incidents to be formulated, and develop the incidents later. Events are extended based on components, and process records generated when an event is triggered are added to facilitate future statistics management and troubleshooting.