Yes, you are essentially correct. APIC uses OpenFlow and other such protocols to communicate with network devices, while APIC-EM is able to communicate with traditional devices that do not speak these protocols. APIC-EM communicates to network devices through the southbound interface using TELNET, SSH, or SNMP. So where APIC typically uses OpenFlow, APIC-EM uses the more traditional services described.
In general, APIC is typically used in datacenters while APIC-EM is used on campuses, LANs and WANs. This is not a strict distinction, but just a general trend.
Now Cisco ACI stands for Application Centric Infrastructure. It is Cisco’s SDN solution architecture. It provides automation tools for network administration, and centres around the Nexus series of devices and the APIC controller for the hardware component. It also includes virtual components as well. You can find out more about it here:
Concerning the Service Abstraction Layer (SAL), this is a component of the OpenDayLight open source SDN controller. Cisco also provides a commercial distribution of the OpenDayLight controller. Below you can see an example of its components.
Note the SAL is part of the Core Infrastructure. According to OpenDayLight:
In OpenDaylight, the service abstraction layer (SAL) is the key design that enables the abstraction of services between the services’ consumers and producers. SAL acts like a large registry of services advertised by various modules and binds them to the applications that require them. Modules providing services, or producers, can register their APIs with the registry. When an application, or a consumer, requests a service via a generic API, SAL is responsible for assembling the request by binding producer and consumer into a contract, brokered and serviced by SAL. SAL has two architecturally different ways of implementing this registry: application-driven SAL and module-driven SAL. In Section III, we will describe this service abstraction in detail.
Here a producer is a module providing a service, while a consumer is a network device that requires that service. SAL essentially acts as a middle man that can translate the command/requirements between service modules and network devices via a generic API.
I hope this has been helpful!