Services — A shallow dive
In this article, I’ll show you a general and simplified view related to services-oriented development and how that’s something wonderful allowing us to reach out high levels of standardization and reuse on our projects. Here, the focus will be kept only on the advantages of this concept. I hope this content may be useful to you, providing the basics about this vast subject. Let’s get started!
What is a service?
Services are one of the components present in the business layer that allows us to open our application to the external world exposing our business rules. According to some authors, we can define a service as a unit of exposed functionality by means of a standard. The cohesive union of these units into a single application characterizes the SOA — Service Oriented Architecture term. Figure 1 presents this idea:
Overall, the application shown in Figure 1 is composed of a set of services connected to each other. Services also may be imagined as software blocks that perform a specific function. These functions are executed by means of its invocation through interfaces that establish what we name as “contracts”.
We must be aware that the SOA approach isn’t a methodology, nor a technology, but an architecture concept which promotes the integration. Another important concept that’s inherent in services is the presence of consumer and provider terms — the provider exposes the service and the consumer, in turn, uses it. The consumer can be an application or even another service.
In the corporate context, SOA architecture can be faced with a model of planning and strategy by IT area following directly the business goals. Companies needs to answer quickly and effectively to the trends of the market, therefore, the applications must have enough flexibility to go along this. In this sense, a service-oriented architecture comes to spread the reuse and the interoperability between software assets.
The service layer
The services establish a boundary between the presentation layer and the business layer. The communication among these layers is performed with the use of DTOs (Data Transfer Objects). However, in some cases, there is no presentation layer based on the concept of a graphical user interface. In this situation, the boundary is the service layer itself which may interact with other systems becoming a service provider.
When the presentation layer is available, the services define an interface for this and then, perform the actions according to the info they got from the user layer. Figure 3 presents the location of the service layer into .NET architecture:
Features of a service architecture
At this point, I’ll describe some of the main features that may be found in an SOA architecture, which are:
Encapsulation: Services omit the business rules and separate responsibilities. Thus, we can protect and at the same time delimit clearly the content of our components isolating the business rules of the user interface for instance. Besides that, a service must not aware about the internal implementation characteristics of other services.
Standardizing and Reuse: Services are designed to be reusable by means of consumption interface availability. The interfaces are like an “input/output door” of an application through which we can provide or consumption of business.
Figure 5 shows us an application in which services may be consumed by users through a presentation layer or by external systems. Besides that, the same application may be consuming services from other systems in its data layer. This way, we can have an application that can be a provider or a consumer of services simultaneously.
Besides reuse, this idea allows us to get decoupled software with the separation of concerns.
As an example of standardization, let’s take the Google Maps service to calculate the distance between two points on Earth surface. For that, we need to provide the coordinate points for Google’s tool and it will perform all processing returning us the approximate distance between the two points. The most interesting part in this context is that everything is executed in a way that the consumer doesn’t need to access Google’s database or have any knowledge about the calculation code used for it. The idea is simple: It’s already done, just use it! :D
Now, let’s dive into a scenario in which things get a little messy… Imagine if our application needed to access the Google database directly to get the coordinates of each point and then, implement your own calculation code? What could happen!? The answer is simple: chaos. To illustrate that, let’s say that an application A chooses the Haversine method whereas an application B simply applies the Pythagoras approach to perform the distance calculation between the two points provided. As we know, the Pythagoras theorem tends to provide considerable errors as the distance between the points increases because it doesn’t consider Earth’s curvature.
In conclusion, this scenario could be avoided if we were using something standardized and trusty services like Google Maps, Here Maps (Nokia) or Waze, etc. Of course, some applications may need to perform its own distance calculations due to some peculiarity related to its operation.
Platform Independency: Services has its design based on multi-platform and multi-protocol support. That is, we may have services directed to IoT or mobile platforms supporting the standards SOAP or REST.
Interoperability: Services expose the information flow into a consistent way using contracts. This improves the factors related to interoperability and operation since we have a standardized protocol to access its resources, that is, access driven by solid contracts. To get a better picture, let’s take a look at Figure 7 and pay attention to the communication process between two hypothetical services:
When we define a service, one of the first things that we do is choose the contract type with which we going to expose our information. This contract is the protocol used during the messages exchange. In Figure 7, is necessary to specify some type of contract (as HTTP or MQTT) so that the communication process works. The contract pattern defines directly the reusability level once it is the way how the services talk to each other or with other applications.
Flexibility: An SOA approach provides us the possibility to write the components present in our architecture using whatever language or platform we deem most convenient. We could, for instance, write components that would deal with user interfaces using JavaScript or Ruby whereas components that have critical performance requirements could be written using C or Java.
Mandatory features of a service
The three mandatory features for a service are:
Concurrency: It doesn’t make any sense to develop a service that does not have concurrency support concerning its client’s invocation. A service must be able to handle multiples connections or recalls.
Hardiness: Services must be able to isolate errors to avoid that this causes their unavailability. Errors can not spread or cause majors impacts in the service itself. Finally, services would not need any client configuration for its behavior to be changed.
Security: A service and its client need to use safe communication and there should be some way of customers authenticate in the service. Clients may provide credentials in the messages for the service to allow the incoming request. An example of that would be the utilization of web-tokens as part of an authentication process.
Optional Features of a Service
Interoperability: The service should be designed taking into consideration that multiple clients, regardless of technology, can perform requests — a scenario of multiple contracts.
Availability: The service should always allow their consumption by clients by means of requests. If the service has long periods of unavailability, the clients should treat that situation which will increase the complexity of coupling.
Performance: The client should not wait for a long time so that the service starts the request processing. If the service takes a long time to respond, the client must be notified that your request is being processed.
Among all of those optional and required features, I highlight the focus in the idea of “weak coupling” that must exist between the services which in practice means to reduce the impact of the modifications and failures in the environment of the system.
Categories of Services
The SOA standard defines some basic types of services to perform specific activities. Figure 11 shows us a closer example of reality which we can see various applications constituted by various services that communicate with each other.
Obs.: I guess from this point the intention of the article cover photo is clear for you. :)
Entity Service: The entity services include entities of customers such as purchase order, insurance policy, invoice of order, ordered date, etc in which you can perform CRUD operations on the entities. These services provide information about the business process stored in the database.
Task Service: The task service adds the business logic to other services and due to its focus on business entity, it contains low amounts of reusability. Task services provides operations on more than one entity such as customer purchase order, creating purchase order number, validating customer details, etc. A service is called a task service when it needs to access multiple entities.
Utility Service: The utility services are technology-oriented services that are used to build larger and higher level services and provides other capabilities that are unrelated to the message transfer. The utility services provide reusable functions such as event logging. These services contain small, closely packed services that are used as building blocks in a service-oriented system.
Proxy Service: The proxy services contain the services which act as a connection between members of the service-oriented system and conflict subsystem. The device and process services lie under this type of service. Sometimes services that are defined under proxy services are called gateway services.
Device Service: The device service is a kind of proxy service that is referred to as a hardware device and is used to communicate between other services. The device service does not include the API which is not well suited with the service-oriented system.
Process Service: The device service is also a kind of proxy service that acts as an interpreter between application and service-oriented system members. This service creates and arranges the application services to implement the business processes.
Business Service: Business services are also known as controller services which provide business functions for the completion of the business process and are flexible services that change the business needs. These services are connected with business applications, which in turn, automate the business process like customer service management, product shipping and so on..
Conclusion
This was a brief and shallow discussion about a vast and complex subject which is the service-oriented architecture. Nevertheless, we could notice that the adoption of this methodology allows us to establish a high level of decoupling, reusability, standardization, and security into our applications. Among all these terms, I believe that reusability is what deserves more highlight. From the moment that reusability is applied, we are able to build a lot of services already established and at the same time, it provides additional services requested by the company.
Thinking in terms of service, you will effectively think about what to do so that your business becomes self-sustainable. They define clearly the operations and protocols available, as well as, become a central point to perform validation and authentication for the consumption of our business logic. By means of its flexibility, the SOA architecture provides us greater agility in the workflows, an improvement of reuse and a long-time life to the existing applications.
Translations
Portuguese: https://medium.com/@rogerio_oliveira1992/uma-breve-introdu%C3%A7%C3%A3o-aos-servi%C3%A7os-20b10e2833be
References
NITIN, Kumar — Enterprise Benefits on Service Oriented Architecture — SOA. Available on: https://dzone.com/articles/enterprise-benefits-service
SOA — Service Categories. Available on: https://www.tutorialspoint.com/soa/soa_service_categories.htm
ESPOSITO, Dino e SALTARELLO, Andrea. Microsoft .NET — Architecting Applications for the Enterprise — Microsoft Press 2014.
