Uma aplicação não pode viver exclusivamente à custa de envelopes e cartas. Os envelopes, sem outro código que os assista, não passam de simples objectos que sabem redireccionar invocações. Os serviços, sob a forma de módulos funcionais, existem para permitir aos envelopes exibir funcionalidade útil.
A natureza dos serviços deve ser tal que permita o seu encapsulamento e gestão automatizados, independentes do nível de programa. Não quer isto dizer que os serviços que se podem incluir numa aplicação estejam limitados na sua natureza, mas sim que devem obedecer aos requisitos de desenho da aplicação, nomeadamente, todas as acções que envolvam iniciativas por parte do código da aplicação, em funções de gestão do módulo, devem ser evitadas. Apenas são tolerados acessos reconhecidos pela aplicação como atribuição de características a um objecto por ela conhecido no nível de programa.
O fluxo de informação entre níveis é anisotrópico e muito maior dos níveis superiores para os inferiores. O efeito é uma consequência da transparência: o nível de programa não recebe informação dos níveis inferiores que não esteja relacionada com o algoritmo de alto nível da aplicação, mas estes recebem informação dos níveis superiores (via retorno de upcalls), necessária à gestão automática. A capacidade de fornecer um serviços, aplicando este método, está, deste modo, condicionada pela complexidade do código utilizado na gestão automática dos respectivos módulos funcionais, e pela capacidade de a ferramenta de geração tratar casos que exijam interacções complexas, mas que têm que ser transparentes, junto da fronteira entre os níveis de programa e ligação.
O fornecimento de serviços, obedecendo às regras dos modelo, consegue, de uma forma modular, definir funcionalidade e torná-los independentes entre si. Exclui-se a dependência que existe quando um módulo utiliza os serviços de outro, para evitar a replicação de código: veja-se, como exemplo, a dependência que existe no módulo de persistência em relação ao de distribuição (capítulo 5).