Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Differences between a customer class and a customer service

What is the difference between a customer class and a customer service? For me, even the customer class can process a request from the outside to add a customer, check his or her credit history, etc., using its own methods. Please correct me if I am wrong. I am totally confused!
The simplest way to describe the difference is that services are remote, classes are in-process. But this is only the tip of the iceberg.

Because services are remote, the only relationship that needs to exist between a service consumer and the service itself is an agreement on the "wire protocol" syntax and semantics -- what format are the messages in, and what do the messages mean. This gives a service freedom to be implemented in any programming language, on any operating system, accessing any data sources it chooses. Even when changes occur, there is no impact on the consumers, provided the service can still honor the communication agreement. Thus, services have a tremendous amount of freedom from the applications that use them.

In contrast, a class is built to run on a specific "target environment" -- whether it is a native machine instruction set or a virtual machine such as the JVM or CLR. Your application must be built to the same target environment to use the class directly, and the class will run in your process space sharing resources with your application. Typically, it also means that your application will directly "contain" the class (from the perspective of deployment), which has versioning implications. It also means that your application is usually in charge of providing access to the data sources the class needs. So, by their nature, classes are tightly coupled to the applications that use them.

There are many practical architecture implications of the difference between classes and services. These include differences in the granularity of operations that can be supported efficiently "across the wire" versus in memory, and the implications for state management and reliability to name a few. And, while there is significant commonality in how to design for reuse, many of the specific design points and trade-offs are different.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.