ARQUITETURA ORIENTADA A SERVIÇO : UMA ANÁLISE DAS PROPOSIÇÕES TECNOLÓGICAS COM FOCO NA AUTOMAÇÃO DE PROCESSOS DE NEGÓCIOS

Transcrição

1 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE EDUCAÇÃO SÃO JOSÉ CURSO DE CIÊNCIA DA COMPUTAÇÃO TRABALHO DE CONCLUSÃO DE CURSO ARQUITETURA ORIENTADA A SERVIÇO : UMA ANÁLISE DAS PROPOSIÇÕES TECNOLÓGICAS COM FOCO NA AUTOMAÇÃO DE PROCESSOS DE NEGÓCIOS Fábio Mattos de Barros Acadêmico Paulo Roberto Riccioni Gonçalves Professor orientador São José, junho de 2005

2 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE EDUCAÇÃO SÃO JOSÉ CURSO DE CIÊNCIA DA COMPUTAÇÃO ARQUITETURA ORIENTADA A SERVIÇO : UMA ANÁLISE DAS PROPOSIÇÕES TECNOLÓGICAS COM FOCO NA AUTOMAÇÃO DE PROCESSOS DE NEGÓCIOS Sistemas Distribuídos Fábio Mattos de Barros Acadêmico Proposta de trabalho apresentada ao Responsável pela Coordenação de Trabalho de Conclusão do Curso de Ciência da Computação da Universidade do Vale do Itajaí - São José, para o desenvolvimento durante as disciplinas de Trabalho de Conclusão de Curso I e II. São José, junho de 2005

3 FÁBIO MATTOS DE BARROS ARQUITETURA ORIENTADA A SERVIÇO : UMA ANÁLISE DAS PROPOSIÇÕES TECNOLÓGICAS COM FOCO NA AUTOMAÇÃO DE PROCESSOS DE NEGÓCIOS Este Trabalho de Conclusão de Curso foi julgado adequado como requisito parcial para a obtenção do título de Bacharel em Ciência da Computação, tendo sido aprovado pelo Curso de Ciência da Computação, Centro de Educação São José da Universidade do Vale do Itajaí (SC). São José, 19 de dezembro de Prof. Esp. Alecir Pedro da Cunha Responsável pela Coord. do TCC Prof. M. Eng. Fernanda dos Santos Cunha Coordenadora do Curso Apresentada à Banca Examinadora formada pelos professores: Orientador Prof. Msc. Paulo Roberto Riccioni Gonçalves Profa. Dra. Eliza Coral Prof. Msc. Paulo Henrique de Souza Bermejo

4 SUMÀRIO 1 INTRODUÇÃO Contextualização Justificativa Objetivos Objetivo Geral Objetivos Específicos Metodologia Delimitações da Pesquisa ARQUITETURA ORIENTADA A SERVIÇOS (SOA) Serviços Definindo a SOA Evolução da Arquitetura de Sistemas Os Elementos da SOA SOA e Web Services A GESTÃO DE PROCESSO DE NEGÓCIOS - BPM Processos de Negócios Gerenciando Processos Evolução dos Sistemas de Informação frente à adequação dos Processos de Negócios BPM versus WFMS Processo de Desenvoilvimento BPM versus RUP BUSINESS PROCESS MANAGEMENT SYSTEMS BPMS UTILIZANDO SOA COM BPMS Critérios para Avaliação de BPMS MODELANDO E EXECUTANDO PROCESSOS Identificação dos Processos Definição do Modelo de Referência Modelos de Referência e Padrões para Processos SCOR - Supply Chain Operations Reference Model RosettaNet Captura e Identificação dos Processos Elaboração dos Processos Colaboração de Negócio Definição das Transações de Negócio Linguagens e Notações para Modelagem em nível de Execução A Linguagem BPEL Elementos da Linguagem BPEL PROJETO DE DEMONSTRAÇÃO DE USO DA ARQUITETURA Metodologia Ferramentas e aplicações de infra-estrutura tecnológica Análise dos Processos Definição do Modelo de Referência Definição das Áreas de Negócio...96

5 5.3.3 Definição das Áreas de Processos Identificação dos Processos Elaboração de Processos de Negócio Transação de Negócios Especificação dos Serviços Serviço de Vendas Serviço Gerenciamento de Estoque Serviço de Compras CONCLUSÃO REFERÊNCIAS...109

6 RESUMO Atualmente, o modelo globalizado e altamente competitivo dos negócios sugere a adoção de sistemas de informações altamente adaptáveis às mudanças nos processos organizacionais. Desta forma, para agilizar a disponibilização de serviços computacionais, é necessária a reutilização otimizada dos sistemas existentes, partindo-se da idéia que utilizar elementos de sistemas legados é mais rápido do que refazê-los dentro de um processo de desenvolvimento de software. Assim, esta pesquisa tem como objetivo analisar os elementos pertinentes a Arquitetura Orientada a Serviços bem como os elementos do Gerenciamento de Processos de Negócios como abordagens para a concepção de sistemas de tecnologia da informação em ambientes onde os processos de negócios são altamente suscetíveis a mudanças e a diversidade de plataformas de software é presente no parque tecnológico da organização. Assim, a primeira parte da pesquisa irá abordar os elementos da SOA e da plataforma Web Service. Em uma segunda etapa, serão apresentados os elementos do BPM bem como a definição dos servidores que suportam a automação dos processos de negócios, designados como BPM Systems. Em seguida propõe-se o estudo de metodologias para identificação e modelagem de processos de negócios, juntamente com padrões e modelos que podem ser utilizados em tais atividades. Finalmente, compete também a esta pesquisa, a implementação de uma aplicação de teste que terá como objetivo fornecer dados para uma análise prática da utilização das tecnologias apresentadas.

7 LISTA DE FIGURAS Figura 2-1 Acessando e combinando serviços Figura Sistema de equipamentos de Áudio e Vídeo...22 Figura Alinhamento dos serviços SOA com os serviços oferecidos pela organização...25 Figura Diferentes implementações da SOA...26 Figura Evolução da Arquitetura de Sistemas...27 Figura 2-6 Crescimento Horizontal de Disponibilização de Aplicações...29 Figura Elementos da SOA Figura Componentes de uma descrição de serviço usando WSDL...34 Figura Estrutura UDDI...35 Figura Composição da SOA com a plataforma Web Service...36 Figura Composição de Processos...38 Figura Disciplinas do BPM...43 Figura Separação da Lógica dos Processos de Negócio Figura 3-4 Processos em Sistemas Legados Figura Processos no ERP Figura Funções de um Sistema de Gerenciamento de Workflows...47 Figura Integração de processos internos e externos...49 Figura Comparação Disciplinas BPM versus RUP...50 Figura 3-8- Diferentes Visões dos Fornecedores de BPMS...52 Figura Modelo Simplificado de um BPMS Figura Ferramenta de Modelagem de Processos Microsoft BizTalk Server...53 Figura Esquema de um servidor de regras de negócio Figura Painel de Indicadores Chave de Performance...56 Figura 3-13 Estrutura padrão de distribuição de sistemas...57 Figura 3-14 Inclusão da camada de serviços...58 Figura 3-15 Adicionando a camada de processo de negócio...59 Figura Evolução Contínua das soluções BPMS Figura 3-17 Detalhamento dos elementos de um BPMS em cada nível de evolução do produto...62 Figura SCOR: Nível de Configuração...69 Figura 4-2 Detalhamento do SCOR Nível Figura 4-3 Nível de Implementação do Modelo SCOR...71 Figura 4-4 Estrutura dos Elementos de Processo (RosettaNet)...73 Figura 4-5 Diagrama Conceitual de Processo PIP 3A Figura 4-6 Processo Públicos e Privados (PIP)...75 Figura 4-7 Documentos de apoio para Identificação de Processos Figura Detalhamento de Processo...77 Figura Elaboração dos Processos...78 Figura Colaboração dos Processos...79 Figura Diagrama de Atividades de Colaboração entre Processos...80 Figura Transação de Negócio...80 Figura Diagrama de Atividades de Transações de Negócio...81 Figura Esquema Genérico de Linguagens de Automação de Processos para Web Services...82 Figura 4-15 Tcnologias de Automação de Processos...83 Figura Integração BPEL com Web Services...85 Figura Orquestração versus Coreografia de Serviços...86

8 Figura Mapeamento de participantes BPEL WSDL...89 Figura Definição de Variáveis BPEL e WSDL...91

9 LISTA DE TABELAS Tabela 3-1- Funcionalidades do BPMS...51 Tabela Objetivos de um Modelo de Referência para Processos...66 Tabela Elementos e Objetivos do Modelo de Referência...67 Tabela Conjuntos do Modelo RosettaNet...73

10 LISTA DE ABREVIATURAS E SIGLAS ATM - Automatic Teller Machine B2B Business to Business BAM Business Activity Monitoring BPEL Business Processo Execution Language BPM Business Process Management BPMS Business Process Management System CICS - Customer Information Control System COBOL - Common Business Oriented Language CORBA - Common Object Request Broker Architecture ERP Enterprise Resource Planing HTTP - HyperText Transfer Protocol IMS - Information Management System J2EE Java 2 Platform, Enterprise Edition JMS Java Messaging System KPI Key Performance Indicator MSMQ Microsoft Message Queuing PL/I - Programming Language One SCOR Suplly-Chain Operations Reference SGDB Sistema de Gerenciamento de Banco de Dados SOA Service Oriented Arquitecture SOAP - Simple Object Access Protocol TI Tecnologia da Informação UDDI - Universal Description, Discovery, and Integration UDP - User Datagram Protocol UML Unified Model Language WFMS Workflow Management System WS Web Service WS-I Web Service Interoperability Organization WSDL Web Servoce Description Language XML Extensive Markup Language XSD XML Schema Definition XSLT - Extensible Stylesheet Language Transformation

11 1 INTRODUÇÃO 1.1 Contextualização O desenvolvimento de soluções integradas para grandes corporações sempre implicará em desafios para todos os colaboradores envolvidos nas tarefas de análise e projeto de arquitetura de sistemas. Em muitos casos, um destes desafios resume-se em um complicado problema antagônico: ao mesmo tempo em que se procura reduzir os custos e maximizar a utilização de sistemas legados, a estrutura de TI 1 deve continuadamente oferecer melhores serviços para os clientes, incrementando a competitividade e adequando-se às prioridades estratégicas da empresa. Uma dicotomia que se estrutura então, em uma necessidade de prover maiores facilidades aos consumidores frente à exigência de investir-se menos recursos financeiros. Dentro deste cenário, surgem duas características fundamentais que o mercado exige de uma arquitetura de sistemas de grande porte : Heterogeneidade e Adaptabilidade. Atualmente encontram-se, no cotidiano das maiores empresas, uma série de sistemas, arquiteturas e aplicações, implantadas em diferentes épocas e desenvolvidas com tecnologias diversas, definindo um ambiente heterogêneo. Assim, a Heterogeneidade é definida por uma infra-estrutura de tecnologia da informação que abriga sistemas concebidos em plataformas e linguagens de programação distintas. Contudo, adotar tecnologia de um único fornecedor, para o alcance de uma infraestrutura tecnológica homogênea, também não é uma abordagem recomendada, pois as suítes de aplicativos e o suporte oferecido muitas vezes não são flexíveis o suficiente para adequarse ao modelo de negócio da organização. 1 Tecnologia da Informação

12 12 A Adaptabilidade torna-se uma característica necessária devido ao alto dinamismo do mercado, imposto pela economia neoliberal. A globalização e a adoção do comércio eletrônico estão, gradualmente, acelerando o ritmo das mudanças dos processos comerciais. O mercado competitivo induz as empresas a reduzirem o ciclo de vida de seus produtos, aumentando a diversidade das ofertas dos mesmos. Isto também acaba causando mudanças rápidas das necessidades dos clientes, em relação aos produtos. Como é inquestionável o impacto que mudanças inseridas nos processos comerciais, produtivos e operacionais causam na estrutura de TI que os suportam, é imprescindível a adoção de uma arquitetura de sistema altamente adaptável, que responda rapidamente a todas estas mudanças, em curto ou longo prazo. Neste contexto, a Arquitetura Orientada a Serviços (SOA 1 ) vem ganhando destaque como uma solução para transpor a dificuldade pertinente ao desenvolvimento e integração de sistemas em ambientes tecnológicos heterogêneos e suscetíveis a mudanças. Como muitas das abordagens reconhecidas como padrão, a SOA é um desenvolvimento contínuo de um conjunto de práticas e técnicas, não possuindo um marco temporal para sua criação, podendo também ser considerada como uma evolução da Arquitetura de Componentes. Assim sendo, muitas soluções projetadas desde meados da década de noventa já utilizam alguns conceitos básicos da SOA, mesmo assim, a mesma é considerada uma tecnologia emergente, pois os esforços para a padronização da arquitetura caracterizam-se em projetos recentes. Na SOA, os serviços interagem entre si localmente ou remotamente, utilizando uma abordagem de comunicação do tipo passagem de mensagem ou orientada a documentos. Tal abordagem garante uma grande facilidade de manutenção da interoperabilidade entre os serviços distribuídos. O conjunto de serviços propostos pela SOA, aliado a padrões e técnicas destinadas a elaboração coerente de um projeto de arquitetura, podem oferecer uma solução de projeto ágil e adequado para a implementação de sistemas em ambientes heterogêneos. Paralelamente aos conceitos de SOA, o termo Gestão de Processos de Negócios (BPM 1 ), comumente utilizado em publicações destinadas ao estudo da Ciência da Administração, está sendo introduzido na indústria de Tecnologia da Informação. 1 Service Oriented Architecture

13 13 Enquanto Gerenciar Processos para os administradores está relacionado com a análise, projeto e tomada de decisões referentes à manutenção dos processos organizacionais, na indústria de software tal atividade se refere à automação e formalização dos processos, bem como as regras de negócios associadas aos mesmos. Retornando ao conceito evolutivo, o BPM primeiramente surgiu como uma melhoria de projeto em arquiteturas de três camadas. Esta caracteriza-se por uma separação lógica ou física dos componentes de apresentação, de negócios e de acesso a dados. Para Putte (2000,p. 4), o BPM foi concebido como o próximo passo em ambientes de três camadas, onde a idéia principal foi extrair a lógica e as regras da camada de negócio e estruturá-las em uma aplicação baseada em workflow, mostrando graficamente os vários passos inclusos nos processos de negócio. Em cada nó de um workflow, as regras de negócio são utilizadas para a definição do próximo nó, executando uma seqüência lógica do negócio. Como conseqüência da implantação do BPM para automatizar os processos de negócios, as regras de negócio tornam-se explícitas, mais visíveis e adaptáveis a mudanças, sendo uma prática indicada para atender ao critério Adaptabilidade de um sistema distribuído. Atualmente, existe um grande esforço de fornecedores de tecnologia para prover componentes de middleware 2 capazes de facilitar o desenvolvimento de aplicações utilizando o BPM. Tais componentes são empacotados em aplicativos denominados BPM Systems e oferecem serviços centralizados que implementam e gerenciam as chamadas de início e fim do processo de negócio automatizado. Em um desenvolvimento de um sistema BPM, os processos de negócios são modelados graficamente e seus fluxos podem ser facilmente convertidos em uma linguagem de automação de processos. Isto tende a agilizar desenvolvimento de um sistema, pois o script 3 de linguagem de automação executado no BPM System pode substituir a codificação dos algoritmos de serviços de negócios em uma arquitetura SOA. É fato que as distintas conceituações de BPM e SOA abordam diretamente as vantagens da utilização das mesmas, mas devido ao caráter inovador em que se encontram 1 Business Process Management 2 Aplicativo que contem um conjunto de bibliotecas e componentes que dão suporte ao desenvolvimento de sistemas distribuídos. 3 Procedimentos escritos em uma determinada linguagem que podem ser executados passo a passo por um processo computacional.

14 14 em relação às demais soluções arquitetônicas de TI, não existe uma metodologia unificada para o desenvolvimento de sistemas que os utilizem. Cada fornecedor de TI atuante no novo mercado de produtos para BPM e SOA sugere uma abordagem própria de desenvolvimento, além disto, os padrões e especificações técnicas dos componentes das tecnologias são elaborados por consórcios distintos, dentre eles W3C 1, OASIS 2 e BPMI 3, e muitas vezes existem soluções técnicas diferentes para o mesmo caso, de forma redundante. Neste contexto, quaisquer projetos que queiram utilizar-se dos benefícios do BPM e da SOA implicarão na problemática da escolha ou da elaboração de procedimentos, ferramentas e técnicas que apóiem o desenvolvimento coerente do sistema. Assim, o problema de pesquisa, pode ser definido da seguinte forma : Quais os procedimentos, ferramentas e técnicas necessárias para suportar o projeto e a implementação de um sistema distribuído altamente adaptável e interoperável, utilizando a automação facilitada pelo BPM em uma arquitetura SOA? 1 World Wide Web Consortium (Consórcio da Rede de Abrangência Mundial) 2 Organization for the Advancement of Structured Information Standards (Organização para a Evolução de Padrões de Informações Estruturadas) 3 Business Process Management Initiative (Iniciativa para a Gestão de Processos de Negócios)

15 Justificativa A relevância do projeto de pesquisa apresentado pode ser delineada analisando suas possíveis contribuições técnicas e científicas, bem como a importância dada aos objetos de pesquisa na mídia especializada. No contexto da contribuição técnica, o problema de pesquisa proposto sugere o levantamento de procedimentos, ferramentas e técnicas para projeto e implantação de BPM em uma arquitetura SOA. Sendo assim, os dados levantados resultantes da necessidade desta busca poderão consolidar um guia inicial para a adoção destas tecnologias em um ambiente de produção. Profissionais de TI que assumem o papel de arquitetos poderão encontrar informações para o auxílio de tomadas de decisões de projeto, escolha de produtos disponibilizados no mercado e conhecimento das melhores práticas já adotadas em projetos bem sucedidos. Outra justificativa associada a este projeto de pesquisa é a própria relevância que profissionais do meio científico e mercadológico de tecnologia da informação estão atribuindo e atestando à SOA e ao BPM. Relevância comprovada por estudos e relatórios de renomados institutos de pesquisa, como o Gartner Group, que apontam a SOA e o BPM como tecnologias que proporcionarão um alto retorno de investimento, definindo-as como emergentes e de utilização a longo prazo (FERGUSON, 2005). Finalmente, é importante ressaltar a existência de poucas publicações nacionais sobre o tema desta pesquisa. Portanto, qualquer projeto envolvendo SOA e BPM torna-se importante para promover a diminuição da latência entre as publicações estrangeiras e a produção científica brasileira.

16 Objetivos Objetivo Geral Demonstrar elementos e características pertinentes aos conceitos de SOA e BPM, definindo um relacionamento entre os mesmos, enumerando e analisando os procedimentos, ferramentas e técnicas atreladas ao desenvolvimento de um projeto que utiliza tais conceitos Objetivos Específicos Os objetivos específicos definidos para este projeto são: a) Estudar os elementos da SOA visando o entendimento do funcionamento macro e global da tecnologia. b) Apresentar as proposições teóricas relacionadas à tecnologia BPM, bem como os seus componentes comuns e a interação entre os mesmos; c) Apresentar os aspectos referentes às atividades envolvidas no projeto de sistemas utilizando o BPM, em nível de processos e padrões de projetos; d) Analisar o conceito de BPM System e algumas soluções oferecidas pelos fornecedores da tecnologia; e) Apresentar as opções de linguagens de automação de processos, bem como as vantagens e desvantagens relacionadas à utilização das mesmas; e f) Definir um processo de negócio fictício, para ser utilizado em uma implementação de um aplicativo para teste da arquitetura.

17 Metodologia Este projeto será composto por uma etapa de pesquisa bibliográfica, seguida por uma implementação prática que servirá como prova de conceito. Com base nos resultados e informações obtidos, será feita uma análise conclusiva que buscará as respostas do problema de pesquisa. Em relação à coleta de informações para a revisão bibliográfica, serão consultados principalmente: a) os livros e artigos publicados que abordem os conceitos de Arquitetura de Sistemas, BPM, WebService e SOA; b) as especificações de padrões tecnológicos dos elementos pertinentes a SOA, BPM e Web Service; e c) As publicações de fornecedores de soluções tecnológicas para os objetos de pesquisa. A implementação prática será constituída pela análise, especificação e construção de uma pequena aplicação de demonstração utilizando SOA e BPM. Pretende-se na análise e especificação da aplicação, utilizar as metodologias abordadas na revisão bibliográfica que sejam específicas para o desenvolvimento de softwares arraigados nestes dois objetos de pesquisa. Quando forem necessários outros métodos e documentos de especificação, não inerentes aos temas principais da pesquisa, serão utilizados os elementos do processo unificado (RUP) e os artefatos da UML. A aplicação de demonstração será projetada e construída para operar em uma solução de um fornecedor de produtos para BPM e utilizando a linguagem de automação de processos escolhida como mais representativa no conceito de padrão de mercado. 1.5 Delimitações da Pesquisa Em relação à pesquisa bibliográfica, os seguintes tópicos serão considerados de pequena relevância neste projeto e, portanto, passíveis de não serem abordados: a) Detalhamento dos elementos tecnológico de qualidade de serviço, como controle de acesso, gerenciamento de segurança e política de utilização, controle de transação.

18 18 b) Detalhamento de protocolos de comunicações e de processamento remoto, como por exemplo HTTP 1, SOAP 2, UDP 3. c) Tópicos relacionados a desempenho e performance de aplicações. d) Tópicos relacionados a infra-estrutura tecnológica, como sistemas operacionais, gerenciamento e topologia de redes e gerenciamento de banco de dados. As delimitações de pesquisa bibliográfica também serão refletidas para a construção da aplicação de demonstração. Assim, a mesma deverá ter poucas funcionalidades e atender a uma pequena quantidade de processos simples. Para isto, será elaborado um problema fictício para subsidiar a coleta dos requisitos funcionais necessários. Ressalta-se então, que os processos modelados não terão validade no contexto de uma utilização produtiva em uma organização real. Neste mesmo sentido, questões de performance computacional, segurança, performance de rede, transação e integridade dos dados serão ignoradas tanto em tempo de análise e especificação quanto em tempo de análise conclusiva da aplicação. Assim, o esforço deste projeto de pesquisa estará mais concentrado no estudo e na análise de conceitos e proposições relativas às tecnologias SOA e BPM, do que na implementação prática. 1 Hyper Text Transfer Protocol 2 Simple Object Access Protocol 3 User Datagram Protocol

19 19 2 ARQUITETURA ORIENTADA A SERVIÇOS (SOA) Primordialmente, uma determinada tecnologia ou metodologia de implementação de sistema distribuído era comumente definida apenas pelo conjunto de seus elementos computacionais e pela forma de comunicação entre os mesmos. Porém, diante do cenário atual, onde as decisões tomadas na área de TI estão ganhando uma grande importância no planejamento estratégico das organizações, observa-se uma preocupação dos autores em introduzir, na definição, considerações relacionadas - aos benefícios que tal tecnologia provê e às diferentes formas e motivos para utilização da mesma. Neste sentido, Erl (2004, p. 482), considera que : A Arquitetura Orientada a Serviços pode ser definida em diversas perspectivas : uma arquitetura técnica, uma abordagem de modelagem de negócio, um recurso de integração e um novo meio de visualizar as unidades de automação da empresa. Esta primeira conceituação, apesar de ser muito vaga, torna-se útil para reforçar que ainda não existe uma definição única e formal para SOA. Percebe-se que uma definição de SOA pode ser fundada somente em uma das perspectivas enumeradas por Erl, ou em todas elas concomitantemente. Outro fator que justifica a existência de diversas linhas de definição é o próprio estado inovador em que a SOA se apresenta no contexto atual. Dentro deste contexto, buscar-se-á neste capítulo apresentar os conceitos de SOA de forma a seguir uma única linha de definição, permeando entre textos de vários autores para o alcance desta, ou seja, ao invés de mostrar as várias definições divergentes sobre um tema, serão apresentadas somente aquelas que se adaptam melhor ao alcance do problema de pesquisa proposto.

20 Serviços Para um completo e fácil entendimento da SOA, primeiramente faz-se necessário definir o termo serviço. Este pode ser visto sob duas perspectivas distintas, a de negócio e a de arquitetura de sistemas. Na perspectiva de negócio, as organizações oferecem vários tipos de serviços aos seus stakeholders, dentre eles: consumidores, clientes, cidadãos, funcionários, fornecedores e empresas parceiras. Como exemplo, Newcomer (2004) cita uma agência bancária que dispõe de vários caixas para oferecer diferentes serviços, sendo alguns destes especializados para só atenderem certos tipos de solicitação. Dentre os serviços oferecidos incluem-se : criação e cancelamento de contas; empréstimos; retiradas, depósitos e transferências; serviços de câmbio, seguros; entre outros. Muitos dos caixas oferecem paralelamente o mesmo tipo de serviço, para otimizar o atendimento aos clientes, ao mesmo tempo em que um procedimento complexo pode requerer que o cliente passe por diversos atendentes, conseqüentemente implementando um fluxo de processo de negócio. Por trás dos serviços oferecidos estão os sistemas de TI que automatizam os processos que suportam os mesmos. Uma abordagem eficiente de definição de tais sistemas consiste em alinhar os projetos de TI com as funcionalidades, serviços e os processos de negócio, promovendo que a infraestrutura de TI suporte os objetivos da organização e adapte-se facilmente para prover os mesmos serviços através de diferentes canais, como atendentes, ATM s e aplicações Web (NEWCOMER, 2004). Na Figura 2-1, apresenta-se um esquema de acesso aos serviços bancários através dos sistemas de TI. Figura 2-1 Acessando e combinando serviços. FONTE: NEWCOMER (2004)

21 21 Alinhando o conceito de serviço em uma perspectiva de negócio, Endrei (2004, p.28) aponta que em uma Arquitetura Orientada a Serviços, cada serviço mapeia as funções de negócio que são identificadas durante o processo de análise. Tais serviços podem ser acessados de acordo com uma política definida pelo negócio, determinando quem ou qual sistema está autorizado a utilizar o serviço, quando o serviço estará disponível, o custo de utilização do serviço, o nível de disponibilidade do serviço, os níveis de segurança e a performance, em termos de tempo de resposta (NEWCOMER 2004). Em um primeiro momento, pode parecer que a determinação de tais políticas de utilização dos serviços é algo pertinente a um nível técnico ou de implementação de sistemas. Mas pensando no contexto em que foram definidas, torna-se claro que as políticas são orientadas pelo negócio, podendo também ser aplicadas a serviços disponibilizados por agentes humanos. Em uma perspectiva de arquitetura de sistemas, (NEWCOMER 2004) define: Um serviço da SOA consiste em um recurso de sistema que possui uma interface muito bem definida, separando claramente a interface externa e acessível do serviço de sua implementação técnica. Tal separação possibilita o desacoplamento entre o requerente e o provedor do serviço, assim, ambos podem evoluir independentemente desde que o contrato do serviço mantenha-se inalterado. A interface do serviço possibilita que o mesmo possa ser publicado, localizado e invocado. Pode-se optar por publicar os serviços externamente, para serem utilizados por sistemas B2B, ou internamente, servindo como um elemento participante da estrutura de TI utilizada dentro da organização. Barry (2003), complementa ao observar que um serviço não depende do contexto ou do estado que se encontra um outro serviço, fazendo uma analogia interessante a um sistema de equipamentos de áudio e vídeo (Figura 2-2).

22 22 Figura Sistema de equipamentos de Áudio e Vídeo Cada equipamento é autônomo e tem suas funções básicas definidas pela indústria. Um usuário, por exemplo, não necessita de um vídeo cassete (VCR) para escutar um CD de áudio. Assim, os componentes tornam-se independentes entre si. A televisão não precisa estar ligada para o VCR gravar um programa. É claro que se o usuário der o comando para a leitura da fita gravada com a televisão desligada, o mesmo não conseguirá assistir ao conteúdo que gravou, mas mesmo assim, o VCR cumpre sua função enviando o sinal para a TV sem se preocupar com o estado que a mesma se encontra. Segundo (NEWCOMWER,2004), em uma SOA o serviço deve possuir as seguintes características chaves : a) Fraco Acoplamento O acoplamento do serviço pode ser distinguido em três categorias : acoplamento de interface, acoplamento de tecnologia e acoplamento de processo. O acoplamento de interface mede o nível de dependência que o provedor do serviço impõe no serviço requerente. Quanto menor for a dependência, mais fraco será o acoplamento. A interface deve encapsular todos os detalhes de implementação, tornando-o irrelevante para o requerente. O acoplamento de tecnologia define o quanto um serviço depende de uma tecnologia, produto ou plataforma de desenvolvimento (sistema operacional, servidores de aplicação, frameworks e middlewares). Os serviços estando intimamente acoplados a uma plataforma específica limitam sua extensão, em termos de requerentes que o acessam e de desenvolvimento por outras equipes (outsourcing). Estrategicamente, isto poderia ocasionar uma dependência da organização a um único fornecedor de tecnologia proprietária. Assim, o acoplamento de tecnologia define a interoperabilidade que o serviço irá oferecer.