terça-feira, 29 de dezembro de 2015

Edital IBGE 2015

ANÁLISE DE SISTEMAS - DESENVOLVIMENTO DE SISTEMAS

Bancos de dados:Modelagem conceitual de dados (Modelo de Entidades e Relacionamentos).
Modelo relacional: normalização, integridade; Projeto e implementação de uma base de dados relacional: Linguagens de Definição de Dados (DDL), Manipulação de Dados (DML) e Controle de Dados (DCL); Linguagem SQL Padrão ANSI 2006;
Transações: Recuperação e concorrência; Segurança; Otimização de Consultas. Conceitos de Bancos de dados distribuídos, arquitetura em múltiplas camadas. SGBD: ORACLE, SQLServer, PostGreSql e MySQL. SGBD Oracle: Programação PL/SQL (stored procedures, triggers, functions, packages). SGBD PostGreSql: Programação PL/pgSQL (stored procedures, triggers, functions). Conceitos de Data Warehouse, OLAP e OLTP.

Linguagens de Programação: Estrutura de Dados e algoritmos: algoritmos de pesquisa e de ordenação; estrutura de dados básica (arrays, pilhas, listas e filas); Conceito de Compilação e ligação de programas; Tipos abstratos de dados; Programação orientada a objetos. Tratamentos de exceções. Linguagens de programação: C# e Java (declarações de variáveis, acesso à banco de dados, definição de formulários, tratamento de erros, depuração de programas e estruturas básicas de programação - sequência, repetição e seleção). Desenvolvimento de aplicativos com ferramentas Visual Studio .Net (com ênfase em C#), J2EE, Java (Eclipse); Desenvolvimento de aplicações para dispositivos móveis utilizando a IDE Android Studio e Windows phone com Visual Studio; Construção e uso de componentes e bibliotecas. Engenharia de software: Conceitos Gerais; Ciclo de vida de Software; Análise e gerência de Requisitos; Qualidade de Processo de Software; Qualidade do Produto; Processo de Software; Design Patterns; Padrões de Arquitetura de Aplicações Corporativas, Implementação; Testes;
Técnicas de Estimativa de Projetos: APF (Análise por pontos de função); Padrões de projetos (MVC -Model-ViewControl).
Análise Orientada a Objetos: principais conceitos: abstração, classes, subclasses, herança e composição, polimorfismo; identificação de classes primárias; classes derivadas; mensagens e seus tratadores; representação; linguagem de modelagem UML. Teste de software(unitário, Integração, Funcional, Aceitação, Desempenho e Carga).
Arquitetura: SAAS(Software as a Service).
Projeto de sistemas de informação: Conceitos fundamentais; Planejamento das atividades de análise; projeto de entrada e de saída; controle de sistemas; implementação de sistemas. Arquitetura: Service-Oriented Architecture (SOA); camadas de acesso a dados (OLEDB, ODBC, JDBC); Monitores de processos e transações (TP monitors), gerência e protocolos de transações distribuídas; Conceito de servidor de aplicação. Aplicações Móveis (tablets, celulares, PDA e netbook): Acessibilidade e Engenharia de Usabilidade: Conceitos básicos de engenharia de usabilidade; Critérios, recomendações e guias de estilo; Análise de requisitos de usabilidade; Concepção, projeto e implementação de interfaces. Mapeamento Objeto Relacional, Refatoração, inversão de controle, Injeção de dependência. Redes de Computadores e Internet: Conceitos básicos em comunicação de dados. Protocolo TCP/IP; Serviços: telnet, FTP, SFTP, SSH; Segurança: firewalls, mecanismos de autenticação, criptografia, certificados digitais e vírus. Aplicações web: Servidores web (Apache e IIS), SOAP e REST; Linguagem XML, HTML, XHTML, DHTML, Web Standards, CSS, Ajax.
Tecnologias: multimídia e hipermídia.

quinta-feira, 10 de dezembro de 2015

Tributo: conceito e classificação

 “Art. 3.º Tributo é toda prestação pecuniária compulsória, em moeda ou cujo valor nela se possa exprimir, que não constitua sanção de ato ilícito, instituída em lei e cobrada mediante atividade administrativa plenamente vinculada”

 Prestação pecuniária, em moeda ou cujo valor nela se possa exprimir
O Tributo tem que ser pago em dinheiro, não em serviços, nem em trabalho (in labore) ou bens (in natura). Por exemplo, sou advogada, não posso, como contribuinte, pagar o Imposto de Renda (IR) com prestação de serviço advocaticio à União. Entende-se que a expressão “ou cujo valor nela se possa exprimir” pode se referir a tributos cujo valor não é previsto em reais, mas sim por indexadores, como a extinta UFIR – Unidade Fiscal de Referência.No entanto, a LC n° 104/2001 inseriu, no CTN, a dação em pagamento de bens imóveis (art.156, XI).

 Prestação compulsória
O dever de pagar o tributo é obrigatório, não decorrendo da manifestação de vontade do devedor. Assim, lei tributária cria a obrigação de pagar o tributo. Se a lei obriga, o contribuinte não pode se negar a pagar o tributo. O caráter compulsório da obrigação tributária decorre de imposição legal (terceira característica), já que somente a lei pode obrigar alguém a fazer ou deixar de fazer alguma coisa (CF, art. 5º, II).

Prestação instituída por lei
O dever de pagar tributo decorre da lei, como toda obrigação, mas ao contrário das obrigações civilistas, decorrente indiretamente da lei, a obrigação tributária é diretamente decorrente de imposição legal (“ex lege”). Esta regra não possui exceções (medidas provisórias não são exceções porque têm força de lei).

Prestação que não constitui sanção de ato ilícito
Essa característica traz a diferença entre o tributo e a multa. A Multa é exatamente o que, por definição, o tributo não pode ser: a sanção (penalidade) de um ato ilícito. Conforme será visto, o dever de pagar tributo surge com a ocorrência de uma hipótese abstratamente prevista na lei (o fato gerador). Pois bem, o tributo não pode ter como fato gerador um ato ilícito.

Prestação cobrada mediante atividade administrativa plenamente vinculada
A autoridade tributária não tem a possibilidade de, diante da ocorrência do fato gerador de um tributo, escolher se quer cobrar ou não o correspondente tributo. Ou seja, não há qualquer grau de discricionariedade (análise de conveniência e oportunidade) na cobrança de tributo por parte da autoridade administrativa competente. O poder de lançar é um poder-dever e, se verificado o fato gerador do tributo, a cobrança (lançamento) deve ser obrigatoriamente realizada. A vinculação da cobrança do tributo decorre da obrigatoriedade de lei para instituição e de se configurar uma prestação compulsória.

ESPÉCIES TRIBUTÁRIAS
Impostos, Taxas, Contribuições de Melhorias, Empréstimos Compulsórios e Contribuições Especiais.

Natureza jurídica dos tributos
O art. 4º do CTN dispõe que a natureza jurídica específica do tributo é determinada pelo fato gerador da respectiva obrigação, sendo irrelevantes para qualificá-la a denominação e demais características formais adotadas pela lei, bem como a destinação legal do produto de sua arrecadação. Assim, basta conhecer o fato gerador (= hipótese de incidência) para se identificar qual a espécie tributária de que se trata.
Entretanto, para classificar um tributo quanto ao fato gerador, tem- -se que saber se o Estado tem de realizar atividade específica para o contribuinte. Se sim, o tributo é vinculado (a cobrança se vincula a uma atividade do Estado específica para o contribuinte). Se não, teremos um tributo não-vinculado.
Assim, todos os impostos são não vinculados, pois o fato gerador é uma situação independente de qualquer atividade estatal específica, relativa ao contribuinte. Exemplo, se obtenho rendimentos, passoa dever imposto de renda (IR), independente do Estado realizar uma atividade para mim. Já as taxas e contribuições de melhoria são tributos vinculados, pois, como será visto adiante, para a taxa o fato gerador será o exercício regular do poder de polícia, ou a utilização, efetiva ou potencial, de serviço público específico e divisível, prestado ao contribuinte ou posto à sua disposição. Já para a cobrança de contribuições de melhoria será necessária a realização de obras públicas de que decorra valorização imobiliária.

Impostos é o tributo cuja obrigação tem por fato gerador uma situação independente de qualquer atividade estatal específica, relativa ao contribuinte. Ou seja, quando alguém obtém rendimento, vende mercadoria, presta serviço de assistência médica, por exemplo, deve contribuir com a União (IR), com o Estado (ICMS) e com o Município (ISS), respectivamente. Os recursos arrecadados por esses entes, por sua vez, devem ser usados em prol de toda a sociedade. Os impostos são, também, tributos de arrecadação não vinculada, isso porque sua receita irá financiar atividades gerais do Estado, ou seja, serviços universais (uti universi), que, por não serem específicos e divisíveis, não podem ser custeados por intermédio de taxas. De regra, a receita obtida com impostos não pode ser vinculada a órgão, fundo ou despesa específica, salvo expressa previsão constitucional (art. 167, IV, CF).

Regra geral: Vedada vinculação de imposto a fundo, órgão ou despesa específica.
Exceções:
1) a repartição do produto da arrecadação dos impostos a que se referem os arts.158 e 159 (repartição constitucional de receitas tributárias);
2) a destinação de recursos para as ações e serviços públicos de saúde, que constituem um sistema único (art.198, § 2°);
3) a destinação de recursos para manutenção e desenvolvimento do ensino (art.212);
4) a destinação de recursos para realização de atividades da administração tributária, essenciais ao funcionamento do Estado (art.37, XXII);
5) a vinculação para prestação de garantias às operações de crédito por antecipação de receita, eventualmente previstas na lei orçamentária anual (art. 165, §8°);
6) a vinculação para prestação de garantia ou contragarantia à união (art.167, §4°);
7) a vinculação para pagamento de débitos para com a união (art.167, §4°).

Os impostos se diferenciam entre si pelos respectivos fatos geradores. É a Constituição Federal que atribui competência para cada entepolítico (U, E, DF e M) instituir impostos de maneira enumerada e privativa.
Assim, a União poderá instituir os impostos previstos no art. 153:
II (Imposto de importação),
IE (Imposto de Exportação),
IR (Imposto de Renda e proventos de qualquer natureza),
IPI (Imposto sobre Produtos Industrializados),
IOF (Imposto sobre operações de crédito, câmbio e seguro, ou relativas a títulos ou valores mobiliários – Imposto sobre Operações Financeiras),
ITR (Imposto sobre a Propriedade Territorial Rural) e
IGF (Imposto sobre Grandes Fortunas);

Os Estados (e o DF), os previstos no art. 155:
ITCMD (Imposto sobre a Transmissão Causa Mortis e Doação),
ICMS (Imposto sobre a Circulação de Mercadorias e prestação de Serviços de transporte interestadual e intermunicipal e de comunicação) e
IPVA (Imposto sobre a Propriedade de Veículos Automotores);

Os Municípios (e o DF), os previstos no art. 156:
IPTU (Imposto sobre a Propriedade Predial e Territorial Urbana),
ITMI (Imposto sobre a Transmissão inter vivos de Bens Imóveis e direitos a eles relativos) e
ISS (Imposto sobre Serviços de qualquer natureza).

De acordo com o art. 154, I, da CF, a União ainda pode instituir, mediante lei complementar, novos impostos, não especificados na sua esfera de competência, desde que sejam não cumulativos e não tenham fato gerador ou base de cálculo próprios dos impostos já discriminados na Constituição – é a competência tributária residual. A União possui ainda competência extraordinária para, excepcionalmente, criar, na iminência ou no caso de guerra externa, impostos extraordinários, compreendidos ou não na sua esfera de competência, nos termos do art. 154, II da CF. Nesse caso, o fato gerador do Imposto Extraordinário de Guerra (IEG) pode ser o mesmo dos impostos de competência dos Estados e Municípios. Por exemplo, em caso de guerra externa, ou na sua iminência, a União pode instituir um ISS extraordinário.

É importante saber que a CF não cria tributos, mas atribui competência para que cada ente político possa criar. O momento de criação do tributo está na esfera de discricionariedade do ente federal. A União, por exemplo, até os dias atuais não criou o IGF. Conforme visto acima, é necessário lei em sentido formal para que sejam criados tributos. No caso dos impostos, a CF exige lei complementar, de abrangência nacional, para definir, abstratamente, fatos geradores, base de cálculo e contribuintes (art. 146, III, a). Entretanto, o imposto em si, por exemplo, ICMS, pode ser criado pelos Estados por meio de lei ordinária. No entanto, as normas sobre fato gerador, a base de cálculo e o contribuinte devem seguir a legisla- ção nacional (LC).

Verifica-se, assim, que o constituinte adotou a classificação dos impostos em pessoais ou reais. São pessoais os impostos que consideram os aspectos pessoais do contribuinte. Por exemplo, o IR leva em conta a pessoa (física ou jurídica) que auferiu renda, considerando o valor total anual dos rendimentos auferidos, a quantidade de dependentes, gastos com saúde, educação, etc.

Já os impostos reais incidem sobre coisas, não consideram aspectos subjetivos do contribuinte, mas incidem objetivamente, independente da capacidade econômica (riqueza) do contribuinte. Por exemplo, o IPTU, IPVA, ICMS, ITR, IPI, II. Ou seja, se junto durante 10 anos dinheiro para comprar um carro importado, vou pagar, embutido no preço, o mesmo valor de II, IPI e ICMS que um milionário adquirente do mesmo carro para sua esposa.

A doutrina ainda classifica os impostos em “diretos” (ou “que não repercutem”) e “indiretos” (ou “que repercutem”). Impostos diretos são aqueles em que a mesma pessoa arca com ônus e com reconhecimento do imposto, ou seja, o pagamento é feito pelo próprio contribuinte de fato. Exemplo: IR; ITR; IPTU; IPVA. Já os impostos indiretos são aqueles pagos pelo consumidor (contribuinte de fato) e recolhido aos cofres públicos pelo comerciante, industrial, produtor e prestador de serviço (contribuinte de direito). Exemplo: ICMS, ISS, II, IPI.

Taxas exercício do poder de polícia ou pela utilização, efetiva ou potencial, de serviços públicos específicos e divisíveis, prestados ao contribuinte ou postos a sua disposição (mesmo sentido, art. 77, CTN). Dessa forma, a taxa pode ser instituída por qualquer um dos entes federativos – competência comum. Taxas são tributos vinculados a uma atividade do Estado, uma vez que seu fato gerador é uma atividade realizada pelo Estado: exercício do poder de polícia (taxa de polícia) ou prestação de determinados serviços públicos (taxa de serviço). Diferente dos impostos que, como visto, são tributos não vinculados à uma atividade estatal específica. Por isso, as taxas não podem ter fato gerador idêntico ao dos impostos (parágrafo único do art.77, CTN).

A taxa também não pode ter base de cálculo própria da dos impostos, pois, se fosse possível, o legislador poderia burlar a regra que veda que taxa tenha fato gerador próprio dos impostos. \ Posição do STF Nesse sentido a súmula 565 do STF, “É inconstitucional a taxa municipal de conservação de estradas de rodagem cuja base de cálculo seja idêntica à do imposto territorial rural”. Entretanto, é possível a criação de taxa com um ou mais elementos da base de cálculo de imposto, desde que não haja integral identidade entre as bases de cálculos. Por essa razão, o STF considerou constitucional a taxa de coleta de lixo domiciliar com alíquota que varia em fun- ção da metragem do imóvel, não implicando identidade com a base de cálculo do IPTU. \ Posição do STF Súmula vinculante nº 29 do STF, “É constitucional a adoção, no cálculo do valor de taxa, de um ou mais elementos da base de cálculo própria de determinado imposto, desde que não haja integral identidade entre uma base de cálculo e outra.”

Taxas de polícia
A taxa de polícia, diferente da taxa de serviços, só pode ser cobrada pelo efetivo exercício desse poder. Ou seja, o poder de polícia tem que ser regularmente exercido para dar ensejo à cobrança da taxa de polícia (parágrafo único do art. 78, CTN). Entretanto, o STF vem amenizando tal entendimento, presumindo o exercício do poder de polícia quando existente órgão competente de fiscalização na estrutura do ente tributante, mesmo que este não comprove haver realizado as fiscalizações individualizadas nos estabelecimentos de cada contribuinte.

Taxas de serviços
O segundo fato gerador da taxa é a utilização, efetiva ou potencial, de serviço público específico e divisível, prestado ao contribuinte ou posto a sua disposição. Entretanto, poderá ser cobrada taxa de serviço também quando for disponibilizado ao contribuinte serviço público específico e divisível de utilização compulsória. Ou seja, o serviço público será considerado potencialmente utilizável, quando, sendo de utilização compulsória, seja posto à disposição do contribuinte mediante atividade administrativa em efetivo funcionamento. Assim, caso o serviço ultrapasse os interesses meramente individuais do indivíduo, mesmo o serviço específico e divisível, deve ser definido em lei como de utilização compulsória e o contribuinte deve pagar a taxa mesmo que não utilize efetivamente o serviço. Exemplo de utilização potencial é o serviço de coleta domiciliar de lixo, definido em lei como de utilização compulsória. Assim, se contrato empresa particular de coleta de lixo, a qual recolhe todo o meu lixo e o leva até o aterro sanitário da prefeitura, apesar de a prefeitura disponibilizar, em efetivo funcionamento, o serviço público de coleta de lixo domiciliar, não posso recusar a pagar a taxa de coleta de lixo alegando que não utilizo efetivamente desse serviço. Isso porque, os serviços disponibilizados, efetivamente definidos em lei como de utilização compulsória, permitem a cobrança pela chamada “utilização potencial”. Assim, o serviço público é específico quando o contribuinte sabe por qual serviço está pagando. É divisível quando é possível ao Estado identificar os usuários do serviço a ser pago com a taxa (uti singuli). Por não ser divisível, o STF entendeu inconstitucional a taxa de iluminação pública, pois não havia como mensurar a utilização individualizada da iluminação pública pelo contribuinte.

TAXAS E PREÇOS PÚBLICOS: DISTINÇÃO
Conforme visto, as taxas têm como fator gerador o exercício do poder de polícia (taxas de polícia) ou a utilização, efetiva ou potencial, de serviços públicos específicos e divisíveis (taxas de serviço). Por sua vez, os serviços públicos podem ser remunerados tanto por taxa (taxa de serviço público) como por preço público, mas nunca pelos dois ao mesmo tempo. Ambos remuneram uma atividade prestada pelo Estado, ou por quem lhe faça às vezes, a um beneficiário (devedor) identificável do serviço. Assim, o preço público é cobrado pela utilização de um serviço facultativo (não compulsório), livremente contratado pelo usuário, colocado a sua disposição pela administração pública ou quem lhe faça às vezes. Por exemplo, o serviço de telefonia. Já a taxa de serviço é compulsória, visto que a lei assim a define e o serviço é posto a disposição do usuário (contribuinte), estando em efetivo funcionamento. Exemplo, o serviço de coleta domiciliar de lixo (conforme visto).


Taxa de serviço 
Preço público Regime jurídico tributário (= de Direito Público)
Decorre da lei
Receita arrecadada é derivada
Prestação pecuniária compulsória
Utilização efetiva e potencial enseja a taxa de serviço público
Sujeito ativo: só pessoa jurídica de direito público
Não admite rescisão
Obediência aos princípios tributá- rio da legalidade, anterioridade e anterioridade nonagesimal

Preço Público
Regime Jurídico Contratual (=de Direito Privado)
Decorre da autonomia da vontade
Receita arrecadada é originária
Prestação pecuniária facultativa
O particular tem que utilizar efetivamente o serviço, contratando-o
Sujeito ativo: pode ser privado: Concessionária, Permissionária ou Autorizatária
Admite rescisão
Não Obediência aos princípios tributário da legalidade, anterioridade e anterioridade nonagesimal

Serviço Público Propriamente Estatal:
Estado atua no exercício de sua soberania. São serviços indelegáveis (só o Estado pode prestá-lo). Remunerados mediante taxa. Ex.: Emissão de passaportes, serviço jurisdicional (custas judiciais).

Serviço Público Essencial ao Interesse Público:
São serviços essenciais à coletividade. Remunerados mediante taxa (utilização efetiva ou potencial). Ex.: Coleta residencial de lixo, serviço de sepultamento.

Serviço Público Não Essencial ao Interesse Público:
Quando não utilizados não geram dano à coletividade. São em regra delegáveis. Podem ser concedidos e podem ser remunerados por preço público. Ex.: Serviços de distribuição de energia, de gás, de telefonia, serviço postal.

Fonte: http://www.editorajuspodivm.com.br/i/f/paginas-direito-tributario-resumos.pdf

Financiamento da seguridade social

Prevê o art. 195 da Constituição: "A seguridade é financiada por toda a sociedade, de forma direta e indireta, nos termos da lei, mediante recursos provenientes dos orçamentos da União, dos Estados, do Distrito Federal e dos Municípios".
Os regimes de Seguridade Social são:
a- geral, que é destinado aos particulares. É o regime do INSS;
b- próprios, como o dos servidores públicos;
c- complementares, que visam complementar o regime geral ou dos servidores públicos.
Na verdade, a Seguridade Social não será financiada, mas haverá seu custeio. Não se trata de financiamento, como se fosse um empréstimo bancário , em que haveria necessidade de devolver o valor com juros e correção monetária. Trata-se de custeio, o que é feito por meio de contribuição social.

A forma direta se dá nos moldes do referido artigo, inciso I a IV:
I - do empregador, da empresa e da entidade a ela equiparada na forma da lei, incidentes sobre:
a) a folha de salários e demais rendimentos do trabalho pagos ou creditados, a qualquer título, à pessoa física que lhe preste serviço, mesmo sem vínculo empregatício;
b) a receita ou o faturamento incide a COFINS (Lei Complementar 70/91) e o PIS (Lei Complementar 7/70).
c) o lucro incide a contribuição social criada pela Lei 7.689/88
II - do trabalhador e dos demais segurados da previdência social, não incidindo contribuição sobre aposentadoria e pensão concedidas pelo regime geral de previdência social de que trata o Art. 201;
III - sobre a receita de concursos de prognósticos;
IV - do importador de bens ou serviços do exterior, ou de quem a lei a ele equiparar (Lei 10.865/04).

A forma indireta é a contribuição dos recursos orçamentários da União, DF, Estados e Municípios. Ressalta-se que é União que tem a competência de criar contribuições previdenciárias, mediante lei ordinária.
Alem das fontes anteriormente referidas, a Constituição prevê outras fontes de custeio no parágrafo 4º. Do art. 195, que se reporta ao inciso I do art. 154 (exigência de que a nova fonte de custeio seja instituída por lei complementar, não podendo ter fato gerador ou base de cálculo de outro imposto já existente e que não seja cumulativa).
A não-cumulatividade deve ser compreendida no sentido de que é impossível a criação de uma contribuição social sobre o valor já tributado. Definirá a lei como será custeado o sistema de Seguridade Social.
A lei definirá os setores de atividade econômica para as quais as contribuições incidentes na forma dos incisos I, b, e IV do art. 195 da Constituição serão não cumulativas (parágrafo 12 do art. 195 da Constituição) Essa regra também será aplicada na hipótese de substituição gradual, total ou parcial, da contribuição incidente sobre a folha de pagamentos pela incidente sobre a receita ou faturamento.

SEGURADOS DA PREVIDENCIA SOCIAL
EMPREGADO – Obrigatoriamente deve ter Carteira de Trabalho, e estar laborando.
EMPREGADO DOMÉSTICO – Comprovação do pagamento de contribuições através de guias de recolhimento.
TRABALHADOR AVULSO - Ser cadastrado e registrado no sindicato ou órgão gestor.
CONTRIBUINTE INDIVIDUAL – Deve fazer o recolhimento através do Documento de Arrecadação do Simples Nacional. Tem a obrigação de pagar as contribuições através de guias de recolhimento.
SEGURADO ESPECIAL - Comprovação de exercer o trabalho em área rural.
SEGURADO FACULTATIVO – Apenas se inscrever na Previdência, e pagar todo mês suas contribuições.



Fonte: http://www.egov.ufsc.br/portal/conteudo/fontes-de-custeio-da-seguridade-social

Segurado facultativo: conceito, características

É facultado às pessoas que não exerçam atividade laborativa remunerada filiarem-se ao RGPS, por meio de contribuições.
Idade mínima: 16 anos (art. 7, XXXIII, CF).
A filiação do segurado facultativo, ao contrário do que ocorre com o segurado obrigatório, decorre de ato de vontade da pessoa.
Podem filiar-se, dentre outros, como facultativos à Previdência Social:
- dona-de-casa;
- estudante;
- o bolsista e o estagiário que prestem serviços de acordo com a lei 11.788/08;
- aquele que deixou de ser segurado obrigatório do RGPS (ex.: empregado que foi demitido);
- presidiário que não exerce atividade remunerada, nem esteja vinculado a algum regime de previdência social.
Não se podem filiar como facultativos:
- pessoas já filiadas como seguradas obrigatórias;
- pessoas já amparadas por RPPS (regimes próprios de previdência social);

Segurados obrigatórios

São as pessoas físicas que exercem atividade laborativa remunerada (segurados obrigatórios), à exceção dos ocupantes de cargos efetivos permanentes de regime próprio de previdência social, ou pessoas que, não exercendo trabalho remunerado, filiam-se à Previdência por meio de contribuições (segurados facultativos).
Dessa vinculação do Segurado à Previdência Social nasce a obrigação contributiva para o Segurado e o dever de proteção (concessão de benefícios e serviços) para o ente segurador (INSS).
O artigo 11 da Lei 8.213/91 trata dos segurados obrigatórios da Previdência Social, que são classificados em:

1- Empregado - aquele que presta serviço de natureza urbana ou rural à empresa, em caráter não eventual, sob sua subordinação e mediante remuneração, inclusive como diretor empregado

2- Empregado Doméstico - Aquele que presta serviço de natureza contínua a pessoa ou família, no âmbito residencial desta, em atividades sem fins lucrativos

3- Contribuinte Individual - Os contribuintes individuais são uma espécie de segurados obrigatórios que são muito distintos entre si, mas guardam algo em comum: não se enquadram como empregados, domésticos, trabalhadores avulsos e segurados especiais.

4- Trabalhador Avulso - É a pessoa que, sindicalizada ou não, presta serviços a diversas empresas, sem vínculo empregatício com qualquer delas, com intermediação obrigatória do órgão gestor de mão-de-obra ou do sindicato da categoria.
Também não há vínculo empregatício com o sindicato ou com o órgão gestor de mão-de-obra.
Somente haverá a figura do trabalhador avulso se o serviço for prestado com a INTERMEDIAÇÃO OBRIGATÓRIA DO SINDICATO (para os avulsos terrestres) ou do O.G.M.O. (Órgão Gestor de mão-de-obra) – (para os avulsos portuários).

5- Segurado Especial - O produtor, o parceiro, o meeiro e o arrendatário rurais e o pescador artesanal, bem como os respectivos cônjuges, que exerçam suas atividades em regime de economia familiar, sem empregados permanentes.

Obrigações acessórias

As obrigações acessórias são as prestações de fazer ou não fazer determinados atos em cumprimento do interesse do exercício fiscalizatório do Estado. Na realidade, tratam-se de deveres instrumentais, que auxiliam o Fisco nas suas atividades (nesta classificação, não se incluem as obrigações de dar, pois estas pressupõem o pagamento dos tributos, classificando-se como obrigação principal). Em outras palavras, consideram-se obrigações acessórias a escrituração de livros contábeis, emissão de notas fiscais e recolhimento de imposto de renda.
Ao falar em prestações positivas ou negativas, o legislador tributário quis se referir às obrigações que os civilistas classificam como de fazer ou deixar de fazer. Não se incluem as obrigações de dar dinheiro, porque estas (...) são consideradas "principais". São, na realidade, obrigações meramente instrumentais, simples deveres burocráticos que facilitam o cumprimento das obrigações principais [1].
Novamente, o conceito empregado do termo "acessório" diverge do conceito utilizado no Direito Civil. Aquele pressupõe que a coisa acessória acompanha a principal e esta última existe por conta própria. A obrigação tributária acessória, no entanto, pode existir independentemente de haver uma obrigação principal correspondente. Por exemplo, as entidades que gozam de imunidade tributária, sendo, portanto, livres do cumprimento da obrigação tributária principal, são obrigadas a recolher imposto de renda retido na fonte pago a pessoa física que lhe presta serviços.

Fonte: http://www.direitoeleis.com.br/Obriga%C3%A7%C3%A3o_tribut%C3%A1ria

sexta-feira, 4 de dezembro de 2015

Estabilidade

CF/88
Art. 41. São estáveis após três anos de efetivo exercício os servidores nomeados para cargo de provimento efetivo em virtude de concurso público.
§ 1º O servidor público estável só perderá o cargo:
I - em virtude de sentença judicial transitada em julgado;
II - mediante processo administrativo em que lhe seja assegurada ampla defesa;
III - mediante procedimento de avaliação periódica de desempenho, na forma de lei complementar, assegurada ampla defesa.
§ 2º Invalidada por sentença judicial a demissão do servidor estável, será ele reintegrado, e o eventual ocupante da vaga, se estável, reconduzido ao cargo de origem, sem direito a indenização, aproveitado em outro cargo ou posto em disponibilidade com remuneração proporcional ao tempo de serviço.
§ 3º Extinto o cargo ou declarada a sua desnecessidade, o servidor estável ficará em disponibilidade, com remuneração proporcional ao tempo de serviço, até seu adequado aproveitamento em outro cargo.
§ 4º Como condição para a aquisição da estabilidade, é obrigatória a avaliação especial de desempenho por comissão instituída para essa finalidade.

Nos crimes de responsabilidade do Presidente da República,


Art. 53, P.ú. Nos casos previstos nos incisos I e II, funcionará como Presidente o do Supremo Tribunal Federal, limitando-se a condenação, que somente será proferida por dois terços dos votos do Senado Federal, à perda do cargo, com inabilitação, por oito anos, para o exercício de função pública, sem prejuízo das demais sanções judiciais cabíveis

Art. 85. São crimes de responsabilidade os atos do Presidente da República que atentem contra a Constituição Federal e, especialmente, contra (....) P.ú. Esses crimes serão definidos em lei especial, que estabelecerá as normas de processo e julgamento.

Art. 86 § 1º - O Presidente ficará suspenso de suas funções:
(...) II - nos crimes de responsabilidade, após a instauração do processo pelo Senado Federal.
(...) § 2º - Se, decorrido o prazo de cento e oitenta dias, o julgamento não estiver concluído, cessará o afastamento do Presidente, sem prejuízo do regular prosseguimento do processo.

A Constituição Federal, ao regular a organização políticoadministrativa do Brasil, determina que

  • Fonte: Aprova Concursos

Decreto Legislativo

Os decretos legislativos são atos normativos primários veiculadores da competência exclusiva do Congresso Nacional previstos no art. 49 da Constituição Federal e, ainda, a regulamentação das relações jurídicas decorrentes de medidas provisórias rejeitadas.
Em regra, os decretos legislativos produzem efeitos externos ao Congresso Nacional, contrariamente às resoluções, que, em regra, produzem efeitos internos de acordo com a Casa Legislativa em que foram emanadas. [http://www.ambito-juridico.com.br/site/index.php?n...]
A assertiva B traz a hipótese do art.49, V CF88.

aRT. 86 § 1º - O Presidente ficará suspenso de suas funções: I - nas infrações penais comuns, se recebida a denúncia ou queixa-crime pelo Supremo Tribunal Federal; II - nos crimes de responsabilidade, após a instauração do processo pelo Senado Federal. § 2º - Se, decorrido o prazo de cento e oitenta dias, o julgamento não estiver concluído, cessará o afastamento do Presidente, sem prejuízo do regular prosseguimento do processo. Art. 79. Substituirá o Presidente, no caso de impedimento, e suceder- lhe-á, no de vaga, o Vice-Presidente.

CF, 88 - Art. 86. Admitida a acusação contra o Presidente da República, por dois terços da Câmara dos Deputados, será ele submetido a julgamento perante o Supremo Tribunal Federal, nas infrações penais comuns, ou perante o Senado Federal, nos crimes de responsabilidade.

quinta-feira, 3 de dezembro de 2015

Introdução UML

UML é uma linguagem gráfica para especificar, visualizar, construir e documentar os artefatos de software.

Estereótipos

São extensões ao vocabulário da UML onde se da uma nova semântica utilizando blocos de construção já existentes.
A UML possui duas grandes categorias para seus diagramas que são:

Estático

Apresentam os aspectos estruturais do sistema.

Dinâmico

Apresentam os aspectos comportamentais do sistema.

Arquitetura UML (Princípios de design)

O metamodelo da UML foi projetado considerando os seguintes princípios:

Modularity

Blocos de construção são agrupados em pacotes seguindo princípios de alta coesão e baixo acoplamento.

Layering (separação em camadas)

Níveis de abstração diferentes. Separação de blocos de construção “Core” e blocos de construção de alto nível (user).

Partitioning

Organização de áreas conceituais dentro de uma mesma camada.

Extensibility

É possível estender a linguagem para plataformas específicas usando perfis.
Ou, também é possível criar uma nova linguagem a partir da UML ampliando metaclasses e metarelacionamentos.

Reuse

Uma biblioteca de metamodelos é disponibilizada em nível fino de granularidade, permitindo o reuso.

Diagrama da UML:

Diagrama estruturais (estático)

mostram a estrutura estática do sistema e suas partes em diferentes níveis de abstração e como elas se relacionam. Não utilizam conceitos relacionados ao tempo.
  • Diagrama de classe
  • Diagrama de componente
  • Diagrama de objeto
  • Diagrama de pacote
  • Diagrama de implantação
  • Diagrama de estrutura composta (veio a partir da versão 2.0)
  • Diagrama de perfis (veio a partir da versão 2.2)

Diagrama comportamentais (dinâmicos)

Mostram a natureza dinâmica dos objetos do sistema, que pode ser descrita como uma série de mudanças no sistema com o passar do tempo.
  • Diagrama de atividade
  • Diagrama de caso de uso
  • Diagrama de estado de máquina
Diagrama comportamentais e de interação (Sub especialização dos diagramas que são diagramas comportamentais de interação)
  • Diagrama de sequência
  • Diagrama de comunicação
  • Diagrama de interação geral
  • Diagrama de tempo
Fonte: http://fabricionogueira.eti.br/introducao-a-uml/

Software Testável

Segundo (ZADROSNY,2006), (PRESSMAN,2002), as seguintes características levam a um software testável e devem ser levadas em conta quando ele é construído:
Operabilidade: o software deve ser projetado e implementado com qualidade. "Quanto melhor funciona, mais eficientemente pode ser usado e testado".
Observabilidade: variáveis devem ser visíveis ou consultáveis durante a execução. "O que você vê é o que você testa."
Controlabilidade: variáveis devem poder ser controladas diretamente pelo engenheiro de teste. "Quanto mais você pode controlar o software, mais o teste pode ser automatizado e otimizado".
Decomponibilidade: módulos independentes podem ser testados independentemente. "Controlando o escopo do teste, podemos isolar problemas mais rapidamente e realizar retestagem mais racionalmente".
Simplicidade: o conjunto de características deve ser o mínimo necessário para atender os requisitos. "Quanto menos há a testar, mais rapidamente podemos testá-lo".
Estabilidade: o software se recupera bem de falhas. "Quanto menos modificações, menos interrupções no teste".
Compreensibilidade: a documentação técnica é acessível instantaneamente, bem organizada, específica, detalhada e precisa."Quanto mais documentação temos, mais racionalmente vamos testar".

SOAP

Simple Object Access Protocol (SOAP)


1ª. Versão
Rio de Janeiro, 17 de outubro de 2007


Indice:
1 – Definição
2 – SOAP e Web Services
3 – Estrutura do Protocolo
4 – Remote Procedure Call (RPC)
5 – Web Service Description Language (WSDL)
6 – Exemplos
1. Definição 
SOAP é um protocolo baseado em XML para troca de informações em um ambiente distribuido.

É utilizado para troca de mensagens entre aplicativos distribuidos pela rede.

Estes aplicativos, ou “Web services”, possuem uma interface de acesso simples e bem definida.

Os Web services são componentes que permitem às aplicações enviar e receber dados em formato XML Cada aplicação pode ter a sua própria "linguagem", que é traduzida para uma linguagem universal, o formato XML.
2. SOAP e Web Services 
Web Services são usados para disponibilizar serviços interativos na WEB, podendo ser acessados por outras aplicações. SOAP (Simple Object Access Protocol) está se tornando padrão para a troca de mensagens entre aplicações e Web Services, já que é uma tecnologia construída com base em XML e HTTP.
As aplicações atuais se comunicam usando Chamadas Remotas de Procedimento (RPC) entre objetos como DCOM e CORBA, mas HTTP não foi projetado para isso. RPC representa tanto um problema de compatibilidade como de segurança. Firewall’s e servidores proxy irão normalmente bloquear este tipo de tráfego.

Uma melhor forma para a comunicação entre aplicações é fazendo-se através do protocolo HTTP. Este é protocolo "standard" em todos os navegadores e servidores de internet. SOAP foi criado para que este tipo de comunicação se tornasse possível.

SOAP é um procolo projetado para invocar aplicações remotas através de RPC ou trocas de mensagens, em um ambiente independente de plataforma e linguagem de programação. SOAP é, portanto, um padrão normalmente aceito para utilizar-se com Web Services. Desta forma, pretende-se garantir a interoperabilidade e intercomunicação entre diferentes sistemas, através da utilização de uma linguagem (XML) e mecanismo de transporte (HTTP) padrões.

Concluindo, o SOAP é o elemento principal da infra-estrutura dos Web Services e um fator fundamental para o funcionamento dos mesmos, independente de plataformas, sistemas operacionais, modelos de objetos e linguagens de programação, auxiliando muito a interoperabilidade entre objetos e componentes distribuídos. Este tem um papel muito importante e acaba com a disputa entre linguagens, garantindo que o programador possa desenvolver no ambiente que seja mais adequado às suas necessidades. Além de todas essas qualidades, o fato também de não ser preciso o seu conhecimento para sua utilização fazem do SOAP uma excelente escolha para o desenvolvimento de Web Services.
O fato de não ser preciso o seu conhecimento para a manipulação dos Web Services facilita a vida de qualquer programador. Visto que a maioria das linguagens já trazem classes implementadas deste protocolo, facilitando ainda mais a sua utilização.
3. Estrutura do protocolo 
Envelope: Toda mensagem SOAP deve contê- lo. É o elemento raiz do documento XML. O Envelope pode conter declarações de namespaces e também atributos adicionais como o que define o estilo de codificação (encoding style).Um "encoding style" define como os dados são representados no documento XML.
Header: É um cabeçalho opcional. Ele carrega informações adicionais, como por exemplo, se a mensagem deve ser processada por um determinado nó intermediário (É importante lembrar que, ao trafegar pela rede, a mensagem normalmente passa por diversos pontos intermediários, até alcançar o destino final). Quando utilizado, o Header deve ser o primeiro elemento do Envelope.
Body: Este elemento é obrigatório e contém o payload, ou a informação a ser transportada para o seu destino final. O elemento Body pode conter um elemento opcional Fault, usado para carregar mensagens de status e erros retornadas pelos "nós" ao processarem a mensagem.

De acordo com o W3Schools, a estrutura da mensagem SOAP é definida em um documento XML que contém os seguintes elementos:
<SOAP-ENV:envelope><!— Elemento raiz do SOAP e define que essa é uma mensagem SOAP--><SOAP-ENV:header><!—Especifica informações especificas como autenticação (opcional)--></SOAP-ENV:header>
<SOAP-ENV:body>
<!—O elemento BODY contém o corpo da mensagem--><SOAP-ENV:fault><!—O elemento FAULT contém os erros que podem ocorrer--></SOAP-ENV:fault>
</SOAP-ENV:body>
</SOAP-ENV:envelope>
Envelope (obrigatório): é responsável por definir o conteúdo da mensagem;
encodingStyle: atributo que tem como objetivo especificar como as informações devem ser codificadas.
<SOAP-ENV:Envelope xmlns:SOAP ENV=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>
<SOAP-ENV:Header>
...
</SOAP-ENV:Header>
<SOAP-ENV:Body>

</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Header (opcional): contém os dados do cabeçalho;
<SOAP-ENV:Envelope xmlns:SOAP ENV=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>
<SOAP-ENV:Header>
<a:authentication xmlns:a=”http://www.mauricioreckziegel.com/soap/authentication”>
<a:username>Mauricio</a:username>
<a:password>Reckziegel</a:password>
</a:authentication>
</SOAP-ENV:Header>
<SOAP-ENV:Body>

</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
actor: especifica o receptor que deve processar o elemento do cabeçalho.
<SOAP-ENV:Envelope xmlns:SOAP ENV=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>
<SOAP-ENV:Header>
<a:authentication xmlns:a=”http://www.mauricioreckziegel.com/soap/authentication”
SOAP- ENV:actor=”http://www.mauricioreckziegel.com/soap/authenticator”><a:username>Mauricio</a:username>
<a:password>Reckziegel</a:password>
</a:authentication>
musUnderstand: especifica se uma entrada de cabeçalho é obrigatória ou opcional (booleano).
<SOAP-ENV:Envelope xmlns:SOAP ENV=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>
<SOAP-ENV:Header>
<a:authentication xmlns:a=”http://www.mauricioreckziegel.com/soap/authentication”
SOAP-ENV:mustUndestrand=”1”><a:username>Mauricio</a:username>
<a:password>Reckziegel</a:password>
</a:authentication>
Body (obrigatório): contém a codificação atual de uma chamada a um método e todos os argumentos de entrada ou uma resposta codificada que contém o resultado de uma chamada de um método.
. Fault: contém as informações dos erros ocorridos no envio da mensagem. Apenas nas mensagens de resposta do servidor.
O envelope SOAP é a parte obrigatória de uma mensagem SOAP. Ele funciona como um recipiente de todos os outros elementos da mensagem, possivelmente o cabeçalho e o corpo, assim como os namespaces de cada um. Assim como o nome e o endereço de uma carta entregue pelo correio, o envelope SOAP precisa das informações específicas do protocolo de transporte que está ligado a ele, com o intuito de garantir a chegada ao local certo. Especificamente no HTTP, temos um cabeçalho que se chama SOAPAction, indicador do endereço de entrega da mensagem. Um dos principais motivos de implementarmos o cabeçalho desta maneira é porque administradores de sistemas podem configurar seus firewalls para filtrar as mensagens baseadas nas informações dos cabeçalhos, sem consultar o XML.
Elemento
Namespace / URI
Envelope
http://schemas.xmlsoap.org/soap/envelope
Serializador
http://schemas.xmlsoap.org/soap/encoding
SOAP-ENV
http://schemas.xmlsoap.org/soap/envelope
SOAP-ENC
http://schemas.xmlsoap.org/soap/encoding
Xsi
http://www.w3.org/1999/XMLSchema-instance
Xsd
http://www.w3.org/1999/XMLSchema
Tabela. Namespaces / URI padrões do SOAP
De acordo com o W3Schools, a estrutura da mensagem SOAP é definida em um documento XML que contém os seguintes elementos:
<SOAP-ENV:envelope><!— Elemento raiz do SOAP e define que essa é uma mensagem SOAP--><SOAP-ENV:header><!—Especifica informações especificas como autenticação (opcional)--></SOAP-ENV:header>
<SOAP-ENV:body>
<!—O elemento BODY contém o corpo da mensagem--><SOAP-ENV:fault><!—O elemento FAULT contém os erros que podem ocorrer--></SOAP-ENV:fault>
</SOAP-ENV:body>
</SOAP-ENV:envelope>
Envelope (obrigatório): é responsável por definir o conteúdo da mensagem;
encodingStyle: atributo que tem como objetivo especificar como as informações devem ser codificadas.
<SOAP-ENV:Envelope xmlns:SOAP ENV=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>
<SOAP-ENV:Header>
...
</SOAP-ENV:Header>
<SOAP-ENV:Body>

</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Header (opcional): contém os dados do cabeçalho;
<SOAP-ENV:Envelope xmlns:SOAP ENV=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>
<SOAP-ENV:Header>
<a:authentication xmlns:a=”http://www.mauricioreckziegel.com/soap/authentication”>
<a:username>Mauricio</a:username>
<a:password>Reckziegel</a:password>
</a:authentication>
</SOAP-ENV:Header>
<SOAP-ENV:Body>

</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
actor: especifica o receptor que deve processar o elemento do cabeçalho.
<SOAP-ENV:Envelope xmlns:SOAP ENV=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>
<SOAP-ENV:Header>
<a:authentication xmlns:a=”http://www.mauricioreckziegel.com/soap/authentication”
SOAP- ENV:actor=”http://www.mauricioreckziegel.com/soap/authenticator”><a:username>Mauricio</a:username>
<a:password>Reckziegel</a:password>
</a:authentication>
musUnderstand: especifica se uma entrada de cabeçalho é obrigatória ou opcional (booleano).
<SOAP-ENV:Envelope xmlns:SOAP ENV=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>
<SOAP-ENV:Header>
<a:authentication xmlns:a=”http://www.mauricioreckziegel.com/soap/authentication”
SOAP-ENV:mustUndestrand=”1”><a:username>Mauricio</a:username>
<a:password>Reckziegel</a:password>
</a:authentication>
Body (obrigatório): contém a codificação atual de uma chamada a um método e todos os argumentos de entrada ou uma resposta codificada que contém o resultado de uma chamada de um método.
. Fault: contém as informações dos erros ocorridos no envio da mensagem. Apenas nas mensagens de resposta do servidor.
O envelope SOAP é a parte obrigatória de uma mensagem SOAP. Ele funciona como um recipiente de todos os outros elementos da mensagem, possivelmente o cabeçalho e o corpo, assim como os namespaces de cada um. Assim como o nome e o endereço de uma carta entregue pelo correio, o envelope SOAP precisa das informações específicas do protocolo de transporte que está ligado a ele, com o intuito de garantir a chegada ao local certo. Especificamente no HTTP, temos um cabeçalho que se chama SOAPAction, indicador do endereço de entrega da mensagem. Um dos principais motivos de implementarmos o cabeçalho desta maneira é porque administradores de sistemas podem configurar seus firewalls para filtrar as mensagens baseadas nas informações dos cabeçalhos, sem consultar o XML.
Elemento
Namespace / URI
Envelope
http://schemas.xmlsoap.org/soap/envelope
Serializador
http://schemas.xmlsoap.org/soap/encoding
SOAP-ENV
http://schemas.xmlsoap.org/soap/envelope
SOAP-ENC
http://schemas.xmlsoap.org/soap/encoding
Xsi
http://www.w3.org/1999/XMLSchema-instance
Xsd
http://www.w3.org/1999/XMLSchema
Tabela. Namespaces / URI padrões do SOAP
De acordo com o W3Schools, a estrutura da mensagem SOAP é definida em um documento XML que contém os seguintes elementos:
<SOAP-ENV:envelope><!— Elemento raiz do SOAP e define que essa é uma mensagem SOAP--><SOAP-ENV:header><!—Especifica informações especificas como autenticação (opcional)--></SOAP-ENV:header>
<SOAP-ENV:body>
<!—O elemento BODY contém o corpo da mensagem--><SOAP-ENV:fault><!—O elemento FAULT contém os erros que podem ocorrer--></SOAP-ENV:fault>
</SOAP-ENV:body>
</SOAP-ENV:envelope>
Envelope (obrigatório): é responsável por definir o conteúdo da mensagem;
encodingStyle: atributo que tem como objetivo especificar como as informações devem ser codificadas.
<SOAP-ENV:Envelope xmlns:SOAP ENV=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>
<SOAP-ENV:Header>
...
</SOAP-ENV:Header>
<SOAP-ENV:Body>

</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Header (opcional): contém os dados do cabeçalho;
<SOAP-ENV:Envelope xmlns:SOAP ENV=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>
<SOAP-ENV:Header>
<a:authentication xmlns:a=”http://www.mauricioreckziegel.com/soap/authentication”>
<a:username>Mauricio</a:username>
<a:password>Reckziegel</a:password>
</a:authentication>
</SOAP-ENV:Header>
<SOAP-ENV:Body>

</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
actor: especifica o receptor que deve processar o elemento do cabeçalho.
<SOAP-ENV:Envelope xmlns:SOAP ENV=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>
<SOAP-ENV:Header>
<a:authentication xmlns:a=”http://www.mauricioreckziegel.com/soap/authentication”
SOAP- ENV:actor=”http://www.mauricioreckziegel.com/soap/authenticator”><a:username>Mauricio</a:username>
<a:password>Reckziegel</a:password>
</a:authentication>
musUnderstand: especifica se uma entrada de cabeçalho é obrigatória ou opcional (booleano).
<SOAP-ENV:Envelope xmlns:SOAP ENV=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>
<SOAP-ENV:Header>
<a:authentication xmlns:a=”http://www.mauricioreckziegel.com/soap/authentication”
SOAP-ENV:mustUndestrand=”1”><a:username>Mauricio</a:username>
<a:password>Reckziegel</a:password>
</a:authentication>
Body (obrigatório): contém a codificação atual de uma chamada a um método e todos os argumentos de entrada ou uma resposta codificada que contém o resultado de uma chamada de um método.
. Fault: contém as informações dos erros ocorridos no envio da mensagem. Apenas nas mensagens de resposta do servidor.
O envelope SOAP é a parte obrigatória de uma mensagem SOAP. Ele funciona como um recipiente de todos os outros elementos da mensagem, possivelmente o cabeçalho e o corpo, assim como os namespaces de cada um. Assim como o nome e o endereço de uma carta entregue pelo correio, o envelope SOAP precisa das informações específicas do protocolo de transporte que está ligado a ele, com o intuito de garantir a chegada ao local certo. Especificamente no HTTP, temos um cabeçalho que se chama SOAPAction, indicador do endereço de entrega da mensagem. Um dos principais motivos de implementarmos o cabeçalho desta maneira é porque administradores de sistemas podem configurar seus firewalls para filtrar as mensagens baseadas nas informações dos cabeçalhos, sem consultar o XML.
Elemento
Namespace / URI
Envelope
http://schemas.xmlsoap.org/soap/envelope
Serializador
http://schemas.xmlsoap.org/soap/encoding
SOAP-ENV
http://schemas.xmlsoap.org/soap/envelope
SOAP-ENC
http://schemas.xmlsoap.org/soap/encoding
Xsi
http://www.w3.org/1999/XMLSchema-instance
Xsd
http://www.w3.org/1999/XMLSchema
Tabela. Namespaces / URI padrões do SOAP

4. RPC (Remote Procedure Call) 
Entre outras utilizações, SOAP foi desenhado para encapsular e transportar chamadas de RPC, e para isto utiliza-se dos recursos e flexibilidade do XML, sob HTTP.
RPCs ou chamadas remotas de procedimento, são chamadas locais a métodos de objetos (ou serviços) remotos. Portanto, podemos acessar os serviços de um objeto localizado em um outro ponto da rede, através de uma chamada local a este objeto. Cada chamada ou requisição exige uma resposta.
Processo de uma chamada RPC: Antes de serem enviadas pela rede, as chamadas de RPC (emitidas pela aplicação cliente) são encapsuladas (ou serializadas) segundo o padrão SOAP. O serviço remoto, ao receber a mensagem faz o processo contrário, desencapsulando-a e extraindo as chamadas de método. A aplicação servidora então processa esta chamada, e envia uma resposta ao cliente. O processo então se repete: a resposta é também serializada e enviada pela rede. Na máquina cliente, esta resposta é desencapsulada e é repassada para a aplicação cliente.
5. Web Service Description Language (WSDL) 
Documento WSDL
De que forma um cliente de um Web Service sabe qual formato dos métodos a serem chamados e quais parâmetros a serem passados? Como cliente e serviço sabem como processar uma requisição?
Para solucionar estes tipos de perguntas foi criado um documento, que utiliza uma linguagem chamada WSDL. WSDL ou Web Service Description Language é uma linguagem baseada em XML, utilizada para descrever um Web Service. Um Web Service deve, portanto, definir todas as suas interfaces, operações, esquemas de codificação, entre outros neste documento.
Um documento WSDL define um XML Schema para descrever um Web Service.
Tão logo o cliente tenha acesso à descrição do serviço a ser utilizado, a implementação do Web Service pode ser feita em qualquer linguagem de programação. Normalmente são utilizadas linguagem construídas para interação com a WEB, como por exemplo Java Servlets ou ASP, que, em seguida, chamam um outro programa ou objeto.
Basicamente, quando o cliente deseja enviar uma mensagem para um determinado Web Service, ele obtém a descrição do serviço (através da localização do respectivo documento WSDL), e em seguida constrói a mensagem, passando todos os parametros de acordo com a definição encontrada no documento. Em seguida, a mensagem é enviada para o endereço onde o serviço está localizado, a fim de que possa ser processada. O Web Service, quando recebe esta mensagem valida-a conforme as informações contidas no documento WSDL. À partir de então, o serviço remoto sabe como tratar a mensagem, sabe como processá-la (possivelmente enviando-a para outro programa) e como montar a resposta ao cliente.
6. Exemplos
SOAP sobre HTTP (POST) (Pedido)

POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<SOAP-ENV:Envelope
xmlns:SOAP- ENV="http://schemas.xmlsoap.org/soap/envelope/“
SOAP- ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m="Some-URI">
<symbol>DIS</symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>

</SOAP-ENV:Envelope>


SOAP sobre HTTP (Resposta)

HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<SOAP-ENV:Envelope
xmlns:SOAP- ENV="http://schemas.xmlsoap.org/soap/envelope/“
SOAP- ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Body>
<m:GetLastTradePriceResponse xmlns:m="Some-URI">
<Price>34.5</Price>
</m:GetLastTradePriceResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
7. SOAP em HTTP 
SOAP em HTTP
O SOAP teoricamente atua sobre qualquer protocolo de transporte, mas, sem dúvida nenhuma o http é o protocolo mais utilizado para a utilização de Web Services. Através do comando Post do HTTP é possível o envio das mensagens SOAP, utilizando-se da URI requisitora que especifica um destino ID. No cabeçalho do http, também temos um campo com o nome do método a ser chamado.
POST /rpcrouter HTTP/1.1
Host: 127.0.0.1
Content-Type: text/xml; charset=utf-8
Content-Length: 559
SOAPAction: “http://mauricio.com”
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope
xmlns:xsi="Schema-Instance"
xmlns:xsd="Schema"
xmlns:soap="Envelope">
<soap:Body>
<Converte xmlns="http://conv.com.br">
<Valor>5</Valor>
<De>DEC</De>
<Para>BIN</Para>
</Converte>
</soap:Body>
</soap:Envelope>

Através do HTTP Response é que obtemos uma resposta da solicitação SOAP. Note que alguns itens já não são mais necessários.
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope
xmlns:xsi="Schema-Instance"
xmlns:xsd="Schema"
xmlns:soap="Envelope">
<soap:Body>
<ConverteResponse xmlns="http://mauricio.com">
<ValorResult>101</ValorResult>
</ConverteResponse>
</soap:Body>
</soap:Envelope>
Fonte: http://www.gta.ufrj.br/grad/07_2/daniel/