Avaliando soa em uma empresa de ti

508 visualizações

Publicada em

Conhecendo os conceitos SOA e avaliando a necessidade dentro de um ambiente de uma empresa de TI

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
508
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1
Ações
Compartilhamentos
0
Downloads
10
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Avaliando soa em uma empresa de ti

  1. 1. Universidade Federal de Pernambuco Centro de Informática Especialização em Tecnologias da Informação para Formação AVALIANDO ARQUITETURAS ORIENTADAS A SERVIÇOS EM UMA EMPRESA DE TECNOLOGIA DA INFORMAÇÃO (TI) por RODRIGO MINERVINO PEREIRA Recife, junho de 02
  2. 2. Agradecimentos Agradeço primeiramente aos meus pais, que me ofereceram tudo o que foi possível, para que eu me tornasse um pós-graduado com apenas 23 anos, um especialista em Tecnologia de Informação. Um agradecimento em especial a minha namorada Evinha (como gosta de ser chamada), que me ajudou muito na preparação e finalização da monografia. Ainda mais tendo que me aturar em momentos difíceis e de forte estresse. Agradeço a minha irmã, tios, primos e minhas avós que sempre me deram força e sempre acreditaram no meu potencial. Aos meus amigos, que sem eles nada nessa vida seria possível. Obrigado ao meu orientador Sérgio Soares, que sempre me cobrou quando necessário, e me fez produzir uma monografia de boa qualidade. Agradeço muito ao pessoal da Pitang, local em que trabalho, que mesmo o projeto estando em fases de finalização, me deu a oportunidade de acabar a minha especialização. Agradecimento em especial a Flávio Almeida que me ajudou muito na produção da monografia. Por fim agradeço a todos aqueles que torcem pelo meu sucesso. “Sucesso Total e Absoluto” (Flávio Almeida).
  3. 3. Sumário LISTA DE FIGURAS _________________________________________ V LISTA DE TABELAS ________________________________________ VI RESUMO_________________________________________________ VII ABSTRACT_______________________________________________ VIII CAPÍTULO 1 INTRODUÇÃO __________________________________9 1.1 Motivação ________________________________________________________________ 9 1.2 Objetivo_________________________________________________________________ 10 1.2.1 Objetivo Geral _______________________________________________________ 10 1.2.2 Objetivos Específicos __________________________________________________ 10 1.3 Organização da monografia ________________________________________________ 11 CAPÍTULO 2 ORIENTAÇÃO A SERVIÇOS______________________12 2.1 Introdução ______________________________________________________________ 12 2.2 Princípios de projeto da Arquitetura orientada a serviços _______________________ 13 2.2.1 Contratos de serviços _____________________________________________________ 13 2.2.2 Acoplamento de serviços __________________________________________________ 15 2.2.3 Abstração de serviços_____________________________________________________ 20 2.2.4 Capacidade de reuso de serviços ____________________________________________ 21 2.2.5 Autonomia de serviço ____________________________________________________ 24 2.2.6 Independência de estado __________________________________________________ 25 2.2.7 Visibilidade do serviço____________________________________________________ 27 2.2.8 Composição de serviços___________________________________________________ 28
  4. 4. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) iv CAPÍTULO 3 TECNOLOGIAS ________________________________33 3.1 Web service______________________________________________________________ 33 3.2 XML ___________________________________________________________________ 34 3.3 SOAP___________________________________________________________________ 36 3.4 WSDL __________________________________________________________________ 38 3.5 UDDI ___________________________________________________________________ 40 3.6 ESB ____________________________________________________________________ 41 CAPÍTULO 4 IMPLANTANDO SOA EM UMA EMPRESA TI ________43 4.1 Implantação em um novo projeto____________________________________________ 44 4.2 Adaptação dos projetos já em andamentos ____________________________________ 44 4.3 Cenário de implantação de SOA em uma empresa de TI_________________________ 45 CAPÍTULO 5 CONSIDERAÇÕES FINAIS _______________________49 5.1 Contribuições ____________________________________________________________ 50 5.2 Trabalhos futuros_________________________________________________________ 51 5.3 Aprendendo a vender SOA na sua empresa ___________________________________ 52 REFERÊNCIAS_____________________________________________55 ANEXOS __________________________________________________60
  5. 5. Lista de Figuras FIGURA 1: ALTO ACOPLAMENTO. (VENTURA, 2008). _________________________16 FIGURA 2: WEB SERVICE. (OLIVEIRA E. C., 2009) __________________________34 FIGURA 3: EXEMPLO DE UM ARQUIVO XML. (WIKIPÉDIA, 2010) _________________36 FIGURA 4: EXEMPLO DE UM ENVELOPE SOAP. (WIKIPÉDIA, 2009)_______________37 FIGURA 5: EXEMPLO DE UM WEB SERVICE UTILIZANDO SOAP. (MSDN MICROSOFT, 2003)_______________________________________________________38 FIGURA 6: DIAGRAMA DE UM DOCUMENTO WSDL. (W3C ,2001) ________________39 FIGURA 7: EXEMPLO DA RELAÇÃO DO UDDI ENTRE OUTROS PROTOCOLOS. (OASIS, 2006)_______________________________________________________40 FIGURA 8: EXEMPLO DE UMA APLICAÇÃO SOA UTILIZANDO ESB. (PROGRESS SOFTWARE, 2010) _____________________________________________42 FIGURA 9: CENÁRIO DE IMPLANTAÇÃO DE SOA PARA GRANDES EMPRESAS. (GARTNER, 2008)_______________________________________________________47 FIGURA 10: CENÁRIO DE IMPLANTAÇÃO DE SOA PARA MÉDIAS E PEQUENAS EMPRESAS. (GARTNER, 2008) ______________________________________________48
  6. 6. Lista de Tabelas TABELA 1: PERFIL DO PRINCÍPIO DO CONTRATO DE SERVIÇOS. __________________15 TABELA 2: PERFIL DO PRINCÍPIO DO BAIXO ACOPLAMENTO DE SERVIÇOS. __________18 TABELA 3: RESUMO DOS TIPOS DE ACOPLAMENTO E INFLUÊNCIAS ASSOCIADAS. _____19 TABELA 4: PERFIL DO PRINCÍPIO DA ABSTRAÇÃO DE SERVIÇO. __________________21 TABELA 5: PERFIL DO PRINCÍPIO DA CAPACIDADE DE REUSO DE SERVIÇO. __________24 TABELA 6: PERFIL DO PRINCÍPIO DA AUTONOMIA DE SERVIÇO. __________________25 TABELA 7: PERFIL DO PRINCÍPIO DA INDEPENDÊNCIA DE ESTADO DO SERVIÇO._______27 TABELA 8: PERFIL DO PRINCÍPIO DA VISIBILIDADE DO SERVIÇO. __________________28 TABELA 9: PERFIL DO PRINCÍPIO DA COMPOSIÇÃO DE SERVIÇO. _________________32
  7. 7. Resumo O grande desafio das fábricas de software é o aumento da produtividade mantendo o nível de qualidade dos softwares. Os princípios da arquitetura orientada a serviços (SOA) têm técnicas, que possibilita a percepção do aumento da produtividade em um espaço curto de tempo. Grandes estudiosos afirmam que SOA é uma arquitetura conceitual, que cria serviços com perfis que atendam as suas normas ou princípios. Esses serviços são criados para retirar, por exemplo, lógicas repetidas onde esta seja independente e reutilizada. O objetivo desse trabalho é de propor uma solução arquitetural para aumentar a produtividade e manter a qualidade do software. O uso de tecnologias no desenvolvimento de SOA, que já são conhecidas pelo mercado, é fundamental para que esta agilidade na construção seja visível. E que não passe de mais uma sugestão de melhoria de código (software) sem sucesso. Contudo é sobre esta arquitetura e seus princípios, que será apresentado este trabalho. Palavras-chave: software, serviços, arquitetura orientada a serviços, princípios.
  8. 8. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) viii Abstract The challenge of software factories is increasing productivity while maintaining the quality of software. The principles of service-oriented architecture (SOA) are techniques which allow the perception of increased productivity in a short space of time. Great scholars argue that SOA is a conceptual architecture, which creates profiles with services that meet its standards or principles. These services are designed to remove, for example, where repeated this logic is independent and reused. The aim of this paper is to propose an architectural solution to increase productivity and maintain quality software. The use of technologies in the development of SOA, which are already known by the market, is key to this speed in construction is visible. And that as just a suggestion for improving the code (software) without success. But this is about architecture and its principles, which will be presented this work. Keywords: software, services, service-oriented architecture, principles.
  9. 9. Capítulo 1 Introdução Esse capítulo apresenta a motivação e os objetivos deste trabalho, informando quais os principais problemas encontrados dentro de uma empresa de tecnologia da informação que incentivou a pesquisa e produção do mesmo. Tem como foco o aumento da produtividade, ou seja, produzir mais em menos tempo (Saturino, 2009). Dessa forma visa-se evitar esforços, pois segundo a MSW Métricas e Software cerca de 50% a 70% dos esforços gastos no programa serão perdidos após realizar a entrega ao cliente. 1.1 Motivação A motivação desse trabalho é aumentar a agilidade, a qualidade das soluções de software, utilizando alguns princípios da arquitetura orientada a serviços, gerando assim menos bugs e uma maior satisfação dos clientes. Visto que, é percebido como um dos grandes obstáculos encontrados no desenvolvimento de software (RD Consultoria, 2009). “O grande desafio das fábricas de software é produzir atendendo às necessidades do cliente sob aspectos funcionais e de qualidade, cumprindo prazos cada vez menores e torná-lo viável aos investimentos dos clientes“ (Saturino, 2009). Atualmente é percebido que as falhas de planejamento, de construção de software, são apresentadas frequentemente a cada novo projeto. Mas Segundo Saturino (2009), o processo de software deve ter um mecanismo de melhorias contínuas, sendo aperfeiçoado a cada novo projeto. Fábricas de softwares sentem um pouco mais este problema, pois os projetos são desenvolvidos por equipes diferentes que, em geral, não investem tempo para discutir os problemas encontrados anteriormente. Devido à pressão para produzir mais, com melhor qualidade e em um tempo cada vez menor. Como experiência vivenciada pelo autor desta monografia, percebe-se que
  10. 10. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 10 a agilidade na produção é uma preocupação frequente das equipes de desenvolvimento. Esta informação sempre está sendo medida e comparada para avaliar o desempenho do projeto, buscando a satisfação do cliente, que segundo a RD Consultoria (2009): o cliente é a pessoa mais importante, pois o sucesso e a própria existência da empresa de software dependem dele. Pode-se conseguir a satisfação do cliente construindo software de qualidade que permita a diminuição de erros inesperados, evitando, dessa forma, desperdiçar tempo com esforços na correção dos erros. Tendo em vista que um software de qualidade permite que se consiga um aumentando na produtividade da construção do software. Desta forma uma empresa de TI obtém seu objetivo satisfazendo seu cliente, entregando os projetos em um tempo hábil. 1.2 Objetivo A seguir são apresentados o objetivo geral e os objetivos específicos. 1.2.1 Objetivo Geral O objetivo geral deste trabalho é diminuir o retrabalho das equipes de softwares; diminuindo os esforços com correções de erros inesperados, causando uma menor quantidade de horas extras. Ou seja, aumentar a produtividade na construção de softwares mantendo uma boa qualidade para evitar uma grande quantidade de erros. 1.2.2 Objetivos Específicos Aumentar o conhecimento referente à arquitetura orientada a serviços (SOA) dos colaboradores das organizações de TI, o qual foi um ponto de dificuldade na pesquisa para a elaboração deste trabalho. Mostrar tecnologias essenciais no desenvolvimento de SOA, visto que na produção de software a escolha certa das melhores tecnologias proporciona uma
  11. 11. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 11 melhor construção, baseada no conceito da orientação a serviços. Sugestão de implantação da arquitetura orientada a serviços, em projetos novos ou a adaptação em projetos que já estão em andamento, mostrando um passo a passo de como fazê-la segundo especialistas. 1.3 Organização da monografia Esta monografia esta organizada da seguinte forma: No Capítulo 2, Orientação a serviços, são apresentadas as definições sobre o conceito da orientação a serviços, exibindo todos os seus princípios. No Capítulo 3, Tecnologias, são apresentadas as definições das tecnologias mais conhecidas para o desenvolvimento de uma arquitetura orientada a serviços (SOA). No Capítulo 4, Implantando SOA em uma empresa de TI, são propostas algumas maneiras de implantação da arquitetura orientada a serviços de acordo com a grandeza da empresa e o momento do projeto escolhido. No Capítulo 5, Considerações Finais, são abordadas as conclusões tiradas pela pesquisa para produzir a monografia e quais foram às dificuldades encontradas. Também são exibidos quais os trabalhos futuros esperados e um passo a passo de como vender SOA.
  12. 12. Capítulo 2 Orientação a Serviços Nesse capítulo é introduzido o conceito de orientação a serviços e os seus princípios, que devem ser encarados como boas práticas. Para que os objetivos citados sejam alcançados e os problemas encontrados corrigidos, é necessário seguir tais princípios. 2.1 Introdução Existem alguns mitos referentes ao conceito de SOA. Muitos acreditam que é uma tecnologia, outros que é uma ferramenta, ou ainda um produto, no entanto o conceito da arquitetura orientada a serviços segundo Gabriel (2008) diz respeito: “A arquitetura orientada a serviços na verdade é um conceito arquitetural corporativo que permite a criação de serviços interoperáveis, que podem facilmente ser reutilizáveis e compartilhados entre aplicações e empresas.” SOA é utilizada como uma arquitetura de software conceitual que utiliza um conjunto de características ou princípios, que servem como boas práticas para a aplicação dentro dos projetos e até mesmo dentro da organização. Tendo em vista que ambos propõem um meio de alcançar algo com base na experiência ou na aceitação por todo mercado, segundo especialistas. Esta estrutura de software implementa serviços aprimorando a eficiência, agilidade e a produtividade dentro da empresa, reutilizando funcionalidades de negócios dentro da organização, fazendo com que os serviços sejam os principais meios das soluções lógicas. Os serviços são programas de software que são fisicamente independentes do projeto principal e com características de projeto (design) distintas. Cada serviço recebe seu próprio contexto funcional e um conjunto de capacidades
  13. 13. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 13 relacionadas a esse contexto. Os contratos de serviços públicos servem para expor as capacidades dos serviços, ou seja, aquilo que eles estão dispostos a fazer, para os programas externos (Erl, 2009). Como citado anteriormente, no que diz respeito às características de SOA, existem duas que são mais voltadas para a organização das funcionalidades e serviços, que são a composição e o inventário de serviços, as quais serão explicitadas na Seção 2.2.8. Uma implementação SOA, como forma de arquitetura, pode consistir em uma combinação de tecnologias e produtos, que auxiliarão no desenvolvimento dos princípios da arquitetura orientada a serviços. Contudo sabe-se que está combinação de tecnologias e produtos é uma decisão de projeto. Um projeto que possui vários serviços acoplados à implementação, não garante que a arquitetura e os negócios sejam orientados a serviços, pois alguns princípios devem ser seguidos, como exposto na Seção 2.2. No entanto, se faz necessário que a cultura da organização e as condições financeiras do projeto sejam favoráveis, para que tanto a arquitetura quanto os negócios sejam orientados a serviços. 2.2 Princípios de projeto da Arquitetura orientada a serviços O princípio de projeto representa, no momento de construir soluções, algo fundamental para dar forma, da maneira ideal, à lógica (Erl, 2009). Existem oito princípios básicos, que fornecem regras e diretrizes, que ajudam a determinar exatamente como a lógica deve ser decomposta e modelada em unidades distribucionais. Esses princípios serão detalhados nas seções a seguir. 2.2.1 Contratos de serviços O contrato de serviço é um dos princípios ou normas de modelagem mais
  14. 14. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 14 importantes para a visibilidade, à autonomia e o reuso do serviço, pois são neles que estão sendo expostas todas as características, ou seja, todas as funcionalidades que poderão ser usadas por outras aplicações ou serviços. A abstração de ferramenta e tecnologia, características e limitações, dados não técnicos, detalhes da implementação, são informações que tornam um contrato de serviço fundamental para que a aplicação seja capaz de crescer e modificar sem que haja grandes, ou nenhum, impacto no lado do consumidor de tais serviços. Segundo Gabriel (2009), tais contratos são capazes de traduzir com detalhes a funcionalidade dos serviços específicos para que os clientes possam buscá-los e utilizá-los conforme sua necessidade. Mas existem algumas dificuldades: “Para que todos os detalhes de implementação de um serviço sejam especificados, são necessários diversos padrões de contratos a serem utilizados por toda a corporação. Isso pode se tornar uma tarefa complexa caso haja a necessidade de migração de documentos (já criados) para o conjunto de padrões escolhidos.” (GABRIEL, 2009) Os padrões WSDL (Web Service Description Language), UDDI (Universal Description Discovery Integration), SOAP (Simple Object Access Protocol) são muitos utilizados no dia-a-dia e serão explicados com mais detalhes no Capítulo 3. Portanto, um contrato é um documento textual que descreve o que o serviço faz. É de grande importância que o desenvolvimento do contrato seja acompanhado com a construção das funcionalidades do serviço, pois este tende a evoluir e o contrato deve conter todas as características do mesmo, considerando possíveis evoluções. Este é um dos maiores riscos encontrados, pois o controle de versão nem sempre é feito. Outra dificuldade é a deficiência de ferramentas para o desenvolvimento.
  15. 15. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 15 Segue abaixo a Tabela 1, com o perfil que o serviço tem que ter para atender o princípio de contrato de serviços, segundo Erl (2009): Perfil do princípio Breve definição Serviços compartilham contratos padronizados Definição completa Cada contrato de serviços deve estar de acordo com os mesmos padrões de design aplicados a contratos de outros serviços dentro de um inventário de serviços. Objetivos 1. Ativar serviços com um nível significativo da interoperabilidade natural dentro do limite de um inventário de serviços. Isso reduz a necessidade de transformação de dados, por que os modelos de dados consistentes são utilizados para a troca da informação; 2. Permitir que o propósito e as capacidades dos serviços sejam entendidos de maneira mais fácil e intuitiva. Característica de design 1. Um contrato de serviços (composto por uma interface técnica ou um ou vários documentos de descrição de serviços) deve ser fornecido com o serviço; 2. O contrato de serviços é padronizado pelo aplicativo de padrões de design. Tabela 1: Perfil do princípio do contrato de serviços. 2.2.2 Acoplamento de serviços Outro princípio de SOA é o acoplamento de serviços. O conceito de baixo e alto acoplamento ainda sofre por má compreensão, pois não é algo que ouvimos com tanta freqüência. O alto acoplamento é um serviço que possui uma grande dependência de outros para que seu fluxo principal funcione, por exemplo, em uma engrenagem onde para que a mesma funcione é necessário que todas suas peças estejam trabalhando em conjunto, como ilustra a Figura 1 abaixo:
  16. 16. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 16 Figura 1: Alto acoplamento. (Ventura, 2008). Um serviço não é apenas acoplado ou desacoplado (Schmelzer, 2007), existe um grau de granularidade do acoplamento. Um serviço nunca será 100% desacoplado, mas o desafio é achar o grau de desacoplamento que torne o serviço flexível para compor outros serviços e com custo não tão elevado (Schmelzer, 2007). Um dos principais objetivos de um serviço é que tenha a mínima dependência com um mundo exterior, ou seja, tenha um baixo acoplamento com os seus consumidores (Erl, 2009). Para que isso seja possível, é comum utilizar a tecnologia chamada ESB (Enterprise Service Bus), a qual abstrai a forma de troca de mensagens feitas pelos sistemas. Usando o ESB, o arquiteto de software reúne aplicações e componentes integrados para criar conjunto de serviços de processos de negócios. Por exemplo, existem aplicações de diferentes tecnologias (.NET, JAVA, PHP e etc.) que se comunicam por diferentes protocolos, como por exemplo SOAP, RNI, REST e JNI. No entanto essas formas de comunicação devem ser abstraídas pelo serviço para que, dessa forma, exclua a dependência do protocolo de comunicação, sendo esta a principal finalidade do ESB. O contrato de serviço é fundamental, pois nele será informado qual o máximo de acoplamento que o serviço terá e quais são os critérios escolhidos para a utilização da aplicação. É interessante também ter vários contratos,
  17. 17. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 17 diminuindo dessa forma o acoplamento da lógica central, ou seja, formular várias formas de entradas e saídas de informações. É importante ter bastante cuidado, pois a busca do menor acoplamento pode trazer problemas de desempenho e de manutenção, pois as soluções serão complexas, utilizando soluções reutilizáveis com alguns padrões de projetos (Gamma, Helm, Johnson, & Vlissides ,2000). Segunto Erl (2009), quando se busca uma flexibilidade excessiva, é necessário que a lógica do serviço realize processamento extra, para interpretar os dados recebidos, por exemplo, aumentando os requisitos de desempenho. Para atingirmos este baixo acoplamento o serviço deve ter um perfil que atenda ao princípio de Acoplamento de serviços. Segue a abaixo a Tabela 2 que ilustra o que foi citado acima (Erl, 2009).
  18. 18. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 18 Perfil do princípio Breve definição Serviços são fracamente acoplados. Definição completa Contratos de serviços impõem baixos requisitos de acoplamento de consumidor e são desacoplados de seu ambiente adjacente. Objetivos Ao promover consistentemente um acoplamento reduzido dentro e entre os serviços, trabalhamos em direção a um estado em que os contratos de serviços aumentam a independências com base em suas implementações, e os serviços são cada vez mais independentes entre si, Isso promove um ambiente no qual os serviços e seus consumidores podem evoluir e se adaptar ao longo do tempo, com impacto mínimo um sobre o outro. Característica de design 1. Existência de um contrato de serviços que, idealmente, é desacoplado dos detalhes de implementação e tecnologia; 2. Contexto de serviços funcional, que não é dependente da lógica externa; 3. Requisitos mínimos de acoplamento de consumidor. Tabela 2: Perfil do princípio do baixo acoplamento de serviços. Existem vários de tipos de acoplamentos, mas alguns não são aceitáveis, pois foge alguns princípios de SOA, segue a Tabela 3, que demonstra esta realidade (Erl, 2009).
  19. 19. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 19 Tipo de Acoplamento Negativo? Nota Lógica ao contrato Não O alto acoplamento da lógica de serviços ao contrato é aceitável e suportado pelo princípio do contrato de serviço padronizado. Contrato à lógica Sim Essa forma de acoplamento não é recomendável e pode ser evitada pelo uso de abordagens de design „primeiro o contrato‟. Contrato à tecnologia Sim O contrato de serviços é, de maneira ideal, desacoplado da tecnologia do fornecedor, e suportado pelo uso de XML aberto e dos padrões de Web service. Contrato à funcionalidade Sim Este tipo de acoplamento negativo é evitável pela aplicação do princípio da capacidade de reuso de serviço, mas pode ser requerido para certos tipos de serviços. Contrato à implementação Sim Essa forma de acoplamento não é recomendável, especificamente em relação a recursos de implementação externos e compartilhados. Consumidor à implementação Sim O modelo de design de centralização de contratos é utilizado especificamente para evitar esse tipo de acoplamento. Consumidor ao contrato Não Esta é a forma positiva de acoplamento, mas seu benefício está relacionado a até que ponto os níveis negativos do acoplamento de contrato de serviços foram evitados. Tabela 3: Resumo dos tipos de acoplamento e influências associadas. O baixo acoplamento pode influenciar em outros princípios (Erl, 2009), encorajando a moderação da quantidade e da complexidade do conteúdo técnico do contrato, e assim permite minimizar os requisitos da dependência de
  20. 20. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 20 consumidor. Além desse o princípio de baixo acoplamento afeta a capacidade de reuso, autonomia e a visibilidade do serviço. 2.2.3 Abstração de serviços A abstração de serviço tem como objetivo principal criar uma interface de comunicação com um mundo exterior, informando quais as entradas e qual o retorno, caso necessite, a funcionalidade do serviço utiliza. Essas informações estarão explicitamente contidas no contrato de serviços. Com isso, todo o desenvolvimento do negócio fica em uma camada completamente isolada de outros serviços, possibilitando modificações lógicas, ou até mesmo novas funcionalidades e tornando essas variações invisíveis para os que estão utilizando. Segundo Gabriel (2009), serviços devem ser tratados como uma caixa preta. O serviço deve ter um perfil que atenda a capacidade de reuso, autonomia e independência de tecnologia, garantindo dessa forma a abstração da lógica, ou seja, as modificações se tornem transparente para o consumidor do serviço. Segundo experiência do autor, vivenciada em empresas onde atuou, o mesmo percebeu que quando não se obtém essa transparência poderá acarretar em “desgosto” por parte do usuário. Erl (2009) descreve o perfil que o serviço deve seguir, informando quais as suas características, objetivos e definições, de acordo com a Tabela 4.
  21. 21. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 21 Perfil do princípio Breve definição Informações de serviço dispensáveis são abstraídas. Definição completa Serviços são projetados para limitar informações no contrato de serviços ao que é realmente necessário para que o serviço seja funcionalmente útil a consumidores agora e no futuro. Informações além das que são publicadas no contratado de serviços são consideradas privadas e não devem ser disponibilizadas para a criação de consumidores de serviço potenciais. Objetivos Muitos dos outros princípios enfatizam a necessidade de publicar mais informações no contrato de serviços. O papel principal desse princípio é manter a quantidade e os detalhes do conteúdo do contrato concisos e equilibrados e evitar o acesso desnecessário a detalhes de serviço adicionais. Característica de design 1. Serviços abstraem constantemente informações específicas sobre tecnologia, lógica e função do mundo exterior – o mundo fora do limite de serviço; 2. Serviços têm contratos que definem concisamente requisitos de interação e limitações e outros metadetalhes de serviço necessários; 3. Fora do que é documentado no contrato de serviços, as informações sobre um serviço são controladas ou completamente ocultas dentro de determinado ambiente. Tabela 4: Perfil do princípio da abstração de serviço. 2.2.4 Capacidade de reuso de serviços A capacidade de reuso que o serviço deve ter é fundamental para aumentar a agilidade do desenvolvimento das aplicações. Não é interessante
  22. 22. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 22 “reinventar a roda”, ou seja, sempre utilizar aquilo que já está pronto, que outra pessoa já definiu e programou. Para que os serviços sejam reusados, os contratos de serviços devem ter as informações necessárias e bem claras sobre as suas capacidades. Segundo Gabriel (2009): “Um serviço reutilizável é aquele que não carrega particularidades técnicas de uma implementação ou regra de negócio específica e é genérico o suficiente para atender outros projetos.” Os contratos de serviços devem conter todas as informações fundamentais para que os consumidores possam utilizar suas funcionalidades com confiança. Por tanto os fundamentos devem ser seguidos para que os riscos e o temor para a sua reutilização diminuam. Fazer um serviço bastante reutilizável é um investimento de médio prazo e que demanda tempo e dinheiro e muitas vezes os investidores não enxergam a sua verdadeira e fundamental importância (Erl, 2009). A capacidade de reuso é um dos princípios que mais se destaca em um desenvolvimento de SOA, pois a sua identificação e o seu desenvolvimento parecem nunca ser possível sair do papel. A Tabela 5 demonstra a definição do serviço de acordo com o princípio da capacidade de reuso (Erl, 2009).
  23. 23. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 23 Perfil do princípio Breve definição Serviços são reusáveis. Definição completa Serviços contêm e expressam lógicas e podem ser definidos como recursos da empresa. Objetivos Os objetivos por trás da capacidade de reuso de serviço estão diretamente associados a alguns objetivos mais estratégicos na computação orientada a serviços: 1. Permitir que a lógica do serviço pudesse ser repetidamente alavancada ao longo do tempo, de modo que isso possa resultar em um retorno cada vez maior sobre o investimento inicial de desenvolvimento do serviço; 2. Aumentar a agilidade do negócio em um nível organizacional que permita o atendimento rápido dos futuros requisitos de automação dos negócios por meio da composição de serviço em larga escala; 3. Possibilitar a realização de modelos de serviço agnóstico, ou neutro; 4. Permitir a criação de inventários de serviços com alta percentagem de serviços neutros.
  24. 24. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 24 Característica de design 1. O serviço é definido por um contexto funcional agnóstico - A lógica encapsulada pelo serviço associa-se a um contexto suficientemente agnóstico para que qualquer cenário de uso possa ser considerado reutilizável; 2. A lógica de serviço é altamente genérica – A lógica encapsula pelo serviço é genérico o bastante, o que permite que ela facilite inúmeros cenários de uso por diferentes tipos de consumidores de serviço; 3. O serviço tem um contrato genérico e extensível – O contrato de serviços é flexível o bastante para processar uma grande variedade de mensagens de entrada e saída; 4. A lógica de serviço pode ser acessada concorrentemente – Os serviços são projetados para facilitar o acesso simultâneo por múltiplos programas de consumidor. Tabela 5: Perfil do princípio da capacidade de reuso de serviço. 2.2.5 Autonomia de serviço A autonomia de serviço é a capacidade que o serviço tem de se governar, tendo em vista que dessa forma o mesmo não tem grandes dependências com outros serviços (Erl, 2009). Embora se pense em um serviço autônomo, o que esse princípio aborda é que o mesmo deve ter o mínimo de dependência e que a sua lógica principal seja bastante independente. O ato de se autogovernar ou autonomia de serviço, pode trazer alguns benefícios claros, como por exemplo, o desempenho (Erl, 2009). Tendo em vista que dessa forma se terá o mínimo de dependências com outros serviços e as execuções das funcionalidades se tornam mais diretas e conseqüentemente o número de erros inesperados diminui consideravelmente. Essa autonomia é medida e disponibilizada nos contratos formais, tendo como finalidade esclarecer
  25. 25. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 25 o nível de independência aos seus consumidores. A Tabela 6 explica com mais detalhes as suas características. (Erl, 2009) Perfil do princípio Breve definição Serviços são autônomos. Definição completa OS serviços aumentaram a confiabilidade e a previsibilidade comportamental para suportar a execução autônoma, exercendo um alto nível de controle sobre a lógica e recursos em runtime. Objetivos 1. Aumentar a confiabilidade, o desempenho e a previsibilidade de um serviço em runtime, particularmente ao ser reusado e composto; 2. Aumentar a quantidade de controle que um serviço tem sobre o ambiente em runtime. Característica de design 1. Os serviços têm um contrato que expressa um limite funcional bem definido, que não deve envolver outros serviços; 2. Os serviços são implantados em um ambiente no qual eles exercem muito controle; e preferivelmente, um nível exclusivo;; 3. As instâncias de serviços estão em um ambiente que convive com a alta concorrência quanto a propósitos e escalabilidade. Tabela 6: Perfil do princípio da autonomia de serviço. 2.2.6 Independência de estado A independência de estado é quando um serviço não precisa reter nenhum dado do estado para que outro serviço processe a sua lógica. Podemos citar como exemplo, o uso do protocolo HTTP. O qual monta seu cabeçalho e todo o conteúdo da página que é enviada para o navegador (browser), retornando a uma condição de independência de estado em que ele não retém nenhuma solicitação
  26. 26. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 26 ou memória adicional do browser (Erl, 2009). Os serviços são projetados para minimizar o período, durante o qual eles existem em uma condição de dependência de informação de estado, aumentando a escalabilidade do serviço. Os contratos de serviços devem ter menos restrições, com a finalidade de permitir o recebimento e a transmissão de uma grande quantidade de dados de estado em execução em tempo real (runtime) (Erl, 2009). O gerenciamento das informações de estado quando é feito dentro do próprio serviço torna uma abordagem na construção de uma lógica confiável. Pois é bem mais fácil manter e evoluir um serviço que tenha total controle sobre seu próprio processamento de estado. Porém quando essa responsabilidade é transferida há uma arquitetura externa alguns benefícios são claramente identificados como: o reuso e a divisão de responsabilidades. Mas as dependências resultantes do design e a opção do controle externo precisam ser cuidadosamente avaliadas em longo prazo, principalmente. Outro cuidado fundamental que deve ser observado é a questão do desempenho em runtime, pois quando são criadas mais camadas há uma possibilidade de se ter uma sobrecarga de processamento. A Tabela 7 ilustra com mais detalhes o perfil do serviço para atender o princípio da independência de estados, expondo as suas características e os objetivos (Erl, 2009).
  27. 27. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 27 Perfil do princípio Breve definição Serviços minimizam a dependência de estado. Definição completa Serviços são explicitamente projetadas para minimizar o período durante o qual eles existem em uma condição de dependência de informações de estado. Objetivos 1. Aumentar a escalabilidade do serviço; 2. Dar suporte ao design de lógica agnósticos e aprimorar o potencial do reuso do serviço. Característica de design O que torna a independência de estado de serviço um princípio quase único é o fato de que ela promove uma condição do serviço que, por natureza, é temporária. Dependendo do modelo de serviço e da abordagem de diferimento de estado utilizados, diferentes tipos de características de design podem ser implementados. Tabela 7: Perfil do princípio da independência de estado do serviço. 2.2.7 Visibilidade do serviço A visibilidade do serviço, como o nome já diz, tem como objetivo principal fazer com que o serviço se torne visível a todos, aumentando assim a agilidade, a produtividade e a confiabilidade dos consumidores. Os serviços são projetados para que sejam encontrados e seus propósitos e capacidades sejam claramente entendidos, ou seja, os contratos de serviços devem ter metainformações extras que transmitem claramente o que o serviço realmente faz (Erl, 2009). A aplicação desse princípio após a implantação de um serviço pode comprometer a qualidade da sua visibilidade, portanto é uma boa prática adicionar as metainformações antes do lançamento da versão inicial. Existe um protocolo que especifica um método para publicar e descobrir
  28. 28. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 28 diretórios de serviços em uma arquitetura orientada a serviços, que é conhecido como UDDI (Universal Description, Discovery Integration) que será abordado no Capítulo 3. A visibilidade de serviço afeta alguns outros princípios, mas afeta principalmente a capacidade de reuso. Os serviços ou funcionalidades devem ser encontrados, é necessário que sejam flexíveis e que seus propósitos e capacidades sejam claros para que outros possam utilizá-los. Erl (2009) também afirma que: “Alcançar esse objetivos requer a previsão e uma boa compreensão da natureza do próprio serviço. Dependendo do tipo do modelo de serviço que é projetado, perceber esse princípio pode exigir perícia nos negócios, assim como perícia técnica.”. A Tabela 8 destaca estas características segundo a visão de Erl (2009). Perfil do princípio Breve definição Serviços são visualizáveis. Definição completa Os serviços são projetados para serem efetivamente descobertos e interpretados para que, na descoberta, seu propósito e capacidades sejam claramente entendidos. Objetivos 1. Os serviços são posicionados como recursos altamente visualizáveis dentro da empresa; 2. O propósito e capacidades de cada serviço são claramente expressos para que eles possam ser interpretados. Característica de design Tabela 8: Perfil do princípio da visibilidade do serviço. 2.2.8 Composição de serviços A composição de serviços permite que as capacidades de um serviço
  29. 29. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 29 sejam combinadas várias vezes com as de outros serviços em novas configurações a fim de resolver problemas diferentes. Por exemplo, um serviço que tem como entrada o CEP e informa qual o endereço de destino, utilizando um serviço dos correios. Também informando qual o melhor custo benefício na cobrança do frete, o que corresponde a outro serviço dos correios. Portanto, a composição desses serviços soluciona um determinado problema, mas esses serviços estando isolados e postos em outras composições solucionariam outros tipos de problemas. Os serviços devem ser quebrados ou decompostos em unidades menores, para aumentar a capacidade de reuso e solucionar um número maior de problemas de forma mais ágil e eficiente. Na composição de serviços quando é formada em grandes escalas, com muitos serviços, deve-se ter uma atenção voltada aos pontos que podem ter um custo excessivo de tempo, pontos estes que se assemelham a um “gargalo”. Visto que o desempenho do serviço controlador que encapsula uma composição de diversos serviços adicionais, será sempre determinado pela sua composição. Contudo para tentar evitar que gere este “gargalo” é importante entender com mais detalhes e precisão as definições e características deste princípio, portanto segue abaixo a Tabela 9 que expõe algumas informações importantes segundo Erl (2009).
  30. 30. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 30 Perfil do princípio Breve definição Serviços são componíveis Definição completa Serviços são projetados para que atuem como participantes eficazes de uma composição, independente do tamanho e da complexidade da composição. Objetivos Ao discutir os objetivos da composição de serviços, boa parte dos objetivos de reúso de serviços também é aplicável. Isso ocorre porque, muitas vezes, a composição de serviços é uma forma de reúso de serviços. De fato, talvez você se lembre de que um dos objetivos que selecionamos para o principio da capacidade de reúso era possibilitar a composição de serviços em larga escala. Contudo, além de simplesmente alcançar o reúso, a composição de serviços fornece o meio pelo qual podemos alcançar o que muitas vezes é classificado como o objetivo final da computação orientada a serviços. Ao estabelecer uma empresa composta de lógica representada por um inventário de serviços altamente reusáveis, fornecemos o meio para que uma grande extensão dos futuros requisitos da automação de negócios sejam cumpridos por meio da composição de serviços.
  31. 31. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 31 Característica de design para capacidade de membros de uma composição Idealmente, cada capacidade de serviço, especialmente aquelas que fornecem lógica reusável, é considerada um membro potencial de uma composição. Isso significa essencialmente que as características de design já estabelecidas pelo princípio da capacidade de reúso de serviços são igualmente relevantes para criar membros de composição eficazes. 1. O serviço precisa possuir um ambiente de execução altamente eficiente. Além de ser capaz de gerenciar a simultaneidade, a eficiência com a qual os membros da composição realizam o processamento individual deve ser bem sintonizada. 2. O contrato de serviços precisa ser flexível, para que possa facilitar diferentes tipos de requisitos de troca de dados para funções semelhantes. Isso se relaciona tipicamente a capacidade do contrato de trocar o mesmo tipo de dados em diferentes níveis de granularidade. A maneira como essas qualidades ultrapassam o mero reúso tem a ver principalmente com o fato de o serviço ser capaz de otimizar o processamento em runtime para dar suporte a várias composições simultâneas.
  32. 32. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 32 Característica de design para capacidades do controlador de composição Os membros de uma composição, muitas vezes, também precisam atuar como controladores ou subcontroladores em diferentes configurações de composição. Contudo, as exigências de alto desempenho impostas aos membros de composição geralmente são reduzidas aos serviços que são projetados como controladores. Esses tipos de serviços possuem, portanto, um conjunto próprio de características de design, a saber: 1. A lógica encapsulada por um controlador quase sempre está limitada a uma tarefa de negócios exclusiva. Comumente, é utilizado o modelo de serviço-tarefa, que resulta na aplicação de características comuns a esse modelo de serviços; 2. Embora os controladores possam ser reusáveis, normalmente o reuso de serviços não é uma consideração primária do design. Portanto, as características de design promovidas pela capacidade de reuso de serviços são consideradas e aplicadas onde apropriado, mas com menos rigor do que o habitualmente aplicado a serviços agnósticos; Naturalmente, qualquer capacidade que atue como controlador pode se tornar membro de uma composição maior, o que também leva em consideração as características de design de membro de composição anteriormente listadas. Tabela 9: Perfil do princípio da composição de serviço.
  33. 33. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 33 Capítulo 3 Tecnologias Neste capitulo será citado e definido o conceito das tecnologias mais utilizadas na construção da Arquitetura orientada a serviços (SOA). SOA tem como boa prática, a utilização de tecnologias já conhecidas no mercado. Web service é uma das tecnologias que torna um serviço disponível na grande internet, por exemplo. Vamos agora detalhar sobre algumas tecnologias utilizadas no mundo dos serviços. 3.1 Web service Segundo Sonda & Montez (2004), “Tecnologias de Web Services surgiram recentemente como uma resposta à busca de interoperabilidade entre aplicações que oferecem serviços na web”. “Os Web services são na essência interoperabilidade-conectando programas e aplicações a outros programas e aplicações, especialmente quando estes são desenvolvidos usando diferentes linguagens, ferramentas ou plataformas” (Oliveira E. C., 2009). Segundo Gartner: “Web services são componentes de software com baixo fator de desacoplamento, utilizado por meio de padrões de internet. Um web service representa uma função de negócio ou um serviço que pode ser acessado por uma outra aplicação, sobre redes públicas e, geralmente, disponibilizado por protocolos conhecidos.” O Web service (Figura 2) é baseado em vários padrões de tecnologias XML, SOAP, WSDL e UDDI que revolucionaram a comunicação na web. Basicamente o Web service é o intermediador entre as aplicações, independente de qual plataforma esteja sendo utilizada. Um serviço web utilizando essas tecnologias podem ser processados em uma internet, intranet ou em qualquer outro tipo de rede, mas que use endereçamento IP.
  34. 34. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 34 Em Engenharia de software, Sommerville (2007, p. 189) diz que um Web service é uma instância de uma noção mais geral de um serviço e, cita a definição proposta por Loverlock como: “Uma ação ou desempenho oferecido de um grupo para outro. Embora o processo possa estar ligado a um produto físico, o desempenho é essencialmente intangível e não resulta normalmente em prioridade de algum dos fatores de produção”. Figura 2: Web Service. (Oliveira E. C., 2009) 3.2 XML XML é uma linguagem de marcação para necessidades especiais, diferente do HTML (Wikipedia, 2010) que foi feito para Web e já tem suas tags pré- definidas. O XML (Figura 3) pode ser utilizado em vários contextos de aplicações e não existe tag pré-definidas. É um subtipo de SGML (acrônimo de Standard Generalized Markup Language, ou Linguagem Padronizada de Marcação
  35. 35. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 35 Genérica) capaz de descrever diversos tipos de dados. Segundo o W3C, o criador do XML, sua principal característica é criar uma infra-estrutura única para diversas linguagens, para que linguagens desconhecidas e de pouco uso também possam ser definidas sem maior trabalho e sem necessidade de serem submetidas aos comitês de padronização. A W3C em meados da década de 1990 começou a trabalhar em uma linguagem que tivesse a flexibilidade da SGML e com a simplicidade do HTML. O princípio do projeto era criar uma linguagem que pudesse ser lida por software, e integrar-se com as demais linguagens. Sua filosofia seria incorporada por vários princípios importantes: 1. Separação do conteúdo da formatação 2. Simplicidade e Legibilidade, tanto para humanos quanto para computadores 3. Possibilidade de criação de tags sem limitação; 4. Criação de arquivos para validação de estrutura; 5. Interligação de banco de dados distintos; 6. Concentração na estrutura da informação, e não na sua aparência.
  36. 36. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 36 Figura 3: Exemplo de um arquivo XML. (Wikipédia, 2010) 3.3 SOAP SOAP, vem do inglês Simple Object Access Protocol, é um protocolo para troca de informações, utilizando tecnologias baseadas em XML (W3C). O SOAP tem segundo a Wikipédia (2010): 1. Mecanismo para definir a unidade de comunicação; 2. Mecanismo para lidar com erros; 3. Mecanismo de extensão que permite evolução; 4. Mecanismo entre SOAP e o HTTP, representar tipos de dados em XML. A estrutura básica do SOAP é o envelope que contem as informações a serem enviadas ao servidor. O cabeçalho que pode conter alguns dados como namespace. O cabeçalho fica dentro do envelope. Encontrando-se também neste envelope o body. No body contém o documento que tem as informações a serem trocadas com o servidor, quais serviços deseja executar e o fault (falha), que
  37. 37. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 37 retorna uma mensagem de status do retorno da requisição como mostra a Figura 4 abaixo: . Figura 4: Exemplo de um envelope SOAP. (Wikipédia, 2009) O processo de comunicação SOAP tem seu início a partir do momento em que o cliente (Client) envia os dados, que através do HTTP são enviados para o servidor (Web Server) em uma estrutura pré-definida. Logo após o servidor receber esses dados, o mesmo faz todo o processo de verificação e processando assim as informações. Depois o servidor retorna os dados em uma estrutura SOAP. A Figura 5 ilustra este cenário com mais detalhes.
  38. 38. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 38 Figura 5: Exemplo de um web service utilizando SOAP. (MSDN Microsoft, 2003) 3.4 WSDL O WSDL (Web Services Description Language) é o contrato onde estará toda a estrutura que o XML deve ser montado, para que o serviço requisitado entenda o que se deseja, os dados com que vão trabalhar e em qual estrutura deve ser enviado o retorno ao consumidor. A definição do WSDL segundo o W3C (2001) é:
  39. 39. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 39 “WSDL é um formato XML para descrever serviços de rede como um conjunto de parâmetros operacionais sobre as mensagens que contenham qualquer documento orientado ou procedimento de informação orientada. As operações e mensagens são descritas abstratamente, e em seguida, vinculado a um protocolo de rede de concreto e formato de mensagem para definir um ponto de extremidade. Parâmetros concretos são combinados em parâmetros abstratos (serviços). WSDL é extensível para permitir a descrição dos parâmetros e suas mensagens, independentemente dos formatos que mensagem ou protocolos de rede são usados para comunicar-se...” A Figura 6 ilustra um diagrama em XML, de um documento WSDL 2.0 segundo a W3C (2001): Figura 6: Diagrama de um documento WSDL. (W3C ,2001)
  40. 40. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 40 O WSDL faz o intermédio entre o SOAP com o cliente e o SOAP com o servidor. O SOAP manda os dados para o WSDL e ele interpreta os dados montando assim um XML, que faça com que o cliente e servidor, entendam as informações solicitadas e retornadas. 3.5 UDDI Definimos UDDI como um protocolo que define um método padrão para a publicação e descoberta da rede, baseada em componentes de software de uma arquitetura orientada a serviços aprovada pelos padrões OASIS (2006) que é um membro importante na linha de Web services. UDDI é como um catálogo de serviços que o servidor dispõe. Lá são mostrados quais serviços tem no servidor, os quais são permitidos de acordo com a regra de restrições. A relação conceitual entre UDDI e outros protocolos, na pilha de serviços da Web, é ilustrada na Figura 7 abaixo (OASIS, 2006): Figura 7: Exemplo da relação do UDDI entre outros protocolos. (OASIS, 2006)
  41. 41. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 41 Basicamente o servidor publica via SOAP no UDDI os serviços que ele tem. A camada SOAP do UDDI interpreta e armazena a descrição dos serviços, pois quando o cliente solicitar uma lista de serviços, que ele possa utilizar, será retornado via SOAP ao cliente, a qual poderá ser utilizada. 3.6 ESB ESB (Enterprise Service Bus) serve como um intermediador entre serviços. Ele se comunica com os serviços, independente de qual plataforma é usada. Não importa se seja um serviço em Java solicitando outro serviço em PHP. O ESB deixa transparente a troca de informações entre eles. O uso da tecnologia ESB seria uma boa solução em, por exemplo, uma empresa que tenha um sistema desenvolvido em uma plataforma, que tenha um protocolo de comunicação diferente com o qual irá interagir. De início pode-se utilizar de outras formas mais simples para realizar essa troca de informações, mas supondo que após algum tempo, deve-se fazer integrações entre outros serviços com protocolos diferentes. Por tanto para haver essa comunicação entre aplicações ou serviços, cada um deverá desenvolver diversos tipos de protocolos, para atender qualquer tipo de requisição SOAP. Pesando em uma forma de centralizar o desenvolvimento de diversos tipos de protocolos para as trocas de informações, utiliza-se a tecnologia ESB. A qual é responsável pelo transporte dos dados de maneira assíncrona e síncrona. Sendo esta responsável por mandar as informações para seu destino, interpretar, processar e tratar as informações a serem retornadas como mostra a Figura 8.
  42. 42. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 42 Figura 8: Exemplo de uma aplicação SOA utilizando ESB. (Progress Software, 2010) Neste exemplo, a ESB está fornecendo a conectividade com o roteamento entre os serviços; a transformação de dados XML, a qual permite a comunicação dos serviços com diferentes interfaces; e o processo de sequenciamento de negócios de serviços (Progress Software, 2010).
  43. 43. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 43 Capítulo 4 Implantando SOA em uma empresa TI Neste capítulo serão abordadas sugestões baseadas em pesquisas de especialistas na implantação da arquitetura orientada a serviços, ou seja, SOA. A implantação da arquitetura orientada a serviços dentro de uma empresa de tecnologia da informação trata-se um trabalho árduo e deve ser muito bem estudado. O primeiro passo que toda empresa, a qual tenha como objetivo de adotar o conceito de SOA dentro de sua organização é capacitar seus colaboradores ou contratar pessoas já capacitadas. Este ponto é bastante conflituoso, pois a capacitação dos funcionários estará abrindo novas portas para o mercado vizinho e novas oportunidades aparecerão. Contudo, sem essa formação dos envolvidos a possibilidade de sucesso é muito remota e uma coisa é certa, pensar e produzir orientada a serviços não é simples e nem comum. Visto que um paradigma novo sempre demonstra dificuldades. Depois de todos os colaboradores estarem preparados, deve ser escolhido um projeto piloto para a aplicação do conceito de SOA e posteriormente expandi- lo para toda a organização. Um ponto importante que deve ser levantado na transição para o conceito de orientação a serviços no projeto piloto, é definir as responsabilidades de cada um, pois para uma tarefa tão complexa não cabe apenas aos desenvolvedores, ou analista, ou gerentes de negócios pensarem e definirem este novo conceito de arquitetura. Para a implantação ter sucesso todos os papéis acima citados devem participar dentro de sua capacidade, ou seja, os desenvolvedores ficarão envolvidos sobre os problemas tecnológicos e as melhores escolhas, os analistas referentes às definições de negócios de design, enfim cada a um será incumbida uma responsabilidade.
  44. 44. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 44 Para os projetos que já estão em andamento essa transição se torna um pouco mais complexa, tendo em vista que tudo já está definido e um maior re- trabalho será inevitável. No entanto existe esta possibilidade e a mesma será abordada neste capítulo. 4.1 Implantação em um novo projeto Quando a organização define que irá aderir ao SOA, é preciso se ter a certeza que novos projetos nascerão baseados nessa arquitetura. As pessoas que ficarem responsáveis por desenhar a arquitetura do projeto devem ter o projeto de SOA em mente. (Ângelo, 2005) É interessante que o sistema piloto escolhido seja simples e que suas funcionalidades, que farão parte do serviço na arquitetura orientada a serviços, tragam em um pequeno espaço de tempo benefícios para a organização, ou seja, que sejam utilizadas por outros sistemas e / ou projetos. Essas funcionalidades devem ser de fácil desacoplamento da apresentação. A escolha deste piloto é de extrema importância para a visualização, da diretoria da companhia, dos benefícios trazidos. Estes ganhos com a implantação de SOA é notada rapidamente pela garantia de longevidade que o sistema ganha e em médio prazo a empresa vai alcançar uma alta produtividade no desenvolvimento. Uma dica boa para a identificação das funcionalidades do sistema piloto, chaves para a implantação, é transformar alguns componentes, que já são utilizados em várias partes da própria aplicação e que claramente poderão ser utilizados por outros, em serviços. 4.2 Adaptação dos projetos já em andamentos É recomendado que as organizações comecem a implantar SOA aos poucos, podendo ser feita em etapas assim que as demandas forem surgindo.
  45. 45. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 45 Deve ser aplicado inicialmente em processos críticos, onde a lógica de negócios possa ser facilmente desagregada da parte da apresentação. Existem inúmeras situações em que projetos já em andamentos, necessitem adotar SOA. Porém sempre deve ser levada em consideração se há a possibilidade desta adaptação na arquitetura atual do sistema. Um design bem feito torna esta adaptação um pouco mais simples. Se a escolha da mudança de arquitetura não foi feita pela equipe de desenvolvimento por necessidade do projeto ou pelo cliente e sim uma mudança de paradigma da empresa. Então este projeto deve ser um experimento para futuras estimativas e definições das melhores tecnologias. Implantar SOA é um desafio muito grande para a organização, maior até do que o desafio técnico. Portanto deve haver um alinhamento entre as tecnologias utilizadas e os objetivos de negócio da empresa. Para ter uma abstração das formas de comunicação das aplicações e serviços, deve ser implementado o Enterprise Service Bus (ESB) fazendo com que tecnologias e ferramentas fiquem irrelevantes. 4.3 Cenário de implantação de SOA em uma empresa de TI Neste capítulo vamos abordar as fases da implantação do conceito de SOA, dentro da organização, utilizando com boas práticas de governança. Segundo Zaidan (2009) a revista Decision Report “A implementação correta com boas práticas de governança a reutilização dos serviços implementados pode atingir mais de 80% de reuso. Isso, consequentemente, maximiza o retorno sobre o investimento”. Atingir estes 80% equivale a uma probabilidade muito remota, comparada com as arquiteturas tradicionais. Segundo a revista Decision Report (Zaidan, 2009), “No Brasil, um dos projetos que foi implementado no setor de telecomunicações houve 65% de reutilização dos serviços”.
  46. 46. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 46 Como foi dito antes é fundamental a migração ser feita por etapas, pois se não, pode trazer sérios problemas, por exemplo, alteração de uma só vez o dia-a- dia de todos os funcionários de desenvolvimento; a existência de muitos sistemas para serem alterados não sendo possível a concentração dos esforços nos detalhes necessários. Pelos casos já reportados de projetos que grandes números de sucesso são feitos em fases, primeiro capacitando os funcionários, depois escolhendo um projeto piloto, realiza a migração e observa o funcionamento para no futuro repetir esses mesmos procedimentos para o resto dos projetos da empresa. A figura 7 representa as etapas de migração para SOA, que segundo Gartner (2008) é o cenário ideal para empresas grandes com muitos sistemas distribuídos, utilizando a prática de governança. A primeira etapa é pouco longa e difícil, que consta na definição do projeto piloto e na construção de serviços, que já tragam ganhos. SOA inicialmente não trará retorno sobre o investimento, pois a reutilização só aparecerá nos próximos sistemas, então o CIO deve selecionar pilotos que tragam mais benefícios de negócios. A segunda fase é a mais longa, pode durar até quatro anos, dependendo da infra-estrutura e da maturidade do processo da empresa. É nesta fase que colocarão os experimentos do projeto piloto em construção em todos os outros existentes na organização. Este tempo de quatro anos é relativo, pois dependente muito de quantos projetos irá fazer a migração e suas complexidades. Neste momento é fundamental a criação do repositório de serviços, pois é a partir dele, que serão encontradas as funcionalidades ou os serviços que serão reutilizados por outras aplicações. Ao final dessa etapa chega-se a um bom cenário organizacional: serviços estão implantados, existe reaproveitamento, controle do ambiente, registro de serviços e políticas de governança implantadas. Neste ponto a organização começa a perceber que os novos projetos começam a serem mais ágeis, baratos
  47. 47. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 47 e com menos chances de problemas, ou seja, quanto maior for o nível de reutilização, menor o desenvolvimento e os problemas. A última fase é o cenário estável da organização, os sistemas existem com conceitos de serviços, todos estão no repositório. Não existem serviços duplicados e existe alta taxa de reuso. Nesta fase deve-se pensar no futuro, por exemplo, novos serviços devem seguir o processo de desenvolvimento e as políticas organizacionais. A utilização de serviços deve ser feita via repositório com um contrato formal de prestação de serviço. Isso tudo se aplica para grandes empresas (Gartner, 2008). A ilustração das definições das etapas de implantação segundo Gartner (2008) segue abaixo: Figura 9: Cenário de implantação de SOA para grandes empresas. (Gartner, 2008) Para empresas de médio porte, sugere-se a utilização também de um piloto, mas que ele seja utilizado como experimento onde possam ser exaustivamente repetidas as ações de migração para cada área da empresa. Posteriormente devem ser analisados os resultados das ferramentas escolhidas e
  48. 48. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 48 dos sistemas pilotos. A segunda etapa é a implantação no setor onde foi feito o piloto anteriormente, depois sendo repetido o processo para cada área da empresa quantas vezes forem necessário. A última etapa, da mesma forma que o modelo anterior, é quando a organização já está com a toda a política de governança definida e os serviços implantados. O importante é garantir que os colaboradores da organização sigam as políticas definidas, para que não haja, por exemplo, serviços repetidos. Figura 10: Cenário de implantação de SOA para médias e pequenas empresas. (Gartner, 2008) As propostas mostradas neste trabalho não irão atender ou não serão ideais para todas as empresas, pois é necessária uma análise mais aprofundada para cada situação.
  49. 49. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 49 Capítulo 5 Considerações finais Neste capítulo serão abordadas as considerações finais para aumentar o embasamento, e as dificuldades encontradas para a criação e confecção deste documento. O conceito da orientação a serviços, ou melhor, da arquitetura orientada a serviços, de implantar nos projetos, é mais uma tentativa de melhoria para ajudar as empresas de tecnologia da informação em aumentar a produtividade, a qualidade de softwares e posteriormente a satisfação dos clientes. Visto que as empresas que vivem de projetos devem sempre assistir. Uma coisa é certa, SOA não realiza nenhum milagre e não é a solução de todos os problemas. Fazendo apenas uma analogia referente a processos, que hoje em dia todos os projetos querem utilizar a metodologia Scrum achando que é a solução dos problemas de atrasos, de falhas de planejamento, que segundo Schwaber (2004) – principal formalizador da metodologia – Scrum é: "... o mais perplexo e paradoxal processo para gerenciamento de projetos complexos. Porém, Scrum é incrivelmente simples. [...] Scrum não é um processo prescritivo; ele não descreve o que fazer em cada circunstância. Ele é usado para trabalhos complexos nos quais é impossível predizer tudo que irá acontecer.". Esta mesma falta de conhecimento se encaixa com SOA, que os leigos acreditam que irá solucionar o problema de códigos mal feitos, de bugs, de atrasos. Já é comprovado que SOA é um conceito de sucesso, mas deve ser muito bem estudado antes de ser utilizado e que necessita de uma maturidade de arquitetura, design e análise muito grande da equipe. Algumas dificuldades nas realizações da pesquisa para o desenvolvimento deste documento foram encontradas. Encontrar profissionais engajados neste
  50. 50. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 50 conceito é complicado. Para este trabalho foi criado um questionário para levantamento de soluções para alguns princípios e que menos de 16,66% das pessoas foram capazes de respondê-lo por inteiro. Então talvez a primeira etapa ou barreira que as empresas devem enfrentar seja a qualificação dos seus funcionários em treinamentos e palestras; para que a equipe não “mate” SOA e SOA não “mate” o projeto. 5.1 Contribuições Neste trabalho foi apresentado um estudo de implantação do conceito da arquitetura orientada a serviços – SOA – que mesmo sendo aplicada em uma arquitetura definida. Espera-se que seja possível ser aplicado em praticamente qualquer projeto de uma fábrica de software, sabendo de algumas limitações técnicas e dos clientes. A seguir, uma síntese da proposta oferecida de implantação de SOA: 1. Identificar ou contratar funcionários capacitados para a implantação ou capacitá-los, afim de que esta mudança seja um caso de sucesso e não um investimento perdido; 2. Depois de ter uma equipe capacitada deve ser identificado um projeto ou sistema piloto que servirá como experimento de mudança, obtendo dados para estimativas e informações sobre melhores tecnologias; 3. Identificação de funcionalidades estratégicas, que trarão ganhos importantes e rápidos para a organização; 4. Os responsáveis devem se reunir e identificar os riscos dessa mudança e levantar as ações que deverão ser tomadas; 5. Implementar o conceito de SOA nas funcionalidades escolhidas;
  51. 51. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 51 6. Depois de ter finalizado o desenvolvimento da aplicação piloto, vem o momento mais crucial, identificar novas funcionalidades de projetos em andamento ou já concluídos; 7. Transformação dessas novas funcionalidades em serviços, utilizando o conceito de SOA e o adaptando nos projetos desejados. Em projetos que já estão concluídos, só deve ser feito esta modificação com a permissão do cliente em questão, pois pode gerar novos erros; 8. Por fim, institucionalizar a nova arquitetura e capacitar todos os funcionários que estarão envolvidos. 5.2 Trabalhos futuros Como trabalho futuro, sugere-se que as fábricas de softwares capacitem os seus funcionários e comecem a criar projetos pilotos, aplicando o conceito da orientação de serviços, tendo como base neste trabalho de pesquisa que foi realizado. A partir disto será possível fazer um aperfeiçoamento das arquiteturas, pensando no reaproveitamento de código e diminuindo o retrabalho. Com esta idéia de SOA, poderão surgir novos produtos dentro da organização, pois a idéia de desvincular as funcionalidades da camada de apresentação facilita nessa identificação. Afirmo isso por experiência própria, pois existe um sistema na empresa em que trabalho. Pois da maneira que foi implementado e imposto pelo cliente fica complicada a extração de um produto. No entanto se desde o início tivesse a mentalidade da orientação a serviços, com certeza a criação e a identificação deste produto seriam certas. Espero que em trabalhos futuros tenha a oportunidade de arquitetar um projeto adotando o conceito de SOA, sendo o piloto. Esperando que posteriormente este conceito seja difundido em toda a organização, podendo dar consultorias em empresas que pretenderão fazer o mesmo.
  52. 52. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 52 Pretendo também difundir uma idéia de criação de serviços para as ferramentas de persistências modelos relacionais. Os frameworks ou aplicações não se preocupariam em implementar a conexão, o modo de persistir, log de sistemas e sim seria apenas configurações que o serviço disponibilizaria. Com isso evitaria alguns erros que acontecem sempre em todos os projetos. É uma idéia que ainda não foi bem fundamentada, mas que pretendo me inteirar mais e saber se existe viabilidade para o mesmo. 5.3 Aprendendo a vender SOA na sua empresa O lema ou o grande desafio das empresas de tecnologia da informação é diminuir os custos e aumentar a agilidade. Então a Arquitetura Orientada a Serviços (SOA) vem para superar esses desafios e colocar “um ponto final” nesta preocupação. Mas nos profissionais técnicos, não sabemos vender essa idéia para nossa própria empresa, principalmente referindo-se ao fato de que os benefícios de SOA não se podem dispor. É necessário mostrar para os diretores da sua empresa os benefícios que esta nova arquitetura trará, segue a lista abaixo: 1. Redução do desenvolvimento duplicado 2. Simplificação da integração entre aplicações 3. Aumento da qualidade das funcionalidades 4. Redução do custo de manutenção das aplicações 5. Flexibilidade na alteração de processos de negócio 6. Agilidade na análise de impacto 7. Conhecimento dos ativos existentes E segundo um artigo de Kleber Bacilo (2009) algumas métricas para
  53. 53. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 53 usarmos no cálculo da economia: 1. Reuse Cost Avoidance: trata-se do quanto a empresa economiza por não ter que desenvolver novamente as mesmas funcionalidades. Digamos que para construir um determinado serviço foram necessárias 100 horas. Cada vez que se reutilizar esse serviço, praticamente 100 horas – ou pelo menos uma parte delas – serão economizadas. 2. Consistency: a mesma lógica de negócio desenvolvida várias vezes pode causar comportamentos diferentes dependendo da aplicação e, sempre que muda, é necessário mudar em todos os locais onde esteja implementada. 3. Maintenability: uma parte significativa do orçamento de TI é gasta apenas mantendo as aplicações existentes funcionando. Redução nos custos de manutenção com integrações mais fáceis de manter e componentes isolados sendo reutilizados, e com nível de qualidade já atestada, impactam de forma muito positiva o uso racional dos recursos de TI. 4. Agility: Conseguir fazer a análise de impacto mais rapidamente e promover mudanças nas aplicações e processos de negócios no tempo demandado pelas áreas de negócio é uma argumentação muito efetiva quando relacionado ao business case de SOA. Além de todos esses cálculos, devem ser apresentados para a diretoria da empresa, os investimentos que precisarão ser feitos para a utilização de SOA. Segue abaixo alguns dos itens essenciais para atingir os resultados, tão empolgantes, citados anteriormente (Kleber Bacilo, 2009). 1. Capacitação dos colaboradores; 2. Elementos de infra-estrutura, mas inicialmente tentar utilizar o que a empresa já dispõe e colocar as licenças dos anos seguintes;
  54. 54. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 54 3. Consultorias externas, visando diminuir a quantidade de erros e proporcionando melhores futuros; 4. Selecionar uma equipe pioneira dentro da empresa e calcular o custo que esta equipe terá para ficar alocada apenas para a implantação. É importante exibir os investimentos necessários, mas lembrem que investimento para empresa é sinônimo de custos. Então sempre exiba um item de investimento e enumere 10 pontos de vantagens. Boa sorte e boa venda.
  55. 55. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 55 Referências Ângelo, F. K. (24 de novembro de 2005). Entenda como e quando implantar SOA. Acesso em 01 de março de 2010, disponível em Computerworld Porta-voz do mercado de TI e comunicação: http://computerworld.uol.com.br/gestao/2005/11/24/idgnoticia.2006-03- 29.9253581963/ Bacili, K. (2009 de julho de 14). Aprenda a calcular o ROI em SOA. Acesso em 10 de fervereiro de 2010, disponível em Aquele Blog de SOA: http://www.aqueleblogdesoa.com.br/2009/07/aprenda-a-calcular-o-roi-em-soa/ Davis, A., & Zhang, D. (2002). A comparative study of DCOM and SOAP. Acesso em 22 de março de 2010, disponível em IEEE Xplore Digital Library: http://ieeexplore.ieee.org/search/srchabstract.jsp?tp=&arnumber=1181595&query Text%3Dsoap%26openedRefinements%3D*%26searchField%3DSearch+All Erl, T. (2009). SOA Princípios de design de serviços. São Paulo: Pearson Prentice Hall. Gabriel. (03 de novembro de 2008). O que é SOA. Acesso em 13 de novembro de 2009, disponível em Aquele blog de SOA: http://www.aqueleblogdesoa.com.br/2008/11/o-que-e-soa/ Gabriel. (05 de março de 2009). Princípios Básicos de SOA – Contrato Formal. Acesso em 15 de novembro de 2009, disponível em Aquele Blog SOA: http://www.aqueleblogdesoa.com.br/2009/03/principios-basicos-de-soa-contrato- formal/ Gabriel. (02 de março de 2009). Princípios Básicos de SOA – Serviços Reutilizáveis. Acesso em 20 de novembro de 2009, disponível em Aquele blog de SOA: http://www.aqueleblogdesoa.com.br/2009/03/principios-basicos-de-soa- servicos-reutilizaveis/
  56. 56. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 56 Gabriel. (12 de maio de 2009). Princípos Básicos de SOA – Serviços Abstraem a Lógica. Acesso em 10 de 11 de 2009, disponível em Aquele blog de SOA: http://www.aqueleblogdesoa.com.br/2009/05/principos-basicos-de-soa- servicos-abstraem-a-logica/ Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (2000). Padrões de Projeto Soluções reutilizáveis de software orientado a objetos. Porto Alegre: Bookman. Gartner. (s.d.). Practitioner’s Guide: Best Practices in Enterpricewide SOA Initiatives. Acesso em 18 de fervereiro de 2010, disponível em Gartner: 2010 Hurwitz, J., Bloor, R., Kaufman, M., & Halper, F. (2009). Arquitetura Orientada a serviços – SOA para Leigos (2 ed.). Rio de Janeiro: Alta Books. Martin David, B. M. (agosto de 2002). Web Service Definition Language (WSDL). Acesso em 03 de 03 de 2010, disponível em Web Service Definition Language (WSDL): http://www.ai.sri.com/daml/services/daml-s/0.7/daml-s- wsdl.html Min Luo Goldshlager, B. L.-J. (15 de julho de 2005). Designing and implementing Enterprise Service Bus (ESB) and SOA solutions. Acesso em 10 de março de 2010, disponível em IEEE Xplore Digital Library: http://ieeexplore.ieee.org/search/freesrchabstract.jsp?reload=true&tp=&arnumber= 1524413&queryText%3DESB%26openedRefinements%3D*%26searchField%3D Search+All MSDN Microsoft. (01 de outubro de 2003). Uderstanding WSDL. Acesso em 03 de 03 de 2010, disponível em MSDN: http://msdn.microsoft.com/en- us/library/ms996486.aspx MSW Métricas e Software. (s.d.). Qualidade de Software. Acesso em 20 de fervereiro de 2010, disponível em MSW Métricas e Software - Fábrica de Software: http://www.mswconsult.com.br/qualidade.html
  57. 57. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 57 OASIS. (14 de agosto de 2008). UDDI 101. Acesso em 25 de fervereiro de 2010, disponível em UDDI Xml Org Online community for the Universal Description, Discovery, and Integration OASIS Stantard: http://uddi.xml.org/uddi- 101 Oliveira, E. C. (08 de abril de 2009). Tutoriais CTDO. Acesso em 20 de janeiro de 2010, disponível em Web Services: Java e XML juntos pela interoperabilidade: http://tutoriais.ctdo.com.br/tutoriais/linguagens-para-web- sites/xml/web-services-java-e-xml-juntos-pela-interoperabilidade.html Oliveira, M. (11 de fervereiro de 2009). Caso de Sucesso com SOA. Acesso em 10 de novembro de 2009, disponível em Aquele blog de SO: http://www.aqueleblogdesoa.com.br/2009/02/caso-de-sucesso-com-soa/ Progress Software. (2010). ESB ARCHITECTURE AND LIFECYCLE DEFINITION. Acesso em 03 de março de 2010, disponível em Progress Software Business Making Progress: http://web.progress.com/en/esb-architecture-lifecycle- definition.html RD Consultoria. (14 de fervereiro de 2009). Medindo Satisfação do Cliente. Acesso em 20 de fervereiro de 2010, disponível em Medindo Satisfação do Cliente RD Consultoria: http://www.rdconsultoria.com.br/topic.asp?TOPIC_ID=239&FORUM_ID=16&CAT_ ID=2&Forum_Title=Atendimento&Topic_Title=Medindo+a+satisfa%E7%E3o+do+c liente Rodrigues, R. (16 de janeiro de 2009). Estratégia de implantação SOA: negócios flexíveis, serviços governáveis. Acesso em março de 22, disponível em Administradores - O portal da administração: http://www.administradores.com.br/informe-se/informativo/estrategia-de- implantacao-soa-negocios-flexiveis-servicos-governaveis/20198/ Saturino, L. (26 de outrubro de 2009). Fábrica de Software e Tecnologia de ponta: resultados garantidos. Acesso em 28 de fervereiro de 2010, disponível em
  58. 58. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 58 Baguete tecnologia e informação em um só lugar: http://www.baguete.com.br/artigosDetalhes.php?id=1039 Schmelzer, R. (28 de novembro de 2007). The Seven Levels of Loose Couplin. Acesso em 20 de janeiro de 2010, disponível em ZapThink SOA and Cloud Training, Consulting, and Community: http://www.zapthink.com/2007/11/28/the-seven-levels-of-loose-coupling/ Sommervile, I. (2007). Engenharia de software. São Paulo: Pearson Addison-Wesley. Sonda, G. C., & Montez, C. (01 de maio de 2004). Uma proposta de implementação de diferenciação de serviços na Arquitetura de Web Services. Acesso em 20 de janeiro de 2010, disponível em Artigo de Sonda e Montez: http://inf.unisul.br/~ines/workcomp/cd/pdfs/2508.pdf Standish Group. (23 de abril de 2009). Standish Newroom - CHAOS 2009. Acesso em 03 de 03 de 2010, disponível em The Standish Group: http://www1.standishgroup.com/newsroom/chaos_2009.php Ventura, J. (21 de julho de 2008). Baixo Acoplamento. Acesso em 21 de novembro de 2009, disponível em Aquele blog de SOA: http://www.aqueleblogdesoa.com.br/2008/07/baixo-acoplamento/ W3C. (15 de março de 2001). Web Services Description Language (WSDL) 1.1. Acesso em 25 de fervereiro de 2010, disponível em W3C Note: http://www.w3.org/TR/wsdl Wikipedia. (21 de março de 2010). HTML. Acesso em 28 de março de 2010, disponível em Wikipédia, a enciclopédia livre: http://pt.wikipedia.org/wiki/HTML Wikipédia. (01 de outubro de 2009). SOAP. Acesso em 2010 de ferveriero de 22, disponível em Wikipédia, a enciclopédia livre: http://pt.wikipedia.org/wiki/SOAP
  59. 59. Avaliando arquiteturas orientadas a serviços em uma empresa de tecnologia da informação (TI) 59 Wikipédia. (01 de abril de 2009). Web Service. Acesso em 20 de fervereiro de 2010, disponível em Wikipédia, a enciclopédia livre: http://pt.wikipedia.org/wiki/Web_service Wikipédia. (08 de março de 2010). Web Services Description Language. Acesso em 22 de ferveriero de 2010, disponível em Wikipédia, a enciclopédia livre: http://pt.wikipedia.org/wiki/WSDL Wikipédia. (16 de março de 2010). XML. Acesso em 10 de 01 de 2010, disponível em Wikipédia, a enciclopédia livre: http://pt.wikipedia.org/wiki/XML Zaidan, P. (03 de setembro de 2009). SOA atinge até 80% do reuso com governança, diz BearingPoint. Acesso em 10 de janeiro de 2010, disponível em Decision Report: http://www.decisionreport.com.br/publique/cgi/cgilua.exe/sys/start.htm?infoid=416 3&query=simple&search%5Fby%5Fauthorname=all&search%5Fby%5Ffield=tax& search%5Fby%5Fkeywords=any&search%5Fby%5Fpriority=all&search%5Fby%5 Fsection=all&search%5Fby%5Fstate=all&se
  60. 60. Anexos Anexo I – Questionário para levantamento de informações da capacitação dos técnicos.
  61. 61. Anexo I – Questionário para levantamento de informações da capacitação dos técnicos. “UMA PROPOSTA PARA IMPLANTAÇÃO DO CONCEITO DA ORIENTAÇÃO A SERVIÇOS EM UMA EMPRESA DE TI” 1º) Como seria o cenário de transição de uma empresa que não tem na cultura o conceito de orientação a serviços e mais ou menos quanto tempo levaria ? 2º) Como funcionária a versão final de um projeto, onde deve ser implantado no cliente ou hospedado em algum servidor, que algumas lógicas de negócio são serviços já implementado na empresa ? 3º) Como os desenvolvedores saberiam quais serviços utilizar, ou seja, de que forma e em que local ficarão armazenada essas informações ? 4º) Quando o cliente fica responsável pela Análise e / ou design do projeto e não tem na sua cultura trabalhar com orientação a serviços. Como a empresa de TI ou o projeto trataria isso, pensando que a empresa TI tem já vários serviços implementados e que seriam importantíssimos no desenvolvimento referente a agilidade e eficiência, pois estão bem estáveis ? 5º) Essa quinta questão eu deixo aberta para poderem comentar darem dicas ou falarem de alguma coisa importante que não foi questionada na perguntas anteriores.

×