What are services and SOA?
So what is a service? The best way of understanding what a service is, is by 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.
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.
Example implementations
To make the previous explanation about services more concrete, we will take a look at three very different scenarios in which services can be used.
Microsoft provides an API for Bing Maps and Search that is available to developers in various ways, including a web service. Developers can use this service for things such as calculating a route between two addresses, locating an address on a map, getting search result for a certain query, and so on.
It's not hard to imagine this service being used in a logistics application, for example, to calculate the most efficient route for delivering goods to customers.
Let's look at a scenario where a mobile application has to be developed for Microsoft Dynamics AX 2012. Even if your mobile application contains business logic to work offline, data will have to be sent back to the Application Object Server (AOS) at some time. The mobile application could use services to execute business logic and send data to the AOS when a network is available.
A mobile application can also be built without containing business logic, in a way that it only renders a Graphical User Interface (GUI). In this scenario, the application will have to stay connected to the AOS over the network because the AOS will drive the application and tell it what to do using services.
You can use services in an SOA to model business processes. When all requirements for the business processes are available as services, it is possible to compose processes entirely using services. When done right, this is very powerful because of the great flexibility that the combination of BPM and SOA provides.
Architecture overview
Depending on the requirements of your projects, a different architectural approach will be needed. To make the right decisions when designing your solutions, it is important to understand the services and AIF architecture.
Compared to Microsoft Dynamics AX 2009, there have been a lot of improvements made to the service architecture in Microsoft Dynamics AX 2012. The biggest improvement is the native Windows Communications Foundation (WCF) support. As a result the proprietary Microsoft Message Queuing (MSMQ) and BizTalk adapters that were available in Microsoft Dynamics AX 2009 have been deprecated and replaced by adapters that use WCF. The file system adapter remains intact, and still allows you to import and export messages from and to the file system.
All services are WCF services and are hosted on the AOS. When an application wants to consume these services on the local network, no further deployment is needed, because it can connect directly to the AOS. Just like with Microsoft Dynamics AX 2009, deployment on Internet Information Services (IIS) is needed for consumers that are not on the intranet. However, the services themselves are no longer deployed on IIS; instead a WCF routing service on the IIS routes everything to the AOS.
If you want to modify messages before they are received or after they are sent, you can use pipelines and transformations . Pipelines only apply to the body of a message, and are handled by the request preprocessor and response postprocessor . You can use transformations to transform a complete message including the header. This allows you to exchange messages in non-XML format.
While not displayed in the diagram, there is now load balancing support for services using Windows Server Network Load Balancing (NLB). Combined with NLB for IIS that was already available, this enables high availability and load balancing for services.
