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 takes place. Th= e role of a service container is to build and maintain your services and th= eir dependencies. Basically, each time you need a service, you may ask for = it to the service container which will either build it with the configurati= on you provided, or give you the existing instance if it is already availab= le.
eZ Publish 5 uses Symfony servi= ce 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 Publish 5 s= ervices are made :
Service tags in Symfony DIC are a useful way to dedicate services to a s= pecific 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 Publish 5 exposes several features this way (see the list of core ser= vice tags). This is for example the case for Field Types.
You will find all service tags exposed by Symfony in its reference documentation.