So what is a service? The best way to understand what a service is, is understanding why you would need a service. Typically, there are a lot of different applications being used in an enterprise. Sometimes this is by design; for example, because a specialized functionality is needed that is not implemented in the ERP system. In other cases, legacy systems are not replaced when implementing an ERP system, simply because they do their jobs well. Whatever the reasons, these or others, the result is the same: a growing number of different applications.

One of the problems with these applications is that they are likely to have been built using different technologies. Because they speak a different language, it makes them unable to communicate with each other. This is a problem that services address by providing a means by which applications can communicate, independent of their technology. They achieve this by adhering to standards and protocols so that, in essence, they start speaking the same language.

A service should have many of the same qualities as modern applications. Applications should be modular, components should be reusable, and everything should be loosely coupled. These principles also apply when developing services. Your services should have a well-defined functionality and should be able to autonomously execute that functionality without interaction with other services.

Services should also be abstract. By this we mean that other applications should not have to know the inner workings of the provider in order to use the service. This can be attained by hiding details such as how data is stored, what technologies are used, and how the business logic is implemented. Abstraction is not an end goal, but a way to achieve loose coupling and reusability.

A service is also self-describing, meaning it can provide other applications with metadata about itself. This metadata describes what operations can be used and what the input and output is. In the case of Microsoft Dynamics AX, this information is published using the Web Service Description Language (WSDL).

All of these qualities make services usable in a Service-Oriented Architecture (SOA). In an SOA, services are published and made discoverable. Services are then composed to create loosely coupled applications.