Service-orientation and object-orientation (Part II)
Having now covered the fundamentals behind service-orientation principles, we can continue the discussion we began in the Service-orientation and object-orientation (Part I) section from Chapter 4.
Those of you familiar with object-oriented analysis and design probably will have recognized a similarity between a number of the service-orientation principles discussed and the more established principles of object-orientation.
Indeed, service-orientation owes much of its existence to object-oriented concepts and theory. Table 8.1 provides a look at which common object-orientation principles are related to the service-orientation principles we've been discussing.
|
Service-Orientation Principle |
Related Object-Orientation Principles |
|---|---|
|
service reusability |
Much of object-orientation is geared toward the creation of reusable classes. The object-orientation principle of modularity standardized decomposition as a means of application design. Related principles, such as abstraction and encapsulation, further support reuse by requiring a distinct separation of interface and implementation logic. Service reusability is therefore a continuation of this goal. |
|
service contract |
The requirement for a service contract is very comparable to the use of interfaces when building object-oriented applications. Much like WSDL definitions, interfaces provide a means of abstracting the description of a class. And, much like the "WSDL first" approach encouraged within SOA, the "interface first" approach also is considered an object-orientation best practice. |
|
service loose coupling |
Although the creation of interfaces somewhat decouples a class from its consumers, coupling in general is one of the primary qualities of service-orientation that deviates from object-orientation. The use of inheritance and other object-orientation principles encourages a much more tightly coupled relationship between units of processing logic when compared to the service-oriented design approach. |
|
service abstraction |
The object-orientation principle of abstraction requires that a class provide an interface to the external world and that it be accessible via this interface. Encapsulation supports this by establishing the concept of information hiding, where any logic within the class outside of what is exposed via the interface is not accessible to the external world. Service abstraction accomplishes much of the same as object abstraction and encapsulation. Its purpose is to hide the underlying details of the service so that only the service contract is available and of concern to service requestors. |
|
service composability |
Object-orientation supports association concepts, such as aggregation and composition. These, within a loosely coupled context, also are supported by service-orientation. For example, the same way a hierarchy of objects can be composed, a hierarchy of services can be assembled through service composability. |
|
service autonomy |
The quality of autonomy is more emphasized in service-oriented design than it has been with object-oriented approaches. Achieving a level of independence between units of processing logic is possible through service-orientation, by leveraging the loosely coupled relationship between services. Cross-object references and inheritance-related dependencies within object-oriented designs support a lower degree of object-level autonomy. |
|
service statelessness |
Objects consist of a combination of class and data and are naturally stateful. Promoting statelessness within services therefore tends to deviate from typical object-oriented design. Although it is possible to create stateful services and stateless objects, the principle of statelessness is generally more emphasized with service-orientation. |
|
service discoverability |
Designing class interfaces to be consistent and self-descriptive is another object-orientation best practice that improves a means of identifying and distinguishing units of processing logic. These qualities also support reuse by allowing classes to be more easily discovered. Discoverability is another principle more emphasized by the service-orientation paradigm. It is encouraged that service contracts be as communicative as possible to support discoverability at design time and runtime. |
As it stands today, object-orientation and service-orientation are not necessarily competitive paradigms. Service-orientation clearly has several roots in object-orientation, and typical contemporary service-oriented solutions will consist of a mixture of services (that adhere to service-orientation principles) and object-oriented components. With a balanced design, each set of principles can be properly positioned and leveraged to complement and support each other.
|
SUMMARY OF KEY POINTS |
|---|
|