A service container, (aka DIC, Dependency Inje= ction Container) is a special object that greatly facilitates dependen= cies resolution in your application and sits on Dependency Injection design pattern. Basically, this design pattern pr= oposes to inject all needed objects and configuration into your business lo= gic objects (aka services). It avoids the massive use of s= ingletons, global variables or complicated factories and thus makes your co= de much more readable and testable. It avoids "magic."
The main issue with dependency injection is how to resolve your dependen= cies for your services. This is where the service container comes into play= . The role of a service container is to build and maintain your services an= d their dependencies. Basically, each time you need a service, you may ask = the service container for it, which will either build it with the configura= tion you provided, or give you an existing instance if it is already availa= ble.
eZ Platform uses Symfony servic= e container .
It is very powerful and highly configurable. We encourage you to read it= s dedicated documentation as it will help you understand how eZ Platform se= rvices are made:
Service tags in Symfony DIC are a useful way of dedicating services to a= specific purpose. They are usually used for extension points.
For instance, if you want to register a Twig extension to add custom filters, you will need to creat= e the PHP class and declare it as a service in the DIC configuration with t= he twig.extension tag (see Symfony cookbook entry for a full example).
eZ Platform exposes several features this way (see the list of core serv= ice tags). This is for example the case for Field Types.
You will find all service tags exposed by Symfony in its reference documentation.