Spring and SOA

In the object-oriented method, the function of the system is to implement the object through a group of mutual collaboration objects. The collaboration between objects is achieved through the mutual association between objects. This association is usually represented by the reference of objects or interfaces. In the early object-oriented methodCodeIt is obtained by encoding. the user of the object is responsible for creating and clearing the object, and the method code of the object is called between them. This method binds the creation and cleanup of business-independent objects and Business Code, so that the objects are closely coupled, making it difficult to test and reuse objects. Spring abstracts the association between objects and the creation and removal of objects in the IOC mode and puts them in a public container to complete these business-independent operations.

In spring, the relationship between objects is defined in a configuration file that can be recognized by a spring container. To use objects, apply for an object reference from the spring container, the spring container creates an object instance based on the configuration file, creates (or obtains) other associated objects referenced by the object, and then returns the object reference to the applicant. For applicants, complicated Association processing between objects and object creation are blocked by spring containers, and the code becomes more concise and clear. When the association between objects changes or replaces the associated objects, you only need to modify the configuration file. You are not allowed to modify part of the code for applying to use the object, which improves the maintainability of the system.

Now let's take a look at the situation of SOA. SOA uses services as basic elements to abstract the system. The service granularity is coarse than the object. A service usually requires a group of objects to collaborate with each other to implement its functions. Similarly, system functions are not completed by a single service. Generally, a group of services need to collaborate to complete a business function. So how does SOA assemble services? The answer is ESB (Enterprise Service Bus ).

In the SOA method, services are registered in the ESB, And the ESB provides unified service use interfaces. Collaboration between services is also defined in ESB. Currently, commercial products provide visual interfaces to design the call relationships between services. Generally, several services can be combined into a business process. You can dynamically decide the service to be called next based on the data provided to the service. This process enhancement function is not available for spring containers. Currently, you cannot determine which object to create by initializing data in spring containers. This is also related to the degree of autonomy of objects and services. services have a higher degree of reuse than objects and can be combined into business processes more easily.

The service user applies to the ESB. The service user is completely transparent to the combination of internal services in the ESB. As long as the access interface remains unchanged, changes in the ESB will not cause any additional modifications to the service user, this effectively achieves loose coupling between service users and providers.

Both spring and SOA abstract business-independent infrastructure functions and put them in a public place for processing. This simplifies the use of objects and services and allows code to focus more on business issues. In addition, the object and service are effectively decoupled, making it easier to reuse and test objects and services.