Um serviço web deve estar sempre em um dos seguintes estados em determinado instante de tempo: down e busy.

Um serviço web em estado saturated não pode mudar para o estado crashed sem antes gerar, entre outras notificações, relieve ou restart.

Para desenhar e implementar uma aplicação flexível de mensageria síncrona ou assíncrona, a qual deve ser capaz de gerar mensagens e envelopes especializados conforme políticas de entrega parametrizadas, é mais recomendado empregar os padrões de design Builder e Strategy que os padrões Memento e Facade.

O corpo (body) de um pedido HTTP enviado de um sender para um receiver contém, entre outros campos, os campos padronizados Accept, Accept-Charset, Accept-Encoding, Accept-Language no contexto de uma aplicação web. A primeira linha do cabeçalho de um pedido HTTP contém uma string no formato < Merhod > SP < Resquest-URI > SP < HTTP-Version > CRLF, em que SP representa espaço em branco e CRLF representa final de uma linha de texto.

O emprego do conjunto dos padrões Composite e Iterator é mais viável, em comparação com Prototype e AbstractFactory, para desenho e implementação de capacidades de configuração dinâmica de um sistema de mensageria a partir de famílias de componentes de mensageria distintos.