Este documento discute a Arquitetura Orientada a Serviços (SOA) e sua aplicação em organizações. Ele define SOA, explora os modelos de serviços dentro e fora da organização, e discute como a arquitetura de serviços pode evoluir para um modelo de nuvem. O documento fornece exemplos de como SOA pode ser implementada para melhorar a reutilização, estruturação e qualidade dos sistemas e dados de uma organização.

1. -1334217-899795Service Oriented Architecturena OrganizaçãoHugo Rodrigueshugo.rodrigues@gmail.comJaneiro 2010 <br />Índice<br /> TOC quot;
1-3quot;
Índice PAGEREF _Toc252358414 2<br />Introdução PAGEREF _Toc252358415 3<br />O que é Service Oriented Architecture? PAGEREF _Toc252358416 4<br />Definição de SOA PAGEREF _Toc252358417 4<br />SOA na organização PAGEREF _Toc252358418 5<br />Arquitecturas PAGEREF _Toc252358419 5<br />Serviços da Organização PAGEREF _Toc252358420 7<br />Modelos na Organização PAGEREF _Toc252358421 8<br />Business Services PAGEREF _Toc252358422 9<br />Information Services PAGEREF _Toc252358423 9<br />Information System Services PAGEREF _Toc252358424 10<br />Serviços fora da Organização PAGEREF _Toc252358425 11<br />Arquitectura para serviços fora da Organização PAGEREF _Toc252358426 11<br />Evolução para o Modelo Cloud PAGEREF _Toc252358427 13<br />Resumo SOA PAGEREF _Toc252358428 16<br />Requisitos para implementação PAGEREF _Toc252358429 16<br />Desvantagens PAGEREF _Toc252358430 16<br />Vantagens PAGEREF _Toc252358431 16<br />Exemplo - Implementação Gestão de Viagens PAGEREF _Toc252358432 17<br />Objectivos PAGEREF _Toc252358433 17<br />Arquitectura de Processos PAGEREF _Toc252358434 17<br />Arquitectura Informação PAGEREF _Toc252358435 19<br />Arquitectura Aplicacional PAGEREF _Toc252358436 19<br />Arquitectura Tecnológica PAGEREF _Toc252358437 20<br />Conclusão do Projecto PAGEREF _Toc252358438 21<br />Bibliografia PAGEREF _Toc252358439 22<br />Introdução<br />Com a evolução das formas de comunicação, ocorreu também uma enorme evolução na forma como as organizações lidam com a informação.<br />O ritmo de mudança, cada vez mais rápido, e a necessidade de se manterem permanente actualizadas tem originado uma forte pressão na forma como se seleccionam e implementam os sistemas de informação.<br />Esta pressão, imposta pelo contexto envolvente das organizações, ao mesmo tempo que garante a sua sobrevivência e competitividade impõe o ritmo dos investimentos nos sistemas de informação ao nível aplicacional e tecnológico. A evolução da própria organização é um factor acelerador. A mudança na estratégia ao nível de gestão de topo impõe a implementação de novos sistemas de informações mais adequados aos novos objectivos da organização.<br />É por isso comum a existência de várias aplicações que se encontram distribuídas geograficamente por vários locais e até organizacionalmente por vários departamentos.<br />A maioria das aplicações funciona com esquemas de dados próprio, adequado às características da sua função, como por exemplo: Aplicações de Gestão de Identidade: Funcionários, Fornecedores, Clientes; Aplicações de Suporte à actividade: Assiduidade, Vencimentos, Despesas; Aplicações de Gestão de Compras: Aquisições, Manutenções, Procurement; Aplicações de Gestão de Vendas: Portfolio de produtos, Registos de encomendas, Controlo financeiro; etc.<br />A maturidade da informação produzida e retida nas organizações considera-se pois um dos seus mais valiosos activos.<br />É por isso importante analisar os sistemas implementados numa organização para se poderem conhecer e avaliar as “ilhas de informação”. <br />O que é Service Oriented Architecture?<br />O foco na gestão da informação de uma organização é hoje um dos factores cruciais para a sobrevivência das organizações.<br />Desde as pequenas e médias empresas até às multinacionais, encontra-se na base de funcionamento de todas as organizações sistemas de informação. Dados os requisitos de funcionamento mais exigentes dos tempos modernos, os sistemas de informação são na sua grande maioria suportados por sistemas informáticos e comunicações.<br />A envolvência de um espectro elevado de tecnologias originou várias abordagens, conceitos e metodologias por parte dos fabricantes ao nível da gestão de informação.<br />Como premissa base, para se gerir a informação, é necessário que esta se possa disponibilizar para a organização. E a forma de a disponibilizar pode ser enquadrada numa perspectiva de serviços prestados para a própria organização.<br />Para se implementarem serviços é necessário ter em conta as seguintes áreas: integração de aplicações (EAI), Workflow (WF) e Interoperabilidade entre organizações (B2B).<br />É neste contexto que surge a Arquitectura Orientada a Serviços, ou Service Oriented Architecture (SOA).<br />Definição de SOA<br />De todas as definições, aquela que parece ser mais consensual, é a definição conceptual, independente do fornecedor ser de S.I. ou de T.I.<br />“SOA é uma arquitectura centrada na noção de que os activos (assets) dos SI numa organização são descritos e expostos como Serviços. Estes Serviços podem ser compostos e orquestrados em Processos de Negócio, permitindo agilizar os mesmos, e lidar com a sua dinâmica” <br />SOA na organização<br />Na prática não se trata apenas de tecnologia, SOA é a arquitectura da organização desenhada e pensada numa óptica de serviços, e está por isso relacionado com processos, informação, tecnologia e aplicações da organização.<br />Arquitectura: Design, Contexto, Utilidade, Dados, Semântica, utilizadores e sistemas;<br />Serviços: Conjunto de funcionalidades disponibilizadas pela organização para suporte aos processos de negócio.<br />A decisão de implementação de SOA como uma arquitectura organizacional terá como pressuposto o apoio da gestão de topo da organização. Este pressuposto resulta do impacto que ocorrerá na própria organização pela sua implementação.<br />Arquitectura<br />O conceito de Arquitectura é encontrado na captura e formalização de uma descrição que sirva como um veículo para documentação, visualização, análise, manipulação e evolução de uma organização e dos seus sistemas e serviços. <br />O desenho de arquitecturas orientadas a serviços requer uma visão abstracta da organização em si. <br />O nível de abstracção tem de ser elevado ao nível dos conceitos de negócio da organização, considerando a arquitectura de sistemas de informação da empresa como um todo e não em visões fragmentadas de aplicações.<br />Do ponto de vista da modelação, o desafio que se procura ultrapassar é poder-se caracterizar e construir sistematicamente as abstracções importantes de operação, serviço e processo na organização:<br />Figura SEQ Figura ARABIC 1: Decoupling applications and technology through services <br />Existe outra perspectiva da arquitectura, que pode também ser vista como um modelo conceptual válido. Neste modelo apresenta-se uma perspectiva de Providers de serviços e Consumers de serviços, que confluem num layer de negócio onde se definem os processos e serviços da organização:<br />Figura 2: Three Architectural Perspectives<br />A chave para esta arquitectura é de que o consumidor de um serviço não deve estar interessado nos detalhes de implementação do serviço, mas apenas no serviço que lhe é prestado.<br />Serviços da Organização<br />É considerado um serviço o encapsulamento de uma função de negócio reutilizável da organização.<br />Os serviços são definidos explicitamente, de forma pública através de interfaces, e são independentes da sua implementação. Alterações que possam ocorrer dentro de cada serviço serão por isso invisíveis para os consumidores. Cada serviço é instanciado num único sítio e invocado remotamente nesse sítio por todas as aplicações que o usam.<br />Os serviços são fracamente interligados. Para serem utilizados é necessário que sejam invocados através de protocolos de comunicação independentes da localização e da tecnologia que os suportam. Não existe herança ou dependências fortes entre serviços.<br />Modelos na Organização<br />A Arquitectura de Sistemas de Informação numa organização é uma abordagem metodológica que garante o Alinhamento entre o negócio e as tecnologias de informação que o suporta.<br />A Arquitectura de Sistemas de Informação assenta na representação das diferentes arquitecturas que a compõem e que são: A Arquitectura Organizacional, a Arquitectura de Processos, também referida de Arquitectura de Negócio, a Arquitectura de Informação, a Arquitectura de Aplicações e a Arquitectura Tecnológica.<br />Todas estas Arquitecturas deverão estar, a cada momento no tempo, devidamente alinhadas entre si e alinhadas com a estratégia da Organização.<br />Os modelos na organização darão lugar à Arquitectura de Serviços.<br />Que Serviços têm quee devem existir?Que aplicaçõesImplementam e usam que Serviços? Em que Tecnologias seimplementam os Serviços? Que Serviçospara a gestão daInformação ?<br />Figura 3: Arquitectura e serviços estruturados<br />Business Services <br />Na arquitectura de processos é possível identificar os Business Services. <br />Um Business Service é uma sequência de interacções com sistemas de informação que se repete em vários processos.<br />O seu objectivo é Identificar sub-processos com alto nível de reutilização.<br />Figura 4: EXEMPLO DE Business SERVICES<br />São exemplo de Business Services fragmentos de processos formados por sequência de actividades automáticas<br />Information Services <br />Na arquitectura da Informação é possível identificar os Information Services. <br />Os Information Service identificam e agregam as actividades necessárias para assegurar a coerência da informação e podem envolver workflows de actualização da informação dispersa pelas aplicações.<br />Identificação dos serviços de gestão das entidades com alto padrão de reutilização<br />Garantem a coerência da informação, através da abstracção/ocultação dos diferentes sistemas onde reside a informação<br />Figura 5: EXEMPLO DE INFORMATION SERVICES<br />Information System Services<br />Na arquitectura de Sistemas de Informação é possível identificar os Information System Services. <br />Identificam-se nestes serviços aqueles que são úteis para o suporte de outros sistemas ou aplicações, dos Information Services e dos Business Services.<br />Consistem nas aplicações e na tecnologia que suportam os sistemas de informação.<br />Através da reutilização, permitem alcançar uma optimização ao nível das infra-estruturas na organização. <br />Figura 6: Exemplo de Information system services<br />Serviços fora da Organização<br />Conceptualmente, SOA pode ser um veículo poderoso para entregar valor de negócio real para as aplicações da organização.<br />Uma abordagem leve e ágil que utilize as técnicas correctas e os estilos de arquitectura emergentes permitem implementar soluções de SOA de forma adequada para interacções além das fronteiras da organização.<br />Figura SEQ Figura ARABIC 7: Ambiente externo das organizações<br />Alguns dos exemplos de serviços que se podem encontrar no mercado, de forma exterior à organização são:<br />Procurement (gestão de catálogos de produtos);<br />Logística (tracking encomendas);<br />Controlo de Operações (Instalação de serviços);<br />Brokers Electrónicos (Factura Electrónica);<br />Arquitectura para serviços fora da Organização<br />Apenas depois de se implementar uma arquitectura orientada a serviços na organização é que é possível externalizar actividades de uma forma consistente e sustentável.<br />A arquitectura de Enterprise Service Bus poderá ser adequada ao espectro interno da organização:<br />Figura SEQ Figura ARABIC 8: Enterprise Service Bus na organização<br />Tendo em conta este modelo de arquitectura como referência de implementação, existe a possibilidade de o mesmo modelo ser utilizado na entidade com a qual se poderão pretender utilizar ou disponibilizar serviços.<br />Para ser possível a integração com outra entidade é necessária uma evolução conceptual do modelo para um nível federativo:<br />Figura SEQ Figura ARABIC 9: Modelo Federativo DE ENTERPRISE Service Bus<br />Trata-se de uma evolução do grau de abstracção da implementação de SOA, a qual possibilita que cada organização efectue a gestão do seu Service Bus de forma invisível para as restantes entidades.<br />O modelo federativo adiciona um conjunto de regras a serem respeitadas entre as organizações e garante a publicação de todos os serviços disponibilizados num repositório comum. Possibilita também a manutenção dos serviços e a identificação de problemas no decorrer da sua utilização acreditando a sua utilização por ambas as partes.<br /> <br />Evolução para o Modelo Cloud <br />O aparecimento de modelos de computação na nuvem introduz um novo paradigma na forma de como se desenvolvem actualmente os sistemas de informação. O modelo de implementação de SOA na organização passará a ter também em conta os aspectos específicos dos modelos de serviços Cloud. <br />A influência do modelo Cloud não se reduz apenas à capacidade dos serviços de alojamento Web numa Cloud da organização, numa Cloud pública ou privada. <br />Este modelo distingue-se do modelo federativo por se tratar de uma relação de vários Providers para vários Consumers. Acrescenta por isso um conjunto de serviços mais abrangente do que o modelo de ESB, introduzindo o Internet Service Bus.<br />Teremos desta forma uma evolução dos modelos SOA para modelos Cloud, onde na prática coexistirão de forma complementar, ou híbrida, ambos os conceitos em função dos serviços, das aplicações, e das infra-estruturas:<br />Figura 10: evolução para Modelo cloud<br />Existem serviços específicos em SOA de componentes de infra-estrutura que podem ser directamente activadas em ambientes Cloud, como um complemento às tecnologias clássicas de implementação do sistema em si:<br />Cloud-based service bus – Poderá ser adequado a uma organização que pretenda alojar o seu ESB numa infra-estrutura Cloud. Este conceito simplifica a adopção à arquitectura orientada a serviços, por não ser necessário a organização investir em sistemas como: routing de mensagens, transformação e orquestração.<br />Cloud-based security services – É uma solução que possibilita um nível de interoperabilidade entre serviços e aplicações de autenticação, de gestão de identidade e autorização ao nível da Cloud, ou seja de forma centralizada.<br />Cloud-based storage services – Serviço na Cloud que disponibiliza espaço para armazenamento de dados, facilitando a implementação de soluções centralizadas que tenham necessidade de transferir entre si elevados volumes de dados. <br />São actualmente exemplos de serviços com estas características: Amazon S3 e Microsoft Azure DB.<br />Resumo SOA<br />Requisitos para implementação<br />Para se poder efectuar uma implementação adequada de SOA numa organização é necessário ter em conta os seguintes aspectos:<br />Identificação dos actores e processos de negócio;<br />Identificação da residência da informação;<br />Definição de serviços úteis à organização;<br />Definição de interfaces aplicacionais para disponibilização e utilização de serviços.<br />Desvantagens<br />Principais desvantagens de SOA são:<br />Alteração dos processos de negócio da organização;<br />Complexidade na implementação em grande escala;<br />Compatibilidade de sistemas Legacy;<br />Baixo nível de reutilização.<br />Vantagens<br />A implementação de SOA pode trazer benefícios para as organizações: <br />Promover a reutilização (TI/SI) ao longo de toda a organização<br />Estruturar TI/SI dentro de um Departamento, promovendo a eficiência dentro do mesmo<br />Estruturar uma Aplicação, tornando-as mais fácil de suportar mudanças nos processos de Negócio das organizações<br />Classificar e Promover qualidade e coerência dos dados<br />Exemplo - Implementação Gestão de Viagens<br />Objectivos<br />Efectuar a integração dos sistemas de informação necessários para a implementação de uma funcionalidade de Gestão de Viagens “self-service”.<br />Este processo incluiu as seguintes funcionalidades: <br />Gestão de Reservas;<br />Gestão de Adiantamentos;<br />Pagamento de Ajudas de Custos aos Colaboradores;<br />Pagamento a Fornecedores.<br />Utilizando uma perspectiva SOA, foi possível apresentar e implementar um modelo que considerava os objectivos traçados com sucesso.<br /> A abordagem passou pela definição de arquitecturas de processos, de informação, de aplicações e tecnológica, e respectiva implementação recorrendo a serviços de consultoria, fornecimento de equipamentos e software.<br />Arquitectura de Processos <br />Para se desenhar uma solução que correspondesse aos objectivos traçados, iniciou-se um estudo dos processos correntes, chamado de AS-IS, que espelhasse a forma como se fazia.<br />Figura 11 Diagrama de processos As-Is<br />A definição do processo identificou as entidades e os sistemas utilizados. Constatou-se que o processo era manual e sobrecarregava o Colaborador com demasiadas actividades.<br />Efectuou-se um redesenho do processo de forma a automatizar as actividades e a implementar um nível de autorização com a entidade Chefia, de forma a possibilitar a aprovação da viagem.<br />Figura 12: DIAGRAMA DE PROCESSOS To-Be<br />Arquitectura Informação <br />Com a definição dos fluxos de informação, identificaram-se os serviços de gestão de entidades informacionais envolvidos na solução para se obter um elevado padrão de reutilização e também coerência na informação.<br />Esta arquitectura permitiu definir que serviços deveriam ser expostos garantindo a ocultação dos vários sistemas envolvidos.<br />Foram igualmente definidos os workflows de actualização de informação trocada entre as entidades.<br />Figura 13: Arquitectura Informação<br />Arquitectura Aplicacional<br />Mapeando as necessidades ao nível da arquitectura de informação, foi possível identificar as necessidades ao nível das aplicações.<br />Foi definida uma arquitectura aplicacional, na qual cada aplicação tem um papel na disponibilização, orquestração e utilização de dados. Uma vez que o Grupo PT já possuía uma implementação SAP, a arquitectura focou-se na criação de um módulo adicional integrado com o sistema existente. Para a gestão da informação com as entidades Bancos e Fornecedores, foi necessário o desenvolvimento de novas aplicações específicas.<br />SAP Enterprise Portal 6.0Aplicação de interacção entre a empresa e os colaboradoresESS Registo da reservas de viagem Registo da solicitação de adiantamentos para a viagemMSS Aprovação/rejeição da reserva de viagens e de solicitações de adiantamentos, pela chefiamySAP R3 – FI-TVERP da PT PRO, possui a aplicação de Gestão de Viagens Gestão em backoffice de viagens (desde a sua reserva, passando pela sua realização e pagamentos a fornecedores e a colaboradores)SAP BWSistema de Gestão de Informação (DW) Relatórios de controlo, de estatísticas e com indicadores; Alimentação diária de dados de SAP/R3 para o BWAplicação WebAplicação Web de comunicação entre as empresas e o banco Envio de ficheiros txt com movimentos bancários a realizar sobre as contas do colaborador (pag salários, pag de adiantamentos)SAP WFO Workflow SAP integra e automatiza tarefas de negócio que ainda não estão implementados em SAPWebServicesServiços que permitem a comunicação entre a PT PRO e as entidades externas<br />Figura 14: Arquitectura Aplicacional<br />Arquitectura Tecnológica <br />Com base nas necessidades ao nível da arquitectura aplicacional, foi necessário modificar a arquitectura tecnológica.<br />Neste nível foi necessário ter em consideração os aspectos de segurança física, sendo por isso necessário implementar níveis de segurança: DMZ Pública, DMZ Interna e MZ, em conformidade com a sensibilidade dos dados e serviços a serem expostos para a internet, para a organização e apenas para as aplicações.<br />DMZ PúblicaZona de acesso ao público que aceita tráfego proveniente da internet.Servidor de resolução de nomes para os domínios do Grupo PT e repositório dos webservices disponibilizados.MZZona de acesso restrito onde se situa o CORE das infraestruturas centrais. Servidores SAP e Directório de utilizadoresDMZ InternaZona de acesso exclusivo para a rede local. Servidor SAP Application server para disponibilização do Portal do Colaborador (SAP Portal)<br />Figura 15: Arquitectura tecnológica<br />Conclusão do Projecto<br />A implementação deste projecto segundo uma abordagem SOA trouxe várias vantagens para a organização:<br />Este projecto permitiu automatizar o processo de reservas e pagamento de custos de viagens no Grupo PT;<br />Permitiu a redução de custos de transacção;<br />Permitiu reduzir custos operacionais;<br />Permitiu a uniformização dos processos da organização.<br />Desta forma os colaboradores reduziram o tempo dedicado à gestão de viagens de dias para apenas alguns minutos, rentabilizando o seu horário de trabalho.<br />Bibliografia<br />Pesquisas principais de referência ao trabalho: <br />http://www.microsoft.com/soa/default.aspx<br />Consideration for Agile Systems, MS Journal<br />http://www.adobe.com/enterprise/pdfs/Services_Oriented_Architecture_from_Adobe.pdf<br />http://www.oracle.com/technology/tech/soa/pdf/soa-suite-wp.pdf<br />http://www.ibm.com/developerworks/views/webservices/standards.jsp<br />http://h71028.www7.hp.com/enterprise/w1/en/technologies/soa-overview.html<br />http://www.sap.com/platform/soa/index.epx<br />Roy Thomas Fielding’s PH.D, http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm<br />Service-Oriented Architecture Overview and Guide to SOA Research, Gartner 2008<br />Pesquisa generalizada de suporte ao trabalho:<br />www.google.com<br />www.wikipedia.com<br />