Plano de implantação de uma arquitetura orientada a serviços SOA - na Câmara dos Deputados

Transcrição

1

2 Centro Universitário do Distrito Federal UDF Pós-Graduação Pesquisa e Extensão Especialização em Governança em TI no Setor Público Antonio José de Souza Pereira Plano de implantação de uma arquitetura orientada a serviços SOA - na Câmara dos Deputados Brasília DF 2012

3 Antonio José de Souza Pereira Plano de implantação de uma arquitetura orientada a serviços na Câmara dos Deputados Trabalho de conclusão de curso apresentado a Pós Graduação, Pesquisa e Extensão do Centro Universitário do Distrito Federal - UDF, como requisito parcial para obtenção do título de Especialista - MBA em Governança de Tecnologia da Informação no Serviço Público, sob a orientação do MSc. Prof. Flávio Feitosa Costa Brasília 02 de janeiro de 2012

4 Errata

5 Antonio José de Souza Pereira Plano de implantação de uma Arquitetura Orientada a Serviços SOA - na Câmara dos Deputados Trabalho de conclusão de curso apresentado a Pós Graduação, Pesquisa e Extensão do Centro Universitário do Distrito Federal - UDF, como requisito parcial para obtenção do título de Especialista - MBA em Governança de Tecnologia da Informação no Serviço Público, sob a orientação do MSc. Prof. Flávio Feitosa Costa Brasília 2 de janeiro de BANCA EXAMINADORA Flávio Feitosa Costa MSc. PMP Centro Universitário do Distrito Federal Nota:

6 Dedico este trabalho a minha esposa e filhos que procuram compreender minha ausência durante o longo período dedicado às atividades acadêmicas.

7 AGRADECIMENTO Agradeço a meus pais, José Manoel Pereira e Eliza de Souza Pereira, pelos fundamentos de caráter e ética tão arduamente ensinados e a todos os meus mestres, que encarnados em professores, amigos e colegas dos mais diferentes círculos de ação e convivência sempre estiveram presentes me incentivando ao crescimento e aprendizado contínuos.

8 Embora ninguém possa voltar atrás e fazer um novo começo, qualquer um pode começar agora e fazer um novo fim. Francisco Cândido Xavier.

9 RESUMO Este trabalho tem por objetivo apresentar um plano para implantação de uma Arquitetura Orientada a Serviços SOA, na Câmara dos Deputados Brasil. O plano de implantação SOA foi estruturado em dois projetos: Entender SOA e Implantar SOA, descritos em suas macro atividades e foi embasado em um arcabouço teórico fundamentado em significativa literatura pesquisada que incluiu os modelos de referência e de arquitetura SOA disponíveis. Foram abordados, além dos aspectos tecnológicos, as questões de Governança de TI e questões de cultura organizacional que precisam ser consideradas em projetos dessa natureza, considerando que SOA não é simplesmente uma questão de tecnologia, mas fundamentalmente uma questão de negócio e Governança Empresarial. Os aspectos de TI também foram explorados de forma suficiente para que as equipes técnicas tenham condições de implementar os princípios de desenho da arquitetura SOA. Palavras chave: SOA. Governança de TI. BPM. Arquitetura Orientada a Serviços. Gestão Estratégica. Câmara dos Deputados - Brasil. Centro de Informática CENIN.

10 ABSTRACT This paper aims to present a plan for deploying a Service Oriented Architecture - SOA, the Chamber of Deputies - Brazil. The SOA deployment plan was structured in two projects: "Understanding SOA" and "Deploy SOA" as described in its macro activities and was based on a theoretical framework based on a significant literature that included the reference models and SOA architecture available. Were discussed, in addition to technological aspects, the issues of IT governance and organizational culture issues that must be considered in projects of this nature, considering that SOA is not simply a technology issue, but fundamentally a matter of business and corporate governance. The IT aspects have also been exploited enough that the technical teams are able to implement the design principles of SOA. Keywords: SOA. IT Governance. BPM. Service Oriented Architecture. Strategic Management. Chamber of Deputies - Brazil. Computer Center - CENIN.

11 Lista de Abreviaturas e/ou siglas ABPMP Association of Business Process Management Professionals Associação dos Profissionais de Gerenciamento de Processos de Negócio APROGE BPMS CBOK CCS CENIN CIO IEEE OASIS SOA TI Assessoria de Projetos e Gestão Estratégica Business Process Management System Sistema de Gerenciamento de Processos de Negócio BPM Common Body of Knowledge Base de Conhecimento BPM Centro de Competência SOA Centro de Informática da Câmara dos Deputados Chief information officer Chefe de Tecnologia da Informação TI IEEE Computer Society Organização dedicada ao avanço da teoria e aplicação da informática e tecnologia da informação Organização para o Avanço de Padrões de Informação Estruturada Services Oriented Architecture Arquitetura Orientada a Serviços Tecnologia da Informação Lista de Figuras e Tabelas Figura 1 - Principais conceitos do Modelo de Referência Figura 2- Organograma da Câmara dos Deputados Tabela 1 - Comparativo de princípios de orientação a serviços Tabela 2 - Quadro resumo do Modelo de Referência SOA Tabela 3 - Ingredientes SOA - (JOSUTTIS, 2008) Tabela 4 - Estágios do ciclo de vida SOA (HIGH, KINDER e GRAHAM, 2005)... 37

12 Tabela 5 Questões essenciais para decisão de TI - (WEILL e ROSS, 2006) Tabela 6- Papéis e Responsabilidades propostos por Bieberstein (2006) para implementação de SOA Tabela 7- Exemplo de um formato para formulação de políticassoa (JOSUTTIS, 2008, p. 237) Tabela 8 - Vantagens do modelo de desenvolvimento tradicional (ERL, 2009) Tabela Desvantagens do desenvolvimento de sistemas tradicional (ERL, 2009) Tabela 10 - Os quatro níveis arquitetônicos propostos por Ross (2006) Tabela 11 - Estágios de maturidade de arquitetura Tabela 12 - Atributos para um Catálogo de Serviços simplificado... 75

13 SUMÁRIO 1 INTRODUÇÃO Tema Contexto Gestão por Processos Criação do Núcleo de Integração - SECOMP DELIMITAÇÃO DO PROBLEMA Formulação do Problema Objetivos Objetivo Geral Objetivos Específicos Metodologia REFERENCIAL TEÓRICO Arquitetura Orientada a Oerviços SOA Conceituando Arquitetura Serviços Comparando os modelos de implementação de Erl e Josuttis Arquitetura Orientada a Serviços OASIS e o Modelo de Referência SOA Josuttis (2008) e os ingredientes chave de SOA Os Fundamentos para a arquitetura SOA OASIS Julho/ Governança de ti e governança de SOA O Centro de Competência SOA - CCS Papéis e responsabilidades SOA Políticas SOA... 43

14 2.3 SOA na organização e o papel da TI MATURIDADE DA ARQUITETURA DE TI SOA E BPM ANÁLISE CRÍTICA E DESENVOLVIMENTO Contexto A estrutura organizacional da Câmara dos Deputados Estrutura funcional do Centro de Informática Gestão estratégica e estruturas de governança na Câmara dos Deputados Planejamento Estratégico do Centro de Informática da Câmara dos Deputados Resumo das principais características de contexto atual do Centro de Informática da Câmara dos Deputados Plano de projeto para implantação da SOA Projeto 1: Entender SOA Projeto 2: Implantar SOA Considerações Finais CONCLUSÃO BIBLIOGRAFIA CONSULTADA... 79

15 1 INTRODUÇÃO Este trabalho de conclusão de curso (TCC) apresenta uma proposta de um plano de implantação de Arquitetura Orientada a Serviços SOA na Câmara dos Deputados. Serão apresentados os principais conceitos e padrões que definem a arquitetura de forma a sustentar um plano de implantação que deverá considerar em primeiro plano os aspectos de governança organizacional e de tecnologia da informação. Embora focado principalmente no ambiente organizacional da Câmara dos Deputados, o plano proposto reúne conceitos e estratégias aplicáveis em qualquer organização principalmente às do serviço público. 1.1 TEMA Nas últimas 2 décadas pudemos verificar o grande crescimento dos departamentos de TI, tanto na área pública, como na iniciativa privada, numa profusão de sistemas e plataformas computacionais suportando os mais diversos processos de negócio. Metodologias, processos e arquiteturas se sucederam buscando conferir maior agilidade e efetividade na construção de soluções para problemas e processos cada vez mais complexos. No início, regra geral, as soluções de sistemas eram construídas para atender a departamentos ou processos específicos, sem grandes possibilidades de integração com outros sistemas e sem grandes preocupações com o reuso. Eram sistemas monolíticos, funcionais, difíceis de manter e de evoluir, apoiando processos relativamente estáveis. Em seu livro SOA Princípios de design de serviços, Thomas Erl descreve também esse cenário ao apresentar um estudo de caso da Cutit Saws Ltda uma empresa dedicada à fabricação de lâminas de corte. Nas palavras do autor: O ambiente de TI da Cutit é uma confusão de servidores e estações de trabalho. Hardwares e softwares são comprados conforme a necessidade pelos diferentes departamentos (ERL, 2009).

16 Ainda segundo o autor, um dos diretores e fundadores da empresa, com formação em ciência da computação, foi o desenvolvedor dos sistemas de contabilidade e estoques. As soluções caseiras desenvolvidas, conforme relata o autor, começaram, depois de algum tempo, a apresentar problemas de desempenho e de uso concorrente. Quando a empresa precisou ampliar seus negócios e se adaptar às novas condições de mercado, percebeu que os modelos e arquiteturas utilizadas para automação de seus processos eram rígidos e incapazes de responder aos novos desafios do mercado, o que ameaçava a sobrevivência da própria organização. No entanto, desenvolver novos sistemas seria muito caro e arriscado. Esse cenário parece ser muito comum em grande parte das empresas públicas e privadas. Apesar de rígidos e muitas vezes até ultrapassados, sistemas legados representam grandes investimentos já realizados. Muitas vezes é quase inviável, tanto por questões de tempo como pelos custos envolvidos, refazer essas aplicações, mesmo quando tal medida se mostra inadiável. Integrar sistemas através de uma arquitetura orientada a serviços e desenvolver novas aplicações com base nessa nova abordagem, parece ser a forma mais adequada de preservar investimentos realizados, prevenir o desperdício na construção de novas aplicações, integrar novos sistemas a sistemas legados, suportar as tendências de gestão por processos, gestão de conteúdo e assim por diante. Muitos autores se dedicaram a estabelecer modelos para uma arquitetura orientada a serviços com padrões de desenho, boas práticas, arquitetura, etc. Mas a questão é como iniciar a implantação de uma arquitetura orientada a serviços em uma empresa com seu parque computacional já estabelecido, com sistemas aparentemente estáveis, mesmo que obsoletos, com problemas culturais a serem enfrentadas, novas aquisições e mudança de paradigma. Esse trabalho de conclusão de curso procura alinhar os principais pontos de atenção para a formulação de um plano para implantação de uma arquitetura orientada a serviços em uma organização conhecida, com a elaboração de um projeto de implantação que considere não só as questões técnicas da arquitetura SOA, mas também as questões culturais e de governança.

17 1.2 CONTEXTO O Centro de Informática da Câmara dos Deputados (CENIN) foi criado em janeiro de 1997 através do Ato da Resolução 16, de Suas primeiras iniciativas de desenvolvimento de aplicativos foram voltadas para o desenvolvimento de sistemas de apoio ao processo legislativo; folha de pagamento; atividade parlamentar; consultas à base de dados de legislação e material e patrimônio. Posteriormente, logo nos primeiros anos de suas atividades, o CENIN desenvolveu aplicações para diversas outros processos administrativos, como: cotas parlamentares; manutenção e fornecimento de imóveis para ocupação pelos deputados; painel eletrônico de votação; emissão de passaporte parlamentar; e muitos outros. As aplicações, em sua maioria, eram desenvolvidas em plataforma cliente-servidor, com utilização de Visual Basic 6 (VB6) e componentes COM++. Alguns sistemas foram desenvolvidos em plataforma web, utilizando linguagem ASP ainda com a utilização de componentes COM++. O grande impulso das tecnologias relacionadas à internet, com a necessidade de criação de páginas para a web informativas, ocorrido entre o final da década de 1990 e os primeiros anos da década de 2000 indicou a necessidade de maior especialização de um segmento de desenvolvedores do CENIN para essa nova plataforma. Novas necessidades foram identificadas, como a especialização para o painel eletrônico de votação, reformulação da folha de pagamento e aplicações administrativas diversas, sendo então criados diversos núcleos de desenvolvimento para cada necessidade. Em 2002, a Câmara dos Deputados já contava com três bancos de dados corporativos: INGRES, SQL Server e Oracle e as aplicações estavam dispersas nessas três plataformas, compartilhando alguns dados através de replicações que não se limitavam apenas aos Sistemas Gerenciadores de Bancos de Dados (SGBD), mas também entre aplicativos diferentes em cada SGBD.

18 Em 2003 a Coordenação de Desenvolvimento de Sistemas, uma das coordenações responsáveis pela construção de aplicativos iniciou esforços para a definição de um processo de desenvolvimento baseado no Processo Unificado e direcionando as novas aplicações para a plataforma J2EE. Em 2011, a Câmara dos Deputados conta com aplicações desenvolvidas em Visual Basic, ASP e Java. Existem diversos bancos de dados com informações redundantes e divergentes entre si, com um alto custo de manutenção para as aplicações, dificuldades para evolução dos sistemas que começam a mostrar sinais de obsolescência. São, em geral, aplicações focadas em departamentos e processos muito específicos com baixíssimas possibilidades de integração com outros sistemas, reimplementando funcionalidades básicas como gestão de identidade e acesso e manutenção de dados corporativos, com uma visão muito limitada de processos horizontalizados, que permitam a colaboração entre os diversos departamentos da área administrativa Gestão por Processos Em 2009 o planejamento estratégico da Câmara dos Deputados estabeleceu a gestão de processos como um de seus objetivos. Dois sistemas iniciaram o seu ciclo de desenvolvimento partindo de uma abordagem de desenvolvimento orientado a processos, com bases em processos modelados pelas áreas de negócios, utilizando um BPMS. Logo nas primeiras iniciativas de automação ficaram evidentes as necessidades de consumo de dados de alguns sistemas legados, o que aumentou consideravelmente o risco para os projetos de desenvolvimento desses sistemas. A arquitetura monolítica dos sistemas legados e a cultura de integração entre esses sistemas através do acesso, replicação ou mesmo duplicação de dados mostrou-se totalmente ineficiente para uma abordagem de desenvolvimento orientado a processos, evidenciando a necessidade de integração através de uma camada de serviços que permitisse a colaboração entre os diversos sistemas.

19 1.2.2 Criação do Núcleo de Integração - SECOMP Para tentar contornar os problemas de integração entre sistemas e viabilizar o modelo de desenvolvimento orientado a processos, a Coordenação de Engenharia de Sistemas resolveu criar um pequeno núcleo de integração, a Seção de Administração de Componentes e Processos (SECOMP), cujo objetivo inicial seria incentivar a criação de componentes de negócio catalogados e gerenciados por esse mesmo núcleo. Essa parece ser uma abordagem bastante comum para integração entre sistemas, mas ainda não é suficiente para enfrentar todos os desafios. Aliás, mas do que integração, a gestão de processos aponta para a construção de uma arquitetura orientada a serviços, que poderá ser o próximo passo na evolução da área de sistemas do Centro de Informática da Câmara dos Deputados. A adoção de uma arquitetura orientada a serviços parece ser uma boa alternativa para dar mais flexibilidade e agilidade aos sistemas, apoiar a integração de sistemas legados e as iniciativas de gestão por processos. No entanto, sua implantação não é trivial. Mais do que os aspectos técnicos ela envolve questões culturais, novos modelos de desenvolvimento e mudança de paradigma no desenvolvimento de sistemas. Por isso, tal mudança precisa ser conduzida por um projeto bem elaborado, que minimize os riscos de fracasso do empreendimento, que poderia trazer como consequência o descrédito dos desenvolvedores na arquitetura orientada a serviços, perdendo-se assim a janela de oportunidade e adiando por tempo indeterminado a adoção do novo modelo. 1.3 DELIMITAÇÃO DO PROBLEMA Com este trabalho iremos propor um plano de implantação de uma arquitetura orientada a serviços (SOA), para o Centro de Informática da Câmara dos Deputados, considerando aspectos culturais e de governança específicos.

20 1.4 FORMULAÇÃO DO PROBLEMA A Câmara dos Deputados conta hoje com cerca de 200 sistemas desenvolvidos em diferentes linguagens de programação, servidores de aplicação e gerenciadores de bancos de dados. A profusão de sistemas e dados gerou ao longo do tempo grande redundância e inconsistências entre as diferentes bases de dados, com graves dificuldades para integração entre sistemas e principalmente para a evolução dos sistemas legados e desenvolvimento de novas aplicações. As dificuldades tornam-se mais evidentes com a adoção de modelos de desenvolvimentos orientados a processos e a necessidade de adaptação do centro de informática às diretrizes estratégicas de gestão de processos. Uma das alternativas é a adoção de uma arquitetura orientada a serviços (SOA), que representa uma mudança de paradigma de desenvolvimento para o Centro de Informática. Nesse cenário, a implantação de SOA precisa estar apoiada em um plano bem elaborado que minimize os riscos de fracasso na implantação, o que poderia atrasar por tempo indeterminado a solução dos problemas apontados. 1.5 OBJETIVOS Objetivo Geral Elaborar um plano de implantação de uma Arquitetura Orientada a Serviços para a Câmara dos Deputados Objetivos Específicos a) Apresentar as principais características técnicas da arquitetura SOA, que precisarão ser implementadas b) Avaliar as questões de governança e gerenciamento a serem considerados no projeto de implantação. c) Elaborar o plano de implantação de SOA na Câmara dos Deputados

21 1.5.3 Metodologia Para elaboração deste trabalho serão consultadas fontes bibliográficas sobre os padrões de desenho e arquitetura orientados a serviços e governança SOA. As questões culturais e estratégicas que formam o contexto organizacional da Câmara dos Deputados, serão avaliadas a partir da documentação disponível no próprio sitio web da Organização. Ao final será formulado um plano para implantação de SOA baseado em projetos a serem executados e que considera os aspectos técnicos, culturais e de governança estudados.

22 2 REFERENCIAL TEÓRICO 2.1 ARQUITETURA ORIENTADA A OERVIÇOS SOA Nos últimos anos, a Arquitetura Orientada a Serviços SOA vem sendo apresentada como importante estratégia para incremento de produtividade e competitividade das empresas. Ela é uma abordagem que ajuda os sistemas a permanecerem escaláveis e flexíveis enquanto crescem, e que também ajuda a resolver a lacuna negócio/ti. (JOSUTTIS, 2008, p. 1) No entanto, o significado exato do termo, suas implicações no modelo de desenvolvimento de sistemas e na própria arquitetura de TI parece não estar suficientemente claro para boa parte das organizações e profissionais envolvidos. [...] o termo Arquitetura Orientada a Serviços e sua sigla associada são utilizados tão amplamente pela mídia e na literatura de marketing dos fornecedores, que se tornou quase um sinônimo para a própria computação orientada a serviços. É, portanto, muito importante fazer uma distinção clara entre o que a SOA e de fato e como ela se relaciona com outros elementos da computação orientada a serviços. (ERL, 2009, p. 24) Conceituando Arquitetura Para a IEEE 1471, arquitetura é a organização fundamental de um sistema incorporado em seus componentes, suas relações comuns aos outros e ao meio ambiente e os princípios orientadores da sua concepção e evolução. (MAIER, EMERY e HILLIARD, 2000, p. 6) A arquitetura de sistemas existe no plano conceitual. Isso significa que todo sistema organiza-se fundamentalmente em uma arquitetura, quer tenha sido ela explicitamente desenhada ou não. Entretanto, a descrição de uma arquitetura não é a própria arquitetura, mas uma descrição, segundo um ponto de vista. Uma arquitetura é articulada do ponto de vista das partes interessadas onde seus interesses determinam a sua aptidão para uma finalidade, e tudo isso deve ser entendido no seu contexto ambiental. (MAIER, EMERY e HILLIARD, 2000).

23 A descrição de uma arquitetura deve considerar visão e pontos de vista dos interessados. Visão refere-se ao que está sendo observado e ponto de vista refere-se à posição do observador. Assim, de acordo com o estudo realizado por High (2005, p. 13), na perspectiva do negócio, SOA trata da modelagem do negócio, incluindo desenho e refinamento dos processos. Nessa linha, ainda segundo o autor, Os arquitetos de sistemas de informação irão descrever SOA como um estilo de arquitetura que estrutura artefatos de sistemas de informação como um conjunto de serviços que podem ser agrupados para formar outros serviços ou mesmo como um conjunto de princípios para o baixo acoplamento, modularidade, reuso, etc para alcançar objetivos relacionados a ganhos de produtividade e competitividade para o negócio. (HIGH, KINDER e GRAHAM, 2005) Continuando nesse raciocínio, na perspectiva dos programadores, SOA seria um conjunto modelos de programação e ferramentas para construir, acessar e desenvolver serviços que implementam o desenho de negócio. (HIGH, KINDER e GRAHAM, 2005, p. 13) Numa arqutetura orientada a serviços, não estamos nos referindo apenas às questões de tecnologia da informação, mas à própria estrutura da organização, na forma como os serviços serão identificados e automatizados, como irão agregar valor, como serão governados e gerenciados. Naturalmente, a descrição da arquitetura orientada a serviços irá variar em abordagem, conforme observada por interessados no nível estratégico, tático ou gerencial, e ainda pelas equipes de TI. No entanto, é preciso que haja um entendimento integrado e coerente a respeito desses diferentes pontos de vista. Stal afirma que melhores implementações de SOA são obtidas quando os desenvolvedores entendem esse paradigma por uma perspectiva de arquitetura. Para ele, o objetivo central de uma abordagem de Orientação a Serviços é reduzir as dependências entre as chamadas ilhas de software. (STAL, 2006, p. 55) Para Josuttis, SOA não é uma ferramenta ou framework que se possa comprar. É uma abordagem, uma maneira de pensar, um sistema de valores que

24 leva a certas decisões concretas quando se projeta uma arquitetura de software. (JOSUTTIS, 2008, p. 12) Serviços A OASIS define serviços como um mecanismo para habilitar o acesso a uma ou mais competências, fornecidas por um provedor de serviço, com base em uma interface e uma descrição que inclui políticas e restrições de uso. (MACKENZIE, LASKEY, et al., 2006, p. 13) Erl (2009) afirma que serviços existem como programas de software fisicamente independentes, com características de design distintas. Esses serviços dão suporte ao alcance dos objetivos estratégicos associados à computação orientada a serviços. Para ele, um único serviço pode fornecer uma coleção de capacidades. Tais funcionalidades são agrupadas porque se relacionam a um contexto funcional estabelecido pelo serviço Princípios de design de serviços proposto por Thomas Erl Erl (2009) entende que a chave para ser bem-sucedido na implementação de uma arquitetura orientada a serviços está em compreender o significado de seu bloco de construção fundamental que é o serviço. Para o autor, a orientação a serviços é um paradigma que abrange um conjunto específico de oito princípios de design, onde a unidade mais fundamental da lógica orientada a serviços é o serviço. (ERL, 2009, p. 25) Os oito princípios de design de serviços identificados pelo autor são: 1. Contrato de serviço padronizado Os serviços expressam seu propósito e suas capacidades por meio de um contrato de serviços. Segundo Erl (2009), este seja talvez o componente mais importante da orientação a serviços. No contrato de serviço ficam estabelecidos a natureza e a quantidade de conteúdo que será publicado. Inclui também a forma como os serviços irão expressar suas funcionalidades, além de granularidade e outras questões relacionadas à consistência, confiabilidade e governabilidade.

25 O autor esclarece ainda que um contrato de serviço é muito mais do que uma interface técnica, como algumas vezes é considerado. Um contrato de serviços pode ser composto de um grupo de documentos de descrição dos serviços, cada um dos quais descrevendo uma parte do serviço (ERL, 2009, p. 76) 2. Baixo acoplamento de serviço Defende o estabelecimento de um tipo específico de relacionamento dentro e fora dos limites do serviço, com ênfase em reduzir ( baixar ) as dependências entre o contrato do serviço, sua implementação e os consumidores do serviço. Ainda segundo o autor, este princípio permite que o design e a lógica de um serviço possam evoluir independentemente de sua implementação, ao mesmo tempo em que garante a interoperabilidade básica com consumidores que se utilizam das capacidades do serviço. 3. Abstração Em um nível fundamental, esse princípio enfatiza a necessidade de ocultar o maior número possível de detalhes subjacentes de um serviço. (ERL, 2009, p. 46) O princípio da abstração estabelece que o contrato de serviço deve conter apenas informações relevantes para o usuário do serviço. Detalhes de implementação e outros, desnecessários não devem estar presentes no contrato. O nível de abstração do serviço precisa ser adequadamente planejado durante a fase de implementação do serviço. Excesso de informação pode induzir ao uso indevido do serviço, resultando em futuros problemas de acoplamento. Falta de informação poderia trazer prejuízos para sua utilização e reuso. Como esse princípio resulta na ocultação deliberada de informações, precisamos determinar cuidadosamente que informações devem ser expostas. Cada parte dos metadados disponível pode ser utilizada de um modo que pode ter consequências inesperadas no futuro. (ERL, 2009, p. 140) 4. Capacidade de reuso de serviço

26 O autor considera a capacidade de reuso como um dos mais importantes princípios para alcançar os objetivos da computação orientada a serviços, que é também uma meta há muito perseguida em vários modelos de desenvolvimento. Sob essa perspectiva, talvez não haja outro princípio mais fundamental para alcançar os objetivos da computação orientada a serviços do que o da capacidade de reuso. (ERL, 2009, p. 148) No entanto, segundo o autor, o conceito apesar de simples, é de difícil implementação e muitos daqueles que fizeram parte de iniciativas de reuso mal sucedidas acabaram se desiludindo com essa proposta. Dentre os principais fatores que contribuíram para o fracasso das iniciativas de implantação de reuso, Erl (2009) destaca: a) potencial de reuso limitado a ambientes e ou programas proprietários; b) componentes projetados com fortes dependências em outros componentes, via estruturas de herança, e outras de alto acoplamento; c) componentes reusáveis não eram utilizados o suficiente; d) componentes reusáveis equipados com funcionalidade desnecessárias. Para o autor, para que um serviço alcance a capacidade de reuso, sua lógica precisa ser implementada da forma mais neutra e agnóstica possível. Ele estabelece então o conceito de serviço agnóstico : Um serviço é agnóstico quando sua lógica é independente dos processos de negócio e da plataforma tecnológica proprietária ou de aplicativos proprietários. (ERL, 2009, p. 155) Então, para Erl (2009) um serviço terá um bom potencial de reuso se puder fornecer capacidades que não são específicas a qualquer processo de negócio e for útil à automação de mais de um processo de negócio. 5. Autonomia de serviço O princípio da autonomia estabelece a independência de um serviço com relação ao seu ambiente e outros serviços. Para os serviços realizarem suas capacidades de modo consistente e confiante, sua lógica precisa ter um grau de significativo de controle sobre seu ambiente e recursos. (ERL, 2009, p. 46) Se houver um programa de software em um estado autônomo em runtime, esse programa será capaz de realizar sua lógica independentemente de

27 influências externas. Ele, portanto, deve ter o controle para se governar em runtime. Quanto mais controle o programa tiver sobre o ambiente de execução em runtime, mais autonomia poderá reivindicar. (ERL, 2009, p. 170) Maior autonomia ajuda a alcançar maior confiabilidade e previsibilidade dos programas de software. Por isso, o autor considera a autonomia como uma consideração-chave de design, sendo um princípio de design que irá suportar o reuso e a composição de serviços. 6. Independência de estado do serviço O estado refere-se à condição atual de alguma coisa. Um avião, por exemplo, poderia estar em solo ou em voo e esses seriam dois estados possíveis para a aeronave. No caso de serviços, poderíamos exemplificar os estados ativo e inativo. O princípio da independência de estado estabelece que os serviços agnósticos, para alcançarem seus objetivos de reuso e composição, precisam ser projetados de forma a consumir o mínimo de recursos computacionais no processamento de dados referentes ao gerenciamento de seu próprio estado, delegando, ao máximo essa tarefa. O gerenciamento de excessivas informações de estado pode comprometer a disponibilidade de um serviço e minar o seu potencial de capacidade de escala. Desse modo, os serviços são, idealmente, projetados para manterem informações de estado apenas quando estas forem necessárias. (Erl, 2009, p.46). Segundo Erl (2009), esse princípio enfatiza a necessidade de reduzir ou eliminar o consumo de recursos de sistema, decorrente de processamento desnecessário do gerenciamento de estado. 7. Visibilidade do serviço Uma das questões chave com que o desenvolvedor de software, em uma arquitetura orientada a serviços se depara é se as funcionalidades que ele precisa utilizar já existem ou se precisarão ser implementadas. Isso requer um catálogo de serviços adequadamente construído, de forma a garantir acesso a informações sobre o serviço como: seu propósito; suas capacidades e suas limitações.