In the context of software, service is a computer message invocation that is sent over a telecommunications networking protocol connection (e.g., TCP/IP or UDP/IP socket) to a remote computer. This message invocation has the intent of stimulating an application or multiple applications that are sitting on remote machines to perform some operation. That is, the remote application, upon receipt of the requested message, is expected to parse and process the message accordingly. And then it may either simply process the message and return no response, it could return a response message to the invoker. Sometimes, the application may even forward that message to another systems for processing.
Based on the above definition of a service, we may have several different communication protocols that could used for the transfer of the request and response service messages between the remote computing ends. Below are some common communication protocols that have been used in more recent computing:
- REST over HTTP
- SOAP over HTTP
- CORBA
- Some private messaging protocol over HTTP
- Some private messaging protocol over TCP/IP socket
- HL7 used in the healthcare arena
- SNMP used in the network management arena
CRUD
The essence of any service is based on the CRUD terminology. CRUD stands for Create, Read, Update and Delete. Most of the service APIs fall into one of the CRUD categories. For example:
- Create: AddAccount, CreateAccount
- Read: GetAccount, ReadAccount, RetrieveAccount
- Update: SaveAccount, UpdateAccount, ModifyAccount
- Delete: DeleteAccount, RemoveAccount
As we can see from the CRUD message APIs above, there are many different ways that the same service message can be named. The service API designer should therefore be careful to follow a consistent approach when naming the APIs. Otherwise, we may end up with several different names that mean the same thing (e.g. Create/Add or Get/Read or Delete/Remove).
Service Semantics and Behavior
A service should be well defined and understood, which means that its semantics and behavior should be clearly stated.
- Semantics: It consists of the all the wording that is used to define a service. For example, the service message name, message attributes names and types, and any type of errors (or exceptions) that might be incurred as a result of invoking that service. For example, when creating a customer login, the semantics might be defined as follows "createCustomerLogin(username, password, email), where the username, password and email are all text data defined by certain constraints; e.g., number of characters and character encoding scheme.
Notice, that in the above semantics we are not concerned about the underlying technical implementation of that service. In the "service contract" document, we would then add a section that provides specifics of the semantics implementation. In that case, we would define request/response messages using a WSDL language (SOAP), or use the IDL language for a CORBA service. For RESTFul, we would implement the service semantics in terms of its URI with HTTP header/POST body (request) and corresponding HTTP headers/body (response) along with the media type (e.g., JSON or XML).
- Behavior: It consists of the expected actions that might occur as a result of invoking a given service message. In this case, we want to elaborate on what activities might occur as the outcome of invoking the service. For example, in the case of creating a customer login, we would elaborate that an account with a unique user name is created on a given computer system. Or in multiple computer systems, depending on the business case being solved.
Characteristics of Good Services
A service should, foremost, address a specific business need. A service is therefore a means to an end; that is, it should address and solve a business requirement. Throughout the design and implementation of a service, the implementer should keep in mind the business audience who will consume that service, and aim the naming of the service API to that business audience. That is, service request/response messages, attributes, and resources should have names that are meaningful and aimed at the business audience who will be consuming that service API. Furthermore, the service API should be, whenever possible, validated with the business parties; that is, the programmers or business analysts who will be ultimately using that service API. The goal here is to ensure that the service API is not only well aligned with the business needs, but that it is easy to use and be programmed with. The service API designer or implementer should refrain from trying to map a backend application API to a service API.
A side effect of using service enabler infrastructure computing (e.g., ESB, enterprise service buses) is the use of what is called "technical services". These type of services are used to collect technical information, such as performance analytic, logs, errors and other troubleshooting information from the underlying service enabler infrastructure.
Service Patterns
By service patterns, it is meant good practices and tips that are followed in the market to name a few of the service messages APIs and protocols.
Resource API Pattern
The Resource API Pattern is implemented by RESTFul web services. That is, the API is operating on a given resource (e.g. Account, User, Report, and so on). And the CRUD behaviour is leveraged by the underlying HTTP Protocol. That is, for HTTP the CRUD is as follows:
- Create: Post
- Read: Get
- Update: Put
- Delete: Delete
RPC API Pattern
The RPC (Remote Procedure Call) ..
Rubens Gomes
