Calling it “services”

I do believe that a language does form the reality we experience. It express the meaning of truth.

Service is an architecture term which confuses people about what they doing now. And believe, that can lead us to complexities over complexities. So understant and diferentiate responsabilities is a key approach to avoid system complexty.
I’ve seen many folkes, especially the newbie (with less than 3 years with distributing computing) calling “Service” any business logic and data access package that they build.

The image below shows us a holistic view about a hierarchical packing style which most applications are built.

What makes your service be a business logic or simple data access layer from the past architecture style? A simple word: coupling.

If your project builds the service together with the requestor application, this means that this service is coupled to the requestor application. In order to run the requestor application, the service must be in place. Otherwise they won’t work and doesn’t matter if you are using interfaces and pattern like MVC, MVP, and object injection in anyway. The project structure is organized but still monolithic.

Service means a logic (data access or business algorithms) that can be exposed to any consumer either using web services standards or with queuing mechanism.

There are different services model which can be built in a SOA ecosystem.

1. Application service
   • A generic category used to represent services that contain logic derived
     from a solution or technology platform. Services are generally
     distinguished as application services when creating service abstraction
     layers.
2. Business service
   • A generic category used to represent services that contain business
     logic. When establishing specialized service layers, services that fall
     into the business service layer are collectively referred to as business
     services. However, individually these services are classified as
     entity-centric or task-centric business services.
3. Controller service
   • A service that composes others. Variations of this model exist,
     depending on the position of the controller in the composition hierarchy.
     The parent controller service can be classified as the master controller
     and a service that composes a subset of a larger composition can be
     labeled a sub-controller.
4. Entity-centric business service
   • A business process-agnostic variation of the business service that
     represents one or more related business entities. This type of service is
     created when establishing a business service layer.
5. Hybrid service
   • A service that contains both business and application logic. Most
     services created as part of traditional distributed solutions fall into this
     category. When organizing services into abstraction layers, hybrid
     services are considered part of the application service layer.
6. Integration service
   • An application service that also acts as an endpoint to a solution
     environment for cross-application integration purposes.
7. Integration service
   • An application service that also acts as an endpoint to a solution
     environment for cross-application integration purposes.
8. Integration service
   • An application service that also acts as an endpoint to a solution
     environment for cross-application integration purposes.
9. Process service
   • A service that represents a business process as implemented by an
     orchestration platform and described by a process definition. Process
     services reside in the orchestration service layer.
10. Task-centric business service
    • A business process-specific variation of the business service that
      represents an atomic unit of process logic. Task-centric services are
      different from process services in that the process logic is provided by
      the underlying service logic, not by a separate process definition.
11. Utility service
    • A service that offers reusable logic. This category is primarily intended
      for the classification of solution-agnostic application services. However,
      it also can be used to refer to reusable business services.
12. Wrapper service
    • A type of integration service that encapsulates and exposes logic
      residing within a legacy system. Wrapper services are commonly
      provided by legacy system vendors and therefore frequently introduce
      non-standardized interfaces.

That was just an overview I’ve taken from Tomas Erl’s book Thomas Erl – Service-Oriented Architecture (SOA) – Concepts, Technology, and Design (2005). There’s no doubt that you should read the series so you can fully understand what SOA means.