Comparison Between so and OO

This article is translated from service-oriented architecture: Concepts, technology and design by Thomas ERL. Note that the title of this section is "service-oriented and object-oriented", rather than "service-oriented to object-oriented ". The difference is that the relationship between these two ideas is not a matter of competition. In fact, object-oriented programming is usually used to construct the encapsulation of application logic in Web Services. However, what is the fundamental difference between object-oriented programming methods and service-oriented methods is worth exploring. Understanding their differences helps you put them together. The following lists the comparison of the two methods in design. (Although the use of the term "logical processing unit" can cause confusion in comparison services and objects, service-oriented design is based on services and object-oriented creation is centered .)

• Service Oriented emphasizes the loose coupling between logical processing units (services. Although object-oriented programming supports reusable and loose coupling, it is mainly based on predefined dependency classes and produces tight coupling with logical processing units (objects.

 

• Service-oriented coarse-grained interfaces (service descriptions) are encouraged. Therefore, each communication unit (Message) contains as much information as possible to complete a given task. Object-Oriented Programming fully supports fine-grained APIs (APIs). Therefore, communication units (RPC or local API calls) can execute tasks of various sizes.

 

• The range of service-oriented logical processing units (services) can be large. The logic processing unit (object) in the object-oriented model tends to be smaller and clearer within a certain range.

 

• Service-oriented promotes the creation of unknown behaviors of logical processing units (services), which are behaviors caused by intelligent communication units (messages. Object-oriented encourages logical processing and data binding to generate very intelligent units (objects ).

 

• More service-oriented logic processing units (services) are designed to keep them stateless. Object-oriented Data and logic binding are encouraged, so stateful units (objects) are generated ). (However, more component-based design methods have recently deviated from this trend)

 

• A loosely coupled combination of service-oriented logical processing units (services. Object-Oriented systems also support combination but tend to inherit from logical processing units (objects), which leads to tight coupling.

The above section compares service-oriented and object-oriented data from the aspects of coupling, interface granularity, focus, and status. Next we will compare the design principles of the two methods.

Of course, there are still many existing concepts and theories about object-oriented services. The following table compares the General object-oriented principles with the previously discussed service-oriented principles.

 

Service-oriented principles	Object-oriented Principle
Service Reuse	Object-oriented is usually used to create reusable classes. The object-oriented principle of modular decomposition is the design method of applications.   Related principles, such as abstraction, encapsulation, interface and implementation logic separation. Service reuse is a continuation of this goal.
Service Contract	The requirement of a service contract is similar to that of an interface used to build an object-oriented application. The interface provides a method to extract class descriptions, which is very similar to the definition of WSDL. Like the "WSDL precedence" method encouraged by SOA, the "interface precedence" method is also considered as the best object-oriented practice.
Loose coupling of services	Although the creation of interfaces decouples the class from the class user to a certain extent, coupling is the main feature inherited from the object-oriented service.   Compared with the service-oriented design method, inheritance and other object-oriented principles lead to tight coupling between logical processing units.
Service Abstraction	The object-oriented abstraction principle requires a class to provide an interface to the external world and use this interface to define the class. Encapsulation supports this method by establishing the concept of information hiding. Any internal logic of the class exposed through the interface cannot be accessed by the outside.   Service abstraction can basically reach the abstraction and encapsulation of objects. Its goal is to hide the internal details of the service. Therefore, only the service contract can be obtained. service requestor only cares about the service contract.
Service combination	Object-Oriented Systems Support Association concepts, such as aggregation and combination. In a loosely coupled context, these concepts are also supported by service-oriented methods.   For example, you can assemble composite services into service hierarchies by means of the same object hierarchies.
Service autonomy	Autonomous features play a more important role in service-oriented design than in object-oriented methods. In service orientation, the independence between logical processing units can be achieved by leveraging the loose coupling between services.   In object-oriented design, cross-object references and inheritance-related dependencies support a low degree of Object-level autonomy.
Stateless Service	Objects composed of classes and data are inherently stateful. Stateless services tend to deviate from typical object-oriented designs.   Although stateful services and stateless objects can be created, the stateless principle is more emphasized in service-oriented systems.
Service Discovery	Designing consistent and self-describing class interfaces is another object-oriented best practice that can improve the identification and differentiation of logical processing unit methods. These features also allow classes to be more easily discovered. Discoverability is another principle emphasized in service-oriented examples. It encourages service contract interaction to support discoverability in design and operation.

 

We can see that object-oriented and service-oriented are not competitors. Service-oriented is clearly based on object-oriented in many aspects. Currently, typical service-oriented solutions are composed of services (following the principles of service-oriented) and object-oriented components. In a rational design, each principle can be properly handled and supplemented.