ANÁLISE COMPARATIVA: Metodologias para desenvolvimento de software com arquitetura orientada a serviços

Transcrição

1 FACULDADE SETE DE SETEMBRO FASETE Departamento de Sistemas de Informação Curso de Bacharelado em Sistemas de Informação DANILO VIEIRA LOPES ANÁLISE COMPARATIVA: Metodologias para desenvolvimento de software com arquitetura orientada a serviços PAULO AFONSO BA Novembro-2009

2 II DANILO VIEIRA LOPES ANÁLISE COMPARATIVA: Metodologias para desenvolvimento de software com arquitetura orientada a serviços Monografia apresentada ao curso de Sistemas de Informação, da Faculdade Sete de Setembro, como requisito para avaliação conclusiva. Sob a orientação do professor Msc. Igor Vanderlei. PAULO AFONSO BA Novembro-2009

3 III DANILO VIEIRA LOPES ANÁLISE COMPARATIVA: Metodologias para desenvolvimento de software com arquitetura orientada a serviços. Monografia apresentada ao curso de Sistemas de Informação, da FASETE - Faculdade Sete de Setembro, como parte dos requisitos necessários para obtenção do grau de Bacharel em Sistemas de Informação. Aprovada por: Prof. Orientador Prof. Prof. PAULO AFONSO BA Novembro-2009

4 IV RESUMO Este trabalho tem como objetivo elaborar uma análise comparativa entre as metodologias que possibilitam o desenvolvimento de software com arquitetura orientada a serviços, bem como os processos e as boas práticas associadas a cada uma delas. Partiu-se do pressuposto de que SOA é um novo paradigma que permite as organizações responderem rapidamente ao surgimento de novos requisitos, reduzir constantemente o custo da TI para os negócios, absorver e integrar novos parceiros e clientes, e assegurar a conectividade e integração de aplicações de software melhores e mais rápidas.para realização desse estudo, utilizou-se diferentes formas de referências bibliográficas como: livros, revistas eletrônicas, artigos e principalmente a documentação e manuais referentes às metodologias presentes no estudo.após a realização da análise, pôde-se obter como resultados a indicação do conjunto mínimo de artefatos necessários para o projeto e construção de software com arquitetura orientada a serviços e a seleção, avaliação e o agrupamento das boas práticas presentes nas metodologias estudadas.constatouse, portanto, que cada metodologia SOA estudada possui suas particularidades, onde se pôde perceber: a ausência, a presença ou então, o não relato de alguma das boas práticas presentes no projeto e desenvolvimento de SOA. No entanto, pôde-se notar que independentemente da metodologia analisada, qualquer uma delas pode ter suas fases e processos adaptados de acordo com o perfil e as necessidades da organização que pretende utilizá-la. Palavras-chave: SOA, metodologia, artefatos, boas práticas

5 V ABSTRACT This study aims to develop a comparative analysis of methodologies that provide software development with service-oriented architecture and the processes and practices associated with each. Started from the assumption that SOA is a new paradigm that allows organizations to respond quickly to the emergence of new requirements, constantly reducing the cost of IT to the business, absorb and integrate new partners and customers and ensure connectivity and integration of applications better software and more fast. For conduct this study, we used different types of references such as books, electronic journals, articles, and especially documentation and manuals relating to the methodologies study. After present in the analysis, we could obtain results as an indication of the minimum set of artifacts required for the design and construction of software with service-oriented architecture and selection, assessment and pooling of good practices in these methodologies studied. Found, therefore, that each methodology studied SOA has its peculiarities where he could see, the absence, presence or you have not reported any of these good practices in the design and development of SOA. However, we noticed that regardless of the methodology considered, any of which may have their phases and processes aligned with the profile and needs of the organization you want to use it. Keywords: SOA, methodology, artifacts, practices good

6 VI LISTA DE ABREVIATURAS API Application Programming Interface BPEL Business Process Execution Language BPM Business Process Management BPMN Business Process Modeling Notation EAA Existing Asset Analysis EMF Enterprise Message Format ESB Enterprise Service Bus FAA Funcional Area Analysis GSM Goal Service Modeling HTTP Hypertext Transfer Protocol ISV Independent Service Vendors MSOAM Mainstream SOA Methodology NFRs Non Funcional Requirements QoS Qualidade de Serviço ROI Return on Investiment RQ Repeatable Quality RUP Rational Unified Process SEI Software Engineering Institute SI Sistemas de Informação SOA Service Oriented Architecture SOAD Service Oriented Analysis e Design SOAF Service Oriented Architecture Framework SOAP Simple Object Access Protocol SOMA Service Oriented Modeling e Architecture SOUP Service Oriented Unified Process TI Tecnologia da Informação UDDI Universal Description, Discovery e Integration WSDL Web Services Definition Language XML Extensible Markup Language XP Extreme Programming

7 VII LISTA DE FIGURAS Figura 1 - Exemplo de um Serviço Entidade 28 Figura 2 - Modelo de troca de mensagens exercida por um fornecedor se serviços.42 Figura 3 - Consumidor de serviços requisitando um Fornecedor de serviços 43 Figura 4 - Funcionamento de um serviço de intermediação. 44 Figura 5 - Enterprise Service Bus. 47 Figura 6 - Exemplo de utilização de BPMN. 54 Figura 7 - Exemplo da utilização de um modelo BPEL. 55 Figura 8 - Técnicas envolvidas na identificação de serviços. 63 Figura 9 - Tipos de componentes. 76 Figura 10 - Modelo de processos SOUP. 83 Figura 11 - SOUP e o modelo RUP. 83 Figura 12 - SOUP e o modelo XP. 90 Figura 13 - Modelo de processos pertencentes à fase de análise. 96 Figura 14 - Modelo de processos que permite modelar candidatos a serviços. 98 Figura 15 - Modelo de processos pertencentes à fase de projeto. 104 Figura 16 - Componentes fundamentais em SOA. 105 Figura 17 - Modelo de processos pertencentes à Compose SOA. 106 Figura 18 - Modelo de processos pertencentes ao projeto de serviços centrados em entidades de negócio. 109 Figura 19 - Modelo de processos pertencentes ao projeto de serviços centrados em tarefas de negócio. 114

8 VIII LISTA DE QUADROS Quadro 01 Modelos de serviço 30 Quadro 02 Análise comparativa entre as metodologias para desenvolvimento de software com arquitetura orientada a serviços. 122 Quadro 03 Análise de presença entre as metodologias para desenvolvimento de software com arquitetura orientada a serviços. 126 Quadro 04 Conjunto de práticas sugeridas para o desenvolvimento de SOA. 129

9 IX SUMÁRIO 1. CONSIDERAÇÕES INICIAIS INTRODUÇÃO JUSTIFICATIVA PROBLEMA DE PESQUISA HIPÓTESES OBJETIVOS GERAL ESPECÍFICO METODOLOGIA ESTRUTURA DO TRABALHO ARQUITETURA ORIENTADA A SERVIÇOS FLEXIBILIDADE ORGANIZACIONAL ARQUITETURA DE SOFTWARE ORIENTAÇÃO A SERVIÇOS SERVIÇO DE SOFTWARE COMPOSIÇÃO DE SERVIÇOS INVENTÁRIO DE SERVIÇOS MODELOS DE SERVIÇO Serviço centrado em entidades de negócio Serviço centrado em tarefas de negócio Serviço utilitário OS PARADIGMAS DA ORIENTAÇÃO A SERVIÇOS Contrato padronizado Perda de acoplamento Abstração Reusabilidade Autonomia Sem estado Fácil descoberta Composição BENEFÍCIOS DE SOA REDUÇÃO DOS CUSTOS DE INTEGRAÇÃO DE SISTEMAS REDUÇÃO DO CUSTO DE DESENVOLVIMENTO ATRAVÉS DO REUSO AUMENTO DA AGILIDADE DOS NEGÓCIOS REDUÇÃO DE RISCOS OPERACIONAIS AUMENTO DE INTEROPERABILIDADE INFRAESTRUTURA SOA WEB SERVICES PAPÉIS ASSUMIDOS POR UM SERVIÇO Fornecedor de serviços Consumidor de serviços Serviços de intermediação ENTERPRISE SERVICE BUS (ESB) BUSINESS PROCESS MANAGEMENT (BPM) MODELO DE PROCESSOS DE NEGÓCIOS 53

10 X 3. METODOLOGIAS PARA DESENVOLVIMENTO DE SOA SERVICE ORIENTED MODELING AND ARCHITECTURE (SOMA) VALIDAÇÃO DE INPUTS IDENTIFICAÇÃO Decomposição de domínios Existing asset analysis Goal Service Modeling ESPECIFICAÇÃO Especificação de serviços Análise de subsistemas Especificação de Componentes REALIZAÇÃO Análise de viabilidade técnica Tomada de decisões SERVICE-ORIENTED UNIFIED PROCESS (SOUP) SOUP PARA IMPLANTAÇÃO INICIAL DE SOA Incept Definir Projeto Construir Implantar Manutenção SOUP PARA PROJETOS SOA EM EXECUÇÃO Incept Definir Projeto Construir Implantar Manutenção MAINSTREAM SOA METHODOLOGY (MSOAM) ANÁLISE Definir requisitos de negócio Identificar sistemas existentes Modelar candidatos a serviços Modelagem de serviços Decompor processos de negócio Identificar candidatas a operações Identificar orquestrações lógicas Criar candidatos a serviços Refinar e aplicar princípios da orientação a serviços Identificar candidatos a composições de serviços Revisar operações de serviços Análise de requisitos Identificar operações de serviços a partir de aplicações existentes Criar candidatos a serviços a partir de aplicações existentes Revisar composições de serviços 102

11 XI Revisar operações pertencentes aos candidatos a serviços criados PROJETO Compose SOA Definir camadas de serviço Definir padrões Escolher extensões SOA Projeto de serviços centrados em entidades de negócio Revisão de serviços existentes Definir o tipo de esquema de mensagens Definir a interface do serviço Aplicar princípios da orientação a serviços Padronizar e refinar a interface do serviço Estender o projeto de serviços Identificar o processamento necessário Projeto de serviços centrados em tarefas de negócio Definir o workflow lógico Definir a interface do serviço Aplicar princípios da orientação a serviços Padronizar e refinar a interface de serviços Identificar o processamento necessário ANÁLISE DAS METODOLOGIAS SOA ANÁLISE COMPARATIVA ANÁLISE DE PRESENÇA RESULTADO DA ANÁLISE ARTEFATOS SUGERIDOS PRÁTICAS SUGERIDAS CONCLUSÕES E TRABALHOS FUTUROS CONCLUSÕES TRABALHOS FUTUROS 132 REFERÊNCIAS 133

12 CAPÍTULO I CONSIDERAÇÕES INICIAIS

13 CONSIDERAÇÕES INICIAIS CONSIDERAÇÕES INICIAIS 1.1 INTRODUÇÃO Atualmente, o ambiente corporativo vivencia uma realidade complexa e multifacetada, onde se percebe a presença de uma economia mundial cada vez mais nivelada, a necessidade de se adaptar a mudanças rapidamente e uma concorrência cada vez mais competitiva. São fatores que têm obrigado as empresas a atuarem no mercado de forma ágil e flexível, para garantia de sua sobrevivência. Muitos profissionais comparam esses tempos difíceis ao Darwinismo: Não são os mais fortes das espécies que sobrevivem, nem os mais inteligentes, mais aqueles que respondem melhor as mudanças. A flexibilidade é o conceito de orientação dessa realidade. Segundo Josuttis (2008, p. 1), Flexibilidade é a chave para todas as grandes corporações e os grandes sistemas distribuídos e a flexibilidade da Tecnologia da Informação (TI) é de extrema importância. Na verdade, isso é o capacitador principal de valores de negócio. Como pode ser observado, vivencia-se um tempo onde se pode perceber um mercado totalmente globalizado, que influência a forma como as empresas devem adequar seus processos de negócio para se adaptar rapidamente as mudanças. A necessidade de adaptar os processos de negócio as mudanças exigidas pelo mercado, tem tornado os processos de desenvolvimento de sistemas cada vez mais complexos. A fase da TI em que a questão primária era, simplesmente, automatizar sistemas individuais, já foi ultrapassada, está ocorrendo um movimento em direção a um mundo onde todos esses sistemas individuais se integrarão em um sistema distribuído (JOSUTTIS, 2008 p.1). Desta forma, as maneiras antigas de lidar com os problemas de escalabilidade e distribuição não funcionam mais. Não se pode mais harmonizar ou manter o controle. Por essa razão, é necessário o desenvolvimento

14 CONSIDERAÇÕES INICIAIS 14 de uma nova abordagem uma abordagem que aceite heterogeneidade e que conduza a descentralização. Neste cenário, as organizações tradicionais se deparam com as seguintes necessidades: responder rapidamente ao surgimento de novos requisitos, reduzir constantemente o custo da TI para os negócios, absorver e integrar novos parceiros e clientes. Logo, os Sistemas de Informação (SI) das organizações devem estar preparados tanto para receber informações vindas das mais diversas fontes quanto para fornecer informações e serviços para seus parceiros. A fim de suprir essas necessidades organizacionais, as tradicionais arquiteturas de software ao longo dos anos vêm sofrendo constantes modificações.dentre as mudanças, destacam-se: projetos que permitam processamento distribuído, linguagens de programação multiplataforma, redução do número de tarefas a serem executadas para garantir a conectividade e integração de aplicações melhores e mais rápidas. A Arquitetura Orientada a Serviços (SOA) está sendo visualizada pelas empresas de desenvolvimento de software, como a principal arquitetura capaz de suprir questões como interoperabilidade, perca de acoplamento, modelo de comunicação padronizado e publicação de interfaces (LEWIS, MORRIS e SMITH, 2008 p.7). Devido ao fato que a mesma possui a habilidade de ajudar as organizações de TI a se adequar cada vez mais à complexidade e ao conjunto de desafios encontrados. SOA é um novo paradigma para a realização e a manutenção dos processos corporativos encontrados em grandes sistemas distribuídos (OASIS, apud JOSUTTIS, 2008, p. 18). Entretanto, SOA não é uma tecnologia, que pode ser comprada, na realidade, SOA é uma forma de pensar, ou melhor, pode ser entendido como um sistema para projetar e modelar processos de negócio. Para um melhor entendimento de como SOA poderá auxiliar a superar a complexidade e desafios encontrados pelas empresas de TI, torna-se necessário a compreensão do elemento principal desta arquitetura: o serviço. De acordo com

15 CONSIDERAÇÕES INICIAIS 15 Josuttis (2008, p.7), um serviço é um pedaço de funcionalidade corporativa independente. A funcionalidade pode ser simples (guardar ou armazenar dados de cliente), ou complexa (um processo corporativo de um pedido de cliente). Através dos serviços, são disponibilizadas as funcionalidades abstratas de software, que podem ser flexivelmente constituídos para suportar processos de negócio. Assim como todos os novos paradigmas na área de computação, SOA ainda está engatinhando. O uso de uma boa metodologia de projetos SOA tem se tornado um fator diferencial, visto que influência diretamente na qualidade do produto final (CASTRO e MOREIRA, 2007, p. 1). De acordo com Neto (2004, p.6): Essas metodologias se adéquam às características organizacionais e ao ambiente de desenvolvimento implementado em uma organização, ao paradigma de desenvolvimento e ao tipo de plataforma que o software deve ser desenvolvido, e às características dos projetos: o tempo que pode ser gasto e a real necessidade do cliente, a fim de estimar custos e prazos reais. Como pode ser observado o uso de uma metodologia é fundamental para o sucesso no desenvolvimento de uma aplicação SOA. Porém por se tratar de SOA - um novo paradigma para desenvolvimento - a dificuldade encontrada pelas empresas de desenvolvimento de software é justamente identificar uma metodologia específica para desenvolvimento de SOA, que possua todas as boas práticas e benefícios para desenvolvimento de software com qualidade. Esse trabalho procura descrever e analisar as principais metodologias para desenvolvimento SOA. Onde serão explanados processos e estratégias envolvidas durante a elaboração de software com arquitetura orientada a serviços. 1.2 JUSTIFICATIVA O desenvolvimento de um projeto SOA, requer uma análise concreta dos esforços exigidos pela organização. Onde deve ser adotada uma metodologia capaz de

16 CONSIDERAÇÕES INICIAIS 16 especificar os processos e as estratégias, que deverão ser utilizados para obtenção de sucesso no desenvolvimento do projeto (LEWIS, MORRIS e SMITH, 2008 p.7). Por outro lado, o uso de metodologias tradicionais como, por exemplo, Rational Unified Process (RUP) ou Extreme Programming (XP), não é aconselhável para desenvolvimento de um projeto SOA. Como foi comprovado por Callahan (2007, p.11), o argumento apresentado pelo autor foi justamente que, nenhuma das duas metodologias (RUP ou XP) se demonstrou adequada para o desenvolvimento eficiente e eficaz de SOA. No qual se pôde perceber a ausência de características e princípios que deveriam ser levados em consideração durante a análise, identificação, o projeto e a realização de serviços. Contudo, percebe-se que a utilização de uma metodologia adequada ao perfil do público alvo do desenvolvimento torna-se fundamental, para que as organizações possam utilizar de maneira eficiente os processos necessários para identificação, especificação e realização de serviços. Dessa forma, o desenvolvimento de SOA exige a utilização de metodologias de software que sejam capazes de analisar: esforços, estratégias e processos exigidos para a montagem de componentes e serviços que possibilitaram o desenvolvimento de forma rápida e dinâmica. 1.3 PROBLEMA DE PESQUISA Como as empresas poderão utilizar as metodologias para desenvolver aplicações orientadas a serviço com qualidade? Quais as boas práticas devem ser adotadas durante o projeto e desenvolvimento de software com arquitetura orientada a serviços? Qual o conjunto mínimo de artefatos deve ser produzido por uma organização que pretende desenvolver software com arquitetura orientada a serviços?

17 CONSIDERAÇÕES INICIAIS 17 Existem metodologias de desenvolvimento de software específicas para o desenvolvimento SOA, que abordem os problemas e dificuldades... Quais são os pontos convergentes e divergentes entre as metodologias específicas para SOA? 1.4 HIPÓTESES A utilização de uma metodologia SOA, possibilita o desenvolvimento de uma Arquitetura Orientada a Serviços de forma eficaz e eficiente. O uso de uma das metodologias estudadas é capaz de prever riscos, custos e esforços necessários para o desenvolvimento de um SOA. A adoção de uma metodologia para desenvolver SOA é capaz de identificar, especificar e realizar serviços de software. O emprego de uma metodologia SOA é capaz de conduzir a equipe de desenvolvimento na construção de serviços de software a partir de processos de negócio. 1.5 OBJETIVOS Geral Desenvolver uma análise comparativa entre as metodologias que possibilitam o desenvolvimento de software com arquitetura orientada a serviços Específico Realizar uma pesquisa sobre as metodologias que possibilitam o desenvolvimento de uma Arquitetura Orientada a Serviços.

18 CONSIDERAÇÕES INICIAIS 18 Identificar e analisar as boas práticas presentes em cada metodologia estudada. Realizar um estudo sobre os conceitos, estratégias e tecnologias relacionados a uma Arquitetura Orientada a Serviços. Identificar e detalhar os processos presentes em cada metodologia estudada, que oferecem fundamentos necessários para o projeto e desenvolvimento orientado a serviços. Sugerir o conjunto mínimo de artefatos que deve ser produzido por uma organização que pretende desenvolver software com arquitetura orientada a serviços. Avaliar as estratégias oferecidas por cada metodologia estudada quanto a: Ciclo de vida coberto, estratégia de entrega, prescrição, agilidade, aplicabilidade no setor de desenvolvimento de software, suporte a papéis e a presença de processos tradicionais existentes (como por exemplo: RUP ou XP). 1.6 METODOLOGIA Inicialmente será desenvolvido um estudo bibliográfico para definição de conceitos e quadro teórico da pesquisa, visando formar um embasamento teórico para o desenvolvimento do trabalho. Para isso serão utilizadas diferentes formas de referências bibliográficas como: livros, revistas eletrônicas, artigos e principalmente a documentação e manuais referentes às metodologias presentes no estudo. Os materiais a serem estudados têm como finalidade dar base de conhecimento na busca dos seguintes objetivos: Identificar os processos e estratégias presentes em cada metodologia;

19 CONSIDERAÇÕES INICIAIS 19 Apresentar uma análise comparativa entre as metodologias que estão ganhando ênfase no desenvolvimento de SOA. Em seguida, será realizado o levantamento e reconhecimento das potencialidades apresentadas por cada metodologia estudada, por sua vez, esse embasamento teórico estará subdividido da seguinte forma: Levantamento e reconhecimento das metodologias a serem estudadas; Pré-Diagnóstico de cada metodologia a ser utilizada, onde será verificado a presença dos seguintes pontos: reutilização de componentes, analise de viabilidade, riscos e esforços necessários para o projeto de identificação, especificação e realização de serviços. 1.7 ESTRUTURA DO TRABALHO Esse trabalho está subdividido em 5 (cinco) capítulos. O primeiro capítulo como pôde ser visto, apresenta as informações iniciais utilizadas para situar o leitor do conteúdo que será abordado ao decorrer desse trabalho. O capitulo 2 (dois) fornece uma visão geral sobre os conceitos básicos e a importância de uma Arquitetura Orientada a Serviços (SOA). O capitulo 3 (três) apresenta e descreve os processos e as estratégias pertencentes a cada metodologia estudada. O capitulo 4 (quatro) exibe uma análise comparativa entre as metodologias estudadas. E finalmente o capitulo 5 (cinco) onde serão demonstrados as conclusões finais e os trabalhos futuros.

20 CAPÍTULO II ARQUITETURA ORIENTADA A SERVIÇOS

21 ARQUITETURA ORIENTADA A SERVIÇOS ARQUITETURA ORIENTADA A SERVIÇOS A orientação a serviços tem sido apontada por Thomas Erl (2008, p.70), como um novo paradigma de projetos na área de Engenharia de Software, capaz de introduzir tanto oportunidades como desafios que devem ser enfrentados pelas organizações que pretendem utilizá-la. Esse capítulo tem por objetivo fornecer informações que promovem a apresentação e descrição dos seguintes assuntos: Arquitetura de software, orientação a serviços, modelos de serviços e como todos esses fatores estão fortemente interligados, para definir e conceitualizar SOA. Também poderão ser visualizados os elementos comumente encontrados na infra-estrutura necessária para desenvolvimento de SOA, quais são os benefícios atribuídos a uma Arquitetura Orientada a Serviços e, como os mesmos poderão auxiliar nos problemas encontrados pelas grandes organizações. 2.1 FLEXIBILIDADE ORGANIZACIONAL Uma série de problemas poderá ser solucionada caso uma corporação apresente altos índices de flexibilidade. Entre eles se destacam: Ajustar suas ofertas as necessidades dos clientes, o que fatalmente atingiria maior fatia de clientes no mercado; Desenvolvimento de novos produtos, de forma rápida e eficiente, visando adequar rapidamente suas mercadorias as exigências impostas por um mercado competitivo; Aperfeiçoamento dos processos de gerenciamento, visando maximizar a produtividade.

22 ARQUITETURA ORIENTADA A SERVIÇOS 22 Resumindo, flexibilidade é a chave para longevidade, rentabilidade e sucesso para todas as empresas. No entanto, para Bloomberg e Schmelzer (2006, p.14) a obtenção de flexibilidade organizacional deve está alinhada proporcionalmente ao poder de flexibilidade da TI, e por conseqüência os produtos de software devem possuir a capacidade de se adaptar rapidamente ao surgimento de cada novo requisito. Os processos de negócio que vigoram dentro de uma organização e que tradicionalmente são coordenados executados através de aplicações de software, serão obrigados a se adequar ao mercado competitivo, e certamente esse fato ocasionará uma série de alterações. Com isso, os software responsáveis por implementar cada processo, devem estarem preparados justamente para absorver rapidamente essas modificações exigidas. As principais dificuldades apresentadas pelas tradicionais aplicações de software ocorrem quando as mesmas precisam sofrer alguma modificação ou implementar algum novo requisito (HURWITZ; BLOOR & KAUFMAN, 2009 p.6). Por outro lado, uma Arquitetura Orientada a Serviços tem por objetivo utilizar Tecnologia de Informação (TI), para solucionar problemas de flexibilidade dentro de uma empresa. Através do uso de SOA as empresas poderão ser capazes de combinar novas abordagens tecnológicas, inclusive ter a oportunidade de conhecer e utilizar novos pensamentos referentes ao processo de desenvolvimento de software, que são capazes de fornecer recursos que melhoraram o nível de flexibilidade dentro das corporações (BLOOMBERG & SCHMELZER 2006, p.4). 2.2 ARQUITETURA DE SOFTWARE Arquitetura de software atua como a estrutura organizacional de um sistema (IEEE STANDARD , apud KRAFZIG; BANKE & SLAMA 2004).

23 ARQUITETURA ORIENTADA A SERVIÇOS 23 Por outro lado, arquitetura de software pode ser entendida, como um conjunto de decisões que define a organização de um sistema de computação (RUMBAUGH & JACOBSON, apud KRAFZIG; BANKE & SLAMA, 2004). No entanto, a arquitetura de software de um programa de computador é simplesmente a estrutura ou as estruturas do sistema, que compreende os elementos de software, as propriedades externamente visíveis desses elementos, e o relacionamento entre eles (CLEMENTS & KAZMAN, apud KRAFZIG; BANKE & SLAMA, 2004). Mais informações sobre arquitetura podem ser encontradas no site do Software Engineering Institute (SEI), que mantém uma lista de definições sobre o assunto. Como pode ser observado são várias as definições atribuídas à arquitetura de software. Porém, a principal característica que deve ser destacada perante sua definição é justamente sua capacidade de estruturar e descrever organizacionalmente a forma como os componentes são montados, relacionados e se comunicam entre si dentro de um sistema de software. Pois através dessa característica podemos estabelecer requisitos bem definidos, o que atribui qualidade e facilita não apenas no processo de desenvolvimento, como também em futuras modificações realizadas no software, já que se torna inevitável construir sistemas que não estejam sujeitos a modificações. Pode-se perceber que uma arquitetura de software tradicional é capaz de descrever a estrutura de componentes, seus relacionamentos e sua importância nos processos de desenvolvimento de software. Por outro lado, quando o termo arquitetura de software está associado a SOA, será possível descrever estruturalmente cada serviço, como os mesmos estão interligados e o valor que eles agregam aos processos e soluções desenvolvidas pelas organizações.

24 ARQUITETURA ORIENTADA A SERVIÇOS ORIENTAÇÃO A SERVIÇOS De acordo com Thomas Erl (2005), o termo orientação a serviços já existe há algum tempo, e tem sido usado em diferentes contextos e para diversas finalidades. Um dos valores defendidos pelo autor é justamente que a orientação a serviços representa uma abordagem distinta para separação de preocupações. Isso significa que a lógica necessária para resolução de um grande problema, pode ser melhor construída, realizada, e gerenciada se esse problema for decomposto em uma coleção de soluções menores e bem relacionadas. Onde cada uma dessas pequenas soluções é endereçada a uma parte específica do problema Para Michael Bell (2008, p.29), o termo orientação a serviços é um método para estabelecer conceitos empresariais, desenvolvidos para organizar requisitos de negócios e especificações de produtos de software. Esses ideais empresariais e tecnológicos podem facilitar o projeto, arquitetura e construção de serviços de software. Logo, pode-se notar que a orientação a serviços possui como um de seus princípios suprir as necessidades expostas pelas organizações. Como pode ser observado, temos a decomposição de uma solução em soluções menores, na realidade cada solução pode ser entendida como um serviço de software, que é especificamente projetado e construído para aumentar a produtividade e agilidade dos processos de negócio que vigoram dentro da organização. Para auxiliar na compreensão de como essas soluções serão desenvolvidas, tornase necessário o conhecimento sobre a idéia apresentada por um serviço de software. Para Michael Bell (2008, p.29), esses serviços de software podem capturar as soluções propostas e fornecer uma melhor compreensão dos problemas e preocupações enfrentados pelas empresas.

25 ARQUITETURA ORIENTADA A SERVIÇOS Serviço de software Um serviço é qualquer componente de software que possui um distinto significado funcional, que tipicamente encapsula um alto nível dos processos de negócio que atuam dentro de uma organização. E está constituído das seguintes partes (KRAFZIG; BANKE & SLAMA, 2004): Contrato: Responsável por fornecer informações específicas relacionadas à finalidade, as funcionalidades e a forma como o serviço deve ser utilizado; Interface: A funcionalidade do serviço é exposta através da interface, dessa forma o cliente poderá visualizar as possíveis funções que podem ser desempenhadas por aquele serviço; Implementação: Fornece a lógica de negócio e os dados necessários para desenvolvimento do serviço. A implementação do serviço consiste de um ou mais artefatos, que pode ser representado por classes ou trechos de código; Lógica de negócios: Trata-se de uma parte do serviço que é encapsulada e utilizada durante o processo de implementação; Dados: Opcionalmente um serviço pode conter dados. Por outro lado, Michael Bell (2008, p.50) defende que os serviços incorporam a alma dos requisitos de software; Eles expressam organizacionalmente idéias, pensamentos, opiniões, visões, ou temas que sugerem soluções de software para os problemas pertencentes às organizações. Portanto, pode-se perceber que um serviço de software deve ser entendido como um componente de software, que é formado por partes bem definidas, e que tem por objetivo solucionar os problemas das organizações que utilizam Tecnologia da Informação (TI).

26 ARQUITETURA ORIENTADA A SERVIÇOS 26 Ao estabelecer uma noção conceitual sobre serviço de software, torna-se visível que o mesmo é o fator principal para realização de um desenvolvimento orientado a serviços. Onde, através do desenvolvimento de serviços, as empresas poderão suprir suas necessidades, e se adequar as constantes modificações exigidas pelo mercado. Por outro lado, serviços individuais já desenvolvidos não são capazes de suprir e realizar novas necessidades empresariais. Dessa forma, a estratégia tradicionalmente adotada e sugerida por uma arquitetura orientada a serviços é justamente a composição serviços Composição de serviços Normalmente as organizações utilizam a combinação de serviços de software já existentes, para suprir uma nova necessidade identificada pelos processos de negócio que atuam dentro da organização. A um serviço implementado a partir da composição de outros serviços, chama-se de composição de serviços (ROSEN; LUBLINSKY & SMITH, 2008 p.62). Um dos principais fundamentos que viabiliza a composição é a reutilização de serviços que já estão operando no ambiente de software organizacional. Através do reuso, serviços podem ser combinados naturalmente e repetidamente a fim de agregar novos valores e suportar novas necessidades organizacionais. Entretanto, uma arquitetura orientada a serviços normalmente abriga uma grande quantidade de serviços, com finalidades, características e segmentos empresariais diferenciados. O inventário de serviços é a estratégia sugerida, para a padronização e o gerenciamento de serviços Inventário de serviços O inventário de serviço é uma coleção de serviços complementares que são independentes, padronizados, governados e representam uma empresa ou um segmento significativo de uma empresa (ERL, 2008 p.40). É válido ressaltar, que

27 ARQUITETURA ORIENTADA A SERVIÇOS 27 nada impede que um ambiente empresarial possa conter vários inventários de serviço, desde que cada um seja individualmente padronizado e governado por uma arquitetura orientada a serviços. Normalmente, o desenvolvimento de um SOA, exige a implementação de um número elevado de serviços de software. Dessa forma, existem alguns fundamentos que são levados em consideração durante o planejamento desses serviços, como: escopo, propriedades, funcionalidades e finalidade Modelos de Serviço Uma das boas práticas adotadas pelos desenvolvedores SOA é justamente agrupar os serviços de software de acordo com sua finalidade. Segundo Thomas Erl (2008, p.43), os serviços podem ser divididos em três modelos de serviço: entidade, tarefa e utilidade Serviço centrado em entidades de negócio Serviços do tipo entidade são desenvolvidos especialmente para suprir as necessidades pertencentes aos processos de negócio. O alto teor de reusabilidade é o fator principal pelo qual esse modelo de serviço é implementado constantemente. O serviço entidade fornece um enorme potencial para reuso (ROSEN; LUBLINSKY & SMITH, 2008 p.71). Essa característica permite que serviços entidade desenvolvidos especialmente para um processo de negócio em particular, possam ser reutilizados para implementar novas necessidades empresariais expostas pelas organizações. Abaixo pode ser visto na figura 1 a representação de um serviço entidade, contendo um conjunto de funções relacionadas à entidade funcionário de uma determinada organização.

28 ARQUITETURA ORIENTADA A SERVIÇOS 28 Figura 1 - Exemplo de um Serviço Entidade Employee GetWeeklyHoursLimit UpdateWeeklyHoursLimit GetHistory UpdateHistory DeleteHistory AddProfile DeleteProfile UpdateProfile Fonte: Thomas Erl, Serviço centrado em tarefas de negócio Assim como o serviço centrado em entidade de negócio, o serviço tarefa também está totalmente voltado para suprir as necessidades dos processos de negócio. No entanto, um serviço tarefa é composto por pequenos serviços e devem ser projetados especificamente para suportar um ou mais processos. (ROSEN; LUBLINSKY & SMITH, 2008 p.71). Contudo, apesar de ambos os modelos de serviço suportarem processos de negócio, quando se trata de serviço tarefa, o objetivo é implementar uma determinada necessidade exigida por um processo de negócio. Dessa forma, o desenvolvimento do serviço é subdividido em capacidades, onde cada capacidade na realidade é um pequeno serviço. Com isso, cada capacidade irá encapsular uma lógica de processo do negócio, formando uma seqüência de passos para completar o serviço tarefa em especifico. É válido ressaltar, que quando se trata de serviço tarefa, ocorre um baixo nível de reusabilidade de serviços (ERL, 2007 p.45). Devido ao fato que cada pequeno serviço desenvolvido, é especialmente implementado para compor uma etapa do

29 ARQUITETURA ORIENTADA A SERVIÇOS 29 serviço tarefa. Dessa forma, um serviço que é desenvolvido para esse fim, apresenta ligação e um conjunto de características fortemente associadas à etapa da tarefa que o mesmo tenha sido designado a implementar. Logo, esse fato reduz as possibilidades que o serviço seja reutilizado por outro processo de negocio. A seguir será descrito um exemplo de serviço tarefa, que basicamente representa um processo de negócio que calcula o faturamento de um determinado cliente de uma empresa. Para cumprir tal tarefa, basicamente necessitaria realizar alguns cálculos matemáticos e consultar o histórico de compras do cliente. Após o término das duas atividades, o faturamento poderia então ser emitido. Apesar de ser um processo fictício composto basicamente por duas tarefas, pode-se associar o exemplo a fragmentação de pequenos serviços citados anteriormente, que deveriam ser associados para compor uma determinada tarefa ou serviço tarefa Serviço utilitário Diferente do que pôde ser visualizado anteriormente, onde os tipos de serviço possuíam sua lógica de implementação, fortemente interligada aos processos de negócio que vigoram dentro de uma organização, os serviços utilitários estão voltados para automatizar um ambiente SOA. De acordo com Thomas Erl (2008, p.46), uma organização que possui SOA, deve manter um ambiente de software autônomo. Logo, para que isso se torne realidade, deve ser utilizado o serviço utilitário, que possui a capacidade de fornecer decisões complexas, relacionadas às regras de negócio estabelecidas pela organização. Serviço utilitário também pode ser usado como: eventos de login, notificações, lançamento de exceções e etc. Abaixo segue um quadro que exibe a principal característica e um exemplo de cada modelo de serviço apresentado.

30 ARQUITETURA ORIENTADA A SERVIÇOS 30 Quadro 01 Modelos de serviço Modelo de Serviço Principal Característica Exemplo Entidade Tarefa Utilitário Alto teor de reusabilidade Capacidade de fragmentar processos de negócio, em várias tarefas. Habilidade de automatizar um ambiente SOA Conjunto de métodos CRUD, para controle de funcionários. Calcular o faturamento de um cliente. Lançamento de exceções. Fonte: Danilo Vieira, Após a fundamentação teórica sobre serviço de software, onde foram abordados assuntos como: composição, inventário e modelos de serviço, a seguir serão apresentados os paradigmas que compõem a orientação a serviços Os paradigmas da orientação a serviços Para que a orientação a serviços seja realizada com sucesso dentro de um ambiente, torna-se necessário que a solução lógica seja desenvolvida, de forma que os serviços sejam implementados seguindo um conjunto de paradigmas em especifico (ERL, 2008, p.70), que por sua vez, nada mais é do que um guia de princípios que especifica o seguinte conjunto de propriedades: contrato padronizado, perda de acoplamento, abstração, reusabilidade, autonomia, sem estado, fácil descoberta e composição. Onde todas elas devem estar presentes em cada serviço desenvolvido.

31 ARQUITETURA ORIENTADA A SERVIÇOS Contrato padronizado De acordo com Thomas Erl (2008, p.71), o contrato padronizado é responsável por expressar informações que especificam a finalidade, as funcionalidades e as capacidades que podem ser exercidas por um serviço de software. Dessa forma, durante o processo de desenvolvimento devem ser levadas em consideração as políticas e as regras que regulamentam cada serviço, assim como, a especificação de todos os modelos de dados e as mensagens de entrada e saída suportada por cada função pertencente ao serviço de software Perda de acoplamento O termo acoplamento se refere à dependência e relacionamento entre módulos, componentes ou serviços. O alto nível de acoplamento entre serviços afeta a flexibilidade e a estabilidade do sistema, tornando-o mais vulnerável às falhas (ROSEN; LUBLINSKY & SMITH, 2008 p.64). Thomas Erl (2008, p.165) define perda de acoplamento, como uma propriedade capaz de possibilitar que um serviço seja utilizado juntamente com outro serviço, ainda que ambos sejam totalmente independentes. Portanto, acoplamento pode ser entendido como o nível de dependência existente entre os serviços. O ideal é que todos os serviços fossem desenvolvidos com baixos níveis de acoplamento, dessa forma seriam produzidos serviços menos dependentes e conseqüentemente mais flexíveis. Quando se desenvolve serviços mais flexíveis e com poucas dependências, tanto as modificações como as falhas em um serviço proporcionaram poucas conseqüências aos demais serviços ou sistemas que estão interligados.

32 ARQUITETURA ORIENTADA A SERVIÇOS Abstração Com base em Thomas Erl (2008, p.213), pode-se ter a seguinte definição sobre abstração, esconder informações de um programa, que não são necessárias para que outras pessoas possam utilizá-lo corretamente. O autor ainda enfatiza que é de fundamental importância esconder o máximo possível os detalhes de implementação de um serviço. Projetar e construir serviços com uma boa abstração proporciona redução de aclopamento, acomodação de mudanças e facilidade na separação de preocupações. Isso pode ser observado em serviços de alto nível, que escondem a complexidade e os detalhes de implementação por trás de uma consistente interface que é especificada e desenvolvida de acordo com os processos de negócio (ROSEN; LUBLINSKY & SMITH, 2008 p.64). Como pode ser notada, a abstração de um serviço, é justamente a capacidade de ocultar informações técnicas, que não são necessárias para que o cliente possa utilizar o serviço efetivamente. Normalmente são informações técnicas que estão relacionadas a detalhes de implementação, e estão fortemente encapsuladas Reusabilidade De acordo com Thomas Erl (2008, p.254), reuso é fazer com o que um serviço de software seja capaz de realizar mais do que uma única finalidade. O autor enfatiza que tornar um serviço potencialmente reutilizável, possibilita o aumento da capacidade de acomodar futuros requisitos sem que haja a necessidade de muitos esforços durante o processo de desenvolvimento. Portanto, serviços podem ser reutilizados para desempenhar mais do que apenas uma única finalidade. Caso seja levado em consideração que um serviço de software responsável por implementar apenas um processo de negócio, possui a capacidade de agregar valor a organização. Então, caso um serviço for reutilizado para representar mais do que um único processo de negócio, conseqüentemente o

33 ARQUITETURA ORIENTADA A SERVIÇOS 33 serviço poderá atrair uma gama maior de valores, muito mais valiosos e mais atrativos para organização. O reuso é também é fundamental para a composição de serviços. Através do agrupamento lógico de serviços existentes, novos serviços podem sem agrupados, a fim de constituir composições que serão capazes de realizar novos requisitos de negócios, que surgem constantemente em um ambiente organizacional Autonomia Autonomia representa a habilidade de auto-governo. Uma máquina que é autônomoa tem a liberdade e o controle para tomar suas próprias decisões, sem a necessidade de aprovação ou envolvimento externo (ERL, 2008 p.294). No entanto, quando esse termo está associado a serviço de software, autonomia representa a capacidade de realizar a lógica do serviço independentemente, ou seja, o mesmo pode ser implantado, modificado e mantido independentemente de outros serviços ou soluções que esteja utilizando-o Sem estado Durante a realização de uma determinada tarefa, normalmente o serviço necessita processar uma série de dados, o tempo em que o serviço está processando e utilizando esse conjunto de dados, é conhecido como estado de um serviço. Caso um serviço mantenha seu estado por um longo período de tempo, certamente terá sua disponibilidade afetada. (ERL, 2008, p ). Logo, pode-se perceber que os serviços devem ser desenvolvidos sem estado. Onde, assim que um serviço tenha terminado de executar sua tarefa solicitada, todos os dados, que na realidade são variáveis e objetos locais que tinham sido criados temporariamente para executar o serviço, devem ser excluídos.

34 ARQUITETURA ORIENTADA A SERVIÇOS Fácil descoberta Com base em Thomas Erl (2008, p.362), o processo de procurar e encontrar uma solução lógica dentro de um ambiente específico é conhecido como descoberta. O autor complementa afirmando que um componente arquitetural desenvolvido adequadamente é facilmente descoberto. Porém, para que um serviço de software seja descoberto dentro de uma organização, é necessário que o mesmo seja equipado com meta informações (informações sobre informações) que torna o serviço capaz de ser introduzido dentro do escopo de pesquisa e descoberta. Contudo, percebe-se que esse paradigma permite que o serviço seja encontrado facilmente dentro do ambiente de software da organização. Quando o autor menciona o termo meta informações, na realidade se trata de informações que estão especificadas no contrato do serviço e, permitem que os serviços sejam encontrados facilmente através de registros de armazenamento Composição Composição de serviços, nada mais é do que um processo de combinar serviços existentes, com o objetivo de formar um novo serviço de alto nível. A composição de serviços habilita o desenvolvimento de novos processos, permitindo que as empresas possam adotar novos processos de negócio, tornando-os muito mais eficientes, e conseqüentemente melhorando o nível dos serviços oferecidos a clientes e parceiros (BROWN, 2008). Como pode ser visto, serviços podem ser combinados em serviços mais complexos. Um dos fatores fundamentais, para a adoção desse paradigma é justamente que a composição possibilita que serviços já existentes sejam combinados para implementar novos funções de negócio. Essa nova capacidade, não apenas proporciona o aperfeiçoamento dos serviços já existentes, como também, durante o processo de desenvolvimento, minimiza custos e esforços por parte da organização.

35 ARQUITETURA ORIENTADA A SERVIÇOS 35 As organizações que desenvolverem serviços de software seguindo esses paradigmas descritos acima poderão se preparar melhor para enfrentar os novos requisitos que surgem durante as constantes mudanças ocasionadas pelo mercado globalizado. 2.4 BENEFÍCIOS DE SOA As organizações esperam que uma Arquitetura Orientada a Serviços possam resolver praticamente todos os seus problemas tecnológicos. Na realidade essa situação é comum, assim como todos os novos paradigmas que surgem, SOA vem desencadeando uma série de mitos e fatos a respeito de suas qualidades, a seguir serão apresentados os reais benefícios ocasionados pela implantação de SOA Redução dos custos de integração de sistemas Um dos desejos pretendidos pelas organizações é justamente cortar custos. O adequado desenvolvimento de SOA pode reduzir os custos de integração de sistemas. O fraco acoplamento associado a padrões de desenvolvimento baseados em interfaces mantêm um baixo custo para a integração de sistemas. A utilização de protocolos padronizados, formatos de dados bem definidos, e o uso de interfaces, reduz grande quantidade dos custos tradicionais com a integração de sistemas, permitindo que gastos possam ser reduzidos ou até mesmo evitados. Outra abordagem adotada pelas organizações que se tornou possível após o surgimento de SOA é justamente o uso de Web Services, que tem por função, atuar como interfaces entre sistemas. Os mesmos são responsáveis por substituir conectores e adaptadores que necessitavam de licenciamento para serem utilizados (GABHART & BHATTACHARYA, 2008 p.60). Portanto, como pode ser visto que SOA reduz os custos de integração de sistemas para as organizações através de fundamentos como acoplamento fraco, interfaces ou dados com formatos bem definidos. Outra possibilidade é justamente através da combinação de outras tecnologias, como é o caso do uso de Web Services, que atuam como interface entre sistemas e substituem perfeitamente componentes de

36 ARQUITETURA ORIENTADA A SERVIÇOS 36 software, que normalmente eram mantidos através de licenciamentos, ocasionando despesas e maiores gastos as organizações Redução do custo de desenvolvimento através do reuso As organizações tratam o reuso como a maior razão para adoção de SOA (GABHART & BHATTACHARYA, 2008 p.62). A idéia de reuso de software tem ultrapassado décadas, o pensamento inicial estava focado justamente no reuso de funções, objetos, classes, bibliotecas. No entanto as empresas vivenciam uma época onde a necessidade é justamente reutilizar serviços de software no mesmo tempo de execução. Ou seja, o mesmo serviço deve ser capaz de executar suas funcionalidades dentro de um número diferente de subsistemas ao mesmo tempo, isso não só implica no compartilhamento comum de uma base de código, mas agora em diferentes subsistemas que estão compartilhando a mesma aplicação de dados (KRAFZIG; BANKE & SLAMA, 2004). Outro fator associado ao reuso, é justamente que um serviço não está preso ou confinado ao projeto para o qual ele foi inicialmente desenvolvido, e por isso pode ser reusado em outras aplicações (KRAFZIG; BANKE & SLAMA, 2004). Logo, essa é uma das estratégias adotadas pela TI, onde atividades não devem ser separadas por projeto, em vez disso, devem ser associadas e combinadas para atingir sinergia total. Através do reuso fornecido por SOA, desenvolvedores podem criar novos processos de negócio e compor novas aplicações utilizando serviços existentes (BLOOMBERG & SCHMELZER, 2006 p.192). Dessa forma, as organizações podem reduzir tanto o tempo para construir novas composições de serviços como também será possível reduzir os custos com o desenvolvimento, pois parte dos serviços que irão compor a aplicação, já estão

37 ARQUITETURA ORIENTADA A SERVIÇOS 37 devidamente desenvolvidos e testados. Uma das boas práticas adotadas pelas organizações que utilizam essa estratégia, é iniciar o projeto implementando as funcionalidades básicas. Baseado nessa implementação inicial, novas funcionalidades são adicionadas passo a passo, reusando as funcionalidades que já tenham sido desenvolvidas. É válido ressaltar que, as organizações que reutilizam serviços, não associam seus ganhos apenas à redução de tempo e custo de desenvolvimento. A partir do momento que o tempo consegue ser bem administrado pela empresa, o tempo que seria gasto com o desenvolvimento pode ser mais bem utilizado, como por exemplo, para repensar necessidades expostas pelos clientes ou recriar novos processos de negócio. Outro fator que deve ser lembrado é justamente a experiência obtida pela equipe de desenvolvimento que irá obter maior habilidade para futuras criações, implementações e composições de serviços Aumento da agilidade dos negócios Aumentar a agilidade dos negócios dentro das organizações é mais um dos promissores benefícios oferecidos por SOA. O termo agilidade significa uma forma de medir a velocidade com o que uma organização consegue modificar capacidades existentes, criar novos produtos e serviços, ou modificar processos de negócio. Uma Arquitetura Orientada a Serviços aumenta a visibilidade de compreensão de regras de negócio, e permite que as organizações possam desenvolver serviços capazes de modificar as habilidades empresariais ofertadas (GABHART & BHATTACHARYA, 2008 p.64). O aumento da agilidade dos negócios pode resultar na habilidade de capturar fluxos e receitas que a companhia anteriormente considerava inacessíveis e, com isso, proporcionar as organizações novas possibilidades para disponibilizar novos valores empresariais a fornecedores e parceiros, podendo resultar em significativas novas oportunidades de negócio (BLOOMBERG & SCHMELZER, 2006 p.193). Como pode ser visto um dos benefícios ofertados por SOA é justamente o aumento da agilidade dos negócios que vigoram dentro de uma organização. Contudo, SOA

38 ARQUITETURA ORIENTADA A SERVIÇOS 38 atua fornecendo um coleção de serviços de software capazes de implementar as habilidades empresariais pertencentes às organizações, no qual os serviços possuem a capacidade de ser facilmente e rapidamente modificados, de acordo com as necessidades exigidas pelo mercado. Dessa forma, as constantes modificações podem ser executadas dentro do ambiente organizacional, e novos serviços podem ser oferecidos a clientes, fornecedores e parceiros, tornando-se a respectiva diferença em um mercado competitivo Redução de riscos operacionais Uma das boas práticas oferecidas por SOA é justamente o efetivo gerenciamento de riscos durante o desenvolvimento. Onde um sistema tem suas funcionalidades subdivididas em serviços de software. SOA possibilita que a equipe de desenvolvedores possa utilizar poucos componentes tanto para desenvolver novas capacidades como para realizar modificações em sistemas existentes, proporcionando a redução de riscos. Adicionalmente, o foco é mantido somente nos processos ou serviços que realmente devem ser modificados, dessa forma os mesmos são devidamente isolados e testados sem que haja interferência nos demais sistemas. Interfaces bem definidas, serviços modulares, e distintas camadas de software, trabalham juntos para produzir um ambiente com baixos índices de riscos operacionais. Como pode ser observado, uma arquitetura orientada a serviços auxilia no isolamento de processos de negócio, dessa forma grandes modificações, ou até mesmo a introdução de um novo sistema dentro de um existente fluxo de processos de negócio, pode ser realizado sem grandes dificuldades. Contudo, a utilização de interfaces bem definidas e um efetivo mapeamento de dados, permite que uma SOA possa acomodar um conjunto significativo de modificações enquanto minimiza o impacto em processos de negócio já existentes (GABHART & BHATTACHARYA, 2008 p.66).. Contudo, SOA auxilia na decomposição de sistemas grandes e complexos em serviços de software, que podem ser melhor estimado e planejado efetivamente.

39 ARQUITETURA ORIENTADA A SERVIÇOS 39 A decomposição de sistemas complexos em serviços bem gerenciáveis atua como uma ferramenta efetiva durante o projeto de desenvolvimento, proporcionando o gerenciamento de estratégias. Dessa forma, SOA possibilita que funcionalidades complexas possam ser executadas em uma seqüência de pequenos passos, que reduz os riscos do projeto, pois potenciais problemas podem ser identificados durante os processos iniciais do desenvolvimento Aumento de interoperabilidade Interoperabilidade é a capacidade para se comunicar, executar programas, ou transferir dados entre várias unidades funcionais, de forma que o usuário necessita de pouco ou nenhum conhecimento relacionado às características pertencentes a cada unidade utilizada (ISO/IEC , apud BELL, 2008, p. 355). Ainda segundo o autor, interoperabilidade estabelece mecanismos que auxiliam os serviços de software a alcançar os seguintes objetivos organizacionais: padronização de contratos, estabilidade, estrutura lógica e comportamental bem definida de uma arquitetura, segurança e etc. Dessa forma a organização poderá produzir e montar composições de serviços de software para auxiliar na automatização de tarefas de negócio. Logo, SOA proporciona o aumento de interoperabilidade dentro das organizações. Onde, os sistemas pertencentes às corporações ou até mesmo de outros proprietários como: é o caso de parceiros ou fornecedores, que podem trocar ou compartilhar informações de forma autônoma, ou seja, sem que haja a necessidade de conhecer informações relacionadas à especificação técnica, como por exemplo, linguagem de programação, plataforma operacional, versão de desenvolvimento ou localização do determinado sistema que se deseja realizar a troca ou compartilhamento de informações. Essa nova possibilidade é de fundamental importância para que as empresas possam se comunicar com parceiros, fornecedores ou ate mesmo utilizar serviços de software terceirizados. Isso se torna possível graças a SOA, que oferece fundamentos como: padronização de contratos, estabilidade, estrutura lógica e

40 ARQUITETURA ORIENTADA A SERVIÇOS 40 comportamental bem definida de uma arquitetura e segurança necessária para automatização de processos de negócio que atuam dentro da organização. 2.5 INFRAESTRUTURA SOA Qualquer infraestrutura SOA deve ser capaz de fornecer abordagens tecnológicas e especificar padrões, que deverão ser utilizados durante o projeto de desenvolvimento de uma Arquitetura Orientada a Serviços (JURIC; LOGANATHAN & SARANG, 2007 p.100). A seguir serão apresentadas e descritas as tecnologias e os padrões que promovem o desenvolvimento de SOA Web services Anteriormente, na seção 2.2.5, foram apresentados os conceitos relacionados aos paradigmas que devem ser obedecidos durante o desenvolvimento orientado a serviços. A seguir poderá ser acompanhado uma das tecnologias mais utilizadas para promover o desenvolvimento de software orientado a serviços, durante a implementação das funcionalidades pertences aos processos de negócio que atuam dentro das empresas. Web services é visto por muito dos analistas, fabricantes e autores, como a maneira em que SOA deve ser realizado na prática. SOA contemporânea representa uma... arquitetura que promove orientação a serviços e é composta de... serviços, implementados como Web services (ERL, apud JOSUTTIS, 2008, p. 181). De acordo com Josuttis (2008, p.182): Web services refere-se a um conjunto de padrões que cobrem a interoperabilidade. Na realidade, esses padrões definem tanto os protocolos que são usados na comunicação quanto o formato das interfaces que são usados para especificar os serviços e contratos de serviços.

41 ARQUITETURA ORIENTADA A SERVIÇOS 41 Logo, a utilização de Web services fornece a infraestrutura necessária para o desenvolvimento orientado a serviços, uma das características pertencentes aos Web services é justamente o fornecimento de uma arquitetura bem estruturada, capaz de fornecer um conjunto de padrões utilizados para especificar protocolos e interfaces, que oferecem os fundamentos necessários para que as organizações possam desenvolver produtos de software com altos índices de interoperabilidade, permitindo a comunicação entre sistemas ou serviços de software, independentemente de linguagem de programação, plataforma ou sistema operacional utilizados. Todo Web services mantém uma classificação temporária baseado em papéis que o mesmo pode assumir, durante o tempo de execução e processamento de uma mensagem Papéis assumidos por um serviço Como pôde ser visto na seção anterior Web services representa uma das tecnologias capazes de implementar serviços, devido a esse fato, durante o decorrer desse capítulo as palavras serviço e Web service podem ser tratadas como sinônimos. Contudo, um dos fundamentos empregados pelo o uso de Web services é justamente a capacidade de assumir diferentes papéis, dependendo do contexto que o mesmo está sendo inserido ou usado. Segundo Thomas Erl (2006), não é nada incomum que Web services possa modificar seu papel mais do que uma vez dentro de uma determinada tarefa de negócio, isso irá depender exclusivamente das responsabilidades de processamento pertencentes a cada serviço, Na realidade, é comum que Web services possa assumir, dentro de SOA, vários papeis em diferentes tarefas de negócio. A seguir serão apresentados os tipos de papéis que podem ser assumidos por Web Services Fornecedor de serviços De acordo com Thomas Erl (2006), Web services que assume o papel de fornecedor de serviços deve expressar as seguintes condições:

42 ARQUITETURA ORIENTADA A SERVIÇOS 42 O Web services deve ser invocado por um código externo, tal como um consumidor de serviço; O Web services deve publicar a descrição do serviço, oferecendo informações referentes às suas características e comportamentos. Um serviço que possui o papel de fornecedor atua basicamente desempenhando a função de um servidor, quando comparado a tradicional arquitetura, conhecido como cliente-servidor. O fornecedor de serviço tem seu processo de invocação baseado na troca de mensagens, onde o mesmo irá atuar recebendo e, a depender do tipo de mensagem, outra mensagem será retornada contendo a resposta solicitada, como pode ser observado na figura 2, logo abaixo. Figura 2 - Modelo de troca de mensagens exercida por um fornecedor se serviços. Fonte: Thomas Erl Consumidor de serviços O papel assumido por um serviço consumidor é de uma unidade lógica de processamento, que possui a capacidade de emitir mensagens de requisição. Ainda segundo o autor, Web services que desempenha o papel de um consumidor de serviço, apresenta as seguintes características (ERL, 2006):

43 ARQUITETURA ORIENTADA A SERVIÇOS 43 Invocar um fornecedor de serviços através do envio de mensagens. Capacidade de realizar consulta e pesquisa de fornecedores de serviços, e avaliar qual melhor se adéqua a suas necessidades. O fornecedor de serviços pode ser comparado a um servidor, o consumidor de serviços exerce o papel equivalente ao desempenhado pelo cliente, se comparado a uma arquitetura cliente-servidor. Logo, o consumidor de serviços atua consultando e requisitando o fornecedor de serviços, que fornece as funcionalidades desejadas, através do envio de mensagens. Como pode ser percebido na figura 3, logo abaixo: Figura 3 - Consumidor de serviços requisitando um Fornecedor de serviços Fonte: Thomas Erl Serviços de intermediação Tradicionalmente os Web services estabelecem uma comunicação do tipo ponto-aponto. De acordo com Thomas Erl (2006), esse tipo de comunicação torna os serviços menos flexíveis e menos escaláveis.

44 ARQUITETURA ORIENTADA A SERVIÇOS 44 Isso acontece devido ao fato que uma vez que o fornecedor de serviço submete uma mensagem, por exemplo, ela pode ser processada por múltiplos caminhos, ou até mesmo perdida, antes mesmo de chegar ao seu destino final. Visualizando essa necessidade, os desenvolvedores criaram o que é chamado de serviços de intermediação, que são serviços que normalmente estão localizados entre o consumidor e o fornecedor de serviços, recebendo e submetendo mensagens, e tipicamente são responsáveis por rotear as mensagens até que elas possam atingir seu destino final. Como pode ser visualizado na figura 4. Figura 4 - Funcionamento de um serviço de intermediação. Fonte: Thomas Erl PADRÕES FUNDAMENTAIS DE WEB SERVICES Tradicionalmente, um conjunto de padrões pode ser adotado durante o desenvolvimento de Web services. De acordo com Josuttis (2008, p ), esses padrões estão divididos em dois grupos.

45 ARQUITETURA ORIENTADA A SERVIÇOS 45 O primeiro grupo é composto por Extensible Markup Language (XML) e Hypertext Transfer Protocol (HTTP), que são dois padrões bastante utilizados pela Web, e foram incorporados ao processo de implementação de Web services. XML: pode ser vista tanto como uma linguagem de marcação de dados extensível utilizada para descrever outras linguagens. Como também pode ser definida como uma linguagem universal que permite a troca de informações de forma estruturada através da internet, independente de linguagem de programação e ambiente operacional. Essas características permitem que o mesmo possa estruturar e descrever modelos de documentos e tipos de dados, que serão utilizados durante a troca de informações (ou mensagens) entre serviços. HTTP: é um protocolo de baixo nível usado pela Internet, principalmente para a comunicação de sites da Web e que pode ser utilizado para enviar e trocar mensagens pertencentes à Web services. O segundo grupo é constituído por três padrões: Web Services Definition Language (WSDL), Simple Object Access Protocol (SOAP) e Universal Description, Discovery e Integration (UDDI). No entanto esse segundo grupo de padrões, apresenta uma diferença significativa em relação ao primeiro, esses padrões foram os primeiros a serem desenvolvidos especificamente para auxiliar o processo de implementação de Web Services. WSDL: É a linguagem mais comum para descrever serviços. Sua função é justamente definir a interface e o binding de cada serviço desenvolvido. Interface: é responsável por expor a lista de operações dentro de cada serviço, e o contrato definido para cada operação. Por outro lado, o contrato nada mais é do à especificação de parâmetros de entrada e saída de cada operação executada pelo serviço;

46 ARQUITETURA ORIENTADA A SERVIÇOS 46 Binding: atua especificando detalhes técnicos pertencentes ao serviço, como por exemplo, localização e protocolo que devem ser utilizados para que o serviço possa ser acessado. SOAP: Os serviços têm o processo de comunicação totalmente baseada em mensagens, A especificação do SOAP foi desenvolvido para reunir todos os requisitos necessários para transportar mensagens processadas pelo Web services. Contudo, o SOAP tem sido freqüentemente revisado para acomodar estruturas de mensagens sofisticadas, fazendo com o que esse protocolo se torne o formato padrão e específico para a troca de dados através de Web Services. UDDI: É um padrão para gerenciamento de Web services, onde são utilizadas estruturas capazes de registrar e localizar serviços. Dessa forma os serviços registrados podem ser pesquisados e acessados facilmente de forma manual ou até mesmo programaticamente, através de componentes de software. Ainda segundo o autor: Usar o padrão WSDL é normalmente a característica chave de Web Services. Todo o resto é operacional. Por exemplo, o desenvolvedor não tem que usar SOAP ou HTTTPS para enviar as requisições de serviços, poderá usar outros protocolos e ainda estar usando Web services. Alem disso, UDDI desempenha apenas um papel auxiliar, que não é exigido e freqüentemente não é usado na prática. Como pode ser observado, o desenvolvimento de Web services possui uma série de padrões que podem ser adotados durante o processo de implementação. No entanto, o único padrão que é adotado fortemente pelos desenvolvedores é o WSDL. Claro, todo desenvolvedor que pretende construir Web services, deve utilizar um tipo de protocolo, para especificação e troca de mensagens, no entanto não se tem o protocolo único. Logo, é válido ressaltar que os padrões que serão adotados durante o processo de implementação de Web services, devem ser escolhidos de acordo com as necessidades organizacionais, ou seja, o conjunto de padrões adotados deverão se adequar as necessidades expostas pela organização.

47 ARQUITETURA ORIENTADA A SERVIÇOS Enterprise Service Bus (ESB) É outra tecnologia que faz parte da infra-estrutura de SOA, e atua permitindo que serviços possam interagir perfeitamente em um ambiente de sistemas produtivos (JOSUTTIS, 2008 p.43). ESB fornece um middleware que segue um conjunto de responsabilidades como, por exemplo, roteamento inteligente de mensagens, transformação de dados, integração de tecnologias, conectividade entre outros. Que atuarão conjuntamente para proporcionar uma perfeita interação entre os serviços que são utilizados em ambientes produtivos organizacionais. Abaixo se pode visualizar a figura 5, que demonstra vários Web services conectados a um ESB. Figura 5 - Enterprise Service Bus. Fonte: A seguir será apresentada uma melhor descrição sobre as responsabilidades atreladas a ESB. Prover conectividade: Um ESB não só possui a capacidade de adicionar flexibilidade a comunicação entre serviços, como também, simplifica a integração entre os mesmos. Dessa forma, é possível prover conectividade entre Web Services que utilizaram tecnologias diferentes durante seu processo de implementação, de uma forma simples e fácil (JURIC; LOGANATHAN & SARANG, 2007 p.45).

48 ARQUITETURA ORIENTADA A SERVIÇOS 48 Logo, pode-se notar que uma das responsabilidades atribuídas a ESB, é justamente garantir a conectividade e possibilitar a comunicação entre serviços, independentemente das tecnologias que tenham sido utilizadas para desenvolvê-los. Transformação de dados: Uma das capacidades expostas por um ESB é justamente a possibilidade de transformar o formato das mensagens antes que elas sejam entregues ao serviço, para o formato XML (JURIC; LOGANATHAN & SARANG, 2007 p.45). Contudo, essa abordagem é mais uma associada à interoperabilidade de um ESB, pois ao transformar as mensagens para o formato XML, a mesma pode ser compreendida por qualquer serviço, independentemente da tecnologia utilizada para sua implementação. Roteamento Inteligente: De acordo com Josuttis (2008, p.44), outra tarefa fundamental de ESB é o roteamento. Tem que existir uma maneira para enviar uma chamada de serviço consumidor ao fornecedor, e depois enviar uma resposta do fornecedor ao consumidor. Dependendo da tecnologia utilizada e o nível de inteligência oferecida, esta tarefa pode ser trivial ou pode requerer processamento muito complicado. Um ESB normalmente fornece a capacidade de roteamento, possibilitando que mensagens sejam roteadas para diferentes serviços, utilizando como base o conteúdo, a origem ou outros atributos pertencentes a cada mensagem (JURIC; LOGANATHAN & SARANG, 2007 p.45). Nota-se, que o roteamento de mensagens é uma tarefa que a depender da maneira que ocorre o processo de execução, pode influenciar na forma como as mensagens são processadas tanto pelo fornecedor como para o consumidor de serviço. Logo, um ESB atua fornecendo estratégias que assegurem a troca de mensagens entre serviços de forma padronizada, e com baixos custos de processamento.

49 ARQUITETURA ORIENTADA A SERVIÇOS 49 Segurança: Para Jossutis (2008, p. 51) Na maioria dos ambientes SOA, mais cedo ou mais tarde, a segurança se tornará um problema, porque nem todos os consumidores têm permissão para ver e manipular informações disponibilizadas por fornecedores de serviços. Logo, um ESB deve prover uma forma de lidar com os diferentes aspectos de segurança. Um ESB deve oferecer suporte à segurança durante o acesso de serviços, incluindo aspectos como: autenticação, autorização, confiabilidade, entre outros (ROSEN; LUBLINSKY & SMITH, 2008 p.347). Pode-se perceber que assim como em todo ambiente de software, a segurança é um fator de grande importância e deve ser levado em consideração durante o desenvolvimento de uma arquitetura orientada a serviços, e um ESB por sua vez, deve oferecer mecanismo capazes de implementar aspectos como: autenticação, autorização, confiabilidade, entre outros que compõe um ambiente de software seguro. Confiabilidade: Anteriormente na seção pôde-se acompanhar que a comunicação entre Web Services é baseada na utilização de protocolos, com o objetivo de estabelecer padrões, que deverão ser adotados durante a troca de mensagens. No entanto baseado em Josuttis (2008, p ): Nem sempre se têm a total certeza que o protocolo realmente será capaz de entregar a mensagem ao destinatário. Na verdade, o protocolo HTTP de Web Services inerentemente não garante a entrega. Alguns outros protocolos como o SOAP podem, por exemplo, garantir que a mensagem será entregue ao menos uma vez ao seu destino final. Contudo, devido a esse fato um ESB deve estabelecer estratégias que deverão ser utilizadas justamente para tratar questões de confiabilidade. Logo, é responsabilidade de um ESB definir mecanismos capazes de prevenir e evitar falhas e erros técnicos.

50 ARQUITETURA ORIENTADA A SERVIÇOS 50 Monitoramento e loggin: O ESB se tornou o coração dos processos de negócio em execução, e a maneira como implementa, depura e mantém os processos locais, agora é distribuída através de múltiplos sistemas (JOSUTTIS, 2008, p.52). Logo, temos o ESB como o núcleo (coração) que permite a conectividade entre Web Services (processos de negócio em execução) que estão distribuídos através de múltiplos sistemas espalhados pela rede de computadores organizacional. Ainda segundo o autor, é de fundamental importância que o monitoramento e loggin indiquem qual é o cliente que está chamando o serviço, e quanto tempo leva uma chamada de serviço especificamente. Contudo, à medida que as organizações desenvolvem e disponibilizam serviços através de sistemas que estão distribuídos pela rede, torna-se necessário o monitoramento e controle de acesso de serviço que está sendo utilizado por um cliente, até mesmo para aprimoramento de requisitos técnicos, como por exemplo, tempo de acesso ou controle de mensagens perdidas durante troca de mensagens e etc. Dessa forma, um ESB tem como uma de suas responsabilidades justamente disponibilizar mecanismos e estratégias que possibilitem o monitoramento e loggin de serviços Business Process Management (BPM) Qualquer negócio existe para fornecer algum tipo de valor. Normalmente quem mais se beneficia com esse tipo de valor, são: clientes, parceiros, acionistas e empregados. Um negócio realiza uma seqüência de tarefas, com o objetivo de produzir um valor especifico. Essa coleção de tarefas seqüenciais juntamente com os papéis e responsabilidades somadas a essas tarefas, são coletivamente chamadas de processos de negócio (GABHART & BHATTACHARYA, 2008 p.29). Como pode ser percebido, todo negócio tem como principal função prover algum tipo de valor. Quando se trata de processos de negócio, torna-se necessário a realização

51 ARQUITETURA ORIENTADA A SERVIÇOS 51 de uma seqüência de tarefas. Claro, essas tarefas podem ser realizadas por pessoas, máquinas ou software. No entanto, é de fundamental importância que papéis e responsabilidades estejam bem definidos ao redor de cada tarefa que será executada. Dessa forma, a utilização de Business Process Management (BPM) (ou Gerenciamento de Processos de Negócio) permite que um analista de negócios alinhe Tecnologia da Informação (TI) aos objetivos estratégicos organizacionais, com a finalidade de criar processos de negócio empresarias bem definidos. Através do BPM é possível exercer monitoramento e controle sobre os processos de negócio que estão atuando dentro da empresa, com isso, pode-se obter melhor desempenho e eficiência operacional (ROSEN; LUBLINSKY & SMITH, 2008 p.137). Logo, pode-se notar a que função exercida por BPM, é justamente permitir a união entre TI e os objetivos estratégicos planejados pelas organizações, onde a finalidade principal dessa união é proporcionar meios pelo qual se possa definir, estabelecer, monitorar e controlar processos de negócio. Assim, as organizações cada vez mais terão a possibilidade de aperfeiçoar os processos de negócio, e com isso, utilizá-los para aumentar a produtividade operacional. Quando aliado a BPM, SOA é responsável por fornecer uma plataforma de capacidades que atua como uma ponte entre os processos de negócio e os recursos operacionais. Em nível de processos de negócio, SOA fornece interfaces capazes de oferecer suporte a execução de tarefas do processo. No nível de recursos operacionais, SOA expõe capacidades que possibilitam a integração de serviços. Juntos, BPM e SOA fornecem uma combinação de mecanismo que beneficiam a computação empresarial. BPM fornece um alto nível de abstração para definir processos de negócio, assim como, estratégias para monitoramento e gerenciamento desses processos. Serviços fornecem as funções que suportam esses processos. SOA fornece as capacidades para que os serviços possam ser combinados, e assim consigam oferecer suporte tecnológico para o desenvolvimento ou aperfeiçoamento de fatores como: agilidade e flexibilidade empresarial (ROSEN; LUBLINSKY & SMITH, 2008 p.137).

52 ARQUITETURA ORIENTADA A SERVIÇOS 52 Torna-se visível que BPM fornece a estrutura necessária para definição, estabelecimento, monitoramento, controle e otimização de processos de negócio. Através dessas capacidades fornecidas por BPM, projetistas podem ter uma especificação técnica relacionada às funções desejadas por cada processo de negócio e, com isso, desenvolver serviços que se adéquam perfeitamente as necessidades e desejos da organização. Por outro lado, SOA deve ser capaz de oferecer mecanismos e estratégias para que esses serviços possam promover agilidade e flexibilidade empresarial. Fatores que fazem grande diferença em um mercado competitivo. Alternativamente, BPM também pode significar Modelagem de Processos de Negócio. No entanto, de acordo com as definições que serão apresentadas a seguir pode-se perceber que na realidade Modelagem de Processos de Negócio, deve ser vista como parte do Gerenciamento de Processos de Negócio. A Modelagem de Processos de Negócio é o conjunto de práticas ou tarefas que as empresas podem executar para descrever visualmente todos os aspectos de um processo de negócio incluindo o seu curso, controle e pontos de decisão, gatilhos e condições para execução das atividades, o contexto em que uma atividade executa e os recursos associados (BLOOMBERG & SCHMELZER, apud JOSUTTIS, 2008 p.73). Modelagem de Processos de Negócio é uma técnica para formalizar os passos de um processo de negócio, as pessoas, organizações, ou sistemas responsáveis por aqueles passos, e os dados associados com aquele passo (ROSEN; LUBLINSKY & SMITH, 2008 p.137).. Logo, essa modelagem pode ser entendida como uma forma de descrever visualmente todas as etapas e recursos relacionados a um determinado processo de negócio, como por exemplo, pessoas, sistemas ou o conjunto de atividades envolvidas. Essa capacidade permite que cada processo de negócio seja modelado, como um conjunto de tarefas que serão processadas independentemente. Onde

53 ARQUITETURA ORIENTADA A SERVIÇOS 53 essas tarefas serão tipicamente implementadas como serviços de software que atuarão dentro da organização Modelo de Processos de Negócios Baseado nos autores Rosen, Lublinsky, Smith e Balcer (2008, p.137), BPM fornece um conjunto de mecanismos capazes de unir Modelagem de Processos de Negócio a padrões que auxiliaram na criação, automatização e execução de um modelo de processos de negócio, com o propósito de descrever o conjunto de passos que deverão ser tomados para realização de atividades como, por exemplo, utilizar ou invocar algum serviço de software. Além de representar graficamente os processos de negócio, o modelo também possibilita a especificação formal de cada processo (ROSEN; LUBLINSKY & SMITH, 2008 p.140). A seguir será apresentada a seqüência de passos, juntamente com a utilização e descrição dos padrões que proporcionam a criação, automação e execução de um modelo de processos de negócio. Inicialmente os processos de negócio são descritos através de uma linguagem formal de modelagem, tal como Business Process Modeling Notation (BPMN). De acordo com Josuttis (2008, p.83), BPMN é uma linguagem de notação utilizada por analistas para reapresentar visualmente processos de negócio. Logo, normalmente a notação BPMN é utilizada por analistas de negócios, para explicar a clientes e fornecedores o fluxo de tarefas que compõe o processo. Devido ao fato, que esse tipo de notação pode ser compreendido até mesmo por pessoas que não estão familiarizadas, com especificações técnicas utilizadas pela área de desenvolvimento software. Abaixo na figura 6 é exibido um processo de negócio, que foi modelado utilizando BPMN, apenas para que o leitor possa ter idéia da utilização dessa linguagem de notação.

54 ARQUITETURA ORIENTADA A SERVIÇOS 54 Figura 6 - Exemplo de utilização de BPMN. Fonte: Normalmente, um modelo BPMN deve ser compilado por uma linguagem de execução, tal como Business Process Execution Language (BPEL). BPEL é um padrão de linguagem de execução que é suportada tanto por um BPM como por SOA, e atua como uma tecnologia complementar capaz de adicionar execução semântica para o modelo de processos de negócio. O objetivo principal do BPEL é descrever um processo de negócio que interaja com Web Services (serviços implementados), internos ou externos. Isso significa definir e criar uma série de regras de fluxogramas, seqüências, paralelismos, condicionais, loops, variáveis e estrutura de controle do processo, etc. Uma das capacidades oferecidas por BPEL é criar o modelo de fluxograma e também de executá-lo, isso é, ler as regras definidas, executar as regras de negócio e invocar os Web Services. (ROSEN; LUBLINSKY & SMITH, 2008 p.140). Abaixo na figura 7 pode ser acompanhado um modelo BPEL, que descreve os passos necessários para cumprimento do processo de invocação de Web Services.

55 ARQUITETURA ORIENTADA A SERVIÇOS 55 Figura 7 - Exemplo da utilização de um modelo BPEL. Fonte: Como pode ser visto diferentemente do BPMN, os modelos BPEL normalmente são utilizados por projetistas e arquitetos para descrever detalhes técnicos (como por exemplo, a especificação do processo de invocação ou utilização de Web services), referentes ao processo de negócio, proporcionando uma maior facilidade de comunicação entre os membros da equipe de desenvolvimento, projetistas e arquitetos de software. Contudo, percebe-se que padrões como BPMN e BPEL, podem auxiliar tanto na criação como na execução de modelos de processos de negócio. Logo, isso é um dos fatores pelo qual BPM é indicado para está presente na infraestrutura necessária para implementação de SOA, pois o desenvolvimento de modelos de processos bem definidos, possibilita que serviços de software possam ser implementados de forma padronizada e com qualidade.

56 CAPÍTULO III METODOLOGIAS PARA DESENVOLVIMENTO DE SOA

57 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA METODOLOGIAS PARA DESENVOLVIMENTO DE SOA Como pôde ser visto no capítulo anterior, o desenvolvimento de SOA engloba uma série de tecnologias e padrões. No entanto, de acordo com Kunal Mittal (2005, p.1), para que um projeto SOA possa ser desenvolvido com sucesso, torna-se necessário a utilização de uma metodologia adequada. Ainda segundo o autor uma metodologia de software, é uma abordagem sistemática que tem por finalidade, fornecer uma estrutura capaz de controlar o desenvolvimento do software. Por outro lado, uma metodologia que se adéqüe as características e princípios que deverão ser adotados durante o desenvolvimento de um projeto SOA, deve ser capaz de fornecer técnicas e estratégias que possibilitem a análise, o projeto e a realização tanto de serviços como dos componentes de software que serão implementados. Levando-se em consideração que a utilização de uma metodologia de software realmente possui um grande impacto no desenvolvimento de SOA. A maior preocupação exposta pelas empresas que desejam adotar uma Arquitetura Orientada a Serviços é justamente, encontrar uma metodologia que realmente permita desenvolver SOA com eficácia e eficiência, O uso de metodologias tradicionais como, por exemplo, Rational Unified Process (RUP) ou Extreme Programming (XP), não é aconselhável para desenvolvimento de um projeto SOA (CALLAHAN, 2007 p.11). Ainda segundo o autor, nenhuma das duas metodologias (RUP ou XP) se demonstrou adequada para o desenvolvimento eficiente e eficaz de um projeto SOA. No qual se pôde perceber a ausência de estratégias e fases voltadas para a especificação de composições e dependências, durante a análise, identificação, projeto e realização de serviços.

58 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 58 É válido ressaltar, que em um projeto de desenvolvimento SOA, a análise e a identificação de serviços, assim como suas composições e os processos que eles formam, são fases cruciais para alcançar um bom plano arquitetural. Uma série de metodologias tem surgido, visando guiar processos e fornecer melhores práticas para o desenvolvimento de projetos SOA, entre elas estão: IBM Service-Oriented Analysis and Design (SOAD), IBM Service Oriented Modeling and Architecture (SOMA), SOA Repeatable Quality (RQ), CBDI-SAE Process, Service Oriented Architecture Framework (SOAF), Service Oriented Unified Process (SOUP), Methodology by Papazoglou, Mainstream SOA Methodology (MSOAM) e Steve Jones Service Architectures. Porém, muitas das metodologias citadas acima foram desenvolvidas e são mantidas por empresas privadas, esse fato acaba impossibilitando que o público tenha acesso a documentação que descreve estratégias, processos, fases, entre outros fatores que permitem a utilização dessas metodologias para desenvolvimento de SOA com qualidade. Esse capítulo tem por objetivo descrever detalhadamente as fases, os processos, as estratégias entre outras características presentes nas seguintes metodologias que possibilitam o desenvolvimento de SOA: IBM Service Oriented Modeling and Architecture (SOMA), Service Oriented Unified Process (SOUP) e Mainstream SOA Methodology (MSOAM). 3.1 SERVICE ORIENTED MODELING AND ARCHITECTURE (SOMA) Essa seção (3.1) é responsável por descrever os processos e as estratégias que compõem a metodologia SOMA. Para isso, serão utilizadas informações que foram baseadas nos seguintes autores: Bieberstein, Laird e Jones (2008). Service Oriented Modeling and Architecture (SOMA) é uma metodologia desenvolvida pela, que possui a capacidade de transformar requisitos de negócio em soluções de TI baseado em serviços.

59 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 59 Logo, essa transformação pode ser vista como um processo em execução, onde se têm como entradas: modelos de negócio e um conjunto de informações, após o processamento, obtêm-se como output (saída) soluções de TI orientadas a serviços. Para execução do processo descrito logo acima SOMA conta com uma estrutura organizacional bem definida e subdivida em três fases: Identificação: onde várias técnicas são usadas para identificar uma lista de candidatos a serviços; Especificação: responsável por apresentar um projeto totalmente detalhado tanto dos serviços, como dos componentes que serão desenvolvidos; Realização: Além de ser a fase onde são tomadas as decisões arquiteturais, também é a fase onde deve ser justificado quais serão as abordagens utilizadas durante a implementação de serviços. Durante a execução dessas fases, SOMA recomenda: análise, modelagem e projeto de atividades que definem os fundamentos empregados por SOA. É válido ressaltar, que quando se trata de soluções de TI orientadas a serviços, o principal resultado obtido dessa solução é um modelo de serviços empresariais. Dessa forma, recomenda-se que um modelo de serviços resultante da solução implementada, apresente os seguintes artefatos: Portfólio de serviços Lista de todos os serviços empresariais. Hierarquia de serviços Oferece uma categorização de serviços dentro dos grupos de serviços empresariais. Exposição de serviços Uma análise e racionalização, de quais serviços devem ser expostos e quais não devem ser.

60 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 60 Dependências do serviço Representa as dependências de um determinado serviço com outros serviços. Composição de serviços Fornece uma especificação detalhada do papel que será desempenhado por cada serviço que compõe a composição.. NFRs do serviço - Especificação dos requisitos não funcionais que um serviço deve obedecer. Gerenciamento de estado - Responsável por gerenciar os vários tipos de estado, que um serviço deve manter e implementar. Realization decisions - Representa decisões arquiteturais para cada serviço, assim como a justificativa dos mecanismos que serão utilizados durante o processo de implementação. Pode-se perceber que o método de execução de SOMA mantém uma estrutura com fases bem definidas, que possuem como respectivas finalidades: identificar, especificar e realizar modelos de serviços, que por sua vez, devem ser compostos por um conjunto de artefatos, utilizados justamente para oferecer a oportunidade que as organizações necessitam, para converter requisitos de negócios em soluções empresariais orientadas a serviços Validação de inputs Antes que os inputs 1 sejam validados, torna-se necessário que eles sejam inicialmente identificados. As seguintes abordagens apresentadas logo abaixo, podem ser utilizadas para realizar a identificação de: 1 Entrada de informações que serão utilizadas durante a fase de identificação de serviços (BIEBERSTEIN; LAIRD & JONES, 2008).

61 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 61 Sistemas e aplicações existentes: as funcionalidades que eles fornecem, a importância e o uso das funcionalidades fornecidas, e o roteiro que deve ser seguido para que cada um dos sistemas sejam aperfeiçoados, são todos inputs chaves que ajudam a compreender a situação que se encontra o atual ambiente de software. Situação organizacional: O atual projeto organizacional e as futuras estruturas, tanto de escopo como de requisitos, também podem se revelar inputs preciosos. Esses fatores podem ser usados para identificar qual linha de negócio irá ser responsável por definir propriedades que serão utilizadas, tanto para definir como para financiar o conjunto de serviços que pretendem ser desenvolvidos pela organização. A próxima etapa é a validação de inputs. Para realização de tal atividade, o método SOMA recomenda a adoção de um workshop, que na realidade nada mais é do que uma reunião entre consultores de TI, clientes e stakeholders (partes interessadas) envolvidos no desenvolvimento do projeto SOA. Onde, a principal finalidade dessa reunião é oferecer oportunidade para que os consultores possam apresentar os inputs identificados. Por outro lado, os clientes poderão sugerir que novos requisitos sejam incorporados. Após a realização do workshop a equipe de consultores de TI poderá apresentar uma lista contendo todos os inputs devidamente validados e prontos para serem utilizados pela metodologia SOMA. No entanto, pode acontecer de algum input não está devidamente de acordo, ou talvez não forneça o conjunto de informações necessárias. Nesse caso, a primeira providência que deve ser tomada é avaliar quais são as divergências existentes entre o que foi requisitado, e quais as informações que se tem disponível no momento. Em seguida, deve-se planejar e discutir o que pode ser feito para eliminar tais divergências encontradas.

62 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 62 Caso as divergências ainda prevaleçam, a metodologia SOMA sugere que novas sessões e reuniões sejam realizadas, a fim de identificar novas informações que possam ser utilizadas para complementar e validar os inputs. Como se pode perceber, a etapa de validação de inputs possibilita que os consultores de TI não apenas mantenham o primeiro contanto com a organização que planeja desenvolver soluções orientadas a serviços, como também permite a identificação e validação de inputs, que na realidade são modelos de processo de negócios ou um conjunto de informações que caracterizam o ambiente de software organizacional. Logo, para realização de tais feitos, os analistas podem utilizar visitas técnicas, a fim de conhecer sistemas e aplicações que atualmente estão em execução dentro do pátio de software empresarial, ou até mesmo utilizar tais visitas para obter informações relacionadas ao escopo e aos requisitos de negócio desejáveis pela organização. Outro fator que deve ser destacado durante essa etapa, é justamente a realização de reuniões entre analistas e clientes, onde não apenas serve para definir e validar o conjunto de inputs anteriormente identificados, como pode ser utilizada para que os clientes possam sugerir requisitos que são de seu interesse. A seguir será apresentada e descrita detalhadamente cada fase que compõe SOMA, assim como os processos e estratégias pertencentes a cada uma delas Identificação Após a finalização da validação de inputs, o foco agora se volta para a identificação de serviços, que tem como uma de suas finalidades constituírem o portfolio de serviços. O objetivo dessa fase é obter uma lista exaustiva de serviços que serão potenciais candidatos para a exposição e, em seguida, promover a categorização dos serviços baseado em algum agrupamento lógico.

63 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 63 Para se chegar a tal lista exaustiva de candidatos a serviços, a metodologia SOMA propõe que sejam combinadas três técnicas complementares: decomposição de domínios, existing asset analysis, e goal service modeling. Depois que a lista de serviços é obtida, a mesma deve ser compilada. Pois, logo após o processo de compilação, normalmente se utiliza uma técnica que realiza a extração de serviços presentes na lista, onde somente aqueles serviços que realmente são relevantes serão expostos. A figura 8 ilustra as três técnicas pertencentes ao processo de identificação de serviços. Figura 8 - Técnicas envolvidas na identificação de serviços. Fonte: Norbert Bieberstein Adiante serão apresentadas e descritas as três técnicas propostas por SOMA para identificar e montar a exaustiva lista de candidatos a serviços Decomposição de domínios Essa é uma técnica top-down 2 que promove a decomposição do domínio de negócios empresariais tanto em áreas funcionais como em subsistemas. Dessa forma, realiza-se a decomposição de processos de negócio, em casos de uso de 2 Top-down abordagem que utiliza a lógica de negócios existente dentro das organizações empresariais, como processo inicial para identificação de serviços (TERLOUW, TERLOUW e JANSEN).

64 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 64 alto nível. Esses casos de uso freqüentemente permitem que processos de negócio sejam expostos como candidatos a serviços. Aparte da identificação de candidatos a serviços, essa técnica ajuda a identificar áreas funcionais que deverão ser analisadas, com o objetivo de delimitar as funcionalidades presentes em cada subsistema desenvolvido pela organização. O primeiro passo proposto por essa técnica é conhecido por Funcional Area Analysis (FAA). A FAA permite a decomposição do domínio de negócios empresariais em unidades lógicas, onde cada unidade é entendida como uma área funcional. Logo, a execução desse passo proporciona a obtenção de um conjunto de áreas funcionais, que além de fornecer uma visão modular dos negócios empresariais, também auxilia na identificação, planejamento e projeto de subsistemas. Outro fator que deve ser levado em consideração pela identificação de áreas funcionais, é justamente a capacidade de categorizar serviços. Onde os candidatos a serviços podem ser agrupados, de acordo com a lógica pertencente a cada área funcional identificada. A hierarquia de serviços apresentado na seção 3.1 é uma formalização da categorização de serviços. O próximo passo dentro dessa técnica é chamado de Decomposição de processos. Nesse passo, o objetivo é decompor processos de negócios, em subprocessos, tarefas e atividades. O resultado dessa decomposição será um modelo de processo, que descreve o fluxo de eventos necessários para execução de um determinado processo de negócios. Um processo representa um agrupamento lógico responsável por relatar atividades e recursos utilizados para que as organizações possam não apenas cumprir seus objetivos, como também, obter resultados satisfatórios. Logo, um modelo de processo deve descrever os esforços necessários, trabalhos que devem ser realizados e até mesmo os sistemas que devem ser utilizados para

65 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 65 que se possa obter, sucesso durante a execução dos objetivos propostos pela organização. Para obtenção e execução de tal modelo de processo, cada processo de negócios seja ele pertencente ao escopo dos negócios ou ao de TI, deve inicialmente ser decomposto em subprocessos, em seguida, cada subprocesso pode ser quebrado em atividades, que por sua vez, pode ser composta por um conjunto de tarefas. Contudo cada subprocesso, atividade ou tarefa resultante dos modelos de processos, deve ser considerado um candidato a serviço. Conseqüentemente, cada um deles é adicionado à lista chamada de portfólio de serviços. Com isso, nesse ponto o portfólio de serviços consiste de todos os subprocessos, atividades e tarefas definidas para cada modelo de processo. A decomposição de processos em atividades e tarefas também pode auxiliar na identificação de semelhanças e variações entre múltiplos processos de negócio. As semelhanças entre atividades e subprocessos são utilizadas para fornecer bons candidatos a serviços, enquanto que os pontos de variação permitem que sistemas sejam planejados e projetados com alto teor de resiliência. Essa característica permite que os sistemas desenvolvidos possam se adaptar incorporar facilmente futuras modificações. As variações de um sistema normalmente são identificadas através de três aspectos: estruturas, processos e regras. Tipicamente, esses pontos de variação não apenas permitem uma injeção configurável de flexibilidade no projeto de sistemas, como também, podem ser utilizadas para sugerir novos serviços baseado em tipos, processos e regras.

66 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA Existing asset analysis Existing asset analysis é uma abordagem bottom-up 3 que examina os seguintes assets 4 : aplicações personalizadas, pacotes de software e modelos de sistema, tendo como finalidade determinar quais assets poderão ser reaproveitados como funcionalidades dos serviços que serão realizados. Essa análise normalmente também é projetada para descobrir algum serviço que tenha sido perdido ou esquecido durante o processo de decomposição. Enquanto a análise do sistema legado e das aplicações de software existentes está sendo executada, recomenda-se que seja realizado um mapeamento conhecido por coarse-grained, que tem por objetivo identificar se alguma das funcionalidades encontradas durante o processo de análise, realmente pode ser utilizada para realizar algum requisito ou processo de negócio desejado pela organização Durante o coarse-grained, recomenda-se que seja desenvolvida uma análise detalhada da qualidade e do estado que se encontram as aplicações, que serão utilizadas para realizar algum serviço. Pois através de tal analise, torna-se possível avaliar os riscos técnicos associados a cada serviço que será realizado através de funcionalidades pertencentes a um sistema que já atua dentro da organização. Para as aplicações que apresentam qualquer risco técnico capaz de comprometer a implementação dos serviços, propõe-se que sejam utilizadas algumas técnicas de prototipação, com o objetivo de realizar testes em fatores básicos, como: conectividade, questões relacionadas a protocolos, estrutura e formato de dados e assim por diante. Essa prototipação permitirá que riscos possam ser precocemente evitados, caso contrário os mesmos poderiam afetar seriamente os próximos estágios, como por exemplo, durante o estágio de implementação. 3 Bottom-up, abordagem que utiliza sistemas e software legado que estão sendo utilizados pela organização, como principal fonte para a identificação de serviços (TERLOUW, TERLOUW e JANSEN). 4 Ativo de software utilizado dentro de uma organização (BIEBERSTEIN; LAIRD & JONES, 2008)

67 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 67 Contudo, pode-se notar que essa técnica conhecida por existing asset analysis, não apenas possibilita que sejam desenvolvidas análises e avaliações do atual legado de software pertencente a organização, afim de determinar o que poderá ser reaproveitado durante a realização de serviços. Como também, permite que novos serviços possam ser identificados, a partir do conhecimento de funcionalidades já desempenhadas por sistemas existentes dentro da empresa. Seguindo a metodologia, após a identificação dos novos serviços, os mesmos devem ser adicionados ao portfolio de serviços. Agora o portfolio de serviços mantém os serviços identificados tanto na abordagem top-down, como na bottomup Goal Service Modeling É a terceira das três técnicas pertencentes à identificação de serviços, e normalmente é utilizada para validar ou descobrir outros serviços que ainda não foram capturados pelas abordagens top-down (Decomposição de domínio) ou bottom-up (Existing asset analysis). Goal Service Modeling (GSM) é responsável por fornecer o equilíbrio exato entre objetivos do negócio e TI, através desse equilíbrio torna-se possível associar a identificação de serviços diretamente com os objetivos de negócio desejados pela organização. Apesar de todos os serviços estarem fortemente interligados aos objetivos de negócio pretendidos pela organização, normalmente alguns objetivos pertencem a um domínio de problemas que apresenta maior importância para organização. Dessa forma, serviços que representaram tais objetivos, provavelmente terão maiores chances de serem projetados e implementados mais rapidamente. Nesse ponto, GSM pode ser utilizado como mecanismo de delimitação, onde o mesmo pode auxiliar na definição do escopo do projeto, permitindo que o foco seja mantido ativamente no domínio de problemas mais importantes para a empresa.

68 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 68 No entanto, o domínio dos problemas freqüentemente apresenta altos níveis de complexidade, impossibilitando que o mesmo seja abordado apenas em uma única interação. Com isso, recomenda-se que seja identificada uma área que forneça altíssimo impacto (possibilidade de realização de um ou mais objetivos de negócio) para o negócio. Após a identificação de tal área, propõe-se que o escopo da mesma seja delimitado. Uma vez que o escopo se apresenta bem definido ao redor dos objetivos do negócio, a técnica GSM pode ser utilizada para identificar serviços. Os objetivos do negócio apresentam um nível muito alto de realização, normalmente esses objetivos de negócio são difíceis e quase sempre são impossíveis de serem identificados e associados a um serviço. Dessa forma, a abordagem recomendada é decompor os objetivos em sub-objetivos, e manter a decomposição até o ponto em que um subobjetivo seja acionável. Acionável aqui significa atingir um fator que possa ser identificado como uma função de TI, que por sua vez, deve ser capaz de realizar o sub-objetivo. Conseqüentemente, cada objetivo de negócio é decomposto em sub-objetivos, e em seguida, serviços são identificados para poder realizá-los. Por último, esses novos serviços identificados devem ser adicionados ao portfolio de serviços. Pode acontecer que alguns dos serviços já constarem no service portfolio. No entanto, essa também é uma das características pertencentes a GSM, validar os serviços identificados pelas abordagens anteriores. Com isso, se obtêm a conclusão da GSM, e conseqüentemente também é finalizada a identificação de serviços, pois essa é a última das três técnicas que deve ser abordada durante essa fase. Logo, presume-se que os seguintes resultados foram obtidos: Portfolio de serviços: contendo todos os candidatos a serviços. Hierarquia de serviços: contendo os serviços agrupados em categorias.

69 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 69 A seguir será dada continuidade a metodologia SOMA, onde será apresentada a próxima fase, conhecida por Especificação Especificação A especificação é a fase que ajuda a projetar detalhes relacionado tanto aos próprios serviços, como: aos componentes e processos pertencentes a um serviço. A especificação utiliza a combinação de três atividades de alto nível, para determinar: Quais serviços realmente serão expostos. Fornecer os detalhes de especificação para cada serviço exposto. Especificar os fluxos (processos) e componentes pertencentes a cada serviço. As três atividades utilizadas são conhecidas por: especificação de serviços, análise de subsistemas e especificação de componentes. Após o término dessa fase, os seguintes resultados são esperados: exposição de serviços, dependências do serviço, composição de serviços, NFRs do serviço, mensagens do serviço e gerenciamento do estado Especificação de serviços A especificação de serviços é responsável por definir: dependências, composições, decisões sobre exposição, mensagens, restrições de Qualidade de Serviço (QoS), e decisões relacionadas ao gerenciamento de cada serviço. A primeira tarefa que deve ser realizada por essa técnica é a conhecida por exposição de serviços, para isso, deve-se utilizar o portfolio de serviços produzido anteriormente. Como se pode perceber, o portfolio de serviços possui uma exaustiva lista de candidatos a serviços que foi obtida através das três técnicas utilizadas durante a fase de identificação de serviços. Logo, facilmente pode-se compreender que essa

70 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 70 lista poderá conter muito mais candidatos a serviços do que o necessário, dessa forma, nem todos eles serão expostos como serviços. Alguns dos candidatos a serviço podem ser entendidos, mais como processos ou subprocessos de negócio do que propriamente serviços individuais (por exemplo, algum dos elementos derivados do primeiro nível da decomposição de processos), enquanto que alguns outros podem ser considerados funções de TI (por exemplo, algumas funcionalidades de um determinado sistema). Pois se pressupõe que, quando uma organização decide expor todos os candidatos a serviço presentes na lista, alguns fatores econômicos e práticos devem ser fortemente levados em consideração. Além do mais, é importante ressaltar que o custo e o tempo necessário para o desenvolvimento de um projeto SOA, estará associado a todos os serviços que foram escolhidos para a exposição de serviços. Com isso, tanto o financiamento como outros fatores que estão associados ao ciclo de vida do serviço, como por exemplo: governança, gerenciamento, segurança, escalabilidade, desempenho, além de outros requisitos devem ser regrados a uma escala econômica, quando se trata da exposição de todos os candidatos a serviços. Baseado nessas premissas recomenda-se que seja realizado um teste de serviço. O teste consiste de critérios específicos que deverão ser aplicados a cada candidato a serviço. Somente os serviços que reunirem tais critérios serão escolhidos para o exposição de serviços. O teste fornece um método que possui o seguinte conjunto de critérios: Alinhamento de negócios O serviço deve está completamente alinhado ao negócio. Se um serviço não está bem alinhado, de uma forma ou de outra, então ele não conseguirá remontar o objetivo do negócio. Logo, ele pode não ser um candidato ideal para ser escolhido para exposição. Composição Testa a habilidade de um serviço ser usado em um contexto completamente diferente do qual o mesmo foi originalmente identificado. Um

71 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 71 serviço deve ser capaz de participar de múltiplos processos de negócio, sem comprometer requisitos não funcionais (segurança, desempenho e etc.) exigidos pelo fluxo de processos. Viabilidade de implementação Testa tecnicamente a viabilidade de implementar o serviço com custos e tempo efetivamente eficaz. Decisões técnicas tomadas de maneira incorreta, podem tornar os serviços excessivamente complexos, com isso o tempo e a qualidade de implementação poderá ser comprometida. Eliminação de redundâncias Testa se uma determinada função organizacional está sendo realizada, por mais de um serviço de software. Após a realização de tais testes, o resultado obtido é um portfolio de serviços filtrado e bem refinado, que agora contém apenas os serviços que realmente serão expostos. No entanto, cada serviço deve ser especificado detalhadamente. Para isso, deve-se ser realizado um conjunto de atividades, e a primeira entre elas é conhecida por dependências do serviço, que possui o objetivo de fornecer todas as dependências relacionadas a um determinado serviço. Normalmente serviços dependem de outros serviços para serem expostos. Essa dependência acontece tipicamente em situações quando requisitos QoS tais como: desempenho, disponibilidade entre outros tendem a impulsionar arquitetos SOA a projetar um serviço que seja compatível com uma ou mais tecnologias em especifico. Existem dois tipos de dependência entre serviço, a primeira conhecida como dependência de processamento, ocorre de serviço para serviço, onde um determinado serviço só poderá executar um determinado processo de negócio, se o serviço que o mesmo depende for executado anteriormente. E o segundo tipo, é chamado de dependência funcional, ocorre de serviço para componente de software, onde às vezes os serviços dependem de requisitos não

72 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 72 funcionais que estão acoplados a componentes. É validos ressaltar, que independentemente do tipo de dependência, todas devem ser levadas em consideração durante a implementação do serviço. Com as dependências do serviço retratada, a próxima atividade a ser abordada é conhecida por identificação de composições. Uma composição de serviços pode ser entendida como qualquer coleção de serviços relacionados, que possui a capacidade de resolver uma função de negocio especifica e de alto nível. Dessa forma, cada processo de negócio pode ser realizado tanto por serviços individuais, como, por uma composição de serviços ou até mesmo por uma orquestração de serviços que pode ser entendida como uma ou mais composições de serviços. Seguindo as atividades de especificação, a próxima a ser comentada é a identificação de non-funcional requirements (NFRs) ou requisitos não funcionais que um serviço deve implementar. Além de implementar a lógica do negócio, cada serviço deve seguir um conjunto de NFRs. Abaixo podem ser notados alguns exemplos de NFRs: A segurança para acesso de um serviço deve estabelecer requisitos de autenticação para consumidores externos ou não; A disponibilidade do serviço será de ou 99.9; A latência máxima para invocação de um serviço, será de 1 milissegundo ou 1 minuto, São exemplos de NFRs que tipicamente devem ser implementados por um serviço. Esse método tem por objetivo documentar todos os NFRs, tanto os que são julgados necessários, como os que podem ser adotados opcionalmente por cada serviço.

73 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 73 A especificação de mensagens de um serviço é uma das atividades mais criticas e significantes dessa fase. Tipicamente as mensagens de: entrada, saída e exceção, são responsáveis por constituírem a especificação sintática de um serviço. Normalmente, as mensagens do serviço são definidas no formato de XML, por razões óbvias de portabilidade e interoperabilidade. Esse método fornece algumas perspectivas que orientam o projeto de mensagens de serviço. E uma das primeiras coisas que se deve fazer, é padronizar o formato de mensagens usado para definir serviços. Seguir um formato de mensagem padronizado facilita a integração com outros parceiros fora do perímetro da empresa. Dessa forma, recomenda-se a definição Enterprise Message Format (EMF) para realizar a especificação de mensagens com sucesso. O EMF utiliza um subconjunto de artefatos alinhado a uma base de extensões, com a finalidade de definir o modelo de dados e o modelo de informações que serão utilizados para especificar mensagens de saída e de entrada que constituem o serviço. Logo, obter-se um EMF, bem projetado e documentado, impacta positivamente no projeto de especificação de mensagens de um serviço. A última atividade tem como foco principal, analisar as necessidades de gerenciamento do estado de um serviço. Como regra geral de um projeto SOA, recomenda-se o desenvolvimento de serviços sem estado. No entanto, muitas vezes por questões como performance, segurança, disponibilidades entre outros fatores que influenciam na qualidade e eficiência, exigem que os serviços possuam estado. Os tipos de estado mais comuns são: transacional, funcional e de segurança. O estado transacional tem por função fornecer suporte às transações, permitindo que as mesmas sejam divididas em múltiplas mensagens. Por exemplo, caso deseje-se obter os resultados de uma ação de negócio, necessita-se que seja estabelecida uma transação que normalmente contém múltiplas mensagens, entre um consumidor e um fornecedor de serviços, logo o estado transacional é responsável por manter o estado das transações ativo, até que todas elas sejam finalizadas e confirmadas.

74 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 74 Por outro lado o estado de segurança é responsável por estabelecer mecanismos capazes de verificar a autenticidade de um consumidor de serviço. Um dos principais mecanismos utilizados é conhecido por token. Onde, esse token é passado através de uma mensagem enviada pelo consumidor, a fim de validar sua autenticidade. Já o estado funcional: refere-se ao estado que deve ser mantido entre as mensagens, enquanto uma ação de negócio é realizada. Após a especificação de cada estado, todos eles devem ser documentados. Com isso, finaliza-se a primeira técnica utilizada durante a fase de especificação. Ainda existem mais duas técnicas que serão explanadas logo em seguida. No entanto, antes de mover-se adiante, deseja-se mencionar que todas as seis atividades recomendadas e discutidas como parte dessa técnica, podem ser utilizadas interativamente, dependendo no escopo e complexidade exigida pelo projeto, cada atividade poderá ser executada múltiplas vezes, até que se possa obter uma especificação robusta, refinada e com serviços de alto nível Análise de subsistemas Assim como uma área funcional fornece um agrupamento lógico de um domínio de negócios, um subsistema significa um agrupamento lógico de artefatos (componentes de software) de TI. Quando uma área funcional é muito abrangente e dificilmente será alcançada totalmente, ela é fragmentada em unidades lógicas, chamadas subsistemas. Um subsistema é constituído por três tipos de componentes: funcionais, técnicos e de serviço. O do tipo funcional é um componente de TI, que encapsula e produz um único tipo de funcionalidade de negócio. Por exemplo, qualquer cliente associado a lógica de negócio e a uma Application Programming Interface (API) pode ser encapsulado em um único componente funcional chamado opcionalmente de CustomerManager.

75 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 75 Por outro lado, um componente técnico é um componente de TI que fornece funcionalidades genéricas, tais como: autenticação, erros de manipulação, autenticação entre outros. Essas implementações normalmente estão intimamente ligadas à plataforma da tecnologia utilizada. Já um componente de serviço é um componente de TI, que atua como artefato central de um subsistema, e possui o papel de mediação entre os componentes: funcional e técnico. No entanto, é valido ressaltar que um componente de serviço normalmente está associado às funções de negócio de alto nível. E para que essas funções de negócio sejam implementadas, o mesmo pode necessitar chamar APIs de TI pertencentes a algum componente funcional ou técnico. Vamos considerar o seguinte exemplo, suponha que um serviço forneça detalhes da última reserva do veiculo de um cliente. Esse serviço requisitado irá necessitar de um componente CustomerManager para recuperar o perfil do cliente, usar alguma lógica de negócio para acessar detalhes do resultado retornado do cliente em questão, e em seguida, deve-se então invocar um componente VehicleManager para recuperar o atual veiculo reservado para um dado cliente. Dentro desse processo, pode-se ainda invocar um componente técnico chamado AuditManager para logar no serviço requisitado. No entanto, nem o CustomerManager, nem o VehicleManager, nem o AuditManager tem a lógica de negócio necessária para controlar esse microfluxo de passos. O controle desse microfluxo, que o componente invoca seqüencialmente para realizar a requisição de um determinado serviço, é responsabilidade de um componente de serviço. A figura abaixo retrata como os subsistemas estão associados aos componentes funcional, técnico e de serviço.

76 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 76 Figura 9 - Tipos de componentes. Fonte: Norbert Bieberstein Identificar subsistemas através de componentes de serviço, que por sua vez, são constituídos por componentes funcionais e técnicos, é crucialmente o principal ponto dessa etapa para realizar a análise de subsistemas com sucesso Especificação de Componentes Essa etapa tem como principal objetivo fornecer um projeto detalhado em microníveis (que é representado por modelos de software, tais como: diagrama de classes, diagrama de seqüências, entre outros). Cada componente de serviço que foi identificado e projetado em alto nível na etapa anterior, agora será descrito de uma forma muito mais detalhada. Para isso, um componente de serviço deve passar pela realização de algumas atividades: Identificar as características de um componente, incluindo não apenas atributos e operações, mas também as regras e políticas que eles implementam.

77 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 77 Identificar e especificar tanto os eventos como as mensagens de entrada e saída de um componente. Identificar o fluxo interno do componente (representar o fluxo interno que controla o componente de serviço, através de um diagrama de seqüência ou de colaboração). Criar o digrama de classes do componente. Normalmente o modelo de classes é utilizado para exibir estaticamente o relacionamento entre os componentes: funcional e técnico. Para finalizar essa etapa, atividades semelhantes as que foram descritas acima, também deverão ser realizadas nos componentes: funcional e técnico. Dessa forma, presume-se que ao término da especificação de componentes, todos os componentes estejam projetados e especificados nos mínimos detalhes, de tal forma que a equipe de implementação possa convertê-los em código sem grandes esforços. Com isso conclui-se a última etapa que compõe a fase de especificação. Logo, o resultado esperado pela a fase de especificação, é que para cada um dos serviços escolhidos para a exposição, seja apresentado uma espécie de manual, contendo as seguintes especificações: Como os serviços dependem uns dos outros (dependências do serviço). Como os serviços são orquestrados e formam composições capazes de realizar processos de negócio (composições de serviços). Identificar e documentar todos os requisitos não funcionais que cada serviço deve atender e implementar (NFRs do serviço). Especificar detalhadamente as mensagens de um serviço (especificação de mensagens dos serviços).

78 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 78 Identificar e documentar os requisitos de estado para cada serviço (gerenciamento de estado do serviço). Após todos esses pontos terem sido atingidos, deve-se mover para a terceira e última fase de SOMA, conhecida por realização Realização O principal objetivo dessa fase é fornecer um guia sobre, como tomar decisões arquiteturais que facilitaram a realização de serviços. É importante ressaltar, que SOMA não possui como um de seus fundamentos a implementação de serviços; Em vez disso, ela fornece informações e detalhes suficientes para que em uma possível fase de implementação de SOA, a equipe de desenvolvimento possa se concentrar apenas na implementação dos serviços. Implementação é a fase onde fatores como: tecnologias, linguagem de programação e plataforma, são escolhidos e usados para transformar a especificação do projeto, e os padrões e recitas da realização, em código executável. Essa fase esta divida em duas atividades: análise de viabilidade técnica e tomada de decisões, como poderá ser visto em mais detalhes a seguir Análise de viabilidade técnica O foco principal dessa atividade é justamente desenvolver uma análise criteriosa e detalhada nos sistemas existentes dentro da organização, a fim de avaliar quanto da tecnologia existente dentro da organização, poderá ser reaproveitada para realizar serviços. Esta atividade, assim como, o método SOMA em si, pode ser realizado iterativamente. Portanto, certamente parte dessa atividade foi inicializada durante a técnica Existing Asset Analysis (EAA), executada pela fase de identificação de serviços.

79 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 79 No entanto, a diferença é que as funcionalidades juntamente com as transações encontradas ao longo dos estágios iniciais da identificação de serviços, precisam ser validadas, a fim de viabilizar a componentização. Portanto, após a realização de uma profunda análise técnica, onde se puderam ser extraídas todas as funcionalidades pertencentes aos sistemas que atuam dentro da organização, e que serão utilizadas para realizar serviços, deverão ser formalizadas. Muitos aspectos tecnológicos relacionados a um sistema legado devem ser levados em consideração, quando se deseja reusar tal ativo de software pra realizar serviços. Entre eles, podem-se destacar os seguintes: Encerramento de execução: O tratamento de exceções em sistemas legados geralmente representa o enceramento da execução do programa. Logo isso não pode ser aceito por um sistema baseado em SOA, que é executado em tempo real. Integração: Freqüentemente desenvolvedores utilizam tecnologias e protocolos proprietários, para incorporar credenciais de segurança, como: autenticação e autorização, a aplicações legadas. No entanto, se for levado em consideração que as funcionalidades protegidas pelas credenciais de segurança, deverão ser reutilizadas, presume-se que haverá a necessidade de utilizar-se um mecanismo de integração, capaz de incorporar tais credenciais de segurança ao ambiente SOA. Provavelmente o surgimento de alguns problemas deverão ser endereçados, justamente a integração de funcionalidades que possuem credenciais de segurança de proprietários diferentes. Tempo de processamento: O batch 5 de processo tipicamente utilizado para sincronização de dados ou para submeter um pedido. Deve apresentar um tempo de execução proporcional a tarefa que está sendo executada por um processo. Por exemplo, caso o tempo para submissão de um pedido 5 Batch arquivo de computador utilizado para automatizar processos (BROWN, 2008).

80 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 80 apresente-se inconstante, então normalmente a funcionalidade não poderá ser utilizada por cenários que exigem execução em tempo real, como é o caso de SOA. Em alguns casos, o tempo de processamento de um sistema legado, poderá precisar ser alterado, ou em casos mais extremos, o processo poderá revelar-se inútil. A análise de viabilidade técnica não só aborda estes tipos de problemas, como também, fornece um embasamento para que decisões relacionadas à estrutura arquitetural sejam adotadas Tomada de decisões Os principais objetivos dessa atividade são: formalizar e justificar as decisões finais que serão adotadas para a realização de cada serviço. Essa justificativa atua como fluxo principal desse processo. Pois, existem diferentes alternativas de alto nível arquitetônico que possibilitam a realização de serviços. Dessa forma, a utilização de uma justificativa, será para fornecer argumentos, tais como: manutenibilidade, esforços e tempo necessário para a implementação, entre outros, que justifiquem a adoção de uma determinada alternativa. A metodologia SOMA recomenda que seis diferentes alternativas sejam levadas em consideração: Integrar Empacotar aplicações legadas existentes juntamente com tecnologias que possibilitam o desenvolvimento de SOA. Exige que seja utilizado, por exemplo, padrões e protocolos livres, que garantam a integração de SOA, sem que ocorra a presença de incompatibilidades. Transformar Transformar e expor partes de aplicações legadas. Essa alternativa pode envolver não apenas a extração de regras e políticas de negócio, como também a necessidade que o código seja reescrito. em uma moderna linguagem de programação que ofereça suporte a SOA. Isso muitas das vezes, atinge a disciplina de modernização de legados.

81 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 81 Comprar Adquirir produtos de independente service vendors (ISV) ou vendedores independentes de serviços. O ISV atua fornecendo funcionalidades que podem ser expostas como serviços. No entanto é valido ressaltar, que antes de comprar tal serviço, deve-se avaliar, se a funcionalidade oferecida pelo ISV realmente atende os requisitos desejados pelo projeto. Construir Construir aplicações seguindo os princípios e as melhores práticas do desenvolvimento de SOA. Isso freqüentemente é entendido como a melhor alternativa para se desenvolver aplicações que atendam as reais necessidades do projeto. Subscrever subscrever serviços externos desenvolvidos por terceiros, que reúnem ou excedem requisitos funcionais de negócio desejados. Vários fornecedores de SOA estão tentando atingir um nicho de mercado, onde eles possam se especializar e ofertar serviços que sejam desenvolvidos especificamente para atender um determinado requisito de negocio. Um serviço que autoriza o uso do cartão de crédito é um exemplo clássico. No entanto, raramente será visto qualquer organização desenvolvendo essa funcionalidade. Em vez disso, elas subscrevem um o serviço externo, a fim de desenvolver um serviço muito melhor, e que se adéqüe as suas necessidades. Terceirizar Existem empresas que são especializadas em fornecer serviços. Com isso, algumas organizações terceirizaram uma parte inteira das suas funções de negócio. No entanto, é valido alertar que cada serviço que for terceirizado, deve ser integrado perfeitamente (sem que haja qualquer incompatibilidade) aos processos de negócio que atuam dentro da organização. Contudo, pode-se notar que a realization decisions, auxilia na escolha das alternativas que deverão ser utilizadas como mecanismos para implementação de todos os serviços contidos no service portfolio.

82 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 82 Apos a conclusão das duas atividades (Análise de viabilidade técnica e a Tomada de decisões), conseqüentemente conclui-se a terceira e última fase da metodologia SOMA. Logo, os seguintes resultados devem ser esperados após o fim da fase de realização: Fornecer as funcionalidades dos sistemas legados existentes, que serão utilizadas para realizar serviços. Identificar a alternativa que melhor se adéqüe a cada serviço que será realizado. Capacidade de tomar decisões que serão utilizadas durante a realização de serviços SERVICE-ORIENTED UNIFIED PROCESS (SOUP) As informações contidas nessa seção (3.2), que são utilizadas para descrever os processos e estratégias pertencentes à metodologia SOUP, são baseadas no autor Mittal (2006 p.1-8). SOUP é uma metodologia de software adaptável, que combina as qualidades oferecidas por dois processos: RUP e XP, para desenvolver um esquema que fornece flexibilidade para gerenciar diferentes estágios durante o desenvolvimento de SOA. Capaz de disponibilizar processos e estratégias que permitam a criação, construção, montagem e reuso de serviços. Dessa forma, SOUP é indicado para qualquer organização que deseja desenvolver uma arquitetura orientada a serviços. SOUP mantém um modelo de processos para desenvolvimento de SOA, que está subdividido em seis fases. Cada fase representa um conjunto distinto de atividades que devem ser seguidas, para que se possa obter sucesso durante o desenvolvimento de um projeto SOA. Na figura 10, pode ser visto o modelo de processos pregado por SOUP.

83 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 83 Figura 10 - Modelo de processos SOUP. Fonte: Kunal Mittal 2006 Além da subdivisão em seis fases, esse modelo de processos SOUP, é quebrado em duas etapas: SOUP para implantação inicial de SOA (utilização do RUP). SOUP para projetos SOA em execução. (utilização do XP). A seguir essas etapas serão descritas em detalhes, assim como cada uma delas suporta e executa o conjunto de fases pertencentes à SOUP SOUP para implantação inicial de SOA. A etapa de SOUP para implantação inicial de SOA utiliza o processo RUP para dar inicio ao processo de criação de SOA. Na figura 11, pode-se perceber as fases de SOUP para implantação inicial de SOA, serem mapeadas em fases pertencentes ao modelo de processos RUP. Figura 11 - SOUP e o modelo RUP. Fonte: Kunal Mittal 2006 Adiante serão apresentadas as atividades e os resultados esperados ao término de cada fase executada.

84 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA Incept Nessa fase, deve-se levantar e argumentar as razões, que comprovem a necessidade de se estabelecer um projeto SOA dentro da organização. Em seguida, recomenda-se que sejam explicados os conceitos básicos de SOA a equipe de analistas de negócio da empresa, e por fim deve ser elaborado um plano estratégico que consiga absorver tanto feedback, como sugestões que possam enriquecer o processo de adoção de um projeto SOA. Os principais resultados esperados ao término dessa fase são: Visão e escopo de SOA: Descreve uma visão global e estabelece os limites de escopo do projeto. Estratégia SOA: Elaboração de um plano de alto nível, que explica detalhadamente como o projeto será executado. Análise do Return on Investiment (ROI): Descreve tanto os custos necessários para desenvolvimento do projeto SOA como, a redução de despesas que será alcançada após o desenvolvimento e execução do projeto. Plano de comunicação: Explica como a equipe responsável por implementar SOA, irá se comunicar com as outras equipes e com os analistas de negócio envolvidos no projeto. Os clientes (stakeholders), nem sempre compreendem completamente todos os benefícios que um novo produto de software será capaz de oferecer. Dessa forma, a equipe empresarial que definiu a estratégia para adoção de SOA, deve aproveitar a experiência e o domínio da equipe do projeto sobre o assunto, como suporte, para ajudar a identificar problemas do negócio, e disponibilizar novas formas que permitam agilizar as operações organizacionais executadas constantemente

85 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 85 Logo, analistas e gerentes de projeto deverão realizar uma análise no negócio do cliente, a fim de encontrar falhas que possam ser superadas, pela adoção de uma solução baseada em SOA. Os analistas tipicamente examinam: Operações internas realizadas no ambiente organizacional do cliente. Interações com os parceiros, fornecedores, e consumidores. Todo o modelo global de negócios. Esses fatores permitem uma fundamentação que será utilizada pelo analista para argumentar e convencer os clientes que o desenvolvimento de SOA, de fato, é uma estratégia recomendada. Nessa fase, também se deve elaborar uma análise completa do ROI, referente a estratégia SOA recomendada. Essa análise deverá claramente exibir um comparativo entre custo e benefício a curto, médio e longo prazo. O plano de comunicação é o produto mais importante desse estágio. A equipe de projeto TI e os stakeholders, conhecem melhor o negócio, do que a equipe de arquitetos e analistas. O plano de comunicação deve garantir que tanto a equipe de TI como os stakeholders, compreenda e se conscientizem que eles realmente fazem parte e estão envolvidos no processo de desenvolvimento Definir A forma como a equipe do projeto está envolvida com o negócio, normalmente determina o sucesso ou o fracasso de um projeto. Desse modo, membros da equipe necessitam esta participando ativamente da definição de requisitos e dos casos de uso, desenvolvidos como parte inicial de SOA. As seguintes atividades devem ser realizadas nesta fase: Coleta de requisitos; Análise de requisitos;

86 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 86 Definição de requisitos não-funcionais; Criação do plano de projeto que mantenha todos os prazos e estimativas; Definição da infra-estrutura técnica; Definição e realização dos casos de uso; Definição e documentação da arquitetura global. Por outro lado, os resultados esperados dessa fase são: Documento de requisitos funcionais: Responsável por descrever em detalhes, todos os processos de negócio que SOA irá mapear como serviços de software. Documento de requisitos não-funcionais: Inclui considerações sobre desempenho, disponibilidade, segurança e os demais requisitos de infraestrutura. Especificação de Casos de Uso: Criar casos de uso que especifiquem as funcionalidades que serão implementadas, por cada serviço de software que será construído. Documento de arquitetura SOA: Descrever a arquitetura global do projeto, inclusive os componentes de hardware e software. Documento para definição de infra-estrutura: inclui diagramas detalhados, relacionados à implantação e infra-estrutura de servidores. Tipicamente apresentam como principal objetivo, descrever os locais e as conexões entre os servidores que serão necessários para execução de SOA. Plano de Projeto: Estabelece um plano que detalha todo o projeto, inclusive todos os marcos e as dependências associadas ao projeto.

87 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 87 Modelo de governo: Tem por função descrever o modelo que será adotado para governar SOA. Normalmente, monitoramento e gerenciamento de serviços, são os fatores que devem ser levados em consideração. É válido ressaltar, que o modelo de governo é o produto que exige maior atenção nesse estágio. Pois através do mesmo deverá ser possível absorver os fundamentos necessários para responder os seguintes questionamentos: Como a organização irá aceitar e receber uma SOA? Quais são as diretrizes que deverão ser utilizadas para governar uma SOA? Logo, se uma organização implementa SOA, mas utiliza as funcionalidades oferecidas pelos serviços de maneira inadequada, ou então existe uma resistência por parte dos funcionários em utilizá-la, provavelmente o projeto será um fracasso. Dessa forma, o documento do modelo de governo pretende prevenir que situações como essas possam acontecer Projeto Já na fase conhecida por Projeto, o objetivo a ser atingido é a elaboração dos artefatos que foram projetados na fase anterior (Definir). Dessa forma, os arquitetos por sua vez, devem elaborar um documento contendo a especificação de casos de uso e a arquitetura de software nos mínimos detalhes. Os resultados a serem obtidos são os seguintes: Documento de projeto detalhado: Que deverá descrever como os serviços serão projetados e construídos. Modelo de programação: Fornece diretrizes sobre a estrutura de desenvolvimento a ser adotada. Nesse modelo, questões como: processos, tecnologias, normas de codificação, procedimentos de implantação entre outros, devem ser especificados detalhadamente. Modelo de banco de dados: Inclui o diagrama de entidade e relacionamento, referente à base de dados que será utilizada.

88 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 88 Plano de Teste: Plano que inclui e especifica todos os casos de teste exigidos pelo projeto Construir Esta fase é responsável pelo desenvolvimento e integração de novas atividades. Logo, essas atividades não se limitam apenas à implementação de serviços de software, mas também, devem envolver fatores que permitam definir a infra-estrutura necessária para implantação de SOA dentro da organização, como por exemplo: projetos que definem a estrutura de hardware necessária, ou então, os esforços exigidos para realizar a hospedagem de servidores. Esta fase envolve as seguintes atividades: Desenvolvimento iterativo; Execução dos casos de teste; Criação da documentação do usuário. Dessa forma, os seguintes resultados devem obtidos por esta fase: Base de Código: O código deve ser armazenado em algum tipo de repositório, para que se possa manter o controle e origem de todo o código já desenvolvido. Resultados dos testes: Os resultados da execução dos casos de teste devem estar disponíveis para exame. Documentação: A documentação deve incluir informações não apenas relacionadas ao código atual, como também sobre qualquer atualização que tenha sido realizada ao longo do projeto.

89 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA Implantar A fase conhecida por Implantar, tem como principais responsabilidades, fornecer instruções iniciais que descrevem as melhores formas de utilizar as funcionalidades disponibilizadas por um projeto SOA dentro do ambiente de produção organizacional. Talvez, o resultado mais esperado e óbvio a ser entregue por esta fase, seria a aplicação de SOA no ambiente de produção organizacional. No entanto, essa fase foca principalmente na elaboração de um projeto-piloto de SOA. Pois, esse projeto-piloto é fator que leva ao próximo passo da metodologia de SOUP, que é determinar como os produtos de software que já estão em uso irão se adequar a nova arquitetura implantada. Os demais resultados esperados esta fase são: Modelo de Implantação: Descreve a estrutura geral de implantação de SOA; Modelo de uso: Fornece orientações sobre como utilizar os serviços fornecidos. Este modelo é de fundamental importância, pois serve como guia, para aqueles usuários que irão utilizar os serviços disponibilizados pela nova arquitetura; Suporte ao modelo: Codifica qualquer atualização que seja necessário realizar, e as adiciona no modelo de governo desenvolvido na fase Definir Manutenção Esta etapa final do ciclo de desenvolvimento no SOUP é muito importante. Na fase de Manutenção, a organização deve oferecer apoio: a alguns passos do desenvolvimento de SOA que ainda possam estar em andamento à correção de bugs e ao desenvolvimento de novas funcionalidades. Esta fase de um projeto SOA envolve algumas atividades, tais como: Manutenção;

90 METODOLOGIAS PARA DESENVOLVIMENTO DE SOA 90 Correção de erros; Treinamento O projeto de SOA está em produção. Mas como o projeto poderá beneficiar as equipes de arquitetura? Será que elas precisaram seguir rigorosamente todas essas fases descritas até agora, para criarem aplicações que consomem serviços existentes, ou então para criarem novos serviços de software? A próxima etapa de SOUP a ser explanada, procura responder tais questionamentos SOUP para projetos SOA em execução A metodologia SOUP também pode ser utilizada em projetos SOA que já foram implantados nas organizações. Nessa situação, SOUP se inspira fortemente no XP para criar tanto aplicações para consumir serviços já existente\s, como para criar novos serviços de software. A Figura 12 Mostra as fases da metodologia SOUP e os processos XP sobrepostos uns aos outros. Figura 12 - SOUP e o modelo XP. Fonte: Kunal Mittal 2006 Este tipo de projeto deverá seguir as mesmas diretrizes SOUP delineadas na última seção, no entanto, como poderá ser visto cada fase é significativamente reduzida. Muitos dos resultados desta seção são os mesmos descritos anteriormente. No entanto, quando necessário, será explicado como eles diferem de suas contrapartes em um projeto onde SOA é construído a partir do zero.