(Em Portuguese Do Brasil) Henrique Shoiti Fugita-SOA-CAMPUS - GRUPO ELSEVIER (2011)

SOA SO A Modelagem, Análise e Design

Preencha a ficha de cadastro no final deste livro E receba gratuitamente informações sobre os lançamentos e as promoções da Elsevier. Consulte também nosso catálogo completo, últimos lançamentos e serviços exclusivos no site www.elsevier.com.br

Preencha a ficha de cadastro no final deste livro E receba gratuitamente informações sobre os lançamentos e as promoções da Elsevier. Consulte também nosso catálogo completo, últimos lançamentos e serviços exclusivos no site www.elsevier.com.br

SOA Modelagem, Análise e Design

Henrique Shoiti Fugita Kechi Hirama

2012

© 2012, Elsevier Editora Ltda. Todos os direitos reservados e protegidos pela Lei n° 9.610, de 19/02/1998. Nenhuma parte deste livro, sem autorização prévia por escrito da editora, poderá ser reproduzida ou transmitida sejam quais forem os meios empregados: eletrônicos, mecânicos, fotográficos, gravação ou quaisquer outros. Copidesque: Ana Paula Bezerra Preparação: Pamela Andrade Revisão: Lara Alves Editoração Eletrônica: Thomson Digital

Elsevier Editora Ltda. Conhecimento sem Fronteiras Rua Sete de Setembro, 111 – 16° andar 20050-006 – Centro – Rio de Janeiro – RJ – Brasil Rua Quintana, 753 – 8° andar 04569-011 – Brooklin – São Paulo – SP Serviço de Atendimento ao Cliente 0800-0265340 [email protected] ISBN: 978-85-352-5340-5 Nota: Muito zelo e técnica foram empregados na edição desta obra. No entanto, podem ocorrer erros de digitação, impressão ou dúvida conceitual. Em qualquer das hipóteses, solicitamos a comunicação ao nosso Serviço de Atendimento ao Cliente, para que possamos esclarecer ou encaminhar a questão. Nem a editora nem o autor assumem qualquer responsabilidade por eventuais danos ou perdas a pessoas ou bens originados do uso desta publicação.

CIP-BRASIL. CATALOGAÇÃO-NA-FONTE SINDICATO NACIONAL DOS EDITORES DE LIVROS, RJ F969s Fugita, Henrique Shoiti SOA : modelagem, análise e design / Henrique Shoiti Fugita, Kechi Hirama. - Rio de Janeiro : Elsevier, 2012. Apêndices Inclui bibliografia e índice Contém glossário ISBN 978-85-352-5340-5 1. Arquitetura de computador. 2. Tecnologia da informação. 3. Software - Desenvolvimento. 4. Projeto de sistemas. I. Hirama, Kechi. I. Título. 12-2643. CDD: 004.22 CDU: 004.2

Agradecimentos

Agradeço à minha esposa, a meus pais e irmãos pelo apoio incondicional. Henrique Shoiti Fugita

Agradeço aos meus pais (in memoriam), filhos, irmãos, cunhados e sobrinhos pelas alegrias vividas. Kechi Hirama

v

Prefácio

O cenário de aplicações de software tem evoluído muito nos últimos anos, acompanhando a crescente necessidade de novas aplicações e de manutenção de soluções existentes. Porém, isso tem exigido novas abordagens de desenvolvimento de software, deixando os paradigmas tradicionais, como a orientação a objetos, insuficientes em entregar soluções adequadas no contexto atual. O que se observa claramente é que cada vez mais o software precisa ser concebido em alto nível de abstração para dar conta de inúmeros requisitos que devem ser atendidos. Se observarmos também a evolução do software juntamente com as abordagens de seu desenvolvimento, poderemos verificar que, no início, nas décadas de 1960 e 1970, o software era apenas uma ferramenta para apoiar alguma rotina de atividade do dia a dia, por exemplo, emissão de relatórios. Visto apenas como uma ferramenta, o software estava desacoplado de uma visão mais ampla da organização. E, assim, progressivamente foi sendo desenvolvido e se proliferando, gerando altos custos de manutenção. Os paradigmas de desenvolvimento de software, notadamente a estruturada e orientação a objetos, surgiram para disciplinar e minimizar seus impactos na organização, ao longo de seu ciclo de vida. Porém, a distância entre as necessidades da organização, ou de negócio, ainda mais exigentes, e as soluções propostas se tornavam maiores. Isto levou à discussão de novas abordagens de desenvolvimento de software. Atualmente fala-se muito em necessidade de alinhamento da Tecnologia da Informação (TI) com as estratégias de negócio, e o paradigma de orientação a serviços tornou-se a forma mais adequada e aceita para esse alinhamento, preservando investimentos através de reuso de aplicações de software. Este livro trata basicamente de tornar esse alinhamento mais simples e produtivo. Para isso, adotou-se uma forma didática para abordar o assunto, desde a conceituação básica de serviço até a sua implementação como um software. O livro traz como tema central a modelagem, a análise e o design, provendo um caminho completo desde a modelagem de negócio até a especificação de serviços, complementado por construção, implantação e gerenciamento de serviços. Esse caminho é um diferencial deste livro em relação às outras publicações semelhantes. Além disso, como o paradigma de orientação a serviços carece de uma padronização, pensamos em prover uma maneira bem embasada e enriquecida de ilustrações para que um leitor, mesmo não experiente em orientação a serviços, possa acompanhar os conceitos e exemplos do livro.

vii

viii

Prefácio

A modelagem, a análise e o design são frutos de diversas pesquisas acumuladas em engenharia de software e, mais especificamente, pesquisas que foram feitas ao longo de três anos em orientação a serviços até resultar em uma dissertação de mestrado e dois artigos publicados, sendo um deles publicado em evento nos Estados Unidos (Fugita e Hirama, 2008a e 2008b).

PÚBLICO-ALVO Este livro é destinado a estudantes de graduação dos cursos de Engenharia de Computação, Ciência de Computação, Tecnologia de Informação, Sistemas de Informação e outros cursos similares. Para os docentes destes cursos, o livro pode ser usado para aulas teóricas e práticas aproveitando os exemplos ou adaptando os casos desenvolvidos. Outro público que também pode se beneficiar do livro é constituído de gerentes e desenvolvedores de software de empresas de software, que estão realizando projetos com Arquitetura Orientada a Serviços (SOA – Service Oriented Architecture ).

ORGANIZAÇÃO DO LIVRO Este livro está organizado em oito capítulos, mais referências, apêndices e glossário. O Capítulo 1, Introdução , apresenta uma contextualização da modelagem, da análise e do design, e perguntas mais frequentes. No Capítulo 2, Entendendo SOA , é feita uma caracterização do conceito de SOA, necessária para o bom entendimento das fases de modelagem, análise e design. O Capítulo 3, Ciclo de vida SOA, apresenta boas práticas em modelagem, análise e design e uma descrição de ciclo de vida e papéis e artefatos envolvidos. O Capítulo 4, Modelagem , apresenta as atividades de modelagem de processo as-is e to-be e especificação de requisitos de serviços. O Capítulo 5, Análise, apresenta as atividades de identificação de serviços candidatos, análise de gap e análise de realização de serviços. O Capítulo 6, Design , apresenta a especificação de contrato, especificação de realização, verificação dos princípios e revisão dos serviços. O Capítulo 7, Fases complementares , apresenta uma descrição complementar do ciclo de vida SOA para as fases de construção e de implantação e gerenciamento de serviços. O Capítulo 8, Considerações finais , apresenta algumas considerações quanto aos aspectos importantes do livro. Na seção Referências, são apresentadas as referências usadas para a elaboração do livro. Na seção Bibliografia complementar , são apresentadas fontes de leitura interessantes àqueles que queiram se aprofundar no assunto tratado no livro.

Prefácio

ix

Na seção Apêndice, são apresentados o Apêndice A – os elementos gráficos usados no livro, e o Apêndice B – um estudo de caso referente a uma instituição bancária, em que as fases descritas no livro podem ser acompanhadas. Na seção Glossário , é apresentada uma lista de termos que são familiares ao assunto do livro.

RECOMENDAÇÕES AO LEITOR O livro está organizado de maneira a atender aos diversos tipos de leitores. No entanto, a leitura ficará mais acessível àqueles que tenham noções de orientação a objetos e que tenham alguma familiaridade com o processo de desenvolvimento de software. Aos iniciantes, recomendamos fortemente a leitura desde o início, sem alternar os capítulos. Àqueles que já dominam os conceitos básicos de orientação a serviços, pode-se iniciar pelo Capítulo 3, no qual o ciclo de vida SOA é descrito. À medida que os conceitos estejam bem assimilados, o estudo de caso do Apêndice B pode ser usado para orientar um projeto real de software orientado a serviços em que você esteja envolvido.

1

Introdução Objetivo O objetivo deste capítulo é apresentar uma visão geral sobre o novo paradigma de desenvolvimento de software baseado no conceito de SOA (Service Oriented Architecture) para atender às demandas atuais de novas soluções de forma flexível e com reuso de capacidades de sistemas existentes. Além disso, algumas perguntas mais frequentes da área são respondidas. A TI (Tecnologia da Informação) é a área mais impactante na vida das pessoas e das organizações. O sucesso e o bem-estar de todos dependem das soluções providas pela TI. Então, conhecê-la é importante para estarmos preparados para as novas necessidades que surgem a cada dia. Velhos conceitos e técnicas podem não ser suficientes em face deste cenário. No estágio atual, o paradigma de orientação a serviços traz muitos benefícios e desafios.

Conteúdo 1.1 Visão geral 1.2 Perguntas mais frequentes

1 4

1.1 VISÃO GERAL Atualmente, cada vez mais as empresas pertencentes às diversas áreas fazem uso da TI para conduzir seus negócios. Por outro lado, devido ao avanço da Internet e das tecnologias de integração e comunicação, é comum as organizações fazerem uso do meio eletrônico para realizar seus negócios com clientes, fornecedores e parceiros. As empresas vêm empregando com mais frequência sistemas de TI no suporte aos seus processos de negócio, com o intuito de automatizar atividades e aumentar a produtividade. As empresas utilizam sistemas de TI como ERP ( Enterprise Resource Planning) para controlar sua operação, CRM ( Customer Relationship Management ) para gerenciar informações sobre o relacionamento com seus clientes, SCM ( Sup ply Chain Management) para gerenciar interações com parceiros, fornecedores e consumidores. Dentro desta infraestrutura de TI, cada sistema possui um conjunto de dados e informações próprio. Devido ao fato de os processos de negócio envolverem diversas áreas da organização, eles passam a demandar funções de mais de um sistema e tornam necessária a troca de informações entre estes sistemas. 1

2

SOA: Modelagem, Análise e Design

Principalmente nas organizações de maior porte, esses sistemas de TI constituem ambientes extremamente complexos e heterogêneos, onde as aplicações geralmente fazem uso de diferentes tecnologias, linguagens e protocolos. É comum encontrar em um mesmo ambiente aplicações desenvolvidas com tecnologia Web, softwares de prateleira (COTS – Commercial Off-The-Shelf), proprietários e aplicações legadas em mainframes . Para suportar a comunicação entre elas, são utilizados adaptadores, conectores e middlewares de integração. Os negócios têm se tornado mais dinâmicos, exigindo mais agilidade por parte das organizações e, consequentemente, de suas áreas de TI. É necessário que os sistemas sejam capazes de se adaptar rapidamente às necessidades de negócio, em constante mudança. No entanto, em um ambiente de TI heterogêneo este tipo de mudança é difícil de realizar. Dentro desse cenário, vem se desenvolvendo e sendo aceito o conceito de Arquitetura Orientada a Serviços (SOA). O modelo de referência do OASIS (OASIS, 2006) define SOA como um paradigma para organizar e utilizar competências distribuídas entre vários domínios. Trata-se de um modo de estruturar as aplicações de software em elementos chamados serviços. Com SOA, os sistemas podem ser vistos de forma mais próxima ao negócio da organização. Isto facilita o modo como os sistemas são desenvolvidos e mantidos. A linguagem passa a ser menos técnica, sendo o termo “serviço” a ponte entre os processos de negócio e as funções do sistema de software. Para se trabalhar com SOA não bastam ter conceitos, boas práticas e ferramentas, mas estes devem ser orientados por métodos que permitam atender eficazmente às necessidades da organização. Por outro lado, seguindo os fundamentos de Engenharia de Software, para se desenvolver um serviço, antes de tudo, deve-se fazer uma análise de o quê realmente se pretende automatizar no âmbito do negócio. Assim, para se projetar aplicações que efetivamente sigam o paradigma de orientação a serviços, e para que elas realmente façam uso dos benefícios trazidos pelo paradigma, é necessário haver uma atenção especial na identificação e especificação dos serviços que as compõem. Os serviços que apoiarão os processos de negócio e atenderão aos seus requisitos devem ser definidos de forma adequada, para que apresentem atributos como reusabilidade e flexibilidade e estejam alinhados com as metas de negócio. Além disso, os serviços devem ser especificados de modo a fazer parte de um repositório de serviços reusáveis, que possam ser orquestrados (compostos) em sistemas para apoiar os processos de negócio. Assim, é necessário haver alguma abordagem para, a partir dos requisitos e metas de negócio, identificar e modelar processos relevantes que façam uso de serviços disponíveis na infraestrutura de TI ou de novos serviços a serem desenvolvidos. No caso de novos serviços, esta abordagem deve ser feita por meio de atividades para especificá-los de modo que eles possam ser implementados utilizando técnicas existentes e consolidadas. Tal abordagem deve ser previsível e repetível, conduzindo de maneira consistente as atividades de análise e especificação. De preferência, esse método deve fazer uso

1 Introdução

3

de ferramentas e notações amplamente conhecidas para a modelagem e representação das informações e para a geração de artefatos. Assim, a adoção desta abordagem seria facilitada e traria menos impactos aos processos de desenvolvimento já existentes na organização. Portanto, o objetivo deste livro é apresentar a modelagem, a análise e o design de aplicações orientadas a serviços. Tem como propósito disciplinar o procedimento de identificação, análise e especificação de um conjunto de serviços alinhados aos requisitos de negócio e aderentes aos princípios de orientação a serviços. A aplicação destas atividades tem como resultado um grupo de especificações de serviços, que pode ser então implementado utilizando-se técnicas de desenvolvimento convencionais. Tem como atividades a modelagem de negócio, na forma de casos de uso ou modelos de processo de negócio, passando pela identificação e especificação dos serviços que compõem a solução, e tem como produto final os artefatos que compõem a especificação de cada serviço, incluindo sua interface, suas operações e mensagens, e seus requisitos funcionais e não funcionais. Considerando-se o ciclo de vida dos processos de negócio e o ciclo de vida dos sistemas como dois processos distintos, geram-se especificações de serviços a partir dos processos de negócio modelados. Os serviços seriam os elementos responsáveis por realizar a ligação entre negócio e TI, por possuírem características de elementos desenvolvidos pela TI para prover funções de negócio. Há alguns poucos estudos na área de metodologias de desenvolvimento voltados para SOA. Papazoglou e Van Den Heuvel (2006) descrevem as atividades do ciclo de vida dos serviços, que consiste num processo cíclico e iterativo, que passa por modelagem de processos, análise, design, implementação e execução e monitoria. Papazoglou e Van Den Heuvel utilizam a tecnologia de Web Services para especificar e implementar os serviços. A empresa IBM (2007) possui uma contribuição, que é um plugin a ser aplicado ao RUP ( Rational Unified Process ) para o desenvolvimento de aplicações orientadas a serviços. Este plugin acrescenta uma série de tarefas, papéis e artefatos ao RUP, de modo a adaptá-lo para projetos de aplicações orientadas a serviços. Erl (2005), por sua vez, descreve um método de análise e design de serviços baseado nos princípios da orientação a serviços. Marks e Bell (2006) também propõem um método de desenvolvimento de serviços, focando nas etapas de análise e design. Ainda não existe uma convergência das diversas propostas de métodos em direção a uma padronização, o que deixa o terreno aberto para discussão e apresentação de novas propostas (Ramollari, Dranidis e Simons, 2007). A modelagem, a análise e o design apresentados aqui contêm atividades, papéis e artefatos definidos. Além da descrição das atividades, são apresentados exemplos que auxiliam na sua aplicação. As atividades são apoiadas em ciclo de vida orientado a serviços similar ao de um ciclo de vida de software. Assim, as atividades são inspiradas nas disciplinas de um ciclo de vida de software como o RUP, ou seja, modelagem de negócio, requisitos, análise & design, implementação, testes e implantação. Para isso,

4


adotou-se um ciclo de vida SOA, conforme descrito no Capítulo 3. As atividades de modelagem, análise e design estão embutidas neste ciclo e usam o termo “fase”, que engloba um conjunto de atividades em vez de “disciplina”. As atividades podem ser aplicadas de forma iterativa como no RUP. É importante destacarmos por que modelagem, análise e design são tão importantes em SOA. No ciclo de vida de uma solução orientada a serviços, tudo começa na modelagem de negócio, seja na forma de processos ou mesmo em casos de uso. Modelagem de processos, modelagem de casos de uso e elicitação de requisitos são áreas amplamente exploradas na literatura. Já existem diversas abordagens e técnicas desenvolvidas, mas certas particularidades devem ser consideradas no contexto do ciclo de vida SOA. O mesmo vale para implementação, testes e implantação. No caso de testes, ela requer novas abordagens e técnicas. Atualmente, já existem diversas tecnologias (Web Services , REST, SCA) que orientam a implementação de serviços e ferramentas que tratam da complexidade destas tecnologias. Plataformas e ferramentas atuais permitem, a partir de um contrato formal de serviço, gerar automaticamente um “esqueleto” de código fonte, resumindo a implementação de um serviço à “clássica” codificação da lógica de negócio, podendo ser empregadas técnicas amplamente conhecidas. Diante disso, pode-se dizer que modelar processos e casos de uso é conhecido. O mesmo pode-se dizer também quanto a como implementar serviços a partir de especificações. Porém, resta um “gap” a ser resolvido, que pode ser resumido na seguinte questão: “Como um modelo de negócio deve ser definido e como, a partir dele, chegar a um conjunto de especificações de serviços coeso que seja aderente aos princípios da orientação a serviços?” A resposta está nas fases de modelagem, análise e design, que devem levar em conta que uma solução orientada a serviços exige considerações específicas. Por este motivo, este livro foca nestas fases, apresentando a modelagem, a análise e o design de serviços que partem de um modelo de negócios e entrega como resultado um conjunto de especificações de serviços.

1.2 PERGUNTAS MAIS FREQUENTES O que é Serviço?

É um mecanismo que possibilita o acesso a uma ou mais capacidades de um sistema, onde este acesso é fornecido usando uma interface definida e exercitada de acordo com restrições e políticas, conforme especificado pela descrição do serviço (OASIS, 2006). O que é Orientação a Serviços?

É um paradigma de desenvolvimento de sistemas de software que permite o acesso a diversas informações disponíveis em computadores ligados na Internet (Sommerville, 2011).

1 Introdução

O que é Arquitetura Orientada a Serviços (SOA – tecture)?

5

Service Oriented Archi-

É um paradigma para organizar e usar competências distribuídas que podem estar sob controle de domínios diferentes (OASIS, 2006). O que é ciclo de vida de software?

É o período de tempo que inicia quando um produto de software é concebido e termina quando o software não é mais disponível para o uso. O ciclo de vida de software tipicamente inclui as fases de concepção, requisitos, design, implementação, teste, instalação e verificação, operação e manutenção e, algumas vezes, retirada de operação (IEEE, 1994). Qual é a diferença entre serviço e objeto de software?

Tanto o serviço como o objeto tem propósitos semelhantes. Ambos podem ser acionados para obter dados. Ambos podem ser integrados para compor uma função ou sistema de software. O que difere um do outro é a sua abrangência. O serviço está mais próximo das necessidades de negócio e lida com sistemas de grande porte. O serviço pode ser implementado por objetos ou componentes de software (OASIS, 2006). Qual é a diferença entre SOA e

Web Services ?

SOA é um estilo arquitetural em que sistemas consistem de usuários e provedores de serviços, e Web Services é uma tecnologia que pode ser usada para implementar SOA (Bianco, Kotermanski e Merson, 2007).

2

Entendendo SOA Objetivo O objetivo deste capítulo é apresentar uma visão geral sobre SOA, as suas características e a visão de alguns autores importantes. São apresentados alguns princípios, solução e benefícios e desafios para trabalhar com este paradigma. Também é apresentada a relação do SOA com outras abordagens. Para falar sobre o paradigma de orientação a serviços, é necessário um entendimento claro do que é SOA e do próprio conceito de serviço em si. Por ser um tema novo que tem ganhado relevância recentemente, não existe ainda um consenso definitivo sobre tais conceitos. Por meio da análise das características do paradigma e das interpretações de alguns autores, este capítulo busca estabelecer um entendimento sobre sua definição.

Conteúdo 2.1 2.2 2.3 2.4 2.5 2.6 2.7

Definições Conceitos relacionados a SOA Princípios de orientação a serviços Solução orientada a serviços Benefícios e desafios Relação com outros paradigmas Considerações do capítulo

7 17 22 25 35 39 40

2.1 DEFINIÇÕES Antes de discutirmos a definição de SOA, ou Arquitetura Orientada a Serviços, é necessário compreender o que é a orientação a serviços . Basicamente, a orientação a serviços é um paradigma de construção e integração de soluções de software compostas por elementos modulares chamados serviços. O paradigma baseia-se nos princípios de orientação a serviços, que serão descritos nas próximas seções (Erl, 2007).

2.1.1 O que é um serviço? A palavra serviço pode ser definida como a execução de um trabalho ou realização de uma função de um prestador para um requisitante. No contexto específico de arquitetura de software, o conceito de serviço está ligado à capacidade de um sistema 7

8


executar uma função para outro. No contexto de SOA, um serviço tem significado semelhante, já que consiste em um módulo de software capaz de realizar uma função específica quando solicitado por seus consumidores. O serviço, unidade fundamental de uma arquitetura SOA, é uma unidade de software que tem como propósito desempenhar uma função específica e que pode ser fornecido por um provedor e utilizado por um consumidor. Para ser considerado um serviço, servi ço, uma unidade de software deve apresentar características de design aderentes aderente s ao paradigma de orientação a serviços. Um exemplo de serviço é o controle de crédito disponibilizado por uma entidade do tipo SERASA e SPC. Ela pode fornecer informações sobre crédito de pessoas físicas e jurídicas a clientes do tipo bancos. Os bancos podem implementar aplicações de concessões de crédito somente chamando o serviço para receber estas informações. Um serviço é composto por diversas operações. Fazendo uma analogia com a orientação a objetos, as operações estão para um serviço assim como os métodos estão para uma classe. Um exemplo de serviço com suas operações e respectivas entradas (inputs ) e saídas (outputs) pode ser visto na Figura 2.1. 2.1.

Figura 2.1 Serviço “Funcionário” com suas operações.

2 Entendendo SOA

9

As operações são s ão invocadas por meio de mensagens. Um cliente envia uma mensagem como parâmetro de entrada para uma operação, a fim de invocá-la. O serviço (por meio de seu provedor/realização) executa a lógica definida em seu contrato e retorna ao cliente uma mensagem de saída com o resultado da lógica executada. Assim, um processo de negócio é um agregado de diversos serviços, conforme pode ser visto na Figura 2.2. 2.2. As instâncias de um processo executam uma série de operações. Um serviço é composto de um conjunto de operações relacionadas. Uma operação processa os dados recebidos. re cebidos. As mensagens são responsáveis por conduzir os dados necessários de (e para) operações. Observação:

Alguns autores utilizam o termo “competência” ou “capacidade” para se referir ao conceito de operação.

O conceito de serviço é adequado para representar transações que a área de TI (Tecnologia (T ecnologia da Informação) oferece ofe rece para seus clientes e usuários usuár ios de negócio. Serviço é um conceito facilmente compreendido pela perspectiva de TI e pela de negócio, além de possuir a granularidade apropriada para ser mapeado para atividades automatizadas de um processo de negócio (Marks e Bell, 2005). Devido à sua natureza, os serviços estabelecem um termo comum às linguagens de negócio e de TI, podendo, assim, facilitar a comunicação e o alinhamento entre a área de TI e os usuários/clientes de negócio durante a análise e o design de serviços. Por ser a unidade fundamental de análise do SOA e por possuir correspondência

componentes de uma arquitetura SOA (Erl, 2005). 2005). Figura 2.2 Relacionamentos entre os componentes

10


direta com o conceito de processo de negócio, o serviço possibilita uma melhoria na identificação de requisitos de negócio e promove o alinhamento entre as áreas de negócio e de TI.

2.1.2 SOA: estilo arquitetural e arquitetura a rquitetura Já o termo SOA pode ser definido como um estilo arquitetural de software que se baseia no paradigma de orientação a serviços. Segundo esta definição, SOA é um estilo arquitetural que suporta o paradigma de orientação a serviços. Estilo arquitetural é definido como a combinação de características distintas sobre a qual uma arquitetura é realizada ou expressada. Comumente, utiliza-se também o termo arquitetura SOA para designar uma arquitetura de software que segue o estilo arquitetural SOA SOA.. Dessa maneira, uma arquitetura SOA possibilita a obtenção de uma infraestrutura infraestrutur a para computação distribuída, por meio de serviços que podem ser fornecidos e consumidos dentro de uma organização e entre organizações, por meio de redes de comunicação como a Internet, conforme pode ser visto na Figura 2.3. 2.3. Para que essa infraestrutura funcione, f uncione, se existem provedores e clientes de serviços, devee haver uma maneira padronizada para que estes se conheçam. Uma arquitetura dev SOA é caracterizada pelas interações entre três tipos de agentes de software: os provedores provedo res de serviço, os consumidores (ou clientes) de serviço e o registro de serviço s erviço (Huhns e Singh, 2005). As interações entre estes agentes podem ser visualizadas na Figura 2.4. 2.4.

Figura 2.3 Infraestrutura geral criada para fornecimento e consumo de serviços.

2 Entendendo SOA

11

Figura 2.4 Agentes de uma arquitetura SOA (Papazoglou, 2003).

Assim, os serviços são oferecidos pelos provedores de serviço, agentes responsáveis por desenvolver suas implementações, fornecer suas descrições e prestar suporte técnico e de negócio. De modo geral, os provedores disponibilizam módulos de software (as implementações dos serviços) que podem ser acessados através de uma rede e que publicam suas descrições em um registro de serviços – agente que abriga informações sobre as funções oferecidas, os requisitos para se utilizar o serviço e orientações sobre como realizar a interação com o provedor de serviço. É o registro de serviços que torna estas informações disponíveis para serem consultadas por consumidores em potencial. Por sua vez, os consumidores de serviço são os agentes que necessitam solicitar a execução de um serviço. Os consumidores buscam nos registros a descrição de um serviço que satisfaça às suas necessidades e, ao encontrá-la, utilizam esta descrição para ligar-se ao provedor e realizar a invocação do serviço. Note que os papéis de provedor e consumidor são lógicos, de modo que um mesmo agente pode exibir características de ambos dependendo do contexto (Papazoglou, 2003). Desse modo, uma arquitetura SOA funciona como, por exemplo, uma biblioteca virtual. Alguém (provedor) anuncia que possui determinados livros. Estas informações são catalogadas em uma estante virtual (registro). Um leitor (cliente) procura por um livro fornecendo os seus dados ao registrador. Ao encontrar o livro procurado, descobre que alguém (provedor) possui este livro e se conecta ao provedor para obter o seu conteúdo.

2.1.3 Anatomia de um serviço A Figura 2.5 apresenta a estrutura que compõe um serviço. Um serviço é composto por um contrato e uma realização , ou seja, geralmente, um serviço consiste em uma função de negócio desempenhada por um módulo de software (a realização) que é descrito e encapsulado por um contrato bem definido,

12


Figura 2.5 Anatomia de um serviço.

através do qual o consumidor utiliza este serviço. Assim, os consumidores do serviço não têm acesso aos detalhes de como ele foi construído, mas apenas aos detalhes expostos em seu contrato. O contrato define as funções desempenhadas pelo serviço e eventuais pré-condições para utilizá-lo, mas não revela como estas funções são realizadas. Esta forma de encapsulamento é conhecida como caixa-preta, e é um princípio característico de paradigmas como orientação a objetos e componentização de software. Porém, diferentemente destes, serviços representam funções completas de negócio e são projetados de modo a serem utilizados não somente no âmbito de um programa ou sistema, mas no âmbito da organização ou até entre organizações (Papazoglou, 2003). O contrato de serviço é complementado por uma descrição independente de tecnologia, definindo funcionalidade, propósito, modo de utilização e restrições. As descrições são geralmente armazenadas e disponibilizadas nos repositórios de metadados. A interface de serviço é a definição técnica do contrato. A interface normalmente é representada com o uso de uma linguagem formal, de preferência baseada em padrões abertos. A interface contém as assinaturas das operações do serviço, com seus parâmetros de entrada, de saída e exceções.

2 Entendendo SOA

13

Os esquemas de mensagens descrevem o modelo e o formato dos dados utilizados como entrada e saída das operações definidas na interface do serviço. As políticas definem os requisitos não funcionais do serviço e restrições de uso. Já os SLAs (Service Level Agreements ), ou acordos de nível de serviço, especificam os níveis de desempenho, disponibilidade e capacidade oferecidos pelo provedor aos consumidores do serviço. A realização é a parte que efetivamente executa a funcionalidade definida pelo contrato de serviço. Pelo fato de não ser acessada diretamente pelo cliente (este tem conhecimento apenas de sua interface), a realização pode sofrer modificações de manutenção e evolução, sem que o impacto seja percebido pelo cliente. Uma realização pode ser inclusive substituída sem que ocorra tal impacto. Isto se dá devido ao desacoplamento proporcionado pela interface. Para executar a funcionalidade do serviço, a realização combina lógica e dados. A lógica corresponde às regras de negócio envolvidas na funcionalidade dos serviços e que são executadas pela realização. A lógica, por sua vez, manipula dados, que podem ser fornecidos pelos consumidores (nas mensagens de entrada) ou ser provenientes de aplicações de back-end , como bases de dados e aplicações legadas.

2.1.4 Arquitetura de referência No contexto de SOA, uma arquitetura de referência é um framework abstrato que permite o entendimento das entidades e relacionamentos significativos entre eles em um ambiente orientado a serviços e para o desenvolvimento de arquiteturas concretas ou de referência, usando padrões ou especificações consistentes que apoiam este ambiente. Tal arquitetura de referência é baseada em conceitos unificados de SOA e pode ser usada por arquitetos que estejam desenvolvendo arquiteturas específicas orientadas a serviços ou treinando ou explicando SOA. A arquitetura de referência não está diretamente associada a quaisquer padrões, tecnologias ou outros detalhes concretos de implementação (The Open Group, 2009). O Open Group é uma organização mundial que desenvolve padrões da área de TI, que produziu uma definição do que é SOA (The Open Group, 2006) e também uma arquitetura de referência para o estilo arquitetural SOA. Conforme a Figura 2.6, segundo a arquitetura de referência, uma arquitetura SOA pode ser interpretada por uma hierarquia com diversos níveis de abstração. Segundo esta hierarquia, uma arquitetura SOA pode ser dividida em diversas camadas, cada qual com sua função e relacionamentos com outras camadas. A arquitetura de referência é composta por nove camadas, sendo divididas em cinco camadas funcionais que representam os elementos de uma solução orientada a serviços (representadas pelas camadas horizontais: sistemas operacionais, componentes de serviço, serviços, processos de negócio e interfaces consumidoras) e quatro camadas não funcionais que representam aspectos transversais que se aplicam a todas as camadas funcionais (representadas pelas camadas verticais: integração, qualidade de serviço, informação e governança).

14


Figura 2.6 Arquitetura de referência SOA (The Open Group, 2009).

A camada de sistemas operacionais representa a infraestrutura de TI existente, composta por sistemas e aplicações não orientadas a serviços. De modo geral, esta camada fornece recursos que podem ser reusados por provedores de serviços para implementar contratos de serviços. Nesta camada estão: aplicações orientadas a objetos (implementadas, por exemplo, em Java e Microsoft .NET); aplicações implementadas com tecnologias legadas (como cliente-servidor e alta plataforma); sistemas transacionais; bases de dados; aplicações-pacote (como ERPs e CRMs). A camada de componentes de serviço contém componentes de software que proveem as realizações dos serviços, implementando as definições dos contratos e servindo como ponte para os sistemas operacionais. Um componente de serviço pode realizar sozinho um contrato de serviço, ou pode encapsular o acesso a uma aplicação legada (localizada na camada de sistemas operacionais) reusada para realizar o contrato. Nesta camada, podemos ter: componentes implementados em plataforma compatível com tecnologias de implementação de serviços (por exemplo, plataformas Java e .NET que suportam Web Services ); ●

●

● ● ●

●

2 Entendendo SOA

●

15

mediações que encapsulam o acesso a um sistema operacional e o disponibiliza por uma interface de serviço.

A camada de serviços representa todos os serviços definidos em uma arquitetura SOA e contém os contratos dos serviços e os metadados que os descrevem. É esta a camada que provê a interface entre provedores e consumidores de serviço, pois fornece uma abstração dos contratos publicados pelos provedores que podem ser descobertos pelos consumidores e possibilita a interação entre eles. A camada de processos de negócio contém a lógica de negócio, que é realizada por meio de processos de negócio. Os processos de negócio, por sua vez, podem ser realizados por serviços compostos que orquestram a execução de outros serviços ou por plataformas BPMS ( Business Process Management Systems ) que executam fluxos de processo. Esta camada é responsável por gerenciar e executar os fluxos de trabalho de cada processo de negócio e possibilitar a participação de pessoas na execução de tarefas humanas. A camada de interfaces consumidoras representa os canais através dos quais a funcionalidade dos serviços e processos de negócio é disponibilizada para os usuários finais. Esta camada contém interfaces e aplicações de front-end , como: plataformas de portal e mashups; formulários eletrônicos; aplicações Web; aplicativos desktop; aplicativos móveis.

● ● ● ● ●

Através das interfaces consumidoras, os usuários poderão: ● ● ● ● ●

iniciar instâncias de processos de negócio; executar tarefas humanas dos processos de negócio; acompanhar o andamento de uma instância de processo de negócio; invocar operações de serviços; executar casos de uso que envolvem tarefas de processos e operações de serviços.

A camada de integração é fundamental para uma arquitetura SOA, pois é a que possibilita a comunicação entre os elementos nas cinco camadas funcionais (provedores e consumidores de serviços). Esta camada contém componentes capazes de executar funções de mediação, como roteamento de mensagens, transformação de formato de dados e conversão de protocolos de comunicação. A camada de qualidade de serviço é a responsável por assegurar aderência a políticas, SLAs e requisitos não funcionais definidos nos contratos de serviços. E contém ferramentas e agentes que permitem a monitoração dos serviços e a captura de métricas e eventos. Por meio destes, a camada de qualidade de serviço provê desempenho, confiabilidade, disponibilidade, escalabilidade e segurança às camadas funcionais da arquitetura de referência. A camada de informação representa a arquitetura de informação da organização, provendo aos usuários e gestores do processo acesso e análise dos dados dos processos

16


de negócio e serviços. Nesta camada, atuam tecnologias de business intelligence , monitoração e análise de dados de processo. A camada de governança tem o objetivo de garantir que os serviços e elementos das demais camadas funcionais sejam aderentes aos padrões, modelos e orientações da organização. Esta camada provê o gerenciamento do ciclo de vida dos serviços e pontos de controle para verificação de conformidade com os padrões.

2.1.5 Tecnologias de implementação Para implementar uma arquitetura SOA, diversas plataformas tecnológicas podem ser utilizadas. Uma das mais difundidas para implementação de serviços é a tecnologia Web Services . A tecnologia Web Services consiste em um conjunto de padrões abertos que possibilita a comunicação entre duas aplicações através da Web. Por ser baseada em padrões abertos, que são amplamente aceitos e suportados por entidades internacionais como o OMG ( Object Management Group ) e a W3C (World Wide Web Consortium), a tecnologia Web Services promove a interoperabilidade, pois permite a interação entre aplicações desenvolvidas em diferentes linguagens de programação, plataformas de middleware e sistemas operacionais. Um Web Service pode ser definido como um componente de software que possui uma interface separada de sua implementação, expondo para seus consumidores somente sua interface e abstraindo detalhes de implementação. Um cliente se comunica com um Web Service para fazer invocações através de troca de mensagens, definidas em sua interface, conforme a Figura 2.7. A tecnologia Web Services é fundamentada na linguagem XML ( eXtensible Markup Language ) (Bray et al., 2006), utilizada para a representação dos dados e como base para os outros padrões. Os padrões fundamentais da tecnologia Web Services são: ●

●

WSDL (Web Service Definition Language ) – linguagem baseada em XML para definição formal de interfaces de serviços; SOAP (Simple Object Access Protocol ) – protocolo de comunicação baseado na troca de mensagens em formato XML transmitidas via HTTP ou outros protocolos;

Figura 2.7

Web Service (Erl, 2007).

2 Entendendo SOA

●

17

UDDI (Universal Description, Discovery and Integration ) – especificação de registro de serviços publicados e descoberta de interfaces de serviços em WSDL.

Além dos padrões fundamentais, uma série de outros padrões foram definidos com o objetivo de prover qualidade de serviço às interações com Web Services : ● ●

●

●

●

●

●

WS-Policy – padrão para definição formal de políticas de serviços; WS-Security – permite a aplicação de mecanismos de segurança a mensagens SOAP, como autenticação, assinatura digital e criptografia; WS-AtomicTransaction – padrão que possibilita a coordenação de transações distribuídas envolvendo Web Services ; WS-ReliableMessaging – protocolo para assegurar a entrega de mensagens SOAP com tolerância a falhas de comunicação; WS-Notification – possibilita implementar soluções orientadas a eventos, através da notificação de eventos entre Web Services ; WS-Addressing – padrão para a especificação de dados de endereços físicos de Web Services para roteamento de mensagens SOAP; WS-I Profiles – orientações definidas pela organização WS-I (Web Services Interoperability ) com o intuito de garantir a interoperabilidade entre Web Services implementados em diversas plataformas.

Apesar de ser comum a implementação de serviços através do uso de Web Services, é importante ressaltar que uma arquitetura SOA não se limita a um ambiente de computação distribuída utilizando Web Services , mas também deve seguir os princípios de orientação a serviços (veja mais detalhes na Seção 2.3). Além da tecnologia Web Services, vem ganhando espaço o uso da tecnologia REST ( REpresentational State Transfer ) na implementação de serviços. Serviços implementados na tecnologia REST são chamados de serviços RESTful ( RESTful services ou RESTful web services). Apesar de ser considerada uma tecnologia mais simples do que Web Services para implementação de serviços, ainda não há um consenso sobre como se realizar completamente os princípios de orientação a serviços utilizando as tecnologias relacionadas ao REST.

2.2 CONCEITOS RELACIONADOS A SOA Nesta seção, são descritos alguns conceitos importantes relacionados ao paradigma de orientação a serviços: a granularidade de serviço, as camadas de serviços, as composições de serviços e o portfólio de serviços.

2.2.1 Granularidade de serviço Granularidade é um aspecto importante para se determinar o escopo de um serviço. Ao se identificar um serviço, deve-se determinar se ele possuirá baixa granularidade (serviço técnico ou de baixo nível) ou alta granularidade (serviço de negócio ou de alto nível). A granularidade depende de quanta funcionalidade é encapsulada por

18


um serviço, sendo que, quanto mais funcionalidade, mais abrangente é o escopo do serviço e mais alta é sua granularidade. Serviços de granularidade mais alta são utilizados diretamente pelo negócio e podem ser formados pela composição de serviços de granularidade mais baixa. Segundo a interpretação da empresa IBM (Bieberstein et al., 2005), os dois tipos de serviços são necessários. Uma arquitetura SOA deve conter serviços diretamente relacionados e com alto valor para o negócio e serviços técnicos que encapsulam lógica com alto potencial de reuso. Os serviços de granularidade mais alta terão menos consumidores, mas agregarão mais valor para o negócio. Eles terão também alta dependência em relação a serviços de granularidade baixa, que, por sua vez, terão alto potencial de reuso e terão baixa dependência com outros serviços. Já Marks e Bell (2006) afirmam que serviços devem possuir alta granularidade e representar funções, processos e transações de negócio, encapsulando demais componentes de baixa granularidade. Segundo estes autores, serviços de baixa granularidade, como componentes de software, teriam pouca utilidade direta para o negócio. Por isso, eles não compensariam o overhead (custos adicionais) de se transformar em um serviço e deveriam ser encapsulados por serviços maiores.

2.2.2 Camadas de serviço O paradigma de orientação a serviços pode trazer uma abstração entre a lógica de negócio e a infraestrutura de TI, gerando um desacoplamento entre os processos de negócios e a arquitetura de sistemas de informação. De acordo com a arquitetura de referência, em uma arquitetura SOA, a camada de serviços dá suporte tecnológico aos processos de negócio de uma organização, e localiza-se exatamente entre a camada de processos de negócio e a infraestrutura de aplicações de TI, representada pelas camadas de componentes de serviço e de sistemas operacionais (Erl, 2005). A camada de serviços cria uma abstração entre os requisitos do negócio e as soluções providas pela TI (Bieberstein et al., 2005), conforme mostra a Figura 2.8. Baseado no princípio de composição e no Design Pattern Service Layers (Camadas de Serviços) (Erl, 2009), é possível dividir a camada de serviços em mais três subcamadas de abstração que determinam o tipo e a granularidade dos serviços. Assim, temos: a subcamada de serviços de tarefa, a subcamada de serviços de entidade e a subcamada de serviços utilitários. Na Figura 2.9, pode ser visualizada a hierarquia das subcamadas de serviços. Os serviços utilitários possuem menor granularidade e representam os serviços de infraestrutura de uma arquitetura SOA, oferecendo funções específicas de tecnologia. O propósito dos serviços utilitários é prover funções reusáveis e processar dados contidos em sistemas legados e novas aplicações desenvolvidas. Serviços utilitários são agnósticos, ou seja, independentes de áreas ou domínios de negócio. Por esse motivo, são reusáveis em diversos processos, podendo ser comuns à organização como um todo. Eles representam serviços de TI, como segurança, auditoria, notificação, transformação de dados, entre outros. Os serviços utilitários proveem a infraestrutura de apoio aos outros serviços.

2 Entendendo SOA

19

Figura 2.8 Camadas de uma arquitetura SOA (Erl, 2005).

Os serviços de entidade proveem acesso às entidades pertencentes ao modelo de dados da organização, por exemplo, cliente, pedido de venda, produto etc. Geralmente suas operações representam funções de acesso a dados, como busca, inserção, atualização e deleção. Serviços de entidade são considerados agnósticos, pois não são vinculados a nenhuma aplicação ou processo específico. Por consequência, possuem alto potencial de reuso, uma vez que proveem funções aplicáveis a diversos contextos. É importante que os serviços de entidade estejam alinhados ao modelo de dados corporativo ou à arquitetura de informação da organização. Os serviços de tarefa representam a lógica contida em uma tarefa de processo de negócio. Geralmente, possuem granularidade mais alta e atuam como controladores de composições de serviços de entidade, utilitários ou outros serviços de tarefa para implementar a lógica de negócio. Os serviços de tarefa refletem eventos relativos aos processos de negócio. A execução de um serviço de tarefa pode ser associada à realização de uma função ou atividade de um processo. Estes serviços possuem alta granularidade e representam conceitos reais de negócio, como abrir nova conta, analisar crédito ou aprovar solicitação. Estes são exemplos de eventos reais que podem ser executados por uma pessoa (um atendente, por exemplo), por um sistema ou por um serviço de tarefa.

20


Figura 2.9 Camadas de serviços (Erl, 2005).

Um tipo específico de serviço de tarefa, os serviços de tarefa orquestrada realizam a ligação entre os processos de negócio e outras camadas de serviço. O conceito de orquestração baseia-se na construção de processos de negócio a partir da composição de diversos serviços, por exemplo, utilizando uma linguagem de orquestração como o WS-BPEL ( Web Services Business Process Execution Language ) (OASIS WS-BPEL TC, 2007). Trata-se de uma linguagem para se especificar o fluxo de trabalho e lógica de negócio envolvidos nas chamadas Web Services . Nesta camada estão os serviços de processo, que possuem alta granularidade e representam processos de negócio completos, encapsulando a lógica de processamento necessária para coordenar a execução de diversos serviços.

2.2.3 Composições de serviços Uma composição de serviços é um conjunto de serviços agregados com o intuito de automatizar uma determinada tarefa complexa ou processo de negócio. Um serviço composto é aquele que possui, pelo menos, uma operação composta, sendo uma operação composta aquela cuja lógica inclui invocações a outras operações de outros serviços. No exemplo da Figura 2.10, o Serviço A é um serviço composto, pois sua Operação A forma uma composição das operações Operação B do Serviço B e Operação C do Serviço C.

2 Entendendo SOA

21

Figura 2.10 Exemplo de composição de serviços (Serviço A composto pelos Serviços B e C).

Inclusive, o princípio de orientação a serviços “Facilidade de Composição” orienta que os serviços devem ser projetados e construídos de forma que possam participar de composições (Erl, 2007).

2.2.4 Portfólio de serviços Um portfólio de serviços consiste em um conjunto de serviços que, de forma coletiva, representam funções lógicas de uma organização ou domínio. Serviços pertencentes a um mesmo portfólio devem formar um conjunto coeso onde as funções de um serviço complementam os demais e todos os serviços seguem os mesmos padrões de design, realização e implementação. Uma organização pode possuir um único portfólio de serviços compartilhados entre todas as áreas, ou pode possuir diversos portfólios de serviços de domínio para cada área (Erl, 2007). Um portfólio de serviços pode ser definido em uma única iniciativa, ou pode ser desenvolvido incrementalmente através de diversos projetos de soluções orientadas a serviços. Na definição “do zero”, o portfólio de aplicações e processos de negócio da organização é analisado de modo a se identificar os serviços. Atividades de modelagem, análise e design orientados a serviços são conduzidas de forma a se obter um portfólio de serviços aderente aos princípios do paradigma de orientação a serviços. Esta abordagem garante um conjunto inicial de serviços coeso e aderente ao paradigma, que pode necessitar modificações conforme os requisitos de negócio sofram mudanças. No entanto, esta abordagem pode mostrar-se inviável em muitos casos por exigir um alto investimento inicial. Na abordagem incremental, a cada projeto de implementação de aplicações ou automação de processos, novos serviços podem ser adicionados ao portfólio, ou serviços já existentes podem ser modificados. É uma abordagem com menor custo inicial, já que o esforço é diluído ao longo dos vários projetos. Não exige a execução de um projeto exclusivo de modelagem, análise e design de serviços. Porém, pode impor um custo adicional relacionado ao impacto de eventuais mudanças em serviços

22


já existentes no portfólio. Pode exigir um esforço de governança e versionamento para gerenciar tais mudanças.

2.3 PRINCÍPIOS DE ORIENTAÇÃO A SERVIÇOS Segundo Erl (2005), o paradigma de orientação a serviços pode ser descrito a partir de uma série de princípios que devem ser seguidos na construção de uma arquitetura: contrato padronizado, reusabilidade, baixo acoplamento, abstração, capacidade de composição, autonomia, independência de estado, visibilidade, capacidade de composição e interoperabilidade. A seguir, estes princípios serão descritos com mais detalhes.

2.3.1 Contrato padronizado Um serviço deve possuir um contrato bem definido que descreva para o mundo externo a funcionalidade por ele exposta e ao mesmo tempo encapsule os detalhes específicos de sua implementação (Marks e Bell, 2006). O contrato representa um acordo formal firmado entre o provedor do serviço e seus consumidores, criando uma relação de dependência. Por isso, deve haver uma atenção especial na manutenção e versionamento destes contratos. O contrato do serviço disponibiliza as seguintes informações aos consumidores: a localização do serviço, as operações executadas, as mensagens de entrada e saída utilizadas pelo serviço e as regras para sua utilização (Erl, 2005). Podem conter também detalhes semânticos (significados) das operações do serviço. Contratos de serviço devem ser representados em uma linguagem ou notação bem definida, seguindo padrões abertos que garantam a interoperabilidade do serviço. Por exemplo, no contexto de Web Services, contratos de serviço são definidos por interfaces de serviço em WSDL (Web Services Description Language ), esquemas de mensagens na linguagem XSD ( XML Schema Definition ) e políticas. Em um documento WSDL, são especificados os tipos de dados envolvidos, as mensagens e as operações do serviço. Já os esquemas XSD são a especificação dos tipos de dados e das mensagens XML que serão utilizadas.

2.3.2 Reusabilidade A orientação a serviços visa tornar cada serviço reusável, mesmo que não haja requisitos específicos para um dado serviço no momento em que ele é desenvolvido (Erl, 2005). Serviços reusáveis são aqueles que podem possuir valor em diversos contextos de processos de negócio e em interações intra e interorganizacionais e, por isso, devem suportar diversos padrões de consumo destes serviços. Devido a esta natureza, novos clientes podem reusar um serviço de uma maneira que não foi prevista em seu projeto original. Nestes casos, deve haver uma infraestrutura de gerenciamento e governança de serviços que garanta o desempenho e o devido funcionamento de tal serviço (Marks e Bell, 2006).

2 Entendendo SOA

23

Os serviços devem ser projetados considerando-se as várias formas de reuso, como transações entre aplicações, composição de serviços e processos de negócio e uso como serviços utilitários. A reusabilidade de um serviço é relacionada à sua granularidade, sendo que, quanto mais alta a granularidade de um serviço menores são as possibilidades de ele ser usado em mais de um processo de negócio. Por exemplo, um serviço de gerenciar contas de clientes possui uma granularidade mais alta do que o serviço cadastrar clientes. As possibilidades de reuso do segundo serviço são maiores do que o primeiro, que pode implementar especificidades de uma organização. Além da granularidade, outro fator que afeta a reusabilidade de um serviço é a lógica que ele executa. Quanto mais agnóstica for a lógica de um serviço, isto é, quanto menos específica ela for com relação a um determinado contexto de aplicação, maior será sua reusabilidade. Caso um serviço possua características específicas de um processo de negócio ou contexto de aplicação, sua utilização em outras situações ou por outros consumidores fica limitada.

2.3.3 Baixo acoplamento Uma característica importante de serviços em uma arquitetura SOA é a de que eles devem possuir baixo acoplamento entre si, ou seja, devem ser fracamente acoplados (baixa dependência). No entanto, na literatura, o termo baixo acoplamento pode possuir vários significados práticos. Um serviço fracamente acoplado pode significar um serviço cuja implementação pode ser substituída, modificada ou evoluída ao longo do tempo sem causar impactos aos consumidores do serviço (Marks e Bell, 2006). Nesse caso, está-se referindo ao acoplamento entre a implementação do serviço e seus Consumidores. Nessa mesma linha, baixo acoplamento pode ser indicado pela transparência de localização. Por exemplo, um serviço pode ser consumido independentemente de onde seu provedor está fisicamente localizado, criando um desacoplamento entre consumidor e provedor (Papazoglou, 2003). De maneira geral, o baixo acoplamento é uma condição em que um serviço está ciente da existência de outros serviços, mas ainda é independente deles (Erl, 2005).

2.3.4 Abstração Um princípio importante na orientação a serviços é a abstração ou encapsulamento da lógica interna de um serviço por meio de sua interface. Ao separar interface de implementação, o serviço age como uma caixa preta e expõe aos seus consumidores somente informações sobre as operações disponíveis. A granularidade de um serviço está diretamente relacionada com a quantidade de funcionalidade que é encapsulada pelas operações de um serviço (Erl, 2005). Quanto mais funcionalidade é encapsulada em um serviço, mais alta a granularidade deste serviço.

24


2.3.5 Autonomia Autonomia exige que a lógica de processamento encapsulada por um serviço fique restrita dentro de certa fronteira estabelecida, o que evita a dependência com relação a outros serviços. Isto permite que um serviço tenha controle total sobre sua própria lógica e possa exercer um tipo de autogovernança (autocontrole). A autonomia de um serviço pode ocorrer em dois níveis diferentes (Erl, 2005): no nível do serviço e autonomia pura. Na autonomia no nível do serviço, os limites entre os serviços são distintos, mas eles ainda podem compartilhar recursos encapsulados, como bases de dados e sistemas legados. Este cenário é comum, por exemplo, em diversos serviços desenvolvidos a partir de uma mesma aplicação já existente. Neste caso, os serviços compartilham a aplicação, mas fazem uso dela de maneira independente. Na autonomia pura, a lógica e os dados encapsulados estão sob completo controle do serviço, não sendo compartilhados com outros.

2.3.6 Independência de estado Um serviço deve evitar armazenar informações de estado e contexto ou minimizar o período de tempo que estas informações serão mantidas (Erl, 2005). Isso quer dizer que a resposta do serviço para uma mensagem deve ser independente das mensagens anteriores processadas pelo serviço. Dependência de contexto ou de estado diminui o potencial de reuso do serviço. Além disso, enquanto o serviço retiver informações de estado de um consumidor, ele se torna indisponível para atender chamadas de outros consumidores. Para tornar um serviço o mais independente possível de estado, as mensagens devem ser inteligentes, isto é, deve ser adicionado às mensagens o máximo de informação para que elas se tornem autossuficientes e possam ser processadas sem a necessidade de dados de estado.

2.3.7 Visibilidade Os serviços devem ser visíveis, o que significa que seus contratos devem ser publicados e disponibilizados de modo que possam ser descobertos e acessados pelos potenciais consumidores. Na arquitetura SOA básica, estas interfaces são publicadas em um registro de serviços, de onde elas podem ser buscadas pelos consumidores (Marks e Bell, 2006).

2.3.8 Capacidade de composição Serviços devem possuir capacidade de composição, isto é, devem ser projetados de forma que possam participar de composições com outros serviços, formando serviços compostos, ou ser orquestrados (compostos) no contexto de um processo de negócio. Para isso, os serviços devem ser os mais desacoplados possíveis e suas operações devem ser as mais atômicas possíveis (Marks e Bell, 2006; Erl, 2005).

2 Entendendo SOA

25

2.3.9 Interoperabilidade Serviços devem ser interoperáveis, isto é, deve ser possível interagir com um serviço independentemente da tecnologia empregada em sua implementação. Quaisquer que sejam a linguagem de programação, a plataforma ou o sistema operacional utilizado na construção dos provedores, clientes e registros de serviços, as interações entre eles devem ser possíveis. Para isso, estas interações devem ser realizadas utilizando-se padrões e protocolos abertos compatíveis com qualquer tecnologia ou plataforma. Por isso, em uma arquitetura SOA, a provisão e o consumo de serviços ocorrem de maneira transparente às tecnologias e linguagens utilizadas em sua implementação, garantindo a interoperabilidade entre serviços. Atualmente, os padrões relacionados à tecnologia Web Services permitem a descrição de interfaces, a troca de mensagens e a busca por serviços de maneira neutra com relação às plataformas e linguagens utilizadas. Observação:

Apesar de não ser considerada por alguns autores um princípio propriamente dito, a interoperabilidade é listada nesta seção, pois descreve uma característica de design que os serviços devem possuir e que é fundamental para o paradigma de orientação a serviços.

2.4 SOLUÇÃO ORIENTADA A SERVIÇOS Em essência, toda solução de software é concebida para realizar algum tipo de automação. No contexto de SOA, uma solução de software orientada a serviços consiste em um conjunto de serviços e composições de serviços que automatizam um processo de negócio. A lógica de um processo de negócio é encapsulada em um serviço de orquestração, que, por sua vez, é composto por outros serviços de tarefa, entidade e utilitários. Além dos serviços em si, uma solução orientada a serviços é composta por elementos que dão suporte à automação do processo de negócio.

2.4.1 Elementos Uma solução orientada a serviços consiste em uma aplicação composta por diversos elementos que, integrados, automatizam um processo de negócio. Os elementos de uma solução orientada a serviços distribuem-se nas camadas da arquitetura de referência SOA, conforme a Figura 2.11. Na camada de interfaces consumidoras, temos as interfaces através das quais os usuários poderão interagir com os processos de negócio e com os serviços da solução orientada a serviços. Na camada de processos de negócio, temos os fluxos de processo sendo orquestrados por uma plataforma BPMS ou por um serviço de tarefa orquestrada, que encapsula a lógica do processo e é composto por outros serviços. Um processo de negócio de lógica complexa pode ser dividido em subprocessos.

26


Figura 2.11 Elementos de uma solução orientada a serviços.

Na camada de serviços, a solução conta com um conjunto de serviços identificados a partir do portfólio para suportar os processos de negócio e interfaces consumidoras. Em uma solução orientada a serviços, pode haver serviços simples e compostos, pertencentes às camadas de serviços de tarefa, de entidade e utilitários. Os serviços são realizados por elementos contidos na camada de componentes de serviço. Para realizar um serviço, podem ser utilizados componentes de serviço desenvolvidos sob medida para implementar seu contrato, ou mediações para possibilitar o reuso de recursos existentes. Na camada de sistemas operacionais, temos os recursos existentes, que podem ser bases de dados ou aplicações legadas acessadas por componentes de serviços e mediações. Nesta camada podem ser incluídos também os provedores de serviços externos (cloud service providers ) da organização.

2.4.2 Ferramentas Ao se implementar uma arquitetura SOA, torna-se necessária uma infraestrutura tecnológica para dar suporte aos diversos tipos de elementos que compõem uma

2 Entendendo SOA

27

solução orientada a serviços e atender aos requisitos de cada camada da arquitetura de referência. As ferramentas utilizadas para suportar cada elemento da solução são: ●

●

●

●

interfaces consumidoras – servidores de aplicação (com suporte a aplicações Web), servidores de portais, ferramentas de desenvolvimento (com suporte a aplicações Web e aplicações de portal); processos de negócio – plataformas BPMS, barramentos de serviços, ferramentas de desenvolvimento (com suporte a modelagem de processos e orquestração de serviços); mediações – barramentos de serviços, adaptadores de integração, ferramentas de desenvolvimento (com suporte a implementação de mediações); componentes de serviços – servidores de aplicação (com suporte a tecnologias de serviços), ferramentas de desenvolvimento (com suporte a implementação de componentes de serviço).

Além das ferramentas que dão suporte aos elementos funcionais de uma solução orientada a serviços, a infraestrutura de TI pode contar com outras ferramentas para atender à arquitetura SOA como um todo: monitores de atividade de negócio (BAM), monitores de serviços, registros de serviços, repositórios de metadados e ferramentas de infraestrutura de aplicações. Servidor de aplicação

O servidor de aplicação é o ambiente de execução responsável por executar os componentes de serviço e alguns tipos de interfaces consumidoras (aplicações Web), conforme pode ser visto na Figura 2.12. Deve suportar tecnologias de implementação de serviços, como Web Services ou REST.

Figura 2.12 Servidor de aplicação.

28


Para abrigar interfaces consumidoras, o servidor de aplicações deve suportar a execução de aplicações Web. Atua nas camadas de serviços, componentes de serviço, sistemas operacionais e interfaces consumidoras. Plataforma BPMS

Uma plataforma BPMS ( Business Process Management System ), ou plataforma de orquestração de processos, é um container capaz de executar processos de negócio definidos na forma de modelos de processo, conforme a Figura 2.13. Uma plataforma BPMS pode suportar a composição de serviços na execução das tarefas do processo. A plataforma pode suportar também a orquestração de tarefas humanas (como os sistemas de workflow), isto é, gerenciar a participação de pessoas na execução de tarefas de um processo de negócio. Atua nas camadas de processo e integração. Barramento de serviços (ESB)

O barramento de serviços, ou ESB ( Enterprise Service Bus), é um middleware que possibilita a comunicação entre vários elementos de uma solução orientada a serviços, conforme pode ser visto na Figura 2.14. O objetivo principal do ESB é permitir a construção de serviços a partir de aplicações legadas, através das mediações. O ESB permite que um ambiente heterogêneo com diversas tecnologias e protocolos de comunicação possam se conectar em uma arquitetura SOA. O barramento pode adicionalmente prover funções como segurança, tolerância a falhas, transações distribuídas, auditoria, acesso unificado a diferentes modos

Figura 2.13 Plataforma BPMS.

2 Entendendo SOA

29

Figura 2.14 Barramento de serviços.

síncronos e assíncronos, escalabilidade, entre outros (Keen et al., 2005). Atua nas camadas de serviço, componente de serviço, integração e qualidade de serviço. Adaptadores de integração

Adaptadores de integração são ferramentas que possibilitam a comunicação com aplicações legadas ou sistemas proprietários por meio de protocolos de comunicação e formatos de dados que não são abertos nem padronizados, conforme a Figura 2.15. Os adaptadores facilitam a construção de serviços a partir de aplicações legadas, pois abstraem a complexidade de se lidar com protocolos e interfaces de programação (APIs – Application Programming Interfaces ) proprietárias. Atua nas camadas de componentes de serviço e integração. Portal

Um portal é um container de aplicações Web baseadas em páginas e aplicativos Web chamados portlets, conforme pode ser visto na Figura 2.16. Sua principal função é prover uma interface entre os usuários e os processos de negócio e serviços. É através do portal que os usuários poderão verificar suas caixas de entrada de tarefas, executar as tarefas humanas de processos, preencher e visualizar formulários, monitorar as métricas e indicadores do processo e acessar aplicações Web que utilizam serviços. Atua na camada de interfaces consumidoras.

30


Figura 2.15 Adaptador de integração.

Figura 2.16 Portal.

2 Entendendo SOA

31

Monitor de atividade de negócio (BAM)

É uma ferramenta responsável por capturar eventos dos processos de negócio e coletar valores de métricas que permitam aos usuários e gestores monitorar em tempo real o desempenho dos processos de negócio, implementando o conceito de BAM – Business Activity Monitoring, conforme a Figura 2.17. Geralmente, os monitores proveem painéis para exibição de métricas e indicadores de desempenho (KPIs – Key Performance Indicators). Podem também fazer uso de tecnologias de Business Intelligence e Data Warehousing para possibilitar a geração de relatórios e a realização de análises baseadas em dados de histórico e predições. Atua na camada de arquitetura de informação. Registro de serviços

Um registro de serviços é uma base de dados que provê informações sobre os serviços em uma arquitetura SOA, conforme a Figura 2.18. O registro de serviços contém informações como: ● ● ● ●

descrições de serviços e suas operações; interfaces de serviços e esquemas de mensagens; especificações de políticas de serviços e SLAs; endereços físicos de serviços.

Figura 2.17 Monitor de atividade de negócio.

32


Figura 2.18 Registro de serviços.

Em implementações de SOA com Web Services , registros de serviços são comumente construídos baseados no padrão UDDI, de modo a funcionar como um catálogo de endereços físicos de serviços. Um barramento de serviços pode consultar um registro de serviços em tempo de execução, para obter os endereços físicos e realizar o roteamento dinâmico de mensagens de serviços. Atua nas camadas de serviços, integração e governança. Repositórios de metadados

Em uma arquitetura SOA, um repositório de metadados é uma base de dados utilizada para armazenar metadados de serviços e artefatos relacionados, conforme a Figura 2.19. Alguns exemplos de metadados e artefatos armazenados por um repositório são: ● ●

versão do serviço; status do ciclo de vida;

Figura 2.19 Repositório de metadados.

2 Entendendo SOA

● ● ● ● ● ●

33

descrições de contratos de serviços; especificações de realização de serviços; especificações de SLA; código fonte; modelos de análise e design; relacionamentos e dependências entre os serviços.

Potenciais consumidores consultam um ou mais repositórios para obter informações sobre serviços, que podem satisfazer suas necessidades, e sobre como acessá-los (o contrato do serviço). Para isso, um repositório pode prover funções de busca de serviços. Alguns registros são capazes de gerenciar o ciclo de vida dos serviços, servindo como ferramenta de governança. Atua nas camadas de serviços e governança. Monitor de atividade de serviços (SAM)

É uma ferramenta responsável por coletar valores de métricas operacionais dos serviços, implementando o conceito de SAM – Service Activity Monitoring , conforme pode ser visto na Figura 2.20. O monitor SAM diferencia-se do monitor BAM por focar em aspectos operacionais dos serviços e ser voltado para administradores de

Figura 2.20 Monitor de atividade de serviços.

34


serviços e operadores, enquanto o BAM é voltado para monitoração de dados de negócio e é destinado a usuários finais dos processos de negócio. O monitor de serviços deve registrar valores de métricas como tempo de resposta de operações, tamanho e quantidade de mensagens, número de mensagens processadas por período de tempo e disponibilidade, exibindo tais dados em painéis para os administradores de serviços. Monitores de serviços proveem mecanismos para assegurar o desempenho dos serviços e o cumprimento de SLAs, possibilitando a geração de alertas e automação de ações corretivas. Além disso, os monitores de serviços podem prover informações sobre o uso dos serviços e da capacidade dos recursos, apoiando a governança dos serviços. Atua nas camadas de qualidade de serviço, arquitetura de informação e governança. Ferramentas de desenvolvimento e testes

A construção de uma solução orientada a serviços, com diferentes tipos de elementos que devem ser integrados, geralmente demanda a utilização de ferramentas específicas. Existem atualmente diferentes ambientes de desenvolvimento integrados (IDEs – Integrated Development Environments ), conforme a Figura 2.21, específicos para implementar e testar: componentes de serviços (com suporte a diferentes linguagens de programação e tecnologias); mediações;

●

●

Figura 2.21 Ferramentas de desenvolvimento e testes.

2 Entendendo SOA

● ● ● ●

35

orquestrações de serviços; aplicações para Web; aplicações de portal; modelos de processos e simulações. Permitem a construção e testes de elementos em todas as camadas funcionais.

Ferramentas de infraestrutura de aplicações

Uma arquitetura SOA pode fazer uso de algumas ferramentas para gerenciar a infraestrutura de serviços, provendo desempenho, escalabilidade, confiabilidade e disponibilidade. Alguns exemplos de tais ferramentas são: ● ● ● ●

ambientes de grid computing; soluções de gerenciamento de carga (workload management ); soluções de virtualização; soluções de computação em nuvem (cloud computing ). Atuam nas camadas de integração e qualidade de serviço.

2.5 BENEFÍCIOS E DESAFIOS Uma vez entendido o conceito de SOA, pode-se pensar sobre quais resultados podem ser obtidos por uma organização ao adotar o paradigma de orientação a serviços. Implementar e manter uma arquitetura SOA dentro de uma organização é uma tarefa custosa, que exige tempo, recursos e esforço, além de promover mudanças no comportamento e na cultura da organização. Os resultados de uma arquitetura SOA devem ser tangíveis e devem compensar o investimento realizado. Dessa maneira, são discutidos os benefícios e possíveis desafios que podem ser trazidos pela adoção do paradigma de orientação a serviços nas organizações.

2.5.1 Facilidade de integração Uma arquitetura SOA é baseada em serviços intrinsecamente interoperáveis (Erl, 2005). Devido ao uso de padrões abertos de interação, aplicações estruturadas na forma de serviços possuem uma capacidade inerente de se comunicarem de maneira interoperável. É como se as aplicações orientadas a serviços já nascessem pré-integradas, minimizando o esforço de se desenvolver integrações entre aplicações. A estrutura de serviços tende a facilitar a integração de aplicações, uma vez que uma arquitetura SOA é uma maneira de se reorganizar uma infraestrutura formada de silos de software em um portfólio de serviços compartilhados. Em uma arquitetura SOA, as aplicações existentes e futuras podem acessar os serviços sem a necessidade de se desenvolver integrações ponto a ponto baseadas em protocolos proprietários. Assim, esta arquitetura pode ser utilizada em ambientes com múltiplas aplicações baseadas em variadas tecnologias e plataformas que necessitam se comunicar. Para efetuar transações entre elas, pode-se conectar e reusar serviços com esforço mínimo de programação e integração (Papazoglou, 2003).

36


Marks e Bell (2006) chegam até a chamar esse benefício de integração de custo zero. Tal afirmação baseia-se no fato de que não é necessário nenhum esforço para realizar a conversão entre protocolos e formatos, para se estabelecer a comunicação entre aplicações em uma arquitetura SOA, uma vez que elas já estariam baseadas nos mesmos padrões abertos de interação.

2.5.2 Padronização de tecnologias Como parte da implementação da arquitetura SOA em uma organização, é desenvolvida toda uma infraestrutura de comunicações para viabilizar as interações inter e intra-aplicações seguindo os princípios de orientação a serviços. Esta infraestrutura de comunicação de serviços passa a fazer parte da infraestrutura de TI e torna-se o padrão de comunicação no âmbito da organização como um todo. Deste modo, a organização deve investir seus recursos focando-se em uma única plataforma tecnológica de comunicação (Erl, 2005). Além disso, se forem utilizados a tecnologia de Web Services e os padrões baseados em XML para a implementação da arquitetura SOA, tem-se a oportunidade de estabelecer o XML como uma plataforma padronizada de representação de dados na organização (Erl, 2005). Tendo-se um formato padrão para representar dados pode reduzir a complexidade do ambiente de aplicações. Dessa maneira, estabelecem-se os documentos XML como o padrão para troca de informações e os esquemas XML como o padrão para representação das entidades de dados. A padronização traz seus benefícios para a organização, mas sua implementação torna-se um desafio importante para as organizações ao adotar o conceito de SOA (Erl, 2005). É necessário garantir que os esquemas definidos nos vários projetos sigam as mesmas diretrizes e padrões e formem um modelo de dados organizacional, ou corre-se o risco de obter uma arquitetura não flexível e acoplada a aplicações existentes.

2.5.3 Maior reuso de recursos A orientação a serviços prega que os serviços sejam especificados de forma que possam suportar o reuso de maneira inerente. O projeto de aplicações voltadas para o reuso permite um reaproveitamento imediato de lógica pré-existente, bem como cria oportunidades futuras de reuso por potenciais clientes (Erl, 2005). A longo prazo, o reuso de serviços tende a reduzir custos, prazos e esforço para implementação de soluções (Bieberstein et al., 2005). Apesar de o projeto de serviços reusáveis exigir um esforço adicional (se comparado ao esforço de se desenvolver um serviço sem suporte a reuso), tal investimento é recompensado quando futuras aplicações desenvolvidas reaproveitarem as funções existentes. Marks e Bell (2006) estimam como algo em torno de 50% o esforço adicional para tornar um serviço reusável. Portanto, o ROI ( Return on Investment ) é obtido no primeiro reuso do serviço, se considerarmos que o reuso representa uma economia do custo de se desenvolver o serviço a partir do zero (Marks e Bell, 2006).

2 Entendendo SOA

37

O uso de Web Services permite também encapsular funções de ambientes legados de forma que estes possam fazer parte de uma arquitetura SOA. Isso permite a interoperabilidade de sistemas legados sem a necessidade de integrações ponto a ponto, que são custosas e inflexíveis. Assim, reduz-se o custo de se integrar legados e novas aplicações e torna-se possível que as novas aplicações reusem funções existentes no legado dentro do contexto de orientação a serviços. Com a possibilidade de se reusar sistemas legados, a necessidade de se substituí-los passa a não ser tão imediata (Erl, 2005).

2.5.4 Agilidade no negócio A orientação a serviços promove flexibilidade nas soluções construídas, uma vez que são constituídas por serviços fracamente acoplados, sendo, portanto, preparadas para mudanças. O projeto de serviços com baixo acoplamento e a possibilidade de realizar composições entre eles torna a arquitetura SOA um ambiente mais adaptativo. A estruturação dos serviços em camadas de negócio e de tecnologia também gera flexibilidade, pois permite que ambos os domínios evoluam e sofram alterações de maneira isolada (Erl, 2005). A orientação a serviços pressupõe que as aplicações construídas tendem a evoluir com o tempo, conforme os requisitos de negócio se alterem ou novos surjam. Em uma arquitetura SOA bem estruturada, o impacto desta evolução é minimizado, uma vez que propriedades como reuso e interoperabilidade permitam que a área de TI responda mais rapidamente às solicitações da área de negócio. Isso promove a agilidade organizacional, que permite à organização responder prontamente aos eventos do ambiente, reduzir o time-to-market de seus produtos e serviços e obter vantagem competitiva. Não somente o tempo para se ter uma solução pronta é diminuído como também o custo e o esforço (Erl, 2005). Desse modo, a orientação a serviços busca responder aos requisitos de negócio em prazos mais curtos e oferecer soluções mais flexíveis. As mudanças, que costumam ser custosas e danosas em ambientes não flexíveis, passam a ser facilitadas (Bieberstein et al., 2005). Para se atingir tal estado, é necessário que a infraestrutura esteja padronizada e que os serviços efetivamente possuam características de baixo acoplamento, reusabilidade e interoperabilidade.

2.5.5 Alinhamento com o negócio A orientação a serviços promove o alinhamento estratégico entre TI e negócio. Devido ao fato de os serviços representarem conceitos de negócio, o vínculo entre as soluções entregues pela área de TI (os serviços) e as metas estratégicas da organização (tanto de TI como de negócio) torna-se mais claro. Desta maneira, os investimentos destinados a TI são justificados devido a esta percepção do valor agregado (Bieberstein et al., 2005). O serviço pode ser visto também como uma maneira de uniformizar os vocabulários das áreas de negócio e de TI dentro de uma organização. Em uma organização

38


com uma arquitetura SOA, o conceito de serviço pode tornar-se um elemento de ligação entre os profissionais de TI e os usuários/clientes das áreas de negócio. Com um termo comum no vocabulário de ambas as áreas, torna-se possível estabelecer metas de negócio baseadas diretamente no conceito de serviço e tendo em mente os serviços existentes, além de melhorar a comunicação e o entendimento no relacionamento TI-negócio (Marks e Bell, 2006). Quando o paradigma de orientação a serviços é aplicado para dar suporte aos processos de negócio, a noção de atividade de processo pode ser mapeada diretamente à execução de um serviço de negócio orquestrado pelo processo. Com o surgimento de linguagens para especificação e execução de processos de negócio como o WS-BPEL, reduziu-se o gap (à distância) que existia entre os modelos de processos elaborados pelos analistas de negócio e a implementação do fluxo de trabalho desenvolvida pelos profissionais de TI. Quando um modelo de processo é elaborado seguindo a sintaxe do WS-BPEL, o próprio modelo torna-se o código executável que será utilizado na implementação do processo (Erl, 2005).

2.5.6 Requisitos de desempenho Em uma arquitetura SOA com um grande número de serviços interagindo uns com os outros, é esperado um aumento no volume de comunicações baseadas em mensagens. Caso o ambiente de execução destes serviços não esteja preparado para tal demanda, pode começar a haver latência de processamento e degradação do tempo de resposta das operações (Erl, 2005). Como a arquitetura SOA pode ser composta de diversas camadas, com necessidade de processamento nas interações entre elas, é esperado que os requisitos de desempenho tornem-se maiores. Além disso, o processamento e o transporte de dados nos formatos e protocolos da tecnologia Web Services , como XML, XSD e SOAP, tendem a ser custosos para a infraestrutura. Ao adotar o paradigma de orientação a serviços, as organizações devem atentar para tais requisitos de desempenho no momento de dimensionar a infraestrutura necessária para seu ambiente.

2.5.7 Requisitos de segurança Em um ambiente de serviços autônomos disponíveis para quaisquer potenciais consumidores, surge a preocupação com a segurança das operações dos serviços. Alguns tipos de operações mais críticas necessitam meios de garantir que apenas consumidores autorizados possam utilizá-las. Além disso, como a comunicação entre provedores e consumidores de serviços é baseada em mensagens, é preciso assegurar a integridade e confidencialidade de certos tipos de informação (Erl, 2005). Desse modo, é necessário que a infraestrutura e as ferramentas utilizadas na implantação de uma arquitetura SOA possuam mecanismos e tecnologias que atendam a tais requisitos de segurança para serviços. O padrão WS-Security busca solucionar estes requisitos em um ambiente de Web Services.

2 Entendendo SOA

39

2.5.8 Complexidade de análise e design O desenvolvimento de soluções compostas por diversos serviços independentes e desacoplados traz um aumento na complexidade da arquitetura e introduz um número maior de pontos de falha (Bieberstein et al., 2005). Além disso, é preciso assegurar que os serviços desenvolvidos possuam características aderentes aos princípios de orientação a serviços. Sem estas características, pode-se ter como resultado uma arquitetura de serviços que não traz os benefícios esperados, como reuso, facilidade de integração e alinhamento com o negócio. Segundo Papazoglou e Van Den Heuvel (2006), os paradigmas de desenvolvimento existentes, como a orientação a objetos e o desenvolvimento baseado em componentes, não são diretamente aplicáveis a arquiteturas orientadas a serviços e nem baseadas em tecnologia Web Services . Desse modo, fazem-se necessárias técnicas e métodos específicos para análise e design de soluções orientadas a serviços.

2.5.9 Necessidade de governança Com a existência de um portfólio de serviços disponíveis para toda a organização, pode haver diversas equipes de projeto desenvolvendo e utilizando serviços deste portfólio ao mesmo tempo. Um serviço deixa de ser responsabilidade de uma única equipe de projeto e deixa também de pertencer a um único processo de negócio. O paradigma de orientação a serviços exige que seja definida uma estrutura de governança na organização, de modo a estabelecer papéis, responsabilidades, processos para organizar os serviços desenvolvidos (Erl, 2007). A governança define mecanismos para desenvolver, manter e divulgar os serviços do portfólio e garantir a padronização da arquitetura.

2.6 RELAÇÃO COM OUTROS PARADIGMAS O paradigma de orientação a serviços não significa uma ruptura com relação a outros paradigmas de desenvolvimento de software, pois representa uma evolução derivada da orientação a objetos e do desenvolvimento baseado em componentes e pode, inclusive, ser aplicado juntamente com eles. A seguir, é descrita a relação da orientação a serviços com estes outros paradigmas e suas diferenças.

2.6.1 Orientação a objetos Conforme citado anteriormente, o paradigma de orientação a serviços tem como ponto em comum com o paradigma de orientação a objetos o fato de ambas serem maneiras de se construir software com base na separação de assuntos (Erl, 2005). Princípios como abstração, encapsulamento e composição de serviços foram formulados a partir de conceitos de orientação a objetos. Além disso, orientação a objetos é comumente utilizada para implementar a lógica de aplicação encapsulada em um serviço. Entretanto, as duas abordagens possuem algumas diferenças.

40


A orientação a serviços prega a autonomia entre suas unidades (os serviços). Apesar de objetos possuírem rotinas desacopladas e até reusáveis, as classes por definição possuem relacionamentos entre si (agregação, herança), o que gera certo grau de dependência entre os objetos. Além disso, os objetos geralmente são executados utilizando um mesmo conjunto de recursos compartilhados. Na orientação a serviços, muito das informações necessárias para o processamento está contido nas mensagens, de forma que os serviços guardem o mínimo possível de informação de estado. A orientação a serviços encoraja a amarração da lógica de processamento com os dados, mantendo mais informação contida nos objetos e criando uma dependência de estado.

2.6.2 Orientação a componentes Apesar de serem relacionados, os conceitos de componente e de serviço guardam diferenças entre si e não devem ser confundidos. Alguns princípios da orientação a serviço, como a abstração de interface e implementação e a transparência de localização, são oriundos de boas práticas da orientação a componentes. Porém, o serviço difere dos componentes ao não se limitar a uma determinada plataforma, linguagem ou tecnologia de implementação. Alguns autores afirmam que serviços podem ser implementados utilizando-se componentes (Endrei et al., 2004), o que pode levar à falsa ideia de que componentes e serviços podem ser mapeados de um para um. Existem dois pontos a serem considerados que desfazem este tipo de conclusão. O primeiro é a granularidade de componentes e serviços. As funções oferecidas por componentes em geral têm granularidade baixa, não possuindo valor direto para os processos de negócio (Marks e Bell, 2006). Serviços devem possuir granularidade um pouco mais alta, pois representam atividades de negócio e proveem funções de utilidade direta para o negócio. Portanto, a implementação de um serviço geralmente é construída pela composição de mais de um componente de baixa granularidade, resultando em algo de granularidade um pouco mais alta. O segundo é o fato de, apesar de possuírem interface e implementação separadas, assim como os componentes, os serviços operam sob um tipo de contrato que estabelece um acordo e cria expectativas com base em suas características semânticas. Tais características, pelo fato de serem complexas e de natureza humana, não podem ser representadas por um simples conjunto de assinaturas de funções, como as descrições de interface de arcabouços de componentes atuais (Perrey e Lycett, 2003). Mesmo a tecnologia de Web Services , que é frequentemente empregada na implementação de SOA, ainda não oferece uma maneira consolidada de representar estas características semânticas.

2.7 CONSIDERAÇÕES DO CAPÍTULO Neste capítulo, foi apresentado o conceito de SOA e foram discutidas algumas de suas definições e características. Tais definições e características deverão ser mantidas em

2 Entendendo SOA

41

mente para se poder acompanhar a descrição da modelagem, da análise ou do design orientados a serviços e o estudo de caso apresentado no Apêndice B. O paradigma de orientação a serviços tende a ser cada vez mais adotado pelas organizações, tendo em vista benefícios que se espera dele. Porém, esta transição impõe alguns desafios a serem considerados. A modelagem, a análise e o design orientado a serviços devem buscar resolver de modo direto a complexidade do paradigma de orientação a serviços, e indiretamente tratar requisitos de desempenho, segurança e governança. É especialmente importante focar nos princípios de orientação a serviços e em conceitos como granularidade e camadas de serviços. São estes os conceitos-chave que definem as características desejadas nos serviços desenvolvidos no modo como são tratados neste livro.

3

Ciclo de vida SOA Objetivo O objetivo deste capítulo é apresentar um ciclo de vida para o paradigma de orientação a serviços. São descritas boas práticas do paradigma, assim como atividades, papéis e artefatos, destacando-se os modelos de negócio e as especificações de serviços. Este capítulo descreve um ciclo de vida para SOA baseado em boas práticas do paradigma de orientação a serviços. Destacam-se os papéis ou atores que desempenham as atividades e artefatos de entrada e saída das atividades do ciclo de vida.

Conteúdo 3.1 3.2 3.3 3.4 3.5 3.6 3.7

Boas práticas Ciclo de vida SOA Modelagem, análise e design Papéis Artefatos Ciclo de vida iterativo Considerações do capítulo

43 47 50 50 54 58 58

3.1 BOAS PRÁTICAS As boas práticas identificadas na literatura descritas no Capítulo 2 consistem em soluções propostas pelos métodos mais relevantes para atender às necessidades de análise e design de serviços. Nas seções a seguir, serão descritas as boas práticas que são atendidas pelas atividades de modelagem, análise e design descritas neste livro.

3.1.1 Abordagem meet-in-the-middle No desenvolvimento de soluções orientadas a serviços, não se pode seguir totalmente uma abordagem top-down, levando em conta apenas os requisitos e objetivos do negócio para a identificação e especificação de serviços. Tampouco deve ser adotada uma abordagem puramente bottom-up, apenas encapsulando a funcionalidade de aplicações legadas na forma de serviços. Um método deve, de alguma forma, equilibrar as duas alternativas, resultando em uma abordagem meet-in-the-middle. 43

44


A identificação de serviços deve ser guiada pelos requisitos e pela modelagem de negócio, assim como estar alinhada às suas metas e estratégias de negócio. No entanto, os serviços identificados a partir do negócio devem ser analisados e revisados de modo a ajustar-se à realidade dos serviços já existentes na organização e das aplicações legadas. Desta maneira, obtém-se o reuso de recursos existentes e cria-se valor a partir do investimento já realizado.

3.1.2 Compatibilidade com Business Process Management A adoção da arquitetura SOA em uma organização pode trazer maiores benefícios se realizada em conjunto com a adoção de práticas de BPM ( Business Process Management ). Com o surgimento do padrão WS-BPEL, a utilização conjunta de SOA e de BPM foi viabilizada e potencializada. O WS-BPEL permite a composição e orquestração de serviços a partir de definições de processos, criadas por analistas de negócio. Desta maneira, aumenta-se o alinhamento dos serviços desenvolvidos com as metas e estratégias de negócio. Um método orientado a serviços deve levar em consideração essa sinergia e incorporar técnicas de BPM para a análise e o design de serviços (Papazoglou e Van Den Heuvel, 2006). Nas atividades de análise e design, dois aspectos do BPM são aplicáveis: a modelagem de processos e a automação de processos. A técnica de modelagem de processos pode ser empregada para documentar o modelo de negócio e seus requisitos, que, por sua vez, serão o ponto de partida para a identificação de serviços. Já a automação de processos em uma arquitetura SOA pode ser realizada por meio da orquestração de serviços. Caso os processos sejam modelados em uma notação como o BPMN, eles poderão ser convertidos para uma linguagem de orquestração como WS-BPEL e executados em um servidor de aplicações. Um método deve viabilizar projetos de BPM com SOA, mas não deve limitar-se a essa abordagem, permitindo também a realização de projetos de SOA somente.

3.1.3 Reuso de recursos existentes Um dos princípios fundamentais da orientação a serviços é o reuso. Sendo assim, um método de análise e design orientado a serviços deve procurar maximizar o reaproveitamento de lógica já existente, esteja ela na forma de serviços disponíveis no portfólio da organização ou na forma de aplicações legadas, que ainda teriam de ser transformadas em serviços. Segundo esse requisito, durante o processo de análise e design de uma solução orientada a serviços, os recursos existentes na organização devem ser analisados como alternativas para identificação ou realização de serviços. Um método deve abordar atividades com o intuito de avaliar se há algum serviço ou sistema legado existente que atenda aos requisitos definidos durante a modelagem dos processos e serviços.

3 Ciclo de vida SOA

45

3.1.4 Especificação de requisitos não funcionais Um ponto bastante questionado de implementações de arquitetura SOA é o suporte a requisitos não funcionais dos serviços, também chamados de requisitos de qualidade de serviço (QoS – Quality of Service ). Nesta área, existe uma série de padrões abertos sendo desenvolvidos no sentido de especificar o tratamento de requisitos como segurança, desempenho e transações. Um método proposto deve buscar formas de abordar requisitos não funcionais, ou seja, incluir em seu fluxo de trabalho atividades em que esses requisitos sejam definidos e documentados como parte da especificação de um contrato de serviço. Para tal, o método pode adotar padrões específicos, como WS-Security, WS-Policy ou WS-AtomicTransaction.

3.1.5 Diferentes fontes para identificação de serviços Um método de análise e design orientado a serviços deve oferecer flexibilidade aos analistas no momento de identificar potenciais serviços necessários para a organização, a partir da modelagem de negócio. Como fontes para esta identificação, podem ser utilizados modelos de processos, descrições de casos de uso de negócio e modelos de dados para a abordagem top-down e, no caso bottom-up, aplicações legadas e serviços já existentes que possam ser reusados em uma composição.

3.1.6 Diferentes alternativas para realização de serviços Assim como no caso da identificação, deve existir flexibilidade para a especificação de serviços, sendo considerados diversos cenários de realização. Um serviço identificado pode ser especificado como um novo componente a ser desenvolvido, como uma composição de serviços existentes, na forma de reuso de um serviço já existente com potenciais ajustes ou na forma de reuso de lógica de alguma aplicação legada, que pode ser disponibilizada por um serviço encapsulando ou por meio de alguma API ( Application Programming Interface ) ou adaptador. Um método deve levar em conta os diversos cenários possíveis para realização de um serviço e analisar aspectos como custo, risco, esforço e ROI, o que permitirá ao analista que estiver criando a especificação decidir qual abordagem adotar.

3.1.7 Conceito de serviço candidato De acordo com essa prática, o ciclo de vida de um serviço deve possuir um passo intermediário entre o momento em que é concebido ou identificado e o momento em que ele é especificado. Neste passo intermediário, o serviço seria classificado como candidato. Em um método orientado a serviços, o conjunto de serviços de uma solução concebidos ou identificados não é necessariamente realizado e especificado em seu estado original. Por este motivo, ele é considerado candidato até passar por análises e revisões, que podem resultar em mudanças nas operações, no reagrupamento de operações e na redefinição do escopo funcional de cada serviço.

46


3.1.8 Aderência aos princípios de orientação a serviços Um método de análise e design orientado a serviços deve assegurar que os serviços desenvolvidos sejam aderentes aos princípios de orientação a serviços, como reusabilidade, interoperabilidade, baixo acoplamento e autonomia. Esta aderência pode ser obtida inserindo-se no fluxo de trabalho do método pontos de verificação em que um conjunto de serviços é avaliado em relação aos princípios. Outra maneira seria por meio de orientações sobre como executar uma determinada atividade levando em conta os princípios.

3.1.9 Uso de padrões abertos Caso um método utilize de maneira explícita linguagens e notações específicas para representar seus artefatos, essas linguagens e artefatos devem adotar padrões abertos e que sejam independentes de plataforma ou de fornecedor de ferramentas de implementação. Exemplos de padrões abertos relacionados a análise e design de serviços são o WSDL para descrição de interfaces de serviço, o XSD para definição de formato de dados, o WS-BPEL para orquestração de processos de negócio, o BPMN para modelagem de processos, a UML para documentar requisitos e arquitetura de software e os diversos padrões WS-* para uso com a tecnologia Web Services .

3.1.10 Uso de técnicas existentes para implementação Um método de análise e design deve ser estruturado de maneira tal que os seus produtos finais (as especificações de serviços) possam servir como entrada para atividades de uma metodologia de implementação já existente e consolidada (Papazoglou e Van Den Heuvel, 2006), como programação orientada a objetos ou desenvolvimento baseado em componentes (CBD – Component Based Development ). Para que isso seja possível, é necessário que os serviços sejam especificados em um nível detalhado o suficiente para a realização de modelagem de classes e de interfaces de componentes.

3.1.11 Conceito de camadas de serviços Um método de análise e design deve classificar os serviços especificados em camadas, de acordo com sua função ou nível de granularidade. As camadas de serviços (Erl, 2005) definem uma maneira de se separar os tipos de lógica contidos em serviços e de se representar os relacionamentos dos serviços com os processos de negócio e com as aplicações existentes. Dependendo da camada a que um serviço pertence ou de seu nível de granularidade, um método de análise e design deve levar em consideração aspectos específicos, como o nível de reusabilidade e presença de lógica de processo.

3 Ciclo de vida SOA

47

3.1.12 Abordagem “do zero” ou incremental Um método de análise e design deve permitir a implementação de serviços a partir “do zero”, desde o início, baseada em necessidades de negócio. Por outro lado, deve também permitir a implementação de serviços considerando a existência de serviços na organização e que possam ter a sua funcionalidade acrescida de forma incremental. Um método de análise e design deve permitir a implementação de serviços seguindo uma abordagem sequencial a partir do levantamento das necessidades de negócio, semelhante ao processo cascata de desenvolvimento de software, ou uma abordagem incremental a partir de serviços mais críticos para o negócio, semelhante ao processo RUP ou ágil de desenvolvimento de software.

3.1.13 Suporte a governança de serviços Um método de análise e design deve possuir pontos de controle que permitam a uma organização exercer governança sobre os serviços desenvolvidos. Tal governança ou controle deve ser inerente a todo o ciclo de vida. Este controle é especialmente necessário durante as fases de análise e design, já que é neste ponto do ciclo de vida que novos serviços são definidos e especificados e serviços existentes são reusados.

3.2 CICLO DE VIDA SOA O desenvolvimento de soluções orientadas a serviços deve ser parte de uma boa abordagem de desenvolvimento. Uma boa maneira de tratar tais soluções é encará-los dentro de um ciclo de vida semelhante ao de um produto de software, aqui denominado Ciclo de Vida SOA. Podemos considerar que desenvolvimento de soluções orientadas a serviços é cíclico, começando pela modelagem de negócio e definição dos requisitos, passando por análise, design e construção, até ser implantada e gerenciada. Uma vez operacional, pode-se, a partir da observação do desempenho da solução ou em resposta a novos requisitos de negócio, retornar à modelagem para promover melhorias ou alterações à solução orientada a serviços. A ideia do ciclo de vida SOA é possibilitar que uma solução orientada a serviços seja dinâmica, evoluindo de acordo com as necessidades de negócio e passando por um processo de melhoria contínua. O ciclo de vida SOA descrito aqui é parcialmente inspirado em metodologias como o RUP e a abordagem proposta por Papazoglou (2007), podendo ter suas fases e atividades mapeadas para disciplinas e tarefas do RUP. Um ciclo de vida SOA pode ser definido através das fases de modelagem, análise, design, construção, implantação e gerenciamento, conforme pode ser visto na Figura 3.1.

3.2.1 Modelagem O objetivo da fase de modelagem é capturar o estado atual do negócio, suas necessidades e objetivos e traduzir para um modelo de processo de negócio e especificação

48


Figura 3.1 Fases do ciclo de vida SOA.

de requisitos. Nesta fase, são aplicadas as disciplinas de modelagem de negócio e requisitos. A modelagem tem como objetivo modelar a estrutura e a dinâmica da organização onde será implantada a solução. Esta disciplina visa estabelecer um entendimento sobre os processos, identificando seus problemas, falhas, necessidades e propondo melhorias. Para tal, são utilizados modelos de processo para representar a lógica de negócio a ser suportada pela solução. Como resultado, tem-se um modelo de processo que representa o estado atual ( as-is) e um modelo do estado futuro ( to-be), com as melhorias e alterações. O propósito da disciplina de requisitos é estabelecer um acordo entre desenvolvedores e clientes sobre exatamente o que a solução deverá ser capaz de fazer, isto é, o escopo da solução. As necessidades e os objetivos dos clientes são levantados e documentados com detalhes, servindo de base à elaboração de uma proposta de solução. Os resultados obtidos são descritos na forma de casos de uso e uma lista de requisitos. Os casos de uso servirão para descrever as interações dos usuários com a solução, e a lista de requisitos descreve demais necessidades funcionais e não funcionais que deverão ser atendidas pela solução.

3 Ciclo de vida SOA

49

3.2.2 Análise Durante a fase de análise, são definidos os serviços pertencentes à solução, que devem ser derivados do modelo de processo de negócio to-be e dos requisitos. Nesta fase, devem ser identificadas as operações e os serviços candidatos necessários para dar suporte à solução modelada. É feita então uma análise de gap, para determinar quais dos serviços candidatos já existem no portfólio e quais serviços podem reaproveitar recursos existentes. Finalmente, a análise de realização define qual será a estratégia de implementação dos novos serviços.

3.2.3 Design Em seguida vem a fase de design, quando os serviços candidatos definidos na análise são transformados em contratos de serviços e especificações de realização. Uma vez definidos os contratos dos serviços, ocorre também composição destes em processos de negócio. O design de soluções orientadas a serviços exige que as interfaces sejam muito bem definidas e documentadas antes de serem implementadas. Além disso, deve-se garantir que os serviços especificados possuam características aderentes aos princípios de orientação a serviços.

3.2.4 Construção Na fase de construção , é desenvolvida a implementação dos serviços de acordo com as especificações. Estes serviços podem ser implementados através da criação de novos serviços a partir do zero, da exposição de aplicações existentes ou da composição de serviços existentes reusáveis. Nessa fase, ocorrem também os testes, que têm o intuito de validar se os requisitos foram satisfeitos e se as implementações entregues estão de acordo com os contratos e especificações definidas nas fases de análise e design. São realizados testes de unidade, integrados e não funcionais.

3.2.5 Implantação Na fase de implantação, os processos e serviços implementados são publicados e expostos para todos os participantes, incluindo organizações, aplicações e outros processos. Uma vez que a solução publicada é homologada, ela é colocada em operação.

3.2.6 Gerenciamento A fase de gerenciamento inicia-se assim que os serviços e processos são postos em operação. Nessa fase, ocorre a monitoração da solução, durante a qual é medido o desempenho dos serviços, com o intuito de garantir qualidade na execução e conformidades com SLAs (Service Level Agreements ) e requisitos não funcionais definidos nos contratos de serviço.

50


Métricas de negócio e KPIs ( Key Performance Indicators ) são aferidos para medir também o desempenho dos processos e detectar pontos em que pode haver melhora. Trata-se de um processo contínuo de verificação do atendimento dos requisitos e objetivos de negócio definidos na modelagem. Os dados obtidos poderão servir como entrada para uma nova iteração do ciclo de vida, iniciando um novo projeto de desenvolvimento para evoluir a solução orientada a serviços.

3.3 MODELAGEM, ANÁLISE E DESIGN A modelagem, a análise e o design possuem interações entre si e com outras fases do ciclo de vida SOA, de maneira análoga a um desenvolvimento de software. Foi descrito um ciclo de vida SOA genérico mostrando o relacionamento das fases que são realizadas incrementalmente. Para tornar o desenvolvimento de soluções orientadas a serviços mais prático, destacam-se as fases de entrada (modelagem) e de saída (design), conforme destacadas na Figura 3.2 em retângulos escuros. Os retângulos claros correspondem às demais fases do ciclo de vida SOA, não detalhadas neste livro. O formato do ciclo de vida SOA é apenas ilustrativo, podendo ser seguido na abordagem sequencial ou incremental. Na abordagem sequencial, as atividades definidas em cada fase são realizadas sequencialmente, como no ciclo cascata de software, até chegar aos serviços implementados e testados. Na abordagem incremental, as atividades são realizadas por incrementos de serviços, ou seja, cada serviço é construído isoladamente e integrado gradativamente com outros serviços. No caso da fase de modelagem, caso uma organização já tenha uma própria poderá usá-la. No entanto, terá de adaptá-la para obter os artefatos necessários para a fase de análise. No caso da fase de construção, pode-se aplicar as técnicas de implementação e testes já existentes de desenvolvimento de software. Nos próximos capítulos, serão descritas as fases de todo o ciclo de vida SOA, destacando-se a modelagem, a análise e o design. Para cada fase, são explicitadas as atividades, os papéis das pessoas que a desempenham e os artefatos usados e gerados durante a sua execução.

3.4 PAPÉIS Nesta seção descrevem-se as responsabilidades e habilidades necessárias de cada papel (ou função) de negócio dentro do ciclo de vida SOA.

3.4.1 Analista de processos O analista de processos é responsável pela elaboração dos modelos de processo de negócio que serão automatizados por uma solução orientada a serviços. Este papel deve possuir conhecimentos sobre levantamento de requisitos, modelagem de processos e elaboração de casos de uso de negócio.

3 Ciclo de vida SOA

51

Figura 3.2 Atividades de modelagem, análise e design no ciclo de vida SOA.

É importante que a pessoa que assuma esse papel possua boa capacidade de comunicação, tanto oral como escrita, pois ela precisará interagir com representantes de diversas áreas da organização e precisará documentar claramente as necessidades e requisitos identificados. É essencial que a pessoa possua conhecimento sobre o domínio de negócio no qual a solução está inserida. Por exemplo, caso a solução tenha como objetivo automatizar um processo de contratação de apólice de seguros, o analista deve possuir conhecimento sobre como funciona uma seguradora.

3.4.2 Analista de serviços O analista de serviços é responsável pela realização da transição dos artefatos gerados pela modelagem de negócio para uma solução orientada a serviços. Este

52


papel exige conhecimentos intermediários de modelagem de processo, de forma que ele seja capaz de orientar tecnicamente o analista de processos e de interpretar os modelos criados. Além disso, o analista de serviços deve também possuir a capacidade de analisar especificações de casos de uso para identificar os serviços candidatos. É essencial que o analista de serviços possua conhecimentos sólidos sobre os princípios de orientação a serviços, de modo a aplicá-los durante a identificação e análise dos serviços. Experiência em análise de sistemas e conhecimentos básicos sobre tecnologias de integração e de realização de serviços são necessários principalmente durante a análise de gap e a análise de realização, para avaliar o reuso de aplicações legadas. Boa capacidade de comunicação escrita é desejável, pois será preciso descrever com clareza e precisão os serviços candidatos propostos.

3.4.3 Arquiteto de serviços O arquiteto de serviços tem como função principal criar as especificações dos serviços a serem implementados, projetando suas interfaces e comportamento funcional. Assim como o analista de serviços, o arquiteto de serviços também deve possuir conhecimentos sólidos sobre os princípios de orientação a serviços, de modo a criar contratos e especificações aderentes ao paradigma. O arquiteto de serviços deve possuir larga experiência em análise e especificação de sistemas e conhecimentos avançados sobre tecnologias de integração e de realização de serviços (XML, Web Services, REST etc.), para definir a arquitetura de realização de cada serviço e especificar contratos e realizações de serviços tecnicamente interoperáveis e aderentes aos princípios. Conhecimentos sólidos sobre design patterns SOA também são fundamentais na elaboração dos contratos e especificações de serviços. Ter capacidade de elaborar modelos em UML é uma competência desejável quando a linguagem for adotada para representar realizações de serviços.

3.4.4 Arquiteto corporativo O arquiteto corporativo é responsável pela governança do portfólio de serviços da organização, definindo uma arquitetura de referência e padrões a serem seguidos nos projetos. Este papel pode ser exercido por uma equipe, executando algumas funções de um Centro de Excelência SOA. São responsabilidades do arquiteto corporativo: ● ● ● ●

definir padrões técnicos de design de esquemas e contratos de serviços; definir padrões técnicos de design de realização de serviços; definir arquitetura de referência, com orientações para reuso e integração; validar que os serviços pertencentes ao portfólio sejam aderentes aos princípios de orientação a serviços;

3 Ciclo de vida SOA

●

●

53

validar que os serviços candidatos propostos por analistas e os serviços especificados por arquitetos de serviços estejam de acordo com os padrões definidos, em termos de escopo funcional, contrato e realização; validar que os serviços sejam implementados de acordo com seus contratos e especificações.

Devem possuir conhecimentos sólidos nos princípios de orientação a serviços, governança de serviços, tecnologias de integração e arquitetura de aplicações e design patterns SOA.

3.4.5 Gerente de projeto O gerente de projeto é responsável por conduzir o projeto, controlando aspectos como escopo, prazo, custo e riscos. Deve possuir conhecimentos em gerência de projetos e experiência em projetos de desenvolvimento de software, sendo capaz de planejar e conduzir a execução das atividades realizadas pela equipe. É responsabilidade do gerente de projeto definir prioridades, de forma que o trabalho a ser realizado seja adequado às limitações de prazo e custo do projeto. Boa capacidade de comunicação oral e escrita, negociação, liderança e resolução de problemas são competências importantes ao gerente de projeto ao exercer suas funções. Além disso, são desejáveis conhecimentos básicos sobre orientação a serviços e tecnologias relacionadas, para que o gerente de projeto consiga dialogar de forma clara com representantes dos papéis mais técnicos.

3.4.6 Desenvolvedor O desenvolvedor é responsável pela construção dos serviços especificados. O perfil necessário é o mesmo de um método de desenvolvimento de software tradicional, sendo importante ter conhecimentos sobre os princípios de orientação a serviços e tecnologias de integração e de realização de serviços. Dependendo do tamanho da equipe e da solução orientada a serviços, pode haver a separação dos desenvolvedores em perfis especializados em partes específicas da solução, como desenvolvedores de mediações, desenvolvedores de orquestração de processo e desenvolvedores Web para a camada de apresentação. Além de sólidos conhecimentos das tecnologias empregadas na implementação, os desenvolvedores devem ser capazes de interpretar especificações de serviços, especificações de casos de uso e modelos UML, quando estes forem utilizados.

3.4.7 Testador O testador é responsável pelos testes dos serviços especificados. O perfil necessário para este papel é o mesmo de um método de desenvolvimento de software tradicional, sendo importante ter conhecimentos de orientação a serviços e tecnologias de integração.

54


3.4.8 Administrador de serviços O administrador de serviços é responsável por implantar os serviços em produção e mantê-los operacionais, monitorando seu desempenho e disponibilidade e assegurando-se de que a infraestrutura está bem dimensionada.

3.4.9 Gestor de processos O gestor de processos geralmente é um gerente, coordenador ou diretor que é responsável por um determinado processo de negócio ou por todos os processos de negócio de uma área ou departamento da organização. É o gestor de processos quem demanda um projeto de automação ou melhoria de processo.

3.4.10 Ator de processos O ator de processos é um papel que, no contexto do ciclo de vida SOA, representa todos os colaboradores, funcionários, clientes e parceiros da organização que estão envolvidos na execução de um processo de negócio, seja executando tarefas, fornecendo ou recebendo informações.

3.5 ARTEFATOS Nesta seção serão descritos alguns artefatos gerados durante a realização das atividades do ciclo de vida SOA.

3.5.1 Modelo de processo O modelo de processo as-is e o modelo de processo to-be correspondem, respectivamente, à representação do estado atual do negócio e dos requisitos da solução em uma notação como o BPMN. A Figura 3.3 apresenta um exemplo de um modelo de processo de venda de produtos. Esse modelo de processo está representado por um diagrama na notação BPMN. O processo é representado por um conjunto de participantes (entidades, áreas ou papéis de negócio) que devem realizar determinadas atividades (retângulo com cantos arredondados). Estes participantes e atividades estão representados em um retângulo ( pool) identificados à esquerda com o nome do participante e à direita por um conjunto de atividades em notação específica. O início e o fim de atividades de um participante são representados por eventos (círculos) distintos. Uma atividade está ligada à outra por uma sequência de fluxos (linha cheia com seta). Uma atividade pode se comunicar com outra atividade de outro participante ( pools diferentes) através de fluxo de mensagens (linha tracejada sem seta). A notação BPMN é muito intuitiva, pois se assemelha ao tradicional fluxograma. No exemplo da Figura 3, tem-se três participantes: cliente, atendente e expedição. O processo de venda de produtos é iniciado por um pedido enviado pelo cliente que

3 Ciclo de vida SOA

55

Figura 3.3 Exemplo de modelo de processo – venda de produtos.

é recebido pelo atendente. Este, por sua vez, verifica os dados do pedido, e, se estiverem completos, verifica se o produto existe no estoque. Caso não exista, comunica o cliente. Se existe, o atendente gera a fatura do pedido. A fatura deve ser paga pelo cliente e, em seguida, a área de expedição prepara o produto para o envio ao cliente. Por fim, o cliente recebe o produto.

3.5.2 Especificação de processo A especificação de processo é um documento que pode ser elaborado para complementar o modelo de processos, provendo descrições textuais detalhadas de cada tarefa, dos dados, papéis, recursos e pontos de decisão do fluxo de trabalho. Uma descrição de tarefa pode conter as seguintes informações: ● ● ● ●

objetivo da tarefa; etapas de execução da tarefa; dados e informações utilizadas como entrada; dados e informações geradas como saída.

A descrição de um ponto de decisão pode ser expressa por uma expressão lógica, verbalizada em linguagem natural. Por exemplo, para o ponto de decisão representado na Figura 3.4, a descrição poderia ser a seguinte:

56


Figura 3.4 Exemplo de ponto de decisão.

Se o valor do financiamento for menor que R$ 1.000,00, a solicitação é aprovada automaticamente. Se o valor do financiamento for maior que R$ 1.000,00, a solicitação deve passar pela aprovação de um analista de crédito.

3.5.3 Modelo de serviços O modelo de serviços é utilizado para documentar o processo de análise orientada a serviços, que dá origem a um conjunto de serviços identificados a partir de um modelo de negócio, na forma de processo ou caso de uso de negócio. Ele é preenchido ao longo das seguintes atividades: ● ● ●

identificação de serviços candidatos; análise de gap; análise de realização.

A Figura 3.5 apresenta os principais itens contidos no modelo de serviços, abstratamente, e o relacionamento entre eles e as atividades que os definem. Ou seja, a atividade “Identificação de Serviços Candidatos” define as “Operações Candidatas” e os “Serviços Candidatos”, a atividade “Análise de G ap” define os “Cenários de Reuso” e as “Alternativas de Realização” e a atividade “Análise de Realização” define as “Decisões de Realização”.

3.5.4 Contrato de serviço O contrato de serviço, conforme descrito no Capítulo 2, é composto pela definição da interface técnica do serviço, definições das mensagens do serviço e políticas que definem restrições e requisitos não funcionais, conforme podem ser vistas na Figura 3.6. Complementando estes artefatos técnicos, pode ser elaborado um

3 Ciclo de vida SOA

57

Figura 3.5 Modelo de serviços.

Figura 3.6 Contrato de serviço.

documento em linguagem natural descrevendo semanticamente a lógica executada pelas operações do serviço, o significado dos campos das mensagens do serviço e o acordo de serviço estabelecido entre provedor e consumidor de serviço (SLA).

3.5.5 Especificação de serviço A especificação de serviço fornece a especificação estrutural e comportamental de um serviço. Esta especificação estabelece um contrato entre provedor e consumidor do serviço, além de servir como documentação de referência para o desenvolvedor responsável por implementar o serviço. Contém a descrição da interface do serviço, a definição das mensagens de entrada e saída, a especificação do comportamento de cada operação e os requisitos não funcionais envolvidos, além de indicar a camada a que pertence o serviço.

58


3.6 CICLO DE VIDA ITERATIVO Principalmente em organizações que adotam o RUP, é comum a utilização de uma abordagem iterativa para o processo de desenvolvimento. No ciclo de vida de soluções orientadas a serviços, as fases de modelagem, análise e design foram concebidas de forma a poderem ser executadas em várias iterações antes de passar para a seguinte. Essa abordagem pode ser utilizada para implementação de diversos processos de negócio dentro do mesmo projeto. Após a fase de modelagem, para cada processo de negócio, executa-se uma iteração da fase de análise para se chegar a um conjunto de serviços (descritos no modelo de serviços). A cada iteração de análise, novos serviços são identificados e analisados, adicionando e modificando os serviços previamente definidos no modelo de serviços. Após todas as iterações de análise, chega-se a um conjunto de serviços coeso capaz de suportar todos os processos de negócio analisados. A partir daí, a fase de design também pode ser executada de forma iterativa, sendo que, a cada iteração, um conjunto de serviços é especificado e verificado. Essa abordagem pode ser adotada também para se realizar a modelagem, a análise e o design de todo o portfólio de serviços da organização de uma só vez. Ao invés de se ter cada projeto contribuindo com alguns serviços ao portfólio, pode-se, em uma única iniciativa, analisar todos os processos de negócio e casos de uso de uma organização e aplicar as fases de maneira iterativa de todo o portfólio de serviços da organização. Neste caso, não é necessário que todos os processos de negócio sejam automatizados em um único projeto, e nem todos de uma vez. Assim, nem todos os serviços precisam ser implementados, caso os processos que necessitem deles não estejam automatizados. Mas o intuito desta abordagem é já possuir definido um modelo do portfólio de serviços. Desta forma, a cada projeto de automação de processo, minimiza-se a necessidade de se alterar os serviços existentes e criar novas versões, uma vez que os serviços já serão concebidos de maneira alinhada a todos os processos.

3.7 CONSIDERAÇÕES DO CAPÍTULO Neste capítulo é importante notar que modelagem, análise e design seguem boas práticas identificadas em métodos orientados a serviços encontrados na literatura recente. Para um melhor aproveitamento das boas práticas, elas foram organizadas em um ciclo de vida semelhante ao desenvolvimento de software, que é mais familiar aos desenvolvedores. Para uniformizar as atividades, são descritos papéis que são necessários para melhor divisão das atividades e artefatos, a fim de melhorar a comunicação entre os envolvidos. Os próximos capítulos detalharão as fases de modelagem, análise e design que resultam em contrato de serviço e especificação de serviço a ser desenvolvido. De maneira sucinta as fases de construção, implantação e gerenciamento serão descritas.

4

Modelagem Objetivo O objetivo deste capítulo é apresentar a fase de modelagem, onde os modelos de processos de negócio são obtidos. Estes modelos são essenciais para especificar os requisitos de serviços. A fase de modelagem ocorre antes das atividades da fase de análise. Nessa fase, busca-se um entendimento sobre as necessidades de negócio e levantam-se os seus requisitos. As atividades de modelagem são executadas por analistas de processos ou da área de processos da organização. A Figura 4.1 apresenta as atividades de modelagem de processo as-is, modelagem de processo to-be e especificação de requisitos da fase de modelagem, descritas a seguir.

Conteúdo 4.1 4.2 4.3 4.4

Modelagem de processo as-is Modelagem de processo to-be Especificação de requisitos Considerações do capítulo

59 64 70 74

4.1 MODELAGEM DE PROCESSO AS-IS Papel: analista de processos Artefatos utilizados: necessidades de negócio Artefatos gerados: modelo de processo as-is Na modelagem de processo as-is, conforme apresentada na Figura 4.2, é levantado o estado atual dos processos de negócio envolvidos no projeto, baseado nas necessidades de negócio. Como resultado desta atividade, o analista de processos produzirá um modelo de processo representando o estado do negócio antes do projeto da solução orientada a serviços.

59

60


Figura 4.1 Atividades da fase de modelagem.

Figura 4.2 Modelagem de processo as-is.

Observação:

Esta seção não tem como propósito ser um guia completo de modelagem e otimização de processos, mas apenas fornecer orientações sobre como processos devem ser modelados considerando sua automação por uma solução orientada a serviços.

Para que seja possível a identificação de serviços, o modelo de processo deve conter pelo menos as seguintes informações: ● ● ●

●

●

diagrama representando o fluxo do processo (tarefas, pontos de decisão, loops); atores ou papéis que executam tarefas do processo; dados ou objetos de negócio envolvidos no processo (definição de objetos e campos utilizados durante a execução do processo); descrição de cada tarefa (detalhamento das ações que são executadas durante a tarefa, dados de entrada e saída da tarefa); detalhamento dos pontos de decisão (condições que determinam qual fluxo deve ser seguido).

4 Modelagem

61

Na modelagem de processo as-is, o detalhamento do modelo de processo pode ser escrito em linguagem natural e não estruturada, não necessitando ater-se a aspectos técnicos de automação do processo. Para representar as informações levantadas, o analista de processos deve elaborar um modelo de processo. O modelo pode ser representado por um fluxograma, preferencialmente utilizando uma notação padrão de processo como BPMN, que pode ser convertida diretamente para a linguagem WS-BPEL por diversas ferramentas existentes no mercado. O analista de processos pode acompanhar os seguintes passos para elaborar o modelo de processo as-is.

4.1.1 Entrevistar atores do processo Identifique as pessoas envolvidas no processo, como usuários, gestores e clientes, que podem ter diferentes cargos e funções e pertencer a diferentes áreas da organização. Uma vez feita esta identificação, o analista de processos entrevista representantes de cada função, a fim de obter informações sobre como o processo é executado atualmente e quais papéis e responsabilidades cada pessoa assume no contexto do processo. Nas entrevistas, é importante também captar impressões subjetivas dos diversos envolvidos, focando em identificar problemas ou pontos de ineficiência no processo a partir de diversas perspectivas, desde o usuário até o gestor. O objetivo é detectar gargalos, redundâncias, falhas no processo e pontos que podem ser melhorados. Além disso, devem ser levantadas métricas e dados quantitativos relacionados ao desempenho do processo, como tempo médio de duração do processo e de atividades específicas, custo do processo ou número de execuções realizadas por dia ou por mês. A partir das entrevistas, é possível identificar necessidades e metas de negócio, geralmente relacionadas às métricas quantitativas. Alguns exemplos de metas de negócio são redução de custos, redução de tempo de atendimento ou aumento de receita gerada. Dessa maneira, através das entrevistas, devem ser levantadas as seguintes informações: ● ● ● ●

informações sobre como o processo é executado; problemas e pontos de falha do processo; necessidades e metas de negócio associadas ao processo; métricas e indicadores de desempenho do processo.

Tais informações, além de servirem de insumo para a elaboração do modelo de processo as-is, poderão ser utilizadas nas atividades de modelagem de processo to-be e especificação de requisitos.

4.1.2 Identificar e descrever tarefas A partir das entrevistas, o analista de processos deve identificar quais tarefas os participantes do processo executam ao exercerem suas funções. Para representar

62


o fluxo de tarefas do processo, pode ser elaborado um modelo de processo, representado por um diagrama de processo em notação BPMN ( Business Process Model Notation ) ou por um diagrama de transição de estados da UML ( Unified Modeling Language ). Descreva as tarefas que compõem o fluxo de trabalho do processo de negócio. As tarefas são as ações executadas pelos envolvidos no processo, por exemplo: “Cadastrar Cliente”, “Verificar Crédito” etc.

4.1.3 Identificar e descrever dados Identifique e descreva os dados que são utilizados durante a execução das tarefas do processo. Para executar uma determinada tarefa, um ator pode necessitar de um conjunto de dados de entrada (por exemplo, dados do cliente) e, por sua vez, pode gerar um conjunto de dados de saída (por exemplo, cadastro do cliente) como resultado. Ao longo do fluxo de trabalho do processo, os dados podem trafegar de uma tarefa para outra. Os dados de uma tarefa podem ser identificados a partir das interações entre os atores do processo, descobrindo que tipos de informações eles trocam entre si ao longo do fluxo de trabalho.

4.1.4 Identificar métricas Identifique por meio de relatórios, registros e evidências de execução de tarefas, estatísticas e dados quantitativos que permitam mensurar o desempenho e o custo do processo. Na falta de fontes de dados confiáveis, pode-se recorrer às impressões dos próprios atores do processo para se estimar os valores das métricas de processo. Caso seja um processo já automatizado por uma solução orientada a serviços, esses dados podem ser obtidos por meio da ferramenta de monitoração de atividade de negócio (BAM). Alguns exemplos de métricas de processo são: ●

● ● ● ●

●

tempo de duração de cada tarefa por recurso (cargos, funções, indivíduos, sistemas e parceiros); tempo de espera para execução de cada tarefa; número de execuções do processo por hora, por dia ou por mês; número de execuções do processo ocorrendo paralelamente; custos para execução de uma tarefa (por utilização de algum recurso ou pelo custo-hora da pessoa envolvida na tarefa); receita gerada pela execução de uma tarefa.

É importante entender nesse ponto quais são as métricas críticas para se aferir o desempenho do processo, na percepção do usuário ou do negócio. Por exemplo, em um processo de vendas, a receita gerada é uma métrica importante, enquanto em um processo de atendimento a clientes o tempo de duração torna-se mais crítico.

4 Modelagem Dicas: ●

●

●

É importante manter consistência na nomenclatura das tarefas e entidades relacionadas. Crie um vocabulário padronizado e aplique-o no modelo de processo e nas descrições textuais das tarefas. Nesse ponto, o processo deve representar a lógica de negócio e pode ser mantido com nível alto de granularidade. As tarefas devem representar funções atômicas no nível de negócio. O detalhamento em etapas técnicas de menor granularidade será feito nas próximas atividades do ciclo de vida. Nomes de tarefas geralmente iniciam-se com verbo, como “analisar crédito” e “cadastrar aluno”.

Exemplo

Vamos ilustrar a fase de modelagem tomando como exemplo o processo de negócio consulta médica da clínica médica MEDSOA. Trata-se do processo iniciado quando um paciente agenda uma consulta na clínica MEDSOA, passando pela realização da consulta até o pagamento, realizado pelo próprio paciente ou por um convênio médico. A clínica MEDSOA não conta com nenhuma solução orientada a serviços para automatizar seus processos, possuindo apenas um aplicativo pacote de CRM para cadastro de pacientes. Visando automatizar o processo, o analista de processos da clínica MEDSOA modela o processo atual (as-is) que é executado para a realização de consultas. Para elaborar o modelo de processo as-is, ele realiza entrevistas com os atendentes da recepção da clínica, com os médicos e com os funcionários do setor administrativo (os atores do processo), perguntando sobre como cada um deles executa suas atividades durante o atendimento aos pacientes. Como resultado destas entrevistas, o analista de processos descobre o fluxo de atividades, a sequência em que elas são executadas e a lógica envolvida no fluxo. O processo inicia-se com o paciente entrando em contato por telefone ou pessoalmente para solicitar uma consulta com um dos médicos da clínica. O atendente da clínica agenda a consulta com o médico escolhido na data e na hora escolhidas pelo paciente. Na data e na hora da consulta, o paciente comparece à clínica e é atendido pelo médico. Durante a consulta, o médico obtém o prontuário do paciente e atualiza as informações de acordo com as observações provenientes da consulta e eventuais exames e procedimentos. Se for o caso, o médico pode prescrever um ou mais medicamentos ao paciente e solicitar que ele realize exames diagnósticos e retorne para uma nova consulta. Após a finalização da consulta, caso o paciente não possua um convênio médico, deve realizar o pagamento em cheque, dinheiro ou cartão. Caso possua, o setor administrativo deve gerar uma fatura para ele. Se o médico tiver solicitado retorno, o paciente deve agendar uma nova consulta, iniciando uma nova iteração do processo. Caso contrário, o processo é encerrado. Baseado nessas informações, o analista de processos elabora o diagrama de processo em notação BPMN do modelo de processo as-is de consulta médica, conforme a Figura 4.3. Temos quatro participantes: administração, atendente, paciente e médico. Além do diagrama de processo, o analista de processos ainda descreve textualmente os detalhes de cada tarefa, especificando as etapas executadas pelos atores em cada uma delas. Por exemplo, o detalhamento da tarefa “Agendar Consulta”.

1. 2. 3. 4.

Cliente informa o médico de preferência. Atendente consulta a agenda do médico e informa as datas e horários disponíveis. Cliente informa a data e o horário escolhido. Atendente registra na agenda a consulta com o Paciente na data e no horário escolhido. O modelo de processo as-is elaborado servirá como base para o projeto de automação do processo de consulta médica.

63

64


Figura 4.3 Modelo de processo as-is de consulta médica da clínica MEDSOA.

4.2 MODELAGEM DE PROCESSO TO-BE Papéis: analista de processos, analista de serviços. Artefatos utilizados: necessidades de negócio, modelo de processo as-is. Artefatos gerados: modelo de processo to-be. Enquanto o modelo de processo as-is representa o estado atual de um processo de negócio, o objetivo do modelo de processo to-be é representar o estado desejado do processo, ou seja, descreve os requisitos funcionais a serem atendidos por um sistema ou solução orientada a serviços. Na modelagem de processo to-be, conforme pode ser vista na Figura 4.4, o analista de processos pode realizar avaliações e simulações e propor modificações ao processo com o intuito de promover melhorias de desempenho ou reduzir custos. Tais modificações do processo podem ser mudanças em sua própria estrutura (fluxo de trabalho) ou propostas de automação de parte ou de todo o processo. Como produto desta atividade, é elaborado um novo modelo de processo alterado com relação ao as-is. ●

●

Deve-se realizar uma análise para detectar gargalos e pontos falhos. Exemplos: Tarefas que retêm o avanço do processo, por serem complexas ou demoradas, por indisponibilidade de recursos para serem executadas ou por excesso de trabalho manual repetitivo. Deve-se verificar dados não confiáveis gerados por tarefas (obtidos de fontes imprecisas, informados manualmente).

4 Modelagem

65

Figura 4.4 Modelagem de processo to-be.

Para resolver tais pontos, além de alterar o fluxo e as tarefas, pode-se propor a automação de tarefas utilizando serviços. Este tipo de abordagem é o mais indicado para tarefas manuais demoradas, ou aquelas cujos dados de saída não são confiáveis por serem informados manualmente. Os modelos podem ser representados utilizando-se uma notação de processo, como BPMN, que pode ser convertida diretamente para a linguagem WS-BPEL por diversas ferramentas existentes no mercado. A modelagem de processo to-be deve definir e documentar como um processo será executado dentro de uma organização, identificando papéis, responsabilidades, atividades e ordens de execução. Feita esta modelagem, é possível realizar uma análise de negócios e identificar possíveis ganhos e alterações com a execução deste processo. Pelo fato de descrever a automação do processo, o modelo to-be deve ser detalhado até um nível mais técnico. Na especificação de processo associada devem ser descritos os detalhes de execução de cada tarefa. O analista de processos pode acompanhar os seguintes passos para elaborar o modelo de processo to-be.

66


4.2.1 Definir melhorias A partir do modelo de processo as-is, o analista de processos deve propor melhorias no processo de modo a solucionar os problemas e atender às necessidades e metas de negócio levantadas nas entrevistas com os envolvidos. Definir as melhorias que devem ser implementadas no processo de negócio de acordo com as solicitações dos usuários, resultados de simulações e regras de negócio. ● ● ● ● ●

automação de tarefas humanas que envolvem trabalhos repetitivos; automação de tarefas sujeitas a erros humanos ou fraudes; adição de revisões e verificações em pontos sujeitos a erros humanos ou fraudes; automação de verificações e validações de regras de negócio; aumento no número de recursos para execução de tarefas de longa duração.

4.2.2 Simular processo A simulação de processos de negócio permite ao analista de processos validar se as alterações propostas trarão os resultados esperados. Por meio da simulação, é possível ter uma visão dos ganhos de desempenho do processo antes mesmo de sua implementação. O uso de ferramentas de simulação auxilia o analista de processos na tomada de decisões de melhorias, provendo relatórios gerenciais e comparativos entre cenários. Com uma modelagem de processo de negócio bem-feita, é possível: ● ● ● ●

identificar os gargalos; estimar custos e durações; identificar os impactos antes da implementação de mudanças em um processo; criar novos cenários com a verificação do impacto no desempenho.

Baseado nos resultados das simulações de alguns cenários, o analista de processos pode definir novos cenários para o processo, por meio de ajustes. Alguns dos possíveis ajustes são: ●

●

●

●

adicionar mais pessoas ou recursos para realizar uma tarefa, medindo o impacto em termos de duração, custo ou receita; automatizar uma tarefa, por exemplo, passando de uma consulta manual para uma consulta automatizada e verificando se o ganho obtido justifica o custo da automação; eliminar tarefas duplicadas ou que forem julgadas desnecessárias, aferindo o impacto ao processo; transferir a responsabilidade por uma tarefa de um papel para outro.

4.2.3 Detalhar tarefas do processo Cada tarefa do processo de negócio to-be deve possuir uma descrição textual que detalha as etapas da execução da atividade e a lógica envolvida. Esta descrição pode ser um texto corrido ou pode ser estruturada em uma sequência de passos (como

4 Modelagem

67

em uma especificação de caso de uso) ou em um conjunto de frases de requisitos. Uma forma estruturada facilita a identificação de serviços e a manutenção da rastreabilidade entre operações de serviço e processos-pai. A seguir são apresentados exemplos de formas de descrição das atividades em texto corrido, sequência de passos como uma especificação de caso de uso e em frases de requisitos da atividade abrir pedido do modelo de processo de negócio (Figura 3.3). Descrição textual: o atendente, ao receber um pedido do cliente, deve primeiro definir o número do pedido para poder rastrear o produto ao longo do processo de venda. Após definir o número do pedido, deve verificar se o cliente é cadastrado na empresa, caso contrário, deve solicitar os dados do cliente. Em seguida, deve verificar se os dados do pedido estão completos, quanto ao código do produto, à descrição e à quantidade.

Sequência de passos: 1. Cliente envia pedido. 2. Atendente recebe pedido. 3. Atendente define um número do pedido. 4. Atendente verifica se cliente é cadastrado, caso contrário, solicita dados do cliente. 5. Atendente verifica se dados do pedido estão completos.

Frases de requisitos: O cliente deve enviar pedido. O atendente deve receber o pedido. O atendente deve definir número do pedido. O atendente deve verificar se cliente é cadastrado, caso contrário, deve solicitar dados do cliente. O atendente deve verificar se os dados do pedido estão completos. ● ● ● ●

●

4.2.4 Modelar processo para implementação Quando um processo de negócio é modelado, algumas de suas características devem ser ajustadas para que seja possível sua implementação em uma plataforma BPMS. Caso esses ajustes não sejam feitos, pode ser gerado um desalinhamento entre o processo modelado pelo analista de processos e o processo executado pela solução orientada a serviços e implementado nas fases subsequentes. O analista de serviços pode ser envolvido nessa atividade, suportando o analista de processos com conhecimentos sobre os serviços existentes que poderiam ser reusados e sobre que tipo de automação é suportada pela solução orientada a serviços e pelas ferramentas disponíveis. Este apoio do analista de serviços é importante para garantir que as propostas de automação definidas pelo analista de processos sejam viáveis tecnicamente e estejam de acordo com os serviços existentes.

68


O analista de serviços pode também, acessando um registro de serviços, buscar serviços existentes e sugerir a utilização deles na automação de tarefas. Entretanto, neste ponto do ciclo de vida, esta escolha de serviços tem caráter apenas de sugestão (serviços candidatos). A definição sobre os serviços que serão efetivamente utilizados na automação do processo ocorrerá durante a fase de análise. Dica:

O modelo de processo to-be deve possuir um detalhamento técnico maior, podendo contar com tarefas de menor granularidade ou com detalhamento de uma tarefa em etapas de baixa granularidade. Exemplo:

Dando continuidade ao processo de consulta médica da clínica MEDSOA, o analista de processos parte para a modelagem de processo “to-be”. Nesta atividade, o analista de processos deve elaborar uma nova versão do modelo de processo, incorporando melhorias e prevendo a automação do processo. A clínica MEDSOA visa implementar uma nova versão do processo automatizada através de um BPMS e serviços compostos. O analista de processos, então, modifica o modelo de processo, subdividindo-o em três subprocessos: agendamento, atendimento e pagamento. Além disso, o analista de processos promoveu automação ao processo, acrescentando tarefas realizadas pelo pool “sistema”. Durante o agendamento (representado em BPMN na Figura 4.5), foram adicionadas tarefas sistêmicas para facilitar o trabalho do atendente, como o acesso ao cadastro de pacientes e às agendas dos médicos. Para facilitar o trabalho do médico durante o atendimento (Figura 4.6), foram acrescentadas tarefas sistêmicas na manipulação do prontuário do paciente (agora eletrônico) e na geração

Figura 4.5 Modelo de processo to-be – subprocesso agendamento.

4 Modelagem

Figura 4.6 Modelo de processo to-be – Subprocesso atendimento. de prescrições. Foi acrescentada também uma tarefa automatizada de envio de notificação via SMS ou e-mail ao paciente um dia antes da consulta, para lembrá-lo de comparecer à clínica, visando minimizar o número de atrasos e faltas. Já no pagamento (Figura 4.7), no caso em que o paciente utiliza um convênio médico em vez de realizar o pagamento direto, foi automatizada a tarefa de geração da fatura para o convênio. Além de elaborar os diagramas de processo, o analista de processos ainda deve detalhar as tarefas, especificando dados de entrada e saída, além de descrever a lógica executada em cada uma delas, passo a passo. No exemplo a seguir, é ilustrado o detalhamento da tarefa “Prescrever Medicamentos e Exames” do subprocesso atendimento.

Objetivo da tarefa: baseado no diagnóstico, o médico utiliza o sistema para gerar uma prescrição de medicamentos. Caso ainda sejam necessários exames, o médico gera através do sistema uma prescrição de exames. Dados de entrada: nomes dos medicamentos, instruções de administração dos medicamentos, nomes dos exames. Dados de saída: prescrição de medicamentos, prescrição de exames. Detalhamento da tarefa: o médico acessa no sistema a função de “Geração de Prescrição”. O médico busca e seleciona o medicamento desejado. O sistema adiciona à prescrição as seguintes informações: nome comercial do medicamento, nome do princípio ativo, frequência de administração, forma de administração, dose ou quantidade. Para prescrever um exame, o médico busca e seleciona o exame desejado. O sistema adiciona à prescrição as seguintes informações: nome do exame, instruções de preparação para o exame. Após adicionados todos os medicamentos e exames, o médico imprime uma prescrição de medicamentos e uma prescrição de exames e entrega-as ao paciente.

69

70


Figura 4.7 Modelo de processo to-be – Subprocesso pagamento.

4.3 ESPECIFICAÇÃO DE REQUISITOS Papel: analista de processos Artefatos utilizados: necessidades de negócio Artefatos gerados: especificação de requisitos (casos de uso de negócio, regras de negócio, requisitos não funcionais) A atividade de especificação de requisitos, conforme apresentada na Figura 4.8, ocorre paralelamente às atividades de modelagem de processo as-is e to-be. Durante as entrevistas e levantamentos da modelagem as-is, o analista de processos deve identificar também os objetivos, necessidades e problemas do negócio, isto é, responder à pergunta: o que se busca melhorar ou solucionar com a automação do processo? Já durante a modelagem de processo to-be, conforme o modelo é elaborado, o analista de processos tem uma visão mais clara de como o processo de negócio deve se comportar para suportar as metas de negócio e, assim, formular requisitos para descrever este comportamento. A ideia da especificação de requisitos é complementar o modelo de processo to-be gerado com informações sobre as funções que a solução orientada a serviços deverá executar e como a solução deverá se comportar. Os requisitos provêm um detalhamento adicional sobre a solução como um todo e servem de base para atividades como identificação de serviços candidatos e especificação de serviços.

4 Modelagem

71

Figura 4.8 Especificação de requisitos.

4.3.1 Descrever casos de uso Casos de uso de negócio podem ser elaborados para descrever a interação dos atores do processo com o “sistema”, representado pela solução orientada a serviços. Estes casos de uso, além de potenciais fontes para identificação de serviços candidatos, servirão como especificação para a implementação da camada de apresentação da solução. No desenvolvimento de soluções orientadas a serviços, os casos de uso têm como objetivo complementar o modelo de processo to-be, provendo uma descrição estruturada da interação entre um ator de um processo de negócio e a solução orientada a serviços que automatiza o processo. Um caso de uso pode descrever a interação que um usuário executa dentro do escopo de uma tarefa do processo ou pode descrever a interação entre o usuário e a solução ao longo de diversas tarefas. Por exemplo, na Figura 4.9, o caso de uso 1 descreve a interação do usuário com a solução orientada a serviço durante a execução da tarefa A, enquanto o caso de uso 2 descreve a sequência de eventos da interação do usuário durante a Tarefa B e a Tarefa C.

4.3.2 Descrever regras de negócio Além dos requisitos não funcionais, o analista de processos pode identificar regras de negócio que afetam a lógica executada no processo.

72


Figura 4.9 Casos de uso de um processo.

Uma prática comum na descrição de atividades de processos (utilizada também na descrição de casos de uso) é a externalização ou abstração de regras de negócio. Regras de negócio, sejam específicas da empresa ou regulamentações às quais a organização deve aderir, podem ser descritas em documentos separados das descrições de processos (ou casos de uso). Neste caso, as descrições de processos devem fazer referências aos documentos das regras de negócio. Um exemplo de externalização de regra de negócio é “se o cliente não é cadastrado, solicitar dados ao cliente”.

4.3.3 Descrever requisitos não funcionais A partir de metas de alto nível, podem ser formulados requisitos não funcionais. Por exemplo, em um processo de atendimento de chamados, o gestor do processo pode ter a meta de negócio “melhorar o atendimento”. Após a modelagem do processo e detalhamento da meta, pode ser especificado o requisito “o tempo de duração da abertura do chamado até sua resolução não pode ultrapassar 4 horas”. Os requisitos não funcionais especificados durante a modelagem estarão relacionados principalmente às métricas do processo. Exemplo:

Complementando o modelo de processo “to-be”, o analista de processos elabora algumas especificações de casos de uso, descrevendo as interações dos atores com a camada de apresentação da solução orientada a serviços. Os seguintes casos de uso são descritos: agendamento de consulta – este caso de uso representa a interação do atendente com o sistema, quando o paciente solicita uma consulta; obter prontuário – descreve a interação do médico com o sistema, ao buscar o prontuário de um paciente;atualizar prontuário – descreve a interação do médico com o sistema, ao atualizar o prontuário de um paciente; prescrever medicamentos e exames – descreve a interação do médico com o sistema, buscando medicamentos e exames e inserindo orientações para gerar uma prescrição para o paciente. A seguir, é exemplificada a descrição do caso de uso que detalha uma parte do subprocesso agendamento. O escopo do caso de uso pode ser visualizado na Figura 4.10.

4 Modelagem

Figura 4.10 Escopo do caso de uso. Objetivo: registrar um paciente para uma consulta com um dos médicos da clínica, em data e horário de preferência do paciente. Fluxo básico de eventos: 1. Por telefone, o paciente entra em contato com a clínica e solicita consulta com um médico, identificando-o pelo nome. 2. Atendente acessa o Sistema e seleciona a opção de menu “Agendar Consulta”. 3. Sistema exibe uma lista com os médicos disponíveis e permite que se realize uma busca pelo nome do médico. 4. Atendente seleciona o médico indicado e escolhe a opção “Visualizar Agenda”. 5. Sistema exibe em um calendário as próximas datas e horários disponíveis para o médico selecionado. 6. Atendente informa ao paciente as datas e os horários disponíveis. 7. Paciente informa ao atendente a data e o horário de sua preferência, dentre os disponíveis. 8. Atendente seleciona a data e o horário disponíveis no calendário e seleciona a opção “Nova Consulta”. 9. Atendente preenche no sistema o nome do paciente e confirma o agendamento. 10. Sistema exibe mensagem de sucesso. 11. Atendente informa ao paciente que a consulta foi agendada com sucesso. Fluxo alternativo: [Paciente não possui médico de preferência – nesse caso, o paciente seleciona o médico pela especialidade médica. Ocorre variação nos passos de 1 a 5.] 1. Por telefone, o paciente entra em contato com a clínica e solicita uma consulta, informando a especialidade médica desejada. 2. Atendente acessa o sistema e seleciona a opção de menu “Agendar Consulta”. 3. Atendente seleciona a opção “Busca por especialidade”. 4. Sistema exibe uma lista com as especialidades médicas disponíveis.

73

74


5. Atendente seleciona a especialidade informada pelo paciente e seleciona a opção “Visualizar Agenda”. 6. Sistema exibe em um calendário as próximas datas e horários disponíveis para todos os médicos da especialidade informada. 7. Atendente acessa o sistema, buscando as datas e horários de todos os médicos da especialidade informada pelo paciente. 8. Sistema exibe em um calendário as próximas datas e horários disponíveis para todos os médicos da especialidade informada pelo paciente. Além da especificação de casos de uso, o analista de processos documenta também alguns requisitos não funcionais levantados a partir das necessidades apontadas pelas pessoas entrevistadas. [Segurança de acesso] apenas os médicos cadastrados podem ter acesso a prontuários de pacientes. Atendentes têm acesso somente a dados cadastrais dos pacientes. [Privacidade] dados de prontuários de pacientes devem ser persistidos com criptografia. [Desempenho] o tempo de resposta entre a submissão de uma página e a exibição da próxima não pode ser superior a 2 segundos. [Desempenho] a solução deve suportar a realização de pelo menos 10 consultas médicas simultâneas. [Integridade de dados] o registro de consultas nas agendas dos médicos deve ser persistido de forma transacional, para evitar conflitos e condições de corrida no caso de vários atendentes agendando consultas simultaneamente. ●

● ●

●

●

4.4 CONSIDERAÇÕES DO CAPÍTULO Neste capítulo foi apresentada em detalhes a modelagem de processo de negócio como base para a especificação de serviços a serem considerados na fase de análise. A identificação do modelo de processo as-is é importante para ter uma boa ideia do processo atual e poder projetar melhorias no modelo de processo to-be. O modelo de processo to-be é complementado com a especificação de requisitos que define as funções que deverão ser implementadas como uma solução orientada a serviços. A fase de modelagem fornece insumos alinhados ao negócio para o detalhamento dos serviços na fase de análise.

5

Análise Objetivo O objetivo deste capítulo é apresentar a fase de análise, onde os serviços são detalhados até a análise de sua possível realização. Na fase de análise, são identificados serviços candidatos a partir do modelo de processo to-be. Ainda nesta fase, decide-se como cada serviço será realizado, analisando-se possibilidades de reuso para cada um, chegando a um conjunto de serviços finais. A Figura 5.1 apresenta as atividades de identificação de serviços candidatos, a análise de gap e a análise de realização da fase de análise, descritas a seguir.

Conteúdo 5.1 5.2 5.3 5.4

Identificação de serviços candidatos Análise de gap Análise de realização Considerações do capítulo

75 84 91 97

5.1 IDENTIFICAÇÃO DE SERVIÇOS CANDIDATOS Papel: analista de serviços Artefatos utilizados: modelo de processo to-be, especificação de requisitos (caso de uso de negócio, regras de negócio, requisitos não funcionais) Artefatos gerados: modelo de serviços candidatos A atividade de identificação de serviços candidatos, conforme apresentada na Figura 5.2, é a primeira atividade de análise, e recebe como entrada um modelo de processo to-be e a especificação de requisitos (caso de uso de negócio, regras de negócio e requisitos não funcionais). A partir do modelo de processo to-be, o analista de serviços deve identificar atividades, passos, funções que podem ser executadas por serviços, mais especificamente,

75

76


Figura 5.1 Atividades da fase de análise.

Figura 5.2 Identificação de serviços candidatos.

invocando-se operações de serviços. Em outras palavras, são pontos do processo em que uma operação de um serviço poderia ser invocada para executar determinada lógica. Estas atividades, os passos e as funções serão considerados operações candidatas, ou seja, porções de lógica que podem ser transformadas em operações de serviços. Já nos casos de uso de negócio, o analista de serviços deve identificar, dentre os passos do fluxo de eventos atribuídos ao ator sistema, aqueles que podem vir a ser executados por operações de serviços, originando mais operações candidatas. As regras de negócio devem ser analisadas em conjunto com os modelos de processo to-be e casos de uso, pois estão associadas a eles. Caso uma tarefa de processo ou evento de caso de uso dê origem a uma operação candidata, as regras de negócio associadas à tarefa ou evento devem ser associadas também à operação candidata.

5 Análise

77

5.1.1 Decompor processos de negócio Nessa etapa, o analista de serviços deverá analisar o modelo de processo to-be e identificar pontos em que serviços poderiam apoiar o processo. São pontos do processo em que uma operação de um serviço poderia ser invocada para executar determinada lógica. Conforme descrito na Seção 4.2, as tarefas podem ser detalhadas por uma descrição em texto corrido ou por uma sequência de passos. Seja qual for a maneira adotada, o modelo de processo é decomposto em passos de menor granularidade, sendo que cada passo representa uma função simples que é executada por um ator do processo, seja usuário ou sistêmico. Em uma solução orientada a serviços, as tarefas de um processo poderão ser automatizadas por operações de serviço sendo executadas. Desse modo, o analista de serviços deve decompor o modelo de processo to-be em uma série de passos de baixa granularidade e então analisar cada passo e identificar quais deles podem ser automatizados por uma invocação de um serviço. De modo geral, todo passo sistêmico é um candidato a se tornar uma invocação a um serviço. Dependendo da forma como o processo é documentado pelos analistas de processos, a descrição de uma mesma atividade pode conter tanto passos manuais executados por atores humanos quanto passos sistêmicos executados por aplicações existentes ou a serem desenvolvidas. Mas, geralmente, consegue-se separar claramente tarefas puramente humanas de tarefas puramente sistêmicas. De qualquer modo, após a decomposição, cada etapa deve ser avaliada independentemente para se determinar se é humana ou sistêmica. Nesta atividade de identificação, cada etapa sistêmica é mapeada para uma operação candidata. Passos e tarefas não computacionais (execução de tarefas humanas) do processo não serão consideradas nesta etapa, pois não poderão ser executados por operações de serviços. O analista de serviços deve considerar que o nível de granularidade dessas operações candidatas pode variar, desde tarefas completas do ponto de vista do processo de negócio até funções atômicas de sistemas. Deste modo, considera-se que as operações de um serviço podem corresponder diretamente com uma tarefa inteira do processo ou corresponder a apenas uma etapa da lógica envolvida em uma tarefa identificada em um modelo de processo de negócio. Na Figura 5.3, as tarefas A, B e C do modelo de processo foram decompostas em etapas. Após análise, identificou-se a etapa 3 da Tarefa A como sendo uma etapa sistêmica, dando origem a uma operação candidata. Já no caso da Tarefa B, verificou-se ser possível sua automação por uma única operação candidata, porém, de maior granularidade. E, finalmente, na Tarefa C, as etapas 8 e 9 foram identificadas como candidatas a operações de serviços. Pode-se notar a partir deste exemplo que, dependendo do nível de granularidade das tarefas de um processo e do tipo de lógica executada em cada etapa, operações candidatas podem ser identificadas de maneiras diferentes. É importante ressaltar que as operações identificadas nesse ponto do ciclo de vida não devem necessariamente ser implementadas como descritas no modelo de processo

78


Figura 5.3 Níveis de granularidade de operações identificadas. to-be. As operações identificadas nesta atividade são apenas candidatas, uma vez que

ainda serão analisadas e revisadas, antes de sua especificação e implementação. Alguns exemplos de etapas de processo que podem ser identificadas como operações candidatas são: ● ●

● ● ● ● ● ●

consulta em uma base de dados ou sistema legado; processamento sistêmico de informações (envio de e-mails, geração de relatórios ou massas de dados, manipulação de objetos ou registros); aplicação de regras de negócio; inserção ou atualização de informações em uma base de dados ou sistema legado; resposta a um comando executado por um usuário na interface consumidora; busca de dados para popular um formulário exibido para o usuário; integração ou troca de informações com outro sistema/domínio/organização; validação de dados.

A operação candidata está relacionada a uma operação computacional, portanto, deve-se observar se, dentro das formas de descrição das atividades de negócio, as atividades são passíveis e relevantes para serem automatizadas. Por exemplo, no caso do processo de venda de produtos (Figura 3.3), na atividade “Abrir Pedido”, as operações de envio de pedido pelo cliente e de recebimento do pedido pelo atendente podem ser consideradas como atividades humanas, assim, não precisam necessariamente ser automatizadas. O analista de serviços deve listar e descrever todas as operações candidatas identificadas. As operações candidatas podem ser documentadas no modelo de serviços.

5.1.2 Decompor casos de uso de negócio Em um caso de uso de negócio, o analista de serviços analisa as descrições dos fluxos de eventos, separando os passos executados pelos atores usuários dos passos automatizados, ou seja, executados pelo ator “Sistema”, representando a solução orientada a serviços. Geralmente, em uma descrição de fluxo de eventos de um caso de uso, utiliza-se uma sequência de passos, cada passo executado por um ator. Os atores envolvidos em um caso de uso podem ser pessoas (usuários de um sistema ou participantes da lógica de negócio) ou sistemas e aplicações.

5 Análise

79

Uma prática comum ao se escrever esse tipo de caso de uso é referir-se à solução orientada a serviços como um todo por meio do ator “Sistema”. Assim, eventos do caso de uso que forem automatizados pela solução serão associados ao ator “Sistema”. Durante a fase de análise é que será definido qual elemento da solução orientada a serviços (serviço ou aplicação legada) ficará responsável por executar cada evento. Na identificação inicial, pode-se criar uma relação direta entre as etapas cujo ator é o “Sistema” e uma operação de serviço. Neste caso, a solução orientada a serviços como um todo é representada pelo ator “Sistema”. Assim, como na decomposição de processo de negócio, o analista de serviços deve registrar no modelo de serviços as operações candidatas identificadas nessa etapa. A Figura 5.4 representa o fluxo de eventos de um caso de uso por meio de um diagrama de sequência. Neste exemplo, temos dois eventos que envolvem a interação de um dos atores usuários com o ator “Sistema”, sendo portanto identificados como operações candidatas.

5.1.3 Agrupar operações candidatas O analista de serviços deve listar os passos que serão automatizados, de modo que cada um destes passos poderá ser mapeado para uma operação de um serviço sendo invocada. As operações relacionadas devem ser agrupadas, de modo que cada grupo de operações pertença a um serviço candidato. Devem ser agrupadas operações que compartilhem um mesmo contexto lógico (semântico) ou que trabalhem com as mesmas entidades de dados (Erl, 2005). Em caso

Figura 5.4 Identificação de operações candidatas a partir de caso de uso.

80


de operações identificadas a partir de um modelo de processo, podem ser agrupadas operações executadas por um mesmo papel. Em caso de operações identificadas de um caso de uso, podem ser agrupadas operações relacionadas a um mesmo ator do caso de uso. Ao agruparem-se as operações candidatas, o analista de serviços deve procurar obter coesão no conjunto de serviços candidatos identificados. Para tal, recomenda-se aplicar o design pattern Service Normalization (Normalização de Serviços) (Erl, 2009), segundo o qual não pode haver sobreposição de funcionalidade entre serviços. Cada serviço deve possuir um escopo funcional bem claro e definido, tornando-se o ponto único de acesso à funcionalidade que ele provê. Para agrupar as operações candidatas, o analista de serviços pode utilizar os seguintes critérios: 5.1.3.1 Operações candidatas agrupadas segundo contexto lógico

Um dos critérios mais diretos para se agrupar operações é por semelhança na lógica executada por cada uma delas. Operações que possuam funções relacionadas podem ser agrupadas para dar origem a um serviço. Por exemplo, em um processo de negócio que envolve a geração de notas fiscais, podem ser identificadas diversas operações candidatas com a função de calcular os impostos a serem recolhidos, sendo uma operação para cada tipo de imposto (imposto de renda, sobre mercadorias, sobre serviços, entre outros). Por possuírem funções lógicas semelhantes, estas operações podem ser agrupadas em um serviço candidato chamado “Cálculo de Imposto” ou “Calcular Imposto”, conforme a Figura 5.5. Geralmente, serviços candidatos agrupados segundo esse critério darão origem a serviços de tarefa ou serviços utilitários, dependendo do nível de granularidade. 5.1.3.2 Operações candidatas agrupadas por entidade de dados

Outro critério para agrupamento de operações candidatas é o tipo de dado que elas manipulam. Operações candidatas que envolvem acesso a dados persistentes em algum tipo de base de dados ou sistema operacional podem ser agrupadas de acordo com as entidades de dados acessadas. Geralmente, são operações análogas a uma inserção, atualização, exclusão ou busca de dados em uma tabela. Nesse caso, agrupam-se operações candidatas que manipulem as mesmas entidades de dados.

Figura 5.5 Exemplo de serviço candidato agrupado segundo função lógica.

5 Análise

81

Figura 5.6 Exemplo de serviço candidato agrupado por entidade de dados.

O exemplo clássico desse tipo de agrupamento são as operações candidatas que acessam um cadastro de clientes, presentes em processos de negócio de diferentes domínios. Operações candidatas que inserem um novo cliente no cadastro ou que atualizam os dados de um cliente existente podem ser agrupadas em um serviço chamado “Cliente”, conforme a Figura 5.6.

5.1.4 Descrever serviços candidatos Nesta etapa, o analista de serviços deve documentar no modelo de serviços os serviços candidatos criados. Nesse momento, ainda não estão sendo considerados os requisitos não funcionais que afetam o tipo de serviço a ser desenvolvido. O importante neste ponto do ciclo de vida é descrever claramente a função lógica executada por cada operação candidata, descrever os dados de entrada utilizados para executar a função e os dados de saída gerados como resultado. Na descrição dos dados, deve-se procurar explicitar os campos e seus tipos de dados (texto, valor numérico, data, estrutura de dados etc.) e, se possível, o formato também. Nas operações identificadas a partir de casos de uso, devem ser descritas as funções executadas pelo ator “Sistema”, bem como especificar os dados informados pelo usuário a cada operação e os dados retornados pelo “Sistema” como resultado da execução. O analista de serviços deve também registrar no modelo de serviços as regras de negócio associadas às operações candidatas. Dicas Assim como na fase de modelagem, mantenha consistência na nomenclatura dos serviços ● e operações candidatas, se possível, mantendo o mesmo vocabulário. A decomposição em etapas de baixa granularidade é importante para que as operações ● candidatas identificadas representem porções de lógica agnóstica, isto é, sem características específicas do contexto onde se encontram (processo de negócio ou caso de uso). Exemplo Uma vez definido o modelo de processo “to-be” e a especificação de requisitos (casos de uso de negócio, regras de negócio e requisitos não funcionais) do processo de consulta médica da clínica MEDSOA, o analista de serviços recebe esses artefatos gerados para realizar a análise orientada a serviços.

82

SOA: Modelagem, Análise e Design Na análise do modelo de processo “to-be”, algumas operações candidatas podem ser identificadas diretamente a partir das tarefas associadas ao ator “Sistema”. Neste caso, temos operações candidatas identificadas no nível de granularidade de tarefas de processo. As operações identificadas, deste modo, são as seguintes, separadas por subprocesso: Subprocesso agendamento obter paciente pelo nome; inserir paciente; obter datas disponíveis na agenda; inserir consulta na agenda. Subprocesso atendimento enviar notificação; obter prontuário de paciente; gerar prescrição; atualizar prontuário de paciente. Subprocesso pagamento gerar fatura para convênio; registrar pagamento no caixa. Para identificação das operações de menor granularidade, é necessário decompor as descrições das tarefas. Por exemplo, decompondo-se a descrição da tarefa “Prescrever medicamentos e exames” descrita anteriormente, poderíamos chegar aos seguintes passos:

1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

O médico acessa no sistema a função de “Geração de Prescrição”. O médico busca medicamentos pelo nome. O médico seleciona o medicamento desejado. O sistema adiciona à prescrição as seguintes informações: nome comercial do medicamento, nome do princípio ativo, frequência de administração, forma de administração, dose ou quantidade. O médico busca exames pelo nome. O médico seleciona o exame desejado. O sistema adiciona à prescrição as seguintes informações: nome do exame, instruções de preparação para o exame. O médico imprime uma prescrição de medicamentos. O médico imprime uma prescrição de exames. O médico imprime entrega prescrições ao paciente.

Observe que a descrição em passos de baixa granularidade é bastante semelhante a um fluxo de eventos de um caso de uso. Por esse motivo, recomenda-se estruturar a descrição das tarefas do processo em passos e a especificação de casos de uso para complementar os diagramas do processo. Partindo-se desses passos, são identificadas as seguintes operações candidatas: ● ● ● ● ● ●

obter medicamentos pelo nome (passo 2); adicionar medicamento à prescrição (passo 4); obter exames pelo nome (passo 5); adicionar exame à prescrição (passo 7); gerar prescrição de medicamentos (passo 8); gerar prescrição de exames (passo 9).

Já no caso de uso “Agend ar Consulta” (descrito anteriormente), a partir dos eventos associados ao ator “Sistema”, podem ser identificadas as seguintes operações candidatas:

5 Análise

● ● ● ●

obter todos os médicos (evento 3); obter médico pelo nome (evento 3); obter datas disponíveis na agenda (evento 5, já identificada no nível de tarefa); inserir consulta na agenda (evento 9, já identificada no nível da tarefa).

Note que temos duas operações que já haviam sido identificadas pela análise inicial, no nível de granularidade de tarefa, mas há duas outras que só puderam ser identificadas devido ao detalhamento do caso de uso. Já no fluxo alternativo do caso de uso, podem ser identificadas mais algumas operações candidatas: ● ● ●

obter especialidades médicas (evento 4); obter médico por especialidade (evento 5); obter datas disponíveis na agenda (evento 6, já identificada anteriormente).

Após identificadas todas as operações candidatas necessárias ao processo, o analista de serviços realiza o agrupamento das operações candidatas em serviços candidatos (Figura 5.7). Alguns serviços são agrupados por entidade de dados (paciente, médico, agenda), enquanto outros são agrupados por função lógica (caixa, prescrição). Definidos os serviços candidatos, o analista de serviços os documenta e os descreve no modelo de serviços. A seguir, um exemplo de descrição de um serviço candidato e de uma de suas operações candidatas. Serviço “Agenda” Serviço responsável por gerenciar as agendas de consultas dos médicos da clínica MEDSOA. Operação: inserir consulta na agenda. Dados de entrada: identificação de médico, identificação de paciente, data e hora da consulta. Dados de saída: mensagem de confirmação de agendamento ou erro. Descrição da lógica: insere na agenda do médico selecionado (pelo identificador) um registro de consulta para o paciente selecionado (pelo identificador) na data e hora selecionadas. Caso o registro seja inserido com sucesso, retorna uma mensagem de sucesso. Caso já exista alguma consulta na data e hora selecionadas, retorna uma mensagem de erro.

Figura 5.7 Serviços candidatos identificados.

83

84


5.2 ANÁLISE DE GAP Papel: analista de serviços Artefatos utilizados: modelo de serviços candidatos, documentação de aplicações legadas e registro de serviços Artefatos gerados: não aplicável Um dos principais benefícios buscados com a adoção de SOA é o aumento no reuso de recursos existentes. Para tal, além de se garantir que os serviços possuam características de reusabilidade, é essencial que o método de desenvolvimento preveja a avaliação de serviços ou outros recursos existentes para reuso na construção de novas soluções orientadas a serviços. A atividade de análise de gap, conforme pode ser vista na Figura 5.8, tem como objetivo comparar os serviços candidatos identificados com os recursos já existentes na infraestrutura de TI da organização e avaliar as possibilidades de reuso (Papazoglou; Van den Heuvel, 2006). Para cada operação candidata (pertencente a um serviço candidato), o analista de serviços deve verificar se já existe algum serviço no portfólio ou aplicação de software legada que execute total ou parcialmente sua funcionalidade. Para realizar esta busca, podem ser consultados o registro de serviços da organização, os repositórios de recursos reusáveis ou as documentações de aplicações legadas. Também podem ser avaliados para reuso serviços providos por parceiros externos através da nuvem (cloud services).

Figura 5.8 Análise de gap.

5 Análise

85

Baseado nessa busca, o analista de serviços poderá analisar as possibilidades de reuso e identificar eventuais gaps para o reaproveitamento de um recurso existente. Geralmente, pode-se classificar o gap existente em uma das seguintes opções: ●

●

●

●

gap de lógica – o recurso existente não realiza todas as etapas de lógica necessárias

para a operação candidata; gap de dados – o recurso existente não retorna todos os dados de saída necessários para a operação candidata; gap de formato – o recurso existente trabalha com formato de dados ou esquemas de mensagens diferente do consumidor de serviço candidato; gap de protocolo – o recurso existente é invocado através de um protocolo de comunicação diferente do utilizado pelo consumidor de serviço candidato.

5.2.1 Identificar cenário de reuso Ao se analisar o reuso de um recurso existente para uma operação candidata, deve-se verificar se a operação ou aplicação legada existente executa todas as funções descritas para a operação candidata, se atende a todos os requisitos funcionais e não funcionais relacionados e se entrega todos os dados de saída esperados, ou se há algum tipo de gap. Assim, dependendo do resultado de tal análise, para cada operação analisada, pode-se identificar um dos seguintes cenários de reuso descritos a seguir. 5.2.1.1 Operação realizada por um serviço

Nesse cenário de reuso, não há gap, pois a funcionalidade da operação avaliada já está implementada por um serviço existente no portfólio de serviços da organização ou provido por um parceiro, que pode então ser reusado. Este cenário ocorre quando a operação do serviço existente executa exatamente a lógica necessária para a operação candidata, recebendo os mesmos dados de entrada e retornando os mesmos dados de saída, conforme a Figura 5.9. 5.2.1.2 Operação realizada parcialmente por um serviço

A funcionalidade da operação avaliada é parcialmente realizada por um serviço existente. O serviço pode ser reusado, mas será necessário alterar o serviço existente ou implementar uma mediação para utilizar o serviço. Este cenário ocorre quando o serviço existente possui uma operação que realiza apenas parte da função necessária para a operação candidata ( gap de lógica) ou retorna apenas parte dos dados de saída esperados (gap de dados), conforme a Figura 5.10. 5.2.1.3 Operação realizada por uma aplicação legada

A funcionalidade da operação avaliada já está implementada por uma aplicação legada. Para poder ser usada pelo processo, esta funcionalidade deverá ser encapsulada na forma de um serviço. Este cenário ocorre quando a aplicação legada existente executa exatamente a lógica necessária para a operação candidata, recebendo os mesmos dados de entrada e retornando os mesmos dados de saída. Considera-se

86


Figura 5.9 Operação candidata realizada por serviço existente.

Figura 5.10 Operação candidata realizada parcialmente por serviço existente.

aplicação legada qualquer componente de software, função, rotina, aplicação pacote ou ferramenta que não possua um contrato de serviço e que não faça parte do portfólio de serviços da organização. Deste modo, mesmo não apresentando gap de lógica ou de dados, este cenário de reuso é caracterizado por algum tipo de gap de formato ou protocolo, conforme a Figura 5.11.

5 Análise

87

Figura 5.11 Operação candidata realizada por aplicação legada. 5.2.1.4 Operação realizada parcialmente por uma aplicação legada

A funcionalidade da operação avaliada é parcialmente realizada por uma aplicação legada. Para poder ser usada pelo processo, esta funcionalidade deverá ser encapsulada na forma de um serviço e deverá ser implementado algum tipo de lógica de mediação ou integração. A aplicação legada existente possui alguma rotina que realiza apenas parte da função necessária para a operação candidata ou retorna apenas parte dos dados de saída esperados. Sendo assim, além de gaps de formato ou de protocolo presentes em um cenário de reuso de aplicação legada, este cenário apresenta também algum gap de lógica ou de dados, conforme a Figura 5.12. 5.2.1.5 Operação não existente

A funcionalidade da operação não existe em nenhum recurso disponível e deve, portanto, ser realizada por um novo serviço a ser criado ou por uma nova operação a ser criada para um serviço existente, conforme a Figura 5.13. Para os casos em que a operação candidata é atendida apenas parcialmente, devem-se documentar as diferenças ( gaps ) encontradas. Estas informações serão importantes para as próximas atividades.

5.2.2 Revisar serviços candidatos O agrupamento das operações candidatas em serviços pode necessitar ser revisado em vista do resultado da análise de gap. Serviços candidatos podem ser alterados

88


Figura 5.12 Operação candidata realizada parcialmente por aplicação legada.

Figura 5.13 Operação candidata não existente.

5 Análise

89

caso haja sobreposição com algum serviço já existente. Por exemplo, uma operação que já é realizada por um serviço existente passará a pertencer a ele. Ou ainda, uma nova operação a ser criada pode pertencer ao mesmo contexto lógico de um serviço existente, sendo, portanto, acrescentada a ele. Dicas Ao revisar o agrupamento, lembre-se do design pattern Service Normalization (Normalização ● de Serviços) (Erl, 2009). A participação do analista de serviços durante a modelagem de processo to-be visa ● maximizar o reuso de serviços existentes e minimizar os gaps. O analista de serviços pode prover o analista de processos com conhecimento sobre o portfólio de serviços da organização e aplicações legadas existentes, direcionando a definição do modelo de processo to-be.

Exemplo O analista de serviços da clínica MEDSOA inicia uma análise dos recursos já existentes com o objetivo de localizar alguma função, componente ou provedor de serviço que possa ser reusado para realizar as operações dos serviços candidatos identificados. Para proceder com a análise de gap, o analista de serviços consulta a documentação disponível dos programas e aplicações legadas existentes e faz uma prospecção de provedores de serviços na nuvem. Como a clínica MEDSOA ainda não possui soluções orientadas a serviços implementadas, não há um portfólio de serviços a ser consultado. Caso já existisse, o registro de serviços deveria também ser avaliado para reuso. Como resultado da análise comparativa entre as funções encontradas nos recursos existentes e as funções necessárias para os serviços candidatos, identificam-se os gaps a serem resolvidos. O analista de serviços, então, classifica os gaps em um dos cenários de reuso. Durante a atividade, o analista de serviços descobre que na clínica MEDSOA já existe um aplicativo pacote de CRM utilizado para armazenar os dados cadastrais de pacientes. Por trabalhar com dados de pacientes, o aplicativo CRM foi avaliado para realização das operações do serviço candidato “Paciente”. No entanto, o aplicativo CRM não era voltado à área médica e, por isso, possuía apenas funções de acesso a dados cadastrais dos pacientes, mas não a dados médicos e prontuários. O aplicativo CRM precisa de uma API para possibilitar a integração com outros sistemas. Deste modo, o analista de serviços estuda a documentação desta API para avaliar o reuso. Para a operação candidata “Obter paciente pelo nome”, a API do aplicativo CRM possui duas funções semelhantes que poderiam ser reusadas: “buscarClientePorNome” e “buscarClientePorSobrenome”. Como o aplicativo CRM armazena o nome e o sobrenome dos clientes em campos separados, sua API possui funções separadas de busca por nome e por sobrenome. A operação candidata, no entanto, considera o nome e o sobrenome como um único campo, permitindo que pacientes sejam encontrados informando o nome ou o sobrenome. Já para a operação candidata “Inserir paciente”, o aplicativo CRM possuía em sua API a função “adicionarCliente”, que poderia ser reusada. As outras operações do serviço candidato não existiam na API, pois o CRM não trabalhava com dados de prontuário. Desse modo, foram identificados os seguintes cenários de reuso para as operações do serviço candidato “Paciente”: ●

obter paciente pelo nome — operação realizada parcialmente por aplicação legada (funções “buscarClientePorNome” e “buscarClientePorSobrenome” do aplicativo CRM);

90


TABELA 5.1 Cenários

de reuso para as operações candidatas

Serviço candidato

Operação candidata

Cenário de reuso

Paciente

Obter paciente pelo nome

Operação parcialmente realizada por aplicação legada (aplicativo CRM)

Inserir paciente

Operação realizada por aplicação legada (aplicativo CRM)

Obter prontuário de paciente

Operação não existente

Atualizar prontuário de paciente


Obter todos os médicos


Obter médico pelo nome


Obter todas as especialidades médicas


Obter médico por especialidade


Obter datas disponíveis na agenda


Inserir consulta na agenda


Adicionar medicamento a prescrição


Gerar prescrição de medicamento


Medicamento

Obter medicamento pelo nome


Exame

Obter exame pelo exame


Notificação

Enviar notificação

Operação realizada por serviço existente (provedor de serviço na nuvem)

Caixa

Registrar pagamento


Gerar fatura para convênio


Médico

Agenda

Prescrição

●

● ●

inserir paciente — operação realizada por aplicação legada (função “adicionarCliente” do aplicativo CRM); obter prontuário de paciente — operação não existente; atualizar prontuário de paciente — operação não existente.

O analista de serviços documenta no modelo de serviços os cenários de reuso identificados, junto às descrições de cada operação candidata. Além do aplicativo CRM, o analista de serviços avaliou também a utilização de provedores externos para realização do serviço candidato “Notificação”, que deveria enviar mensagens de

5 Análise

91

texto ao telefone celular do paciente para lembrá-lo da consulta. O analista de serviços pesquisa por provedores de serviços de mensageria na nuvem, obtém informações sobre seus contratos de serviços e conclui que um serviço na nuvem poderia ser reusado para realizar a operação candidata “Enviar notificação”. Já para os demais serviços candidatos, a clínica MEDSOA não possuía nenhuma aplicação legada para atender, nem foram encontrados provedores de serviços adequados na nuvem. Portanto, para as operações candidatas restantes, o cenário de reuso identificado foi “Operação não existente”. A Tabela 5.1 resume os cenários de reuso identificados para todas as operações candidatas.

5.3 ANÁLISE DE REALIZAÇÃO Papéis: analista de serviços, gerente de projeto, arquiteto corporativo Artefatos utilizados: cenários de reuso Artefatos gerados: modelo de serviços e decisões de realização Uma vez identificados os cenários de reuso para cada operação candidata em relação aos recursos existentes, devem então ser analisadas as alternativas de realização possíveis para cada uma delas e decidir qual será adotada para realizar o serviço. A análise de realização, conforme a Figura 5.14, tem por objetivo avaliar as alternativas para realização de cada operação candidata em termos de viabilidade técnica, custos, riscos técnicos e de projeto, esforço e ROI. Para esta tomada de decisão, o analista de serviços pode contar com o apoio do gerente de projetos e do arquiteto corporativo.

Figura 5.14 Análise de realização.

92


5.3.1 Definir realização de serviços Para cada cenário de reuso identificado, as seguintes considerações devem ser feitas: 5.3.1.1 Operação realizada por um serviço

Não é necessário especificar um novo serviço ou operação, uma vez que o serviço existente poderá ser utilizado diretamente pelo processo de negócio sem a necessidade de alteração ou integração. Este é o cenário com menor risco de ser realizado, acarretando apenas no custo de reuso. É também o cenário que aumenta o retorno sobre o investimento já realizado anteriormente. A alternativa de realização neste cenário é a seguinte: ●

Reusar serviço existente – deve ser obtido o contrato do serviço existente, para que o consumidor possa implementar o acesso ao serviço.

Para se manter a governança do ciclo de vida dos serviços, ao se reusar um serviço existente, é necessário que seja estabelecido um entendimento entre o provedor do serviço e o novo consumidor. O provedor de serviço deve ser notificado sobre o incremento no uso do serviço, devendo se assegurar de que possui os recursos computacionais para atender à nova demanda com a qualidade de serviço especificada nas políticas e SLAs do contrato do serviço. Por sua vez, o novo consumidor do serviço deve estar ciente das políticas e condições de uso do serviço e assegurar conformidade com elas. Este acordo entre provedor e consumidor deve ser plenamente estabelecido para que o reuso seja possível. 5.3.1.2 Operação realizada parcialmente por um serviço

Nesse cenário, existe um gap de lógica ou de dados entre o serviço existente e o serviço candidato identificado. Dependendo do tipo de gap encontrado entre a operação candidata e a existente, diferentes opções podem ser analisadas. Nesse cenário de reuso, as seguintes alternativas de realização podem ser avaliadas para resolução do gap: ●

●

Alterar o serviço candidato – uma vez identificado um serviço existente, pode-se alterar a definição da operação candidata identificada para que ela se adeque ao contrato já definido. No entanto, esta alteração pode afetar o modelo de processo ou caso de uso a partir do qual a operação candidata foi identificada e exigir uma revisão. Apesar de representar certo retrabalho sobre o que foi produzido na fase de modelagem, este tipo de revisão garante um alinhamento maior entre o modelo de processo e os serviços existentes. Além disso, o custo de uma alteração em um requisito ou em um modelo de negócio tende a ser menor do que uma alteração em algo já implementado e em operação. Alterar o serviço existente – em caso de gap de lógica ou de dados, pode-se alterar o serviço existente para que ele se adapte ao serviço candidato. Esta alternativa traz um risco a ser considerado, pois alterações em um serviço podem impactar seus consumidores já existentes. Portanto, sempre que se optar pela alteração do serviço, deve-se analisar os possíveis impactos destas alterações. Caso a alteração afete o contrato do serviço existente, recomenda-se criar uma

5 Análise

●

93

nova versão do serviço (Erl, 2008). Neste caso, como a alteração afeta o contrato, nova consequentementee atinge consumidores existentes do serviço. Para minimizar consequentement o impacto, pode-se criar uma operação adicional no serviço, que execute toda a lógica necessária para a operação candidata, ou apenas a lógica faltante. Implementar mediação – uma alternativ alternativaa de realização comum comum nesse cenário é implementar um componente de mediação para reusar o serviço em seu estado atual. A mediação seria um agente intermediário que encapsularia o acesso ao serviço existente, resolvendo eventuais gaps. Em caso de gap de lógica, a mediação poderia implementar as etapas lógicas não realizadas pela operação existente, ou invocar uma outra operação (do mesmo serviço ou de outro outr o serviço existente) que implementasse as etapas faltantes. Em caso de gap de dados, a mediação poderia gerar as informações faltantes ou poderia buscá-las em outra fonte, como outra operação de serviço ou uma base de dados (aplicação legada).

5.3.1.3 Operação realizada por uma aplicação legada

Esse cenário exige a criação de um serviço que encapsule a funcionalidade da aplicação legada e resolva os gaps de formato ou protocolo. Algumas alternativas de realização possíveis neste cenário são: ●

●

●

Expor aplicação legada como como serviço – pode-se propor a criação de um um novo novo componente de serviço que encapsule o acesso à aplicação legada. Os gaps de formato e protocolo devem ser resolvidos pelo componente de serviço invocando o legado através de adaptadores de integração integraçã o ou APIs. Para tal, estes adaptadores ada ptadores e APIs devem ser compatíveis com a tecnologia de implementação do componente de serviço. Caso contrário, dev devem-se em-se avaliar a viabilidade técnica e o custo de se implementar este acesso por outros meios. Implementar mediação – pode-se utilizar uma mediação para encapsular o acesso à aplicação legada. Para solucionar gaps de formato ou protocolo, a mediação tem como objetivo traduzir as mensagens de um formato para outro (através de mapas de mensagens) ou realizar a conversão de protocolos de comunicação (através de adaptadores) para que o consumidor possa utilizar o serviço. Implementar component componentee de serviço serviço – pode-se decidir decidir ignorar ignorar a aplicação aplicação legada legada existente e implementar um novo componente componente de serviço para realizar o serviço candidato. Esta alternativa geralmente é escolhida quando a aplicação legada está planejada para descontinuação ou substituição.

5.3.1.4 Operação realizada parcialmente por uma aplicação legada

Nesse cenário, além de gaps de formato e de protocolo decorrentes da integração integraçã o com uma aplicação legada, existem gaps de lógica ou de dados a serem resolvidos. As alternativas alternativas de realização possíveis para este cenário são: ●

Expor aplicação legada como serviço – nesse caso, a solução é semelhante à proposta no cenário de reuso “Operação realizada por aplicação legada”, com a

94

●

●

●

●


diferença de que o componente de serviço encapsulador deve ser construído de modo a resolver os gaps de lógica ou de dados. Implementar mediação – em caso de gap de lógica, a mediação poderia implementar as etapas lógicas não realizadas pela operação existente, ou invocar uma outra operação (do mesmo serviço ou de outro serviço existente) que implementasse as etapas faltantes. Em caso de gap de dados, a mediação poderia gerar as informações faltantes ou poderia buscá-las em outra fonte, como outra operação de serviço ou uma base de dados (aplicação legada). Além disso, a mediação deve resolver os gaps de formato e protocolo para acesso à aplicação legada. Alterar aplicação legada legada – uma alternativa alternativa possível é alterar a aplicação legada para solucionar os gaps de lógica ou dados com relação à operação candidata. Ainda assim, torna-se necessária a criação de um componente de serviço encapsulador ou de uma mediação para resolver os gaps de formato ou protocolo. Deve-se avaliar avaliar se os custos e os impactos tornariam esta alternativ alternativaa viável. Implementar componente de serviço – semelhante ao cenário “Operação realizada por aplicação legada”. Alterar serviço candidato – essa alternativa alternativa envolve envolve alterar a operação candidata identificada para se adequar à aplicação legada, eliminando gaps d dee lógica e de dados. Ainda assim, os gaps de formato e de protocolo deverão ser resolvidos criando-se um componente de serviço ser viço encapsulador ou uma mediação. Consequentemente, podem ser necessários ajustes no modelo de processo ou no caso de uso que originou a operação candidata. Geralmente, não se recomenda esta alternativa por gerar um acoplamento indesejado entre o serviço candidato e a aplicação legada, que pode se propagar até o processo de negócio.

5.3.1.5 Operação não existent existente e

Nesse cenário, como não há nenhum tipo de recurso existente sendo reusado, a operação candidata deve ser criada a partir do zero. A única alternativa alternativa de realização é: Implementar componente componente de serviço – a alternativa alternativa é implementar um novo novo componente de serviço ou uma nova operação em um componente de serviço já existente. Como a operação deverá deverá ser implementada a partir do zero, o risco é baixo, pois se tem controle sobre sua especificação e realização. O custo resume-se ao esforço necessário para se especificar e implementar a nova funcionalidade. Para cada cenário de reuso, ainda podem ser levantadas outras alternativas de realização específicas de cada caso analisado. Caso a análise de realização tenha dado origem a novas operações ou serviços, estes devem ser descritos no modelo de serviços do mesmo modo que os serviços identificados identifica dos anteriormente. ●

5 Análise

95

5.3.2 Analisar viabilidade e arquitetura Após a análise das alternativas de realização para todas as operações candidatas, o analista de serviços deve ponderar sobre cada uma delas para tomar as decisões de como cada serviço será realizado. Para a tomada da decisão final, é importante o apoio do gerente de projetos, pois são avaliados aspectos como risco, custo e esforço, esf orço, e do arquiteto corporativo, pois pode haver alterações em aplicações e serviços existentes. O gerente de projeto participa dessas decisões, pois é o responsáve responsávell por administrar o escopo, os custos e os prazos do projeto de implementaçã implementaçãoo da solução orientada a serviços. O gerente de projetos procura viabilizar as decisões dentro das limitações de custos e prazos do projeto. Já o arquiteto corporativo corporativo deve assegurar que as decisões de realização tomadas pelo analista de serviços estejam de acordo com os padrões de arquitetura e governança da organização e garantir que os serviços finais definidos possam integrar o portfólio de serviços da organização de forma consistente. Caso seja definida uma alternativa de realização viável, a atividade prossegue com a especificação dos serviços. Caso contrário, os resultados da análise de realização devem deve m ser passados para o analista de processos para que a modelagem de processo to-be seja revisada e as atividad atividades es de análise repetidas. r epetidas.

5.3.3 Revisar serviços candidatos Dependendo das alternativas alternativas de realização r ealização escolhidas, pode ser necessário atualizar o modelo de serviços para refletir as alterações definidas no conjunto de serviços e operações candidatos. Alguns exemplos de alterações ocasionadas pela análise de realização: ● ● ● ●

Substituição do serviço candidato proposto pelo serviço existente existente a ser reusado. Criação de nov novas as operações para solucionar gaps de lógica e de dados. Criação de de novas novas operações ou serviços serviços para encapsular acesso ao legado. Revisão do agrupamento agrupamento das operações nos serviços devido devido às decisões de realizações. Por exemplo, podem ser agrupadas operações que são realizadas pela mesma aplicação legada.

Com as decisões de realização tomadas e as alterações definidas, os serviços deixam de ser “candidatos” e tornam-se efetivamente efetivamente serviços que integrarão o portfólio da organização organização.. Dicas Aplique os design patterns Version Identification (Identificação de Versão) Versão) e Canonical ● Versioning (Versionamento (Versionamento Canônico) (Erl, 2009), de modo a garantir que todos os contratos de serviços sejam versionados de acordo com os mesmos padrões. O reagrupamento de operações por aplicação legada reusada deve ser aplicado com ● parcimônia para evitar que isso gere um acoplamento do serviço com a aplicação legada.

96

SOA: Modelagem, Análise e Design Exemplo Na análise de gap, foram identificados recursos reusáveis para realizar os serviços candidatos “Paciente” e “Notificação”. O analista de serviços, então, avalia as alternativas de realização para cada um deles. Para a operação “Obter paciente pelo nome” do serviço “Paciente”, que foi considerada parcialmente por uma aplicação legada (as funções “buscarClientePorNome” e “buscarClientePorSobrenome” do aplicativo CRM), foram consideradas as seguintes alternativas de realização: Expor a aplicação legada como serviço – essa alternativa consistia em implementar um ● novo componente de serviço que encapsulasse o acesso às duas operações. Como a palavra digitada pelo usuário para realizar a busca poderia ser tanto o primeiro nome quanto o sobrenome de um paciente, a palavra informada como dado de entrada deveria ser utilizada como parâmetro para a invocação das duas funções, e seus resultados seriam retornados pelo componente de serviço como um conjunto único. No entanto, a API exposta pelo aplicativo pacote utilizava uma tecnologia de implementação que não a tecnologia padrão adotada pela clínica MEDSOA. Além disso, o formato dos campos retornados pelo aplicativo CRM era proprietário e necessitaria ser mapeado pelo componente de serviço. ● Implementar mediação – nessa alternativa, seria utilizada uma mediação do ESB para integrar com as funções do aplicativo CRM. A mediação seria responsável por coordenar as chamadas às duas funções do mesmo modo que a alternativa anterior. A diferença é que o ESB da clínica MEDSOA já possuía um adaptador para acessar a API do aplicativo CRM e possui facilidades para construção de mapas de dados. ● Alterar aplicação legada – essa alternativa não foi considerada, pois a clínica MEDSOA não possuía acesso ao código fonte proprietário do aplicativo CRM. ● Implementar componente de serviço – nessa alternativa, os dados contidos no CRM seriam ignorados e seria criado um novo componente de serviço para realizar a operação candidata. O analista de serviços, então, discutiu com o gerente de projeto e o arquiteto corporativo para decidir pela melhor alternativa. A alternativa de expor a aplicação legada como serviço não foi recomendada pelo arquiteto corporativo por envolver a utilização de tecnologia e linguagem de programação que não era a adotada por padrão na organização. Já o gerente de projeto considerou que o esforço para utilizar uma tecnologia não familiar e para implementar o mapeamento de dados seria muito grande. Já alternativa de criar um novo componente de serviço também foi contraindicada pelo arquiteto corporativo, pois resultaria em uma nova fonte de dados de pacientes, gerando redundância funcional entre o serviço e o aplicativo CRM. Esta prática iria contra o design pattern Logic Centralization (Centralização de Lógica). Desse modo, decidiu-se pela alternativa de implementar a mediação. Além de fazer uso de uma ferramenta corporativa recomendada pelo arquiteto corporativo (ESB), esta alternativa foi considerada a mais viável pelo gerente de projeto, pois os requisitos de conectividade com o aplicativo CRM e o mapeamento de dados poderiam ser atendidos pelo ESB com menor esforço do que por um componente de serviço. A mesma análise foi procedida também para a operação candidata “Inserir paciente”, que foi considerada realizada por aplicação legada. As mesmas alternativas de realização foram elencadas, exceto pela alternativa de se alterar a aplicação legada. Como nesta operação candidata, os gaps envolvidos eram somente de dados e de protocolo, a decisão de realização tomada foi a mesma da operação candidata anterior: implementar uma mediação. Já para a operação candidata “Enviar notificação” do serviço “Enviar Notificação”, cujo cenário de reuso identificado foi o de operação realizada por serviço existente, foi considerada apenas a seguinte alternativa de realização: ● Reusar serviço existente – essa alternativa propõe o reuso de um serviço já pronto fornecido por um provedor na nuvem. Para tal, é necessário obter o contrato de serviço dos possíveis provedores e avaliar suas condições de uso.

5 Análise

97

O arquiteto corporativo analisa os contratos técnicos de serviços e recomenda a utilização daqueles que estão definidos segundo os padrões de definição de contrato da clínica MEDSOA. Já o gerente de projeto busca limitar a escolha dos provedores de serviços cujos custos para utilização caibam no orçamento do projeto. Baseado nestas restrições, o analista de serviços seleciona o provedor Cloud Message para o serviço “Enviar Notificação”. Finalmente, para as demais operações de serviços candidatos, que foram identificadas como operações não existentes, a única alternativa de realização considerada é a implementação de novos componentes de serviços. O analista de serviços atualiza no documento de modelo de serviços as decisões de realização e as revisões às operações e serviços que, após esta atividade de análise, deixam de ser considerados candidatos e tornam-se serviços aptos a integrarem o portfólio de serviços da clínica MEDSOA.

5.4 CONSIDERAÇÕES DO CAPÍTULO Neste capítulo foram apresentadas a descrição de serviços candidatos, a avaliação de serviços e os recursos existentes voltados ao seu reuso na construção de soluções orientadas a serviços. Com os cenários de reuso, as operações foram analisadas quanto à sua realização e viabilidade. Com o resultado das análises, o modelo de serviços pode ser revisado. A fase de análise fornece os serviços analisados que serão mais detalhados na próxima fase, ou seja, na fase de design.

6

Design Objetivo O objetivo deste capítulo é apresentar a fase de design onde os serviços são detalhados e especificados em nível suficiente para a sua implementação. Definidos os serviços, inicia-se a fase de design de serviços. O objetivo da fase de design é criar especificações de serviços que satisfaçam aos requisitos do negócio e sejam aderentes aos princípios de orientação a serviços (Erl, 2005). A Figura 6.1 apresenta as atividades de especificação contrato de serviços, especificação de realização de serviços e verificação de princípios da fase de design, conforme descritas a seguir.

Conteúdo 6.1 6.2 6.3 6.4

Especificação de contrato de serviços Especificação de realização de serviços Verificação de princípios Considerações do capítulo

99 107 113 118

6.1 ESPECIFICAÇÃO DE CONTRATO DE SERVIÇOS Papel: arquiteto de serviços Artefatos utilizados: modelo de serviços candidatos Artefatos gerados: contratos de serviços (esquemas de mensagens e interfaces de serviço, políticas e SLAs) A primeira atividade de design é a especificação de contrato de serviços, conforme pode ser vista na Figura 6.2, na qual as interfaces dos serviços serão formalmente definidas e suas operações serão especificadas. Para cada serviço candidato, deverão ser definidas todas as suas operações e as mensagens de entrada e saída envolvidas em cada operação. Caso a tecnologia

99

100


Figura 6.1

Atividades da fase de design.

Figura 6.2

Especificação de contrato de serviços.

utilizada seja Web Services , os formatos das mensagens podem ser definidos na forma de esquemas XSD e as definições de interfaces, representadas na linguagem WSDL. Para cada serviço, será definido um artefato de contrato de serviços, composto por definição de interface, esquemas de dados de mensagens, especificação funcional de cada operação e políticas de serviço. As mensagens de um serviço serão definidas com base nas informações necessárias como entrada e saída de suas operações e com base em modelos de dados existentes. Deve-se procurar especificar mensagens padronizadas segundo um modelo de dados organizacional, para que uma mesma mensagem possa ser utilizada em diversos serviços.

6 Design

101

Dependendo do cenário, a elaboração da interface do serviço pode ser realizada de modo top-down, bottom-up ou meet-in-the-middle. ●

●

●

●

●

Operação realizada por um serviço – nesse cenário, o serviço já existe e possui interface definida, não sendo necessário nenhum tipo de especificação adicional. Operação realizada parcialmente por um serviço – caso tenha se optado por alterar o serviço existente, pode ser necessário alterar sua interface e/ou a especificação funcional da operação a ser chamada. Caso seja utilizada uma mediação, deve-se definir a interface que será exposta por ela e especificar sua lógica de integração. Em ambos os casos, a especificação da interface é feita de modo top-down , sendo realizada a partir do serviço candidato. Operação realizada por uma aplicação legada – nesse cenário, a interface é elaborada de maneira bottom-up, tendo suas mensagens e operações definidas a partir das características da aplicação legada sendo reusada. Operação realizada parcialmente por uma aplicação legada – a interface pode ser elaborada de modo bottom-up como no cenário anterior, ou, caso se tenha optado por alterar o legado, a interface será derivada de modo bottom-up, mas deverá ser especificada como o legado deverá ser alterado de modo top-down, caracterizando uma especificação meet-in-the-middle. Operação não existente – nesse cenário, tanto a elaboração da interface quanto a da especificação funcional das operações são elaboradas de modo totalmente top-down.

As políticas de serviço especificam os requisitos não funcionais relacionados com o serviço, como segurança, comportamento transacional e registro de auditoria, e requisitos de nível de serviço, por meio de contratos de SLA. SLAs definirão os requisitos de desempenho, confiabilidade e disponibilidade acordados entre provedor e consumidor de serviço.

6.1.1 Projetar esquemas de mensagens dos serviços Os esquemas de mensagens para comunicação entre serviços e componentes são uma parte crítica da SOA. Os esquemas de mensagens não apenas definem os dados de entrada e saída das operações de serviços, como também determinam o formato ou a sintaxe a ser utilizada para representar estes dados, conforme o fluxo de informações passa através das camadas da arquitetura do aplicativo. Quando se utiliza a tecnologia Web Services, o padrão geralmente utilizado para especificar esquemas de mensagens é a linguagem XSD. Neste caso, cada mensagem do esquema será definida por um tipo complexo de dados ( complexType). Para a definição das mensagens e de seus atributos, algumas fontes de informação devem ser consideradas, além das descrições de dados de entrada e saída das operações documentadas no modelo de serviços: ● ●

●

modelo de dados corporativo, caso exista; modelos de dados lógicos e físico de bases de dados existentes envolvidas na realização dos serviços; definições de dados contidos no modelo de processo de negócio.

102


As especificações de mensagens e os modelos de dados estão estreitamente ligados. O modelo de base de dados consiste em entidades e seus relacionamentos, um subconjunto do qual pode ser enviado como parte de uma mensagem de saída e recebido como uma entrada de uma mensagem que chega. Deste modo, o mapeamento entre os formatos de mensagens e o modelo de base de dados é uma consideração arquitetural importante. Caso haja um modelo ou arquitetura de dados corporativo, é importante que esse esteja alinhado aos modelos de mensagens de serviços definidos. O arquiteto de serviços deve procurar definir os esquemas de mensagens dos serviços de modo que eles sejam aplicáveis a todo portfólio de serviços, no sentido de procurar representar as entidades do modelo de dados corporativo. Dessa forma, os esquemas de mensagens de todos os serviços formam um modelo de dados único e padronizado, buscando reaproveitar os mesmos esquemas em diferentes serviços. Assim, minimiza-se a necessidade de mapeamento e transformação de dados na interação e composição de serviços. Esta prática é descrita pelo design pattern Canonical Schema (Esquema Canônico) (Erl, 2009). A aplicação desse design pattern exige também que o arquiteto de serviços procure reusar esquemas de mensagens já existentes, consultando um registro de serviços. Na elaboração dos esquemas, deve ser descrito com detalhes de nível técnico cada atributo da mensagem, especificando: ● ● ● ●

tipo de dado (numeral, texto, data, hora etc.); tamanho mínimo e máximo; número mínimo e máximo de ocorrências; dependências entre mensagens.

Durante a especificação, é importante ter o conhecimento prévio dos padrões de arquitetura da organização, como padrões de nomenclatura de dados e padrões de formatos técnicos para representação dos dados. Estes padrões utilizados no design dos esquemas de mensagens devem estar alinhados também aos padrões técnicos suportados pelas ferramentas de infraestrutura da solução orientada a serviços (plataforma BPMS, ESB etc.).

6.1.2 Projetar interfaces dos serviços Uma vez definidos os esquemas de mensagens, o arquiteto de serviços deve elaborar as interfaces dos serviços, isto é, definir as assinaturas das operações com seus parâmetros de entrada e saída. Para cada serviço, deve-se criar um documento de interface que conterá as definições das operações. Quando se adota a tecnologia Web Services , geralmente utiliza-se a linguagem WSDL para elaboração dos documentos de interface de serviço. Neste caso, uma definição de serviço é representada por um tipo de porta ( portType) no documento WSDL, e cada operação é representada por um elemento do tipo operation.

6 Design

103

Os parâmetros de entrada e saída de cada operação devem também ser indicados no documento de interface. Para cada parâmetro, deve-se definir seu nome e seu tipo, que pode ser um tipo de dado simples (numeral, texto etc.) ou uma mensagem definida em algum esquema.

6.1.3 Especificar políticas dos serviços Os requisitos não funcionais identificados durante a modelagem de negócio foram associados às tarefas do processo, que por sua vez são implementadas por operações de serviços. Nesta etapa, deve-se verificar quais requisitos não funcionais da tarefa devem ser atendidos pelos serviços associados àquela tarefa. Desse modo, cada operação de serviço deve possuir listados os requisitos não funcionais atendidos. Caso necessário, na documentação da operação o requisito não funcional pode ser detalhado trazendo sua descrição do domínio de negócio para o domínio de implementação. Devem ser criados documentos de políticas associados a cada serviço para especificar suas condições de uso.

6.1.4 Descrever comportamento dos serviços O comportamento do serviço consiste na especificação dos requisitos funcionais de cada uma de suas operações. Nesta etapa, deve-se descrever, sob o ponto de vista funcional, a lógica executada por cada operação do serviço. Esta descrição deve ser inserida na documentação de cada operação da interface do serviço, ou pode ser criado um documento específico para o contrato de serviço. A lógica de cada operação deve ser descrita por um texto sucinto do tipo caixa-preta, não incluindo detalhes de implementação do serviço. Para detalhar a lógica e a troca de mensagens executadas internamente ao serviço, podem ser adicionadas à especificação diagramas de sequência e de atividades. Caso existam, podem ser referenciadas especificações de regras de negócio que descrevam a lógica contida na operação. Ao serem definidos dessa forma, os serviços podem ser diretamente implementados utilizando técnicas de orientação a objetos e desenvolvimento baseado em componentes, caso a alternativa de realização escolhida tenha sido implementar um novo componente de serviço.

6.1.5 Definir camada de serviço Dependendo da função executada por um serviço, ele pode ser classificado como serviço de entidade, de tarefa ou utilitário. Nessa atividade, o arquiteto de serviços deve determinar a qual camada pertence cada um dos serviços, dividindo-os entre as camadas de serviços utilitários, de serviços de entidade e de serviços de tarefa, de acordo com sua lógica e seu nível de granularidade. A indicação de camada pode ser registrada no documento de descrição do contrato de serviço ou como um atributo de metadado no registro de serviços.

104

SOA: Modelagem, Análise e Design Dica: Ao especificar esquemas de mensagens em linguagem XSD para Web Services, crie os documentos de esquema de mensagem separados dos documentos de interface do serviço, de modo que possam ser reusados em mais de uma interface. Exemplo: A partir do modelo de serviços elaborado, o arquiteto de serviços da clínica MEDSOA dá início à fase de design do projeto para especificar os contratos dos serviços que darão suporte ao processo de negócio “Consulta Médica”. O arquiteto inicia pela especificação dos esquemas de mensagens dos serviços. São definidas as seguintes mensagens: ● DadosPaciente – mensagem contendo dados de cadastro do paciente, utilizada pelo serviço “Paciente”. ● DadosMedico – mensagem contendo dados dos médicos da clínica, utilizada pelo serviço “Médico”. ● DadosProntuario – mensagem contendo dados do prontuário médico de um paciente, utilizada pelo serviço “Paciente”. Possui diversos registros do tipo ItemProntuario. ● ItemProntuario – mensagem que representa um registro de consulta feito por um médico, contendo informações sobre sintomas e diagnóstico, utilizada pelo serviço “Paciente”. ● DadosMedicamento – mensagem contendo dados sobre um medicamento, utilizada pelos serviços “Prescrição” e “Medicamento”. ● DadosExame – mensagem contendo dados sobre um exame médico, utilizada pelos serviços “Prescrição” e “Exame”. Os esquemas de mensagens podem ser visualizados na Figura 6.3. Como o plano da clínica MEDSOA é implementar os serviços utilizando a tecnologia Web Services, os esquemas de mensagens são formalmente descritos na forma de esquemas XML na linguagem XSD. A Figura 6.4 mostra como exemplo o esquema “DadosPaciente” escrito em linguagem XSD. Após definidos todos os esquemas de mensagens, o arquiteto de serviços procede com a especificação das interfaces de serviços, quando são definidas as assinaturas das operações, com suas mensagens de entrada e saída. Por exemplo, para o serviço “Paciente”, a interface definida pode ser visualizada na Figura 6.5.

Figura 6.3

Esquemas de mensagens dos serviços da clínica MEDSOA.

6 Design

Figura 6.4

Exemplo de esquema escrito em XSD.

Figura 6.5

Interface do serviço “Paciente”.

Como os serviços serão implementados como Web Services, as interfaces são formalmente descritas na linguagem WSDL. A Figura 6.6 apresenta a interface do serviço “Paciente” em WSDL. O arquiteto de serviços define também a qual camada pertence cada um dos serviços especificados, de acordo com o tipo de função executada por cada um deles. A alocação dos serviços nas camadas pode ser vista na Figura 6.7.

105

106


Figura 6.6

Interface do serviço “paciente” escrita em WSDL.

6 Design

Figura 6.7

107

Distribuição dos serviços entre as camadas.

6.2 ESPECIFICAÇÃO DE REALIZAÇÃO DE SERVIÇOS Papel: arquiteto de serviços Artefatos utilizados: modelo de serviços candidatos, contratos de serviços e decisões de realização Artefatos gerados: especificação de serviços Na atividade de especificação de realização de serviços, conforme pode ser vista na Figura 6.8, o arquiteto de serviço deve detalhar a especificação de realização de cada contrato de serviço, de acordo com as decisões de realização tomadas durante a fase de análise. O contrato contém somente as informações que são expostas por um serviço para os consumidores. No entanto, são necessárias mais informações para que seja possível construir a realização do serviço. O arquiteto de serviços, nesta atividade, deverá especificar a estrutura interna do serviço, de modo que ela execute as funções e atenda às políticas definidas no contrato. Enquanto as decisões de realização tomadas na fase de análise são apenas orientações sobre quais recursos devem ser reusados e como os eventuais gaps devem ser resolvidos, as especificações de serviços definem detalhadamente a estrutura e o comportamento dos componentes de serviços e mediações que realizam cada operação de serviço. A especificação de serviços deve entrar nos detalhes técnicos dos componentes e mediações, pois deverá servir como insumo para que os desenvolvedores implementem os serviços.

6.2.1 Especificar componente de serviço Definir tecnologia de realização de serviços (geralmente baseada em programação orientada a objetos). Caso as decisões de realização para as operações de um mesmo serviço sejam diferentes, podem ser criados diferentes componentes para cada operação e cria-se

108


Figura 6.8

Especificação de realização de serviços.

então uma classe de fachada que representa o contrato do serviço (interface) e abstrai para os consumidores a existência de diversos componentes de implementação. Alternativamente, a função de fachada também pode ser executada por uma mediação. Ao projetar o componente de serviço, o arquiteto de serviços deve definir a implementação da lógica e dos dados. Por meio de um diagrama de classes ou de componentes da UML, o arquiteto de serviços deve definir a estrutura interna do componente de serviço. Deve ser definido um modelo de classes de negócio para suportar a lógica executada pelo serviço, que pode incluir os seguintes tipos de classes: ●

● ● ● ● ●

Classes para representar a interface do serviço (de preferência gerada automaticamente a partir da interface). Classes para processamento de mensagens (serialização e desserialização). Classes para conversão de protocolo. Classes de mensagem. Classes de acesso a dados. Classes para executar a lógica de cada operação. Definir modelo de dados.

As especificações funcionais de cada operação podem ser definidas na forma de casos de uso de sistema do tipo caixa-branca (Cockburn, 2000), que descrevem um determinado processamento expondo detalhes de sua implementação. Podem-se

6 Design

109

usar diagramas de atividades da UML para detalhar a lógica do serviço e diagramas de sequência ou de colaboração para representar as interações com outros serviços (composição) ou aplicações legadas. Por utilizarem casos de uso e diagramas da UML, os serviços especificados podem ser diretamente implementados utilizando técnicas de orientação a objetos e desenvolvimento baseado em componentes. O Arquiteto de Serviços deve definir também os modelos de dados lógico e físico, no caso de a realização do serviço necessitar de persistência de dados. Nessa atividade, o Arquiteto de Serviços pode também definir a arquitetura física do componente de serviço e elaborar Diagramas de Implantação para representar como o componente deverá ser implantado no ambiente de execução.

6.2.2 Especificar mediação Para especificar a construção de uma mediação, o arquiteto de serviços deve: ● ● ● ● ●

definir protocolo de comunicação do provedor e do consumidor; definir formato de dados do provedor e do consumidor; especificar conversões de protocolo; especificar mapeamento de formatos (de/para); especificar lógica de roteamento.

Do mesmo modo que nos componentes de serviços, devem-se definir dependências com outros serviços e composições. Podem ser usados diagramas UML (colaboração ou sequência) para representar as interações entre serviços. Exemplo: Uma vez decididas as realizações de cada serviço, o arquiteto de serviços partiu para a elaboração das especificações de como cada serviço deveria ser implementado. De acordo com as decisões de realização tomadas na fase de análise e com os contratos de serviço definidos, cada realização deverá ser estruturada e especificada. Serviço “Paciente”

No caso do serviço “Paciente”, que possui operações realizadas por uma aplicação legada e operações não existentes, o arquiteto de serviços deve especificar mediações e componentes de serviços. Para encapsular os componentes de serviços e mediações de cada operação, é criada uma mediação (PacienteMediation), que implementa a interface de serviço, conforme a Figura 6.9. Desse modo, quando uma operação do serviço “Paciente” for invocada através de sua interface, a mensagem será recebida pela mediação “PacienteMediation”, que, por sua vez, roteará a mensagem para um componente de serviço ou mediação de acordo com a operação que for invocada. Esse é um caso de aplicação do design pattern Service Façade (Fachada de Serviço) (Erl, 2009) comumente adotado quando um mesmo serviço possui tipos diferentes de realizações para suas operações. Além de desacoplar as diferentes realizações do contrato, esta alternativa de design centraliza no ESB a função de receber e rotear as mensagens de invocação aos serviços. Para as operações “ObterClientePeloNome” e “InserirCliente”, o arquiteto de serviços especifica as mediações “ObterClientePeloNome” e “InserirCliente” que acessarão o aplicativo CRM, por intermédio de um adaptador de integração, que por sua vez se comunicará com o CRM utilizando sua API nativa. Na operação “ObterClientePeloNome”, a mediação deverá invocar as funções do CRM “buscarClientePorNome” e “buscarClientePorSobrenome”, passando como parâmetro a palavra

110


Figura 6.9

Mediação “Paciente Mediation”.

recebida na mensagem de entrada, e então consolidar os resultados em um único conjunto. Para retornar aos pacientes encontrados, a mediação deve então mapear os dados retornados pelo adaptador de integração no formato específico do CRM para o formato definido para a mensagem “DadosPaciente”. Na Figura 6.10, é possível visualizar o diagrama de sequência da lógica executada pela mediação.

Figura 6.10

Diagrama de sequência da operação “Obter Paciente Pelo Nome”.

6 Design

Figura 6.11

Mapeamento de de/para do formato do CRM para o esquema de mensagem.

O arquiteto de serviços deve definir também o mapeamento dos dados do formato da API do aplicativo CRM para o esquema de mensagens “DadosPaciente” definido no contrato do serviço. Para tal, ele define um mapa de de/para, indicando como cada campo da mensagem “ClienteCRM” deve ser mapeado para a mensagem “DadosPaciente”, conforme a Figura 6.11. As eventuais diferenças entre os campos podem ser solucionadas com funções de manipulação de texto. Por exemplo, para transformar os campos “nome” e “sobrenome” da mensagem “ClienteCRM” em um único campo “nome” na mensagem “DadosPaciente”, é utilizada a função de concatenação. Na operação “InserirPaciente”, o arquiteto de serviços especifica a mediação para mapear os dados da mensagem “DadosPaciente” para o formato da mensagem “ClienteCRM” e acessar a função “adicionarCliente” do aplicativo CRM, conforme a Figura 6.12.

Figura 6.12

111

Diagrama de sequência da operação “Inserir Cliente”.

112

SOA: Modelagem, Análise e Design Para implementar a lógica das operações “ObterProntuarioPaciente” e “AtualizarProntuarioPaciente” do serviço “Paciente”, o arquiteto de serviços especificou os componentes de serviço “ObterProntuarioPacienteImpl” e “AtualizarProntuarioPacienteImpl”. Para recuperar e alterar dados de prontuário de uma base de dados, os componentes deveriam acessar a classe de acesso a dados “PacienteDAO”, que segue o design pattern DAO (Data Access Object ). A Figura 6.13 exemplifica as interações para uma das operações. A Figura 6.14 representa a realização do serviço “Paciente” com todos os componentes e mediações especificados.

Figura 6.13

Diagrama de sequência da operação “ObterProntuarioPaciente”.

Figura 6.14

Diagrama UML de realização do serviço “Paciente”.

6 Design

113

Além desse diagrama, foi elaborado um modelo de dados para representar as tabelas de banco de dados persistentes acessadas pela classe DAO, conforme a Figura 6.15.

Figura 6.15

Diagrama de modelo de dados.

Serviço “EnviarNotificacao”

Para o serviço “EnviarNotificacao”, cuja decisão de realização foi utilizar um provedor de serviço na nuvem, o arquiteto de serviços não especificou nenhuma realização, já que seria reusada uma realização já existente (fornecida pelo provedor de serviços na nuvem Cloud Message). Outros serviços

Já os demais serviços, que deveriam ser realizados por novos componentes de serviços, foram projetados pelo arquiteto de serviços de forma semelhante ao serviço “Paciente”: interface de serviço, mediação encapsuladora, componentes de serviço para cada operação e classes DAO para acesso ao banco de dados.

6.3 VERIFICAÇÃO DE PRINCÍPIOS Papel: arquiteto corporativo Artefatos utilizados: especificação de serviços e contratos de serviços Artefatos gerados: não aplicável Nesta atividade de verificação de princípios, conforme pode ser visto na Figura 6.16, uma série de verificações é realizada sobre as especificações de serviços com o intuito de avaliar sua conformidade com os princípios de orientação a serviços.

114


Figura 6.16

Verificação de princípios.

6.3.1 Validar aderência aos princípios Os princípios verificados são:

6.3.1.1

Contrato padronizado

Deve-se garantir que os documentos formais criados para descrever o contrato do serviço (i.e.: esquemas XML e interfaces WSDL) estão em conformidades com as boas práticas e padrões adotados pela organização (revisão de governança). Exemplos de padrões verificados: sintaxe de representação, padrões de formato, padrões de nomenclatura, padrões de ferramentas, padrões técnicos de interoperabilidade (WS-I), design patterns.

6.3.1.2 Reusabilidade Para garantir a reusabilidade de um serviço, deve-se verificar se não é necessário adicionar operações ou alterar as já existentes ou especificadas para que o serviço possa vir a ser útil em outro contexto que não o do processo de negócio sendo desenvolvido. Mesmo que nem todas as operações não venham a ser implementadas em um primeiro momento, é recomendável que elas já estejam especificadas para minimizar a necessidade de mudanças posteriores na interface do serviço. A aplicação de design patterns como Logic Centralization (Centralização de Lógica) (Erl, 2009) e Contract Centralization (Centralização de Contrato) (Erl, 2009) deve garantir que o acesso aos dados ou funcionalidade provida por um serviço sejam acessíveis somente através de seu contrato. O serviço deve ser concebido como um produto e não como uma aplicação de finalidade única. A lógica do serviço deve ser a mais agnóstica possível (Competência Agnóstica).

6 Design

6.3.1.3

115

Granularidade

Deve-se verificar se o nível de granularidade do serviço (a quantidade de lógica encapsulada) está de acordo com a camada a que pertence e com o nível de reusabilidade esperado. Serviços de aplicação devem possuir nível baixo de granularidade, ou seja, devem ser genéricos para que possam ter maior reusabilidade. Serviços de negócio podem ter nível mais alto de granularidade, pois têm necessidade menor de reusabilidade e devem poder ser utilizados diretamente pelos serviços de orquestração.

6.3.1.4 Autonomia Para se obter autonomia em um serviço, deve-se garantir que a lógica encapsulada é autocontida, isto é, não possui dependências com relação a outros serviços ou processos. Um serviço deve possuir controle sobre seu próprio ambiente de execução, de forma a minimizar impactos causados por fatores externos (outros serviços, outras aplicações). A autonomia pode ser obtida reduzindo-se o acesso compartilhado aos recursos de um serviço, aumentando o isolamento físico do ambiente de execução de um serviço ou reduzindo as dependências externas do ambiente de execução de um serviço.

6.3.1.5

Abstração

Deve-se verificar se o contrato (interface) do serviço está abstraindo detalhes de implementação, ocultando-os dos potenciais consumidores. O serviço deve funcionar como uma “caixa-preta”, expondo em seu contrato apenas as informações essenciais para que possa ser utilizado. Detalhes específicos de design e implementação não podem estar expostos no contrato do serviço.

6.3.1.6

Baixo acoplamento

Para se garantir o baixo acoplamento dos serviços, deve-se verificar se o contrato do serviço não está limitado por características específicas de um processo de negócio ou de sua lógica e tecnologia de implementação. O contrato deve ser o mais desacoplado possível de elementos externos. A implementação de um serviço deve ser acoplada ao contrato, nunca o contrário. Desta forma, características específicas da implementação do serviço (tecnologia de implementação, plataforma, detalhes técnicos da implementação, aplicações legadas encapsuladas) não devem estar expostas no contrato.

6.3.1.7

Independência de estado

Para se garantir que os serviços sejam independentes de estado, deve-se procurar minimizar a quantidade de informação de estado armazenada pelo serviço em memória, armazenando-a nas mensagens trocadas ou na lógica de orquestração do processo de negócio. Caso seja imprescindível o armazenamento de algum tipo de informação de estado, podem-se criar mecanismos para delegar os dados de estado a um repositório de estado externo ao serviço, como uma base de dados persistente.

116


6.3.1.8

Visibilidade

O contrato do serviço, suas operações, seus dados, sua funcionalidade e suas políticas devem ser descritos de forma inteligível para os potenciais usuários e devem ser publicadas em um registro de serviços ou repositório de metadados. Apenas contratos devem ser publicados (especificações de realização, artefatos de implementação, artefatos de testes etc. não necessitam ser expostos para potenciais consumidores).

6.3.1.9

Capacidade de composição

Deve-se assegurar que uma composição de serviços especificada esteja de acordo com os padrões definidos e seja capaz de cumprir os requisitos não funcionais especificados.

6.3.1.10

Interoperabilidade

Deve-se verificar se os contratos de serviço foram tecnicamente desenhados para serem interoperáveis, isto é, suportar a implementação de serviços em diversas plataformas tecnológicas. Para tal, os artefatos técnicos de interface de serviço e esquemas de mensagens devem ser elaborados utilizando padrões abertos e evitando o uso de características e recursos proprietários ou específicos de uma determinada plataforma.

6.3.2 Revisar serviços A verificação da aderência aos princípios de orientação a serviços pode demandar alterações nos serviços especificados. Caso isso seja necessário, executam-se novamente alguns passos da atividade de especificação de serviços para que os contratos dos serviços sejam reprojetados conforme necessário, para se adequar aos princípios de orientação a serviços. Pode ser necessário rever também a alocação dos serviços nas camadas de negócio e de aplicação, caso tenha havido alteração no escopo funcional ou na granularidade dos serviços. Exemplo: O arquiteto corporativo revisa os contratos e especificações de serviços, verificando a aderência aos princípios de orientação a serviços e a padrões corporativos de especificação contrato e realização (nomenclatura e separação de documentos) e o uso de design patterns. Ao verificar o princípio de baixo acoplamento , o arquiteto corporativo recomenda que os contratos não sejam acoplados à realização encapsulada. A interface do serviço “Enviar Notificação” do provedor externo Cloud Message, apesar de estar de acordo com os padrões técnicos e de nomenclatura da organização, gera acoplamento com relação a características específicas do provedor. O arquiteto corporativo recomenda definir uma nova interface de serviço “Enviar Notificação” e encapsular a interface do provedor, utilizando uma mediação para realizar o mapeamento entre as duas interfaces. Deste modo, o contrato fica desacoplado do provedor de serviço, possibilitando que o provedor possa ser alterado futuramente sem impacto aos consumidores do serviço. Como solução, foi especificada uma mediação simples, apenas para servir como ponto de acesso ao serviço externo, conforme a Figura 6.17 e a Figura 6.18.

6 Design

Figura 6.17

Diagrama de componentes do serviço “Enviar Notificação”.

Figura 6.18

Diagrama de sequência da operação “Enviar Notificação”.

Na verificação do princípio de autonomia, o arquiteto corporativo recomenda reduzir o acesso compartilhado aos recursos do serviço “Paciente”, nesse caso, as funções do aplicativo CRM acessadas pelo serviço: “buscarClientePeloNome”, “buscarClientePeloSobrenome” e “adicionarCliente”. Para tal, deve-se evitar que outros serviços e aplicações acessem diretamente estas funções e acessem somente o serviço através de seu contrato, aplicando o design pattern Contract Centralization (Centralização de Contrato) (Erl, 2009). Além disso, o arquiteto corporativo revisa as especificações de realização dos serviços e faz recomendações de modo a garantir que as realizações dos novos serviços tenham implementações independentes, isto é, possuam recursos de infraestrutura próprios. O arquiteto corporativo analisa a especificação de realização do serviço “Paciente” e avalia sua granularidade como demasiadamente alta para um serviço de entidade, por encapsular

117

118


Figura 6.19

Serviços “Paciente” e “Prontuário” com as operações reagrupadas.

diversas funções de uma aplicação legada além de um conjunto de dados próprio. Desta forma, o arquiteto corporativo aplica o design pattern Service Decomposition (Descomposição de Serviço) (Erl, 2009), reagrupando as operações de acordo com a realização e dividindo-as entre os serviços “Paciente” e “Prontuário”, conforme a Figura 6.19. Para aumentar a reusabilidade dos serviços de entidade “Paciente”, “Prontuário” e “Médico”, o arquiteto corporativo propõe a criação de novas operações que possam tornar os serviços reusá veis em outros contextos e processos de negócio. As novas operações propostas têm como objetivo a manipulação dos dados providos pelos serviços de entidade, conforme a Figura 6.20.

Figura 6.20

Serviços com novas operações adicionadas.

6.4 CONSIDERAÇÕES DO CAPÍTULO Neste capítulo os serviços foram detalhados em nível de contrato de serviços e de componentes de serviço para sua realização. Os serviços são verificados quanto à aderência aos princípios de orientação a serviços e são revisados. Com o resultado da revisão, a especificação de serviços pode ser alterada, se necessário. Assim, os serviços revisados estão prontos para as próximas fases, ou seja, as fases de construção e de implantação e gerenciamento.

7

Fases complementares Objetivo O objetivo deste capítulo é apresentar as fases de construção e de implantação e gerenciamento como complemento às fases anteriores. Na fase de construção os serviços são implementados, orquestrados e testados. A fase de implantação e gerenciamento se preocupa em publicar e implantar os serviços e, em seguida, monitorar a sua operação.

Conteúdo 7.1 Construção 7.2 Implantação e gerenciamento 7.3 Considerações do capítulo

119 124 128

7.1 CONSTRUÇÃO Na fase de construção, são desempenhadas atividades com o intuito de se obter os serviços executáveis devidamente integrados e testados, prontos para serem implantados. A Figura 7.1 apresenta as atividades de implementação, orquestração e teste de serviços da fase de construção, conforme descritas a seguir.

7.1.1 Implementação de serviços Papel: desenvolvedor Artefatos utilizados: contratos de serviços, especificação de serviços Artefato gerado: componentes de serviço executáveis A atividade de implementação de serviços tem por objetivo implementar mediação e componentes de serviço, de acordo com os contratos e especificações de realização de serviço, conforme pode ser vista na Figura 7.2. A atividade de implementação de serviços é executada por desenvolvedores, que receberão as especificações dos serviços e implementarão os componentes e mediações necessários. A partir destas atividades, pode ser seguido o ciclo tradicional de desenvolvimento orientado a objetos e/ou baseado em componentes.

119

120


Figura 7.1

Atividades da fase de construção.

Figura 7.2

Implementação de serviços.

Dependendo das ferramentas utilizadas, as seguintes etapas podem ser cumpridas durante a implementação. Diversos design patterns , ferramentas e frameworks podem ser utilizados para implementar serviços. Este livro não tem como objetivo recomendar ou avaliar o uso destas técnicas, mostrando apenas sua relação com as atividades de modelagem, análise e design. Nos casos de serviços realizados por novos componentes de serviços a serem implementados, o desenvolvedor deverá construir a realização conforme especificada pelo arquiteto de serviços. Quando é utilizada uma plataforma tecnológica orientada a objetos, o desenvolvedor deverá implementar as classes conforme especificado nos modelos e diagramas da UML contidos na especificação. Algumas etapas da implementação de componentes de serviço são:

7 Fases complementares

●

●

● ● ●

●

121

criação ou geração automática de classes de mensagens a partir dos documentos de esquemas de mensagens; criação ou geração automática de classes de fachada a partir dos documentos de interface de serviço; criação de classes de acesso a dados; integração com APIs para acesso a aplicações legadas reusadas; criação de classes de negócio para representar e executar a lógica definida para cada operação de serviço, conforme descrito na especificação de serviços; criação ou geração automática de classes de infraestrutura para processamento de mensagens e comunicação específicas da tecnologia de serviços utilizada ( Web Services, REST etc.).

Nos casos em que a realização de um serviço envolve o reuso de uma aplicação legada ou serviço existente, o serviço poderá ser realizado por uma mediação no ESB. O barramento será o responsável por criar o acesso às aplicações legadas e resolver eventuais gaps existentes. Algumas etapas envolvidas na implementação de mediações são: ●

●

●

●

criação ou importação de definições de mensagens para representar os dados que serão manipulados pela mediação; criação ou importação de definições de interfaces que serão utilizadas para expor a mediação e para invocar serviços existentes; criação de mapas para realizar a conversão entre formatos de mensagens e tipos de interfaces, conforme necessário; implementação da lógica de mediação descrita na especificação de serviços, de forma a compor um fluxo de dados entre os conectores de exposição da mediação e os conectores de invocação de serviços existentes.

7.1.2 Orquestração de serviços Papel: desenvolvedor Artefatos utilizados: modelo de processo to-be, contratos de serviços e especificação de serviços Artefatos gerados: processo orquestrado Uma vez especificados os serviços e suas interfaces WSDL, é realizada a orquestração dos serviços, conforme pode ser vista na Figura 7.3. Se o modelo de processo to-be estiver representado na notação BPMN, ele pode ser convertido em um modelo na linguagem WS-BPEL. Caso contrário, a lógica de processo pode ser descrita manualmente em WS-BPEL ou em outra linguagem. Tal lógica deve ser especificada de modo que as chamadas dos serviços sejam devidamente orquestradas com as interfaces de serviços definidas e revisadas. O objetivo dessa atividade é definir a lógica de orquestração necessária para executar o processo, como manipulação de variáveis de processo, gerenciamento de informação de estado, tratamento de exceções e compensação.

122


Figura 7.3

Orquestração de serviços.

O processo orquestrado deverá ser encapsulado por um serviço da camada de orquestração composto por serviços das camadas de negócio e aplicação. Por isso, deverá ser descrito em sua própria especificação de serviços, que conterá a lógica de orquestração definida.

7.1.3 Testes de serviços Papel: testador Artefatos utilizados: contratos de serviços, processo orquestrado e componentes de serviço executáveis Artefato gerado: evidências de teste Sendo uma aplicação SOA uma composição de serviços, deve-se garantir que as instâncias desses serviços estejam disponíveis aos desenvolvedores para serem testadas. Também, deve-se garantir uma infraestrutura necessária aos testes em ambientes distribuídos. A atividade de testes de serviços, conforme pode ser vista na Figura 7.4, deve basicamente verificar se os requisitos especificados foram atendidos e se os serviços se comportam de acordo com as políticas definidas. Para isso ocorrer, devem-se executar os serviços e comparar os resultados com seus contratos e especificações.


Figura 7.4

123

Testes de serviços.

Os objetivos de um teste de serviço devem cobrir os aspectos funcionais e não funcionais. Como aspecto funcional considera-se a lógica especificada pelo contrato do serviço. Como aspecto não funcional consideram-se, por exemplo, o desempenho e a segurança do serviço. A estratégia de teste deve considerar os serviços individuais e composições de serviços gradativamente até a solução completa integrada. Os testes devem ser realizados baseando-se na especificação de serviço e em um plano de testes, e, como resultado, deve-se gerar um relatório de testes reportando os casos de teste executados e os resultados obtidos. Os tipos de teste que podem ser executados são:

a) Testes de unidade O testador deve executar testes de unidade em cada componente de serviço ou mediação, testando cada operação de acordo com o contrato e com os requisitos funcionais e não funcionais. Os testes de unidade aplicam-se à camada de componentes de serviço da arquitetura de referência.

124


b) Testes de contrato de serviço O testador realiza testes verificando se os serviços estão aderentes ao contrato, tanto funcionalmente quanto não funcionalmente (políticas do contrato). Teste o serviço como uma caixa-preta, reproduzindo o ponto de vista do consumidor do serviço. Os testes de contrato aplicam-se à camada de serviços da arquitetura de referência. c) Testes de orquestração O testador valida a execução dos processos de negócio completos, testando a lógica do processo orquestrado integrado aos serviços, composições e mediações. Os testes de orquestração aplicam-se à camada de processos de negócio da arquitetura de referência. d) Testes de usuário O testador valida a solução como um todo sob o ponto de vista dos usuários, executando os testes através das interfaces consumidoras. Serve como teste de aceitação do usuário sobre toda a solução orientada a serviços. Os testes de usuário aplicam-se à camada de interfaces consumidoras da arquitetura de referência. e) Testes não funcionais Apesar de alguns requisitos não funcionais serem testados em testes de contrato de serviço, podem ser necessários outros testes para a validação da solução orientada a serviços como um todo, frente a necessidades específicas de segurança e desempenho. Nessa etapa, faça testes de invasão, testes de carga, testes de tolerância a falhas, entre outros.

7.2 IMPLANTAÇÃO E GERENCIAMENTO Após a fase de construção, o ciclo de vida prossegue com as fases de implantação e gerenciamento, conforme a Figura 7.5. Estas fases não são abordadas na modelagem, na análise e no design, pois não são diretamente afetadas por elas. Por estye motivo, as atividades destas fases são descritas apenas de maneira breve nas próximas seções.

7.2.1 Publicação de serviços Papel: administrador de serviços Artefatos utilizados: contratos de serviços e especificação de serviços Artefato gerado: serviços publicados no registro de serviços e no repositório de metadados A atividade de publicação de serviços tem por objetivo a catalogação dos contratos de serviços no registro de serviços e disponibilização dos metadados e especificações de serviço no repositório de metadados, conforme a Figura 7.6. Nessa atividade, o administrador de serviços deve realizar também a definição da localização física e dos endereços de acesso de cada serviço a ser implantado. Trata-se da publicação dos endereços físicos no registro de serviços.


Figura 7.5

Atividades da fase de implantação e gerenciamento.

Figura 7.6

Publicação de serviços.

125

A publicação pode ocorrer mais cedo no ciclo de vida (após as decisões de realização ou revisão dos contratos), caso o registro de serviços suporte a indicação do status dos serviços. Nestes casos, o contrato de serviço pode ser publicado, mas com a indicação de que ele se encontra “Em especificação”, “Em construção” ou “Em testes”.

126


7.2.2 Implantação de serviços Papel: administrador de serviços Artefatos utilizados: componentes de serviço executáveis e processo orquestrado Artefato gerado: componentes de serviço implantados A atividade de implantação de serviços tem por objetivo implantar os módulos executáveis dos componentes de serviço, mediações, processos de negócio orquestrados e demais elementos da solução orientada a serviços em seus respectivos ambientes de execução, conforme a Figura 7.7. O procedimento de implantação de serviços pode passar por etapas como: ● ● ● ●

geração dos pacotes de implantação a partir dos artefatos de implementação; implantação dos pacotes de implantação em ambiente de homologação; testes de aceitação e homologação da solução orientada a serviços; implantação dos pacotes de implantação em ambiente de produção.

7.2.3 Manutenção de serviços Papel: administrador de serviços Artefatos utilizados: componentes de serviço implantados e métricas, alertas e incidentes Artefatos gerados: componentes de serviço implantados e ações corretivas e preventivas

Figura 7.7

Implantação de serviços.


Figura 7.8

127

Manutenção de serviços.

A atividade de manutenção de serviços tem por objetivo manter os serviços em operação e assegurar que as políticas e SLAs definidas estejam sendo respeitadas, conforme a Figura 7.8. Por meio da monitoração de métricas de desempenho dos serviços (por exemplo, tempo de resposta, volume de mensagens, tamanho de mensagens e número de requisições simultâneas), o administrador de serviços pode verificar se as SLAs e os requisitos não funcionais dos serviços estão sendo atendidos. Algumas ferramentas de monitoração permitem também que o administrador receba notificações caso alguma SLA seja violada. Incidentes ocorridos durante a execução dos serviços, como exceções inesperadas e indisponibilidade, devem ser verificados e solucionados pelo administrador de serviços. O administrador de serviços pode fazer uso dos dados de desempenho e monitorar o uso de recursos (como capacidade de processamento, memória, armazenamento e tráfego de rede) para dimensionar a capacidade da infraestrutura de modo a prevenir a degradação do desempenho em momentos de pico e evitar violações de SLAs. Os ajustes de infraestrutura podem ir desde mudanças de configuração até a adição de recursos de hardware.

7.2.4 Monitoração de atividades de negócio Papel: gestor de processos Artefatos utilizados: métricas de processo de negócio Artefatos gerados: necessidades de negócio

128


Figura 7.9

Monitoração de atividades de negócio.

A atividade de monitoração de atividades de negócio tem por objetivo monitorar o desempenho dos processos de negócio, avaliando métricas como tempo de execução, custos, receitas, uso de recursos e indicadores de eficiência (percentual de aprovações, percentual de solicitações aceitas), conforme a Figura 7.9. O gestor de processos acompanha o andamento do processo, avalia indicadores consolidados (KPIs) e analisa relatórios de dados históricos, para ter uma visão clara sobre o desempenho do processo e validar se as metas de negócio estão sendo atingidas como resultado da implantação da solução orientada a serviços. Para tal, o gestor de processo faz uso de ferramentas de monitoração de atividade de negócio (BAM) e de ferramentas de Business Intelligence e Data Warehousing. Analisando os dados de negócio, o gestor de processos pode identificar gargalos e pontos de melhoria nos processos, de modo a dar origem a um novo conjunto de necessidades e problemas que possibilitarão uma nova iteração no ciclo de vida com o intuito de trazer melhorias aos processos de negócio automatizados. O modelo de processo to-be implementado torna-se o modelo de processo as-is desta nova iteração.

7.3 CONSIDERAÇÕES DO CAPÍTULO Neste capítulo foram apresentadas as fases de construção e de implantação e gerenciamento. A fase de construção se preocupa em implementar a especificação de serviços da fase de design. Os serviços são orquestrados e testados para verificar se os requisitos funcionais e não funcionais especificados foram atendidos. A fase de implantação e gerenciamento se preocupa em criar os registros de serviços para os consumidores. Uma vez publicados, os serviços são monitorados quanto à qualidade de serviço (QoS) oferecida e também quanto ao desempenho dos processos de negócio. Nesta fase, o serviço passa por melhorias dos processos de negócio podendo retornar à fase de modelagem.

8

Considerações finais Objetivo O objetivo deste capítulo é apresentar algumas considerações sobre a modelagem, a análise e o design discutidas neste livro.

Conteúdo 8.1 Algumas considerações

129

8.1 ALGUMAS CONSIDERAÇÕES O paradigma de orientação a serviços tem sido apresentado de forma, às vezes, confusa e simplificada, com o uso de Web Services. Algumas empresas e desenvolvedores de TI consideram a tecnologia de Web Services erroneamente como sinônimo do paradigma. O paradigma tem origem no negócio em que a organização precisa ter melhor retorno e preservação de investimentos em Tecnologia da Informação, e os Web Services se popularizaram como tecnologia de implementação de serviços interoperáveis de baixo acoplamento dentro de uma arquitetura SOA. Este livro torna o paradigma mais prático. Para introduzir o paradigma de orientação a serviços de maneira mais precisa, foi apresentado um estudo aprofundado sobre os conceitos relacionados a SOA, focando em um dos principais desafios enfrentados pelas organizações na adoção do paradigma de orientação a serviços, que é a dificuldade da análise e do design de serviços. Porém, tomou-se o cuidado de definir quais são as entradas e saídas necessárias para as atividades de modelagem, análise e design, enfatizando os modelos de negócio como entradas e especificações de serviços como saídas. A modelagem, a análise e o design baseiam-se nos conceitos de SOA e na análise dos métodos existentes. A modelagem, a análise e o design foram elaboradas de modo a unificar os métodos analisados e torná-lo mais práticos. Foram empregadas no livro boas práticas derivadas de todos os métodos analisados, sendo elas integradas em um fluxo de trabalho único.

129

130


Para facilitar o entendimento, foi adotada uma dinâmica de fases sequenciais, como um processo cascata de software. Porém, as fases discutidas são flexíveis podendo ser aplicadas de maneira iterativa e incremental como no RUP. A realização de um caso (Apêndice B) mostra a aplicabilidade da modelagem, da análise e do design em projetos reais de contextos distintos. As fases foram aplicadas em um projeto de criação de uma nova solução orientada a serviços, com o uso da abordagem BPM. Foi empregada a tecnologia Web Services para especificar e implementar os serviços. A modelagem, a análise e o design são especialmente efetivas na análise de reuso de recursos existentes e na manutenção da governança de serviços. Tais características suportam dois pontos críticos da orientação a serviços. Um deles é a redução do custo de projetos e aumento da agilidade na entrega de soluções, obtidos pelo reuso. E o outro é a necessidade de governança sobre o portfólio de serviços da organização. A modelagem, a análise e o design orientados a serviços são muito úteis às organizações que estão procurando reduzir os custos com TI. E, também, para as organizações serem mais produtivas e responderem mais rapidamente às necessidades de negócio.

Referências

BELL, M. Service-Oriented Modeling: Service Analysis, Design, and Architecture. Estados Unidos: Wiley, 2008. 384 p. BIEBERSTEIN, N. et al. Service-Oriented Architecture Compass: Business Value, Planning, and Enterprise Roadmap. Estados Unidos: IBM Press, 2005. 272 p. BRAY, T. et al. Extensible Markup Language (XML) 1.1. Second Edition. W3C Recommendation, 2006. Disponível em: . Acesso em 27 de março de 2008. CHRISTENSEN, E. et a l. Web Services Description Language (WSDL) 1.1. W3C Note, 2001. Disponível em: .

Acesso em 1º de dezembro de 2008.

COCKBURN, A. Writing Effective Use-Cases. Boston: Addison Wesley, 2000. 304 p. ENDREI, M. et al. Patterns: Service-Oriented Architectures and Web Services. Estados Unidos: IBM Redbooks, 2004. 348 p. ERL, T. Service-Oriented Architecture: Concepts. Technology and Design. Estados Unidos: Prentice Hall, 2005. 792 p. ________. SOA: Principles of Service Design. Estados Unidos: Prentice Hall, 2007. 608 p. ________. SOA Design Patterns. Estados Unidos: Prentice Hall, 2009. 800 p. ________. Web Service Contract Design and Versioning for SOA . Estados Unidos: Prentice Hall, 2008. 826 p. FALLSIDE, D. C.; WALMSLEY, P. XML Schema Part 0: Primer. Second Edition. W3C Recommendation, 2004. Disponível em:

/ >.
Acesso em 1º de dezembro de 2008.

FUGITA, H. S.; HIRAMA, K. MAPOS. Método de Análise e Projeto Orientado a Serviços. In: Anais do Congresso Internacional de Gestão de Tecnologia e Sistemas de Informação (CONTECSI) . 5., São Paulo, 2008(a). ________. Method for Service-Oriented Analysis and Design. In: Proceedings of the International Conference on Software Engineering Research and Practice (SERP) . Las Vegas: CSREA Press, 2008(b). GORNIK, D. IBM Rational Unified Process: Best Practices for Software Development Teams. IBM Whitepapers, 2003. Disponível em:

pdf >. Acesso em 27 de maio de 2007. HUHNS, M. N.; SINGH, M. P. Service-Oriented Computing: Key Concepts and Principles. IEEE Internet Computing, v. 9, nº 1, p. 75-81, jan.-fev. 2005. JESTON, J.; NELIS, J. Business Process Management : Practical Guidelines to Successful Implementations. 2. ed. Estados Unidos: Butterworth-Heinemann, 2008. 504 p. KEEN, M. et al. Patterns: SOA with an Enterprise Service Bus. Estados Unidos: IBM Redbooks, 2005. 386 p. KENNEY, L. F.; PLUMMER, D. C. Magic Quadrant for Integrated SOA Governance Technology Sets. Gartner RAS Core Research Note. Gartner, 2007. KRAFZIG, D.; BANKE, K.; SLAMA, D. Enterprise SOA. Estados Unidos: Prentice Hall, 2004. 408 p. KRUTCHEN, P. The Rational Unified Process: An Introduction. 2. ed. Boston: Addison Wesley, 2000. 272 p. MARKS, E. A.; BELL, M. Service Oriented Architecture : A Planning and Implementation Guide for Business and Technology. Hoboken, Estados Unidos: John Wiley & Sons, 2006. 384 p. OASIS SOA REFERENCE MODEL TC. Reference Model for Service Oriented Architecture 1.0. OASIS Open, 2006. 31 p. OASIS WS-BPEL TC. Web Services Business Process Execution Language, version 2.0. OASIS Open, 2007. Disponível em:
>. Acesso em 1º de dezembro

de 2008. THE OPEN GROUP. Definition of SOA, version 1.1. The Open Group, 2006. Disponível em:

group.org/projects/soa/page.tpl?CALLER=doc.tpl&ggid=1574>. Acesso em 21 de agosto de 2007.

131

132


________. SOA Reference Architecture, draft version 10. The Open Group, 2009. D isponível em:

org/projects/soa-ref-arch/ >. Acesso em 0 9 de dezembro de 2011. PAPAZOGLOU, M. P. Service-Oriented Computing: Concepts, Characteristics and Directions. In: Proceedings of the International Conference on Web Information Systems Engineering. (WISE) , 4., Roma, 2003. Roma: IEEE Computer Society, 2003. p. 3-12. PAPAZOGLOU, M. P.; VAN DEN HEUVEL, W. J. Service-Oriented Design and Development Methodology. In: International Journal of Web Engineering and Technology (IJWET) , v. 2, nº 4, p. 412-442, 2006. PERREY, R.; LYCETT, M. Service-Oriented Architecture. In: Proceedings of the Applications and the Internet Workshops. Uxbridge, 2003. p. 116-119. RAMOLLARI, E.; DRANIDIS, D.; SIMONS, A. J. H. A Survey of Service Oriented Development Methodologies. In: Proceedings of the European Young Researchers Workshop on Service Oriented Computing (YR-SOC) , 2., Leicester, 2007. p. 75-80. RUMBAUGH, J.; JACOBSON, I.; BOOCH, G. The Unified Modeling Language Reference Manual . 2. ed. Estados Unidos: Addison Wesley, 2004. 752 p. SHUJA, A. K.; KREBS, J. IBM Rational Unified Process Reference and Certification Guide : Solution Designer. Estados Unidos: IBM Press, 2007. 307 p. ZIMMERMANN, O. et al. Analysis and Design Techniques for Service-Oriented Development and Integration . Stuttgart: IBM Press, 2005.

Bibliografia complementar

BAJWA, I. S.; SAMAD, A.; MUMTAZ, S. et al. BPM Meeting with SOA: A Customized Solution for Small Business Enterprises. In: International Conference on Information Management and Engineering (ICIME’09 ). p. 677-682, 2009. CHAPIN, N. Software Characteristics of SOA Projects. In: Proceedings of the 11th International Conference on Product Focused Software (PROFES'10) . p. 152-157, 2010. DAN, A.; JOHNSON, R. D.; CARRATO, T. SOA Service Reuse by Design. In: Proceedings of the 2nd International Workshop on Systems Development in SOA Environments (SDSOA’08) . p. 25-28, May 2008. EL YAMANY, H. F.; CAPRETZ, M. A. M.; ALLISON, D. S. Quality of Security Service for Web Services within SOA. In: World Conference on Services – I. p. 653-660, 2009. EMIG, C.; WEISSER, J.; ABECK, S. Development of SOA-Based Software Systems – An Evolutionary Programm ing Approach. In: Proceedings of the Advanced International Conference on Telecommunications and International Conference on Internet and Web Applications and Services (AICT/ICIW 2006) . 2006. GRONOSKY, A.; ATIGHETCHI, M.; PAL, P. Understanding the Vulnerabilities of a SOA Platform – A Case Study. In: 9th IEEE International Symposium on Network Computing and Applications (NCA) . p. 182-187, 2010. GU, Q.; VAN VLIET, H. SOA Decision Making – What do We Need to Know. In: Proceedings of the 2009 ICSE Workshop on Sharing and Reusing Architectural Knowledge (SHARK’09) . p. 25-32, May 2009. GU, Q.; LAGO, P. A Stakeholder-Driven Service Life Cycle Model for SOA. In: 2nd International Workshop on Service Oriented Software Engineering: In Conjunction with the 6th ESEC/FSE Joint Meeting (IW-SOSWE’07) . p. 1-7, September 2007. ________. SOA Process Decisions: New Challenges in Architectural Knowledge Modelin g. In: Proceedings of the 3rd International Workshop on Sharing and Reusing Architectural Knowledge (SHARK’08) . p. 3-10, May 2008. HAU, T.; EBERT, N.; HOCHSTEIN, A.; BRENNER, W. Where to Start with SOA: Criteria for Selecting SOA Projects. In: Proceedings of the 41st Annual Hawaii International Conference on System Sciences . p. 1-9, 2008. KARANDE, A. M.; CHUNEKAR, V. N.; MESHRAM, B. B. Intelligent Database for the SOA using BPEL. In: Proceedings of the 2011 International Conference on Communication, Computing & Security (ICCCS’11) . p. 281-284, February 2011. KRÜGER, I. H.; MATHEW, R. Systematic Development and Exploration of Service-Oriented Software Architectures. In: Proceedings of the Fourth Working IEEE/IFIP Conference on Software Architecture (WICSA’04 ). 2004. KULKARNI, N.; DWIVEDI, V. The Role of Service Granularity in a Successful SOA Realization: A Case Study. In: IEEE Congress on Services – Part I. p. 423-430, 2008. LEE, Y. C.; MA, C. M.; CHOU, S. C. A Service-Oriented Architecture for Design and Development of Middleware. In: Proceedings of the 12th Asia-Pacific Software Engineering Conference (APSEC’05) . 2005. LI, B. Research on SOA and Component Oriented Technology in Development of Large System. In: International Symposium on Computational Intelligence and Design (ISCID) . v. 1. p. 20-23, 2010. MULIK, S.; AJGAONKAR, S.; SHARMA, K. Where Do You Want to Go in Your SOA Adoption Journey? IT Pro fessional. v.10, I. 3. p. 36-39, 2008. O'BRIEN, L.; BASS, L.; MERSON, P. Quality Attributes and Service-Oriented Architectures. Technical Note. CMU/ SEI-2005-TN-014. Carnegie Mellon University. September 2005. 30p. O'BRIEN, L.; BREBNER, P.; GRAY, J. Business Transformation to SOA: Aspects of the Migration and Performance and QoS Issues. In: Proceedings of the 2nd International Workshop on Systems Development in SOA Environments (SDSOA’08). p. 35-40, May 2008. O'BRIEN, L.; GIBSON, J.; GRAY, J. A Method for Selecting SOA Pilot Projects Including a Pilot Metrics Framework. In: Proceeding of the 33rd International Conference on Software Engineering (ICSE’11) . p. 25-32, May 2011. PAPAZOGLOU, M. P. Web Services: Principles and Technology. September 23, 2007. 133

134


PEI, S.; CHEN, D. Implementation of Web Services Composition System Based on SOA. In: International Conference on Uncertainty Reasoning and Knowledge Engineering (URKE) . v. 2. p. 82-85, 2001. SCHEPERS, T. G. J.; IACOB, M. E.; VAN ECK, P. A. T. A Lifecycle Approach to SOA Governance. In: Proceedings of the 2008 ACM Symposium on Applied Computing (SAC’08) . p. 1.055-1.061, March 2008. SETH, A.; AGARWAL, H.; SINGLA, A. R. Designing a SOA Based Model. SIGSOFT Software Engineering Notes , v. 36, I. 5, p. 1-7, September 2011. SNEED, H. M. Integrating Legacy Software into a Service Oriented Architecture. In: Proceedings of the Conference on Software Maintenance and Reengineering (CSMR’06) . 2006. STAROSTA, B. S.; STIREWALT, R. E. K.; DILLON, L. K. Contracts and Middleware for Safe SOA Applications. In: Proceedings of the International Workshop on Systems Development in SOA Environments (SDSOA’07) . May 2007. STOJANOVIC, Z.; DAHANAYAKE, A.; SOL, H. Modeling and Design of Service-Oriented Architecture. In: IEEE International Conference on Systems, Man and Cybernetics. p. 4147-4152. WIECZOREK, S.; STEFANESCU, A. Service Integration: A Soft Spot in the SOA Testing Stack. In: 5th Central and Eastern European Software Engineering Conference in Russia (CEE-SECR) . p. 211-216, 2009. YANG, J. Web Service Componentization. Communication of the ACM . v. 46, nº 10, p. 35-40, October 2003. YOON, H.; JI, E.; CHOI, B. Building Test Steps for SOA Service Orchestration in Web Service Testing Tools. In: Proceedings of the 2nd International Conference on Ubiquitous Information Management and Communication (ICUIMC’08). p. 555-557, January 2008.

YU, W. D.; ONG, C. H. A SOA Based Software Engineering Design Approach in Service Engineering. In: IEEE International Conference on e-Business Engineering (ICEBE’09). p. 409-416, 2009. ZHANG, L. J.; ZHANG, J. Componentization of Business Process Layer in the SOA Reference Architecture. In: IEEE International Conference on Services Computing (SCC’09). p. 316-323, September 2009.

Apêndice A

Elementos gráficos usados no livro

135

Apêndice B

Estudo de caso Aplicando a modelagem, a análise e o design em uma instituição bancária

B.1 CONTEXTO DO ESTUDO DE CASO O exemplo de aplicação de modelagem, análise e design descrito a seguir trata da automação de um processo de negócio da instituição bancária fictícia BANCO SOA. O processo de negócio em questão é o “Cadastro de Cliente”, que descreve a lógica de negócio para avaliação e cadastro de um novo cliente da instituição. Trata-se de um processo de pré -cadastro de pessoas físicas e jurídicas, pelo qual novos clientes em potencial abrirão uma conta, obterão um financiamento ou solicitarão um cartão de crédito. No estudo de caso, partimos de uma situação em que o processo é quase inteiramente manual, sendo apoiado somente pelo sistema de cadastro de clientes, uma aplicação legada construída com tecnologia baseada em componentes. A instituição bancária decide adotar as abordagens SOA em conjunto com uma plataforma de BPM para realizar a automação do processo de negócio.

B.2 MODELAGEM A fase de modelagem tem como objetivo elaborar os modelos de processo de negócio, isto é, documentar o processo de negócio na sua forma atual ( as-is) e o processo futuro (to-be), contendo as mudanças propostas.

Modelagem de Processo as-is Essa tarefa tem como objetivo elaborar os modelos de processo de negócio, isto é, documentar o processo de negócio na sua forma atual ( as-is) e o processo futuro (to-be), contendo as mudanças propostas. O modelo de processo as-is deve ser levantado por um analista de processos junto às áreas envolvidas na execução manual do processo atual. Com base neste levantamento, o analista de processos deve documentar o modelo de processo as-is, através de diagramas (por exemplo, diagrama de atividades da UML ou notação BPMN) e descrições textuais. Na Figura B.1, é apresentado um diagrama do processo as-is de cadastro de cliente em notação BPMN. O processo se dedica a cadastrar clientes. Assim, após o cliente preencher a ficha cadastral, o atendente da agência verifica se o cliente já é ou não cadastrado no sistema.

137

138

Apêndice B

Figura B.1

Diagrama do processo as-is (cadastro de cliente).

Se for, o processo é simplesmente interrompido. Caso contrário, o CPF ou CNPJ do cliente é verificado. Caso haja algum problema, o cadastro é negado e o cliente é informado pelo atendente da agência. Caso contrário, uma série de documentos é determinada pelo back office . Os documentos recebidos são digitalizados pelo atendente da agência e conferidos pelo back office . Caso haja algum problema com os documentos, uma nova visita é agendada pelo atendente da agência para sanar os problemas encontrados. Caso contrário, os dados do cliente são digitados no sistema e o cliente é informado sobre o sucesso de seu cadastro pelo atendente da agência.

Modelagem de Processo to-be O analista de processos propõe automatizar parte do processo na plataforma BPMS, em que o fluxo do processo é orquestrado pela plataforma e apoiado por um conjunto de serviços. O diagrama do modelo de processo to-be pode ser visualizado na Figura B.2. Observe que, nesta proposta, uma parte das tarefas é atribuída ao papel sistema (ver legenda), que representa a plataforma BPMS que orquestra as chamadas a serviços e tarefas humanas. Como pode ser visto, grande parte das tarefas originais do atendente da agência foi atribuída ao sistema. Um modelo de negócio pode ser composto por: diagrama do processo de negócio, documento de especificação (de tarefas e descrição textual de regras de negócio). Complementando o diagrama do processo, o analista de processos elabora uma descrição textual de cada tarefa, detalhando os passos envolvidos em sua execução. A Tabela B.1 apresenta as descrições de cada tarefa do processo to-be.

Apêndice B

Figura B.2

Diagrama do processo to-be (cadastro de clientes).

TABELA B.1 Descrição

de tarefas do processo

to-be (cadastro

de clientes)

Tarefa

Descrição

Informar dados do cliente

O atendente da agência preenche um formulário Web com os dados cadastrais do cliente (nome, CPF/CNPJ, endereço, telefone, e-mail etc.). O formulário valida os dados inseridos, como formato de CPF, CNPJ etc.

Verificar existência do cliente

O sistema verifica no cadastro se o cliente com o CPF ou CNPJ informado já existe.

Enviar notificação de cliente existente

O sistema envia um e-mail ao cliente informando que seu cadastro já existe no banco.

Verificar situação do CPF/CNPJ

O sistema consulta os serviços do Serasa e do SPC para verificar a situação de crédito do CPF ou CNPJ do cliente.

Enviar notificação de negação de cadastro

O sistema envia um e-mail ao cliente informando que seu cadastro foi negado, pois sua situação de crédito encontra-se irregular.

Determinar lista de documentos

O sistema verifica quais documentos devem ser apresentados obrigatoriamente pelo cliente de acordo com seu tipo (pessoa física ou jurídica).

Receber e digitalizar documentos

O atendente da agência recebe os documentos físicos do cliente e os digitaliza, para que o sistema armazene uma cópia eletrônica deles.

Conferir documentos

O Back-Office analisa os documentos digitalizados e verifica se todos os documentos obrigatórios foram entregues e são válidos.

Reagendar visita

O atendente da agência telefona para o cliente por telefone e agenda uma visita para que o cliente traga os documentos necessários à agência.

Gravar dados do cliente

O sistema grava no cadastro os dados do novo cliente.

Enviar notificação de sucesso

O sistema envia um e-mail ao cliente informando que seu cadastro foi realizado com sucesso.

139

140

Apêndice B

Figura B.3

Casos de uso do processo cadastro de cliente.

Especificação de requisitos Além do modelo de processo to-be, o analista de processos elabora também uma especificação de requisitos, que provê um detalhamento adicional sobre como o processo deverá ser automatizado, no aspecto funcional e não funcional. Além de definir requisitos não funcionais, como tempo de resposta e número de usuários suportados, o analista de processos elabora especificações de casos de uso para descrever as interações dos usuários com o sistema nas tarefas humanas. A Figura B.3 representa B.3 representa os casos de uso elaborados.

B.3 ANÁLISE Na fase de análise, o objetiv objetivo o é identificar os serviços, analisar gap e verificar se os serviços são realizáveis.

Identificação de Serviços Candidatos Após a elaboração do modelo de processo to-be, composto pelo diagrama de processo mais as descrições de tarefas do processo, o arquiteto de serviços inicia a identificação de serviços candidatos. Esta atividade recebe como entrada o modelo de processo to-be e tem como objetivo definir um conjunto inicial de serviços, identificados a partir do processo. As operações candidatas devem ser identificadas a partir da análise das descrições das tarefas, seguindo a sequência das tarefas determinada pelo diagrama de processo. No texto de descrição de cada tarefa, é possível identificar funções que devem ser executadas pelo sistema, tanto nas tarefas do sistema quanto nas tarefas humanas. Em alguns casos, uma tarefa inteira pode ser considerada uma operação candidata, enquanto, em outros, apenas alguns passos de uma tarefa podem ser considerados operações candidatas. As operações identificadas nas tarefas do processo são listadas na Tabela B.2 B.2..

Apêndice B

TABELA B.2 Operações

141

candidatas do processo

Tarefa

Operação Candidata

Informar dados do cliente

Validar número de CPF Validarr número de CNPJ Valida Validar dados do cliente

Verificar existência de cliente


Enviar notificação de cliente existente

Enviar e-mail

Verificar situação do CPF/CNPJ

Consultar Serasa Consultar SPC

Enviar notificação de negação de cadastro

Enviar e-mail

Determinar lista de documentos

Consultar documentos obrigatórios

Receber e digitalizar documentos

Armazenar documento

Conferir documentos

(nenhuma operação)

Reagendar visita

(nenhuma operação)



Enviar notificação sucesso

Enviar e-mail

Após a identificação, as operações candidatas devem ser agrupadas em serviços candidatos, baseando-se na similaridade e correlação entre eles. Como orientação geral, procura-se agrupar operações que manipulem os mesmos tipos de dados ou que executem lógica semelhante. Para as operações que manipulam dados de cliente, pode-se criar um serviço “Cliente”. O mesmo critério pode ser utilizado para criar um serviço “Documento”. Já as consultas ao Serasa e ao SPC, por serem operações de lógica semelhante, podem ser agrupadas em um serviço “Consulta Crédito”. Para as operações de validação de CPF e CNPJ, podemos criar um serviço “Validação” e para a operação de envio de e-mail, um serviço “Email”. A Figura B.4 mostra B.4 mostra os contratos definidos para representar os serviços candidatos identificados. Após a definição dos serviços s erviços candidatos, devem ser elaboradas descrições textuais de cada serviço candidato e de cada operação, definindo os dados de entrada e saída e a lógica executada. executada.

Análise de Gap Após a identificação dos serviços candidatos, a análise prossegue com a análise de gap. O objetiv objetivo o básico desta análise é localizar localizar,, nas aplicações existentes (legado), as funções necessárias aos serviços candidatos, chegando a um cenário de reuso para cada operação candidata. Para analisar os cenários de reuso, deve-se consultar um repositório de serviços e recursos reusáveis ou fontes de documentação das aplicações existentes. O cenário

142

Apêndice B

Figura B.4

Serviços candidatos identificados.

mais comum é encontrar uma arquitetura que ainda não possua um repositório de serviços reusáveis. Neste caso recorre-se à documentação dos sistemas legados. Especificamente pecificam ente neste cenário, aplicação legada é o sistema de cadastro de clientes. Como resultado dessa análise, foram obtidos os cenários de reuso apresentados na Tabela B.3 B.3..

TABELA B.3 Cenários

de reuso para as operações candidatas

Serviço Candidato

Operação Candidata

Cenário de Reuso

Cliente


Operação parcialmente realizada por aplicação legada (componente GerenciadorPessoa do sistema de cadastro de clientes)

Val alid idar ar da dado doss de de cli clien ente te

Oper Op eraç ação ão nã não o exi exist sten ente te

Grava Gra varr dado dadoss de de clie cliente nte

Operação Operaç ão rea realiz lizada ada por apl aplica icação ção leg legada ada (componente GerenciadorPessoa GerenciadorPessoa do sistema de cadastro de clientes)

Consultar documentos obrigatórios


Arma Ar mazzen enar ar doc docum umen ento to

Opeeraç Op ação ão nã não exi exist sten ente te

Consultar Serasa

Operação realizada por serviço existente (serviço de consulta do Serasa)

Consultar SPC

Operação realizada por serviço existente (serviço de consulta do SPC)

Validar número de CPF

Operação realizada por aplicação legada (biblioteca de classes LibCorporativ LibCorporativa) a)

Vali alidar dar núm número ero de CNPJ CNPJ

Operação Operaç ão real realiza izada da por por apli aplicaç cação ão lega legada da (biblioteca de classes LibCorporativ LibCorporativa) a)

Enviar e-mail

Operação realizada por aplicação legada (biblioteca de classes LibCorporativ LibCorporativa) a)

Documento

Consulta Crédito

Validação

Email

Apêndice B

143

A lógica necessária para as operações “Gravar dados de cliente” e “Verificar existência de cliente” do serviço “Cliente” já eram realizadas por uma aplicação legada, neste caso o componente “GerenciadorPessoa” pertencente ao sistema de cadastro de clientes. Entretanto, a operação “Verificar existência de cliente” era realizada apenas parcialmente pelo componente “GerenciadorPessoa”, já que este possuía apenas um método de busca de cliente para realizar esta verificação. As operações do serviço “Consulta Crédito” já são executadas por serviços externos ao Serasa e ao SPC e podem ser reusadas diretamente. Verificou-se também a existência de uma biblioteca de classes utilitárias “LibCorporativa” que continha métodos que realizavam as operações “Validar número de CPF” e “Validar número de CNPJ” do serviço “Validação” e “Enviar e-mail” do serviço “Email”. Os cenários de reuso analisados devem ser documentados juntamente com as descrições das operações.

Análise de Realização Na análise de realização, cada operação candidata é avaliada quanto ao seu cenário de reuso identificado anteriormente. Nesta atividade, deve ser decidido como cada operação de serviço será realizada. As possibilidades de realização dos serviços candidatos devem ser analisadas pelo arquiteto de serviços e discutidas com os responsáveis pelo repositório de serviços ou pela arquitetura corporativa. As decisões de realização resultantes da análise devem ser registradas nas descrições das operações e serviços candidatos. Para cada contrato de serviço, deve ser indicado qual será sua realização. Foram tomadas as seguintes decisões de realização: Serviço “Cliente” Para realizar esse serviço, decidiu-se criar um novo Web Service que seria responsável por invocar os métodos do componente “GerenciadorPessoa” do sistema de cadastro de clientes e implementar as funções das operações não existentes. No caso da operação “Verificar existência de cliente”, o Web Service deverá implementar a lógica necessária para retornar o resultado desejado. Serviço “Documento” Como as duas operações desse serviço não existiam, um novo Web Service será implementado para executar suas funções. Como este serviço armazena algumas informações persistentes (como os documentos digitalizados), deve ser utilizada uma base de dados para apoiar o serviço. Serviço “Consulta Crédito” Para esse serviço, ambas as operações já são realizadas por um serviço existente, porém, externo à organização. Para manter a padronização dos serviços, decidiu-se criar um novo Web Service para encapsular o acesso aos serviços externos, abstraindo a localização do serviço original e detalhes específicos. Para tal, o Web Service deverá executar lógica de mediação, como mapeamento de mensagens e roteamento.

144

Apêndice B

Serviços “Validação” e “Email” Operações implementadas por dois novos Web Services responsáveis por encapsular as classes da biblioteca utilitária “LibCorporativa”.

B.4 DESIGN Na fase de design procura-se especificar os serviços definidos em detalhes, verificando também se os princípios estão sendo atendidos. Os serviços são revisados e orquestrados.

Especificação de contrato de Serviços A atividade de especificação de serviços tem como objetivo detalhar as classes de mensagens e as interfaces de serviços, inclusive com a descrição técnica de cada operação, para chegar aos artefatos que comporão o contrato do serviço. Como as operações foram descritas apenas textualmente, neste momento há a necessidade de se definirem os parâmetros das operações, permitindo a identificação de algumas mensagens. Por exemplo, para a operação “Gravar dados de cliente” do serviço “Cliente” definiu-se que um parâmetro de entrada da operação seria uma mensagem com vários campos representando os dados do cliente e o parâmetro de saída (ou de retorno) seria um indicador de sucesso da gravação (boolean). Dessa maneira, devem-se definir as mensagens utilizadas nas operações de serviços a partir das definições do processo. Para a implementação dos Web Services , as mensagens devem ser formalmente modeladas como esquemas XSD (XML Schema Definition). O arquiteto de serviços deve definir também informações adicionais nos contratos de serviços, tais como: ● ● ● ●

especificação do tipo de dado de cada atributo das classes de mensagens; especificação do tipo de dados de cada parâmetro de operação; seleção dos parâmetros das operações com base na lógica a ser implementada; especificação de requisitos não funcionais, como segurança (autenticação e autorização).

Para a especificação formal dos contratos dos Web Services, são utilizadas interfaces WSDL (Web Service Definition Language ). Além dos contratos formais dos serviços, o arquiteto de serviços define também a qual camada pertence cada serviço, de acordo com seu nível de granularidade e relevância para a lógica de negócio. A classificação dos serviços nas camadas pode ser vista na Figura B.5.

Especificação de componentes de serviço Após a definição dos contratos de serviços, o arquiteto de serviços cria as especificações de serviços de acordo com as decisões de realização tomadas na fase de análise. O arquiteto de serviços, então, define, para cada interface de serviço, um componente

Apêndice B

Figura B.5

145

Camadas de serviços.

de serviço exposto através da tecnologia Web Services. Estes componentes de serviço serão os responsáveis por encapsular as aplicações legadas e serviços existentes reusados, ou executar a lógica da operação (no caso de operações não existentes). A especificação de realização dos serviços pode ser visualizada na Figura B.6.

Verificação de princípios O objetivo dessa atividade é verificar se cada especificação de serviço criada atende aos princípios de orientação a serviços e se está adequada a integrar o portfólio de serviços da organização.

Figura B.6

Realização dos serviços.

146

Apêndice B

A verificação de princípios deve ser realizada em uma reunião envolvendo o arquiteto de serviços, os responsáveis pelo portfólio de serviços, ou pela arquitetura corporativa, e o gerente do projeto sendo executado. A seguir, serão descritos os resultados obtidos da verificação de princípios em cada um dos serviços projetados. Serviço “Cliente” A operação “Validar existência de cliente” pode ser considerada como possuindo reusabilidade alta, isto é, tem potencial de ser reusada por outros processos de negócio. Entretanto, para tornar o serviço mais reusável, pode-se adicionar outras operações à interface, já existentes no componente “GerenciadorPessoa” encapsulado pelo serviço, como “Remover dados de cliente” e “Obter cliente por nome”. As operações podem ser especificadas no contrato do serviço, mas não seriam implementadas imediatamente no projeto em questão. As atividades de implementação do projeto podem focar somente nas operações necessárias para suportar o processo de negócio “Cadastro de Cliente”, e as outras operações podem ser implementadas como parte de outro projeto, com esforço e prazo dimensionados para tal. O nível de granularidade do serviço pode ser considerado adequado. Já a autonomia do serviço pode ser um ponto de atenção, uma vez que os componentes encapsulados pertencem a um sistema legado e possuem relacionamentos com outros componentes. Serviço “Documento” O serviço foi considerado com nível de granularidade alta por trabalhar com uma entidade relevante para o processo de negócio – documento. A avaliação do serviço constatou sua autonomia , pois toda sua lógica estava contida em um novo Web Service , sem dependência com outros sistemas externos. Serviço “Consulta Crédito” O serviço foi considerado com nível de granularidade adequado para reuso, uma vez que implementa operações de baixa granularidade. Porém, o serviço pode ter problemas relacionados a autonomia e acoplamento, uma vez que é baseado em serviços providos por entidades externas. Serviços “Validação” e “Email” Esses serviços foram projetados desde o início de forma a possuírem alta reusabilidade , com operações utilitárias de baixa granularidade e aplicáveis a diversos contextos de negócio. Portanto, eventuais ajustes poderiam incluir apenas a adição de novas operações, já presentes nas classes da biblioteca “LibCorporativa”.

B.5 FASES COMPLEMENTARES Construção

Implementação de serviços A partir da especificação dos contratos e realizações de serviços, devem ser conduzidas as atividades de implementação dos componentes de serviços e integração desses ao processo de negócio.

Apêndice B

147

A partir desse ponto podem ser utilizadas tecnologias como Java EE ou Microsoft .NET para implementação dos Web Services , e plataformas BPM para automação do processo, como IBM WebSphere Process Server, Oracle BPM Suite ou jBPM.

Orquestração de Serviços Durante a orquestração de serviços, o modelo de processo to-be elaborado no início do projeto é convertido em um modelo de implementação, que deve ser trabalhado para tratar todas as regras de negócio modeladas e adequar-se aos serviços especificados. O fluxo de trabalho do processo pode ser automatizado na plataforma BPM utilizando-se a linguagem WS-BPEL ( Web Services Business Process Execution Language). Além da própria estrutura do processo (tarefas, decisões e conexões), é necessário também implementar no processo os seguintes aspectos: variáveis; ● lógica de tratamento de dados; lógica de decisão nos nós do tipo “Choice” ( if-then-else); ● ● dados de correlação de instâncias de processo; ● tempo de expiração de atividades com tal requisito; mapeamento das interfaces geradas no WS-BPEL para as interfaces WSDL dos ● serviços utilizados pelo processo. ●

Após implementado, o processo em WS-BPEL é encapsulado pelo serviço de orquestração “Cadastro de Cliente”, que por sua vez será composto pelos outros serviços. Para tal, foi necessário também definir a interface WSDL e as mensagens em XSD para o serviço de orquestração. A Figura B.7 mostra a composição do serviço de orquestração “Cadastro de Cliente”.

Figura B.7

Composição do serviço de orquestração “Cadastro de Cliente”.

148

Apêndice B

Teste de serviços Uma vez implementados todos os componentes de serviços e a orquestração do processo, deve ser testada a solução como um todo. São realizados testes unitários de cada componente de serviço e, então, um teste integrado do processo de negócio orquestrando a execução dos serviços, para assegurar que a solução está funcionando corretamente. Adicionalmente, podem ser realizados testes de carga e desempenho com o intuito de verificar o atendimento a requisitos não funcionais. Por fim, são executados testes de aceitação com os usuários do processo, de forma a homologar a solução para que ela possa passar para as fases seguintes de implantação e gerenciamento.

Glossário

Abstração Abstração é uma técnica usada na modelagem de entidades complexas, como uma organização

ou um sistema de software, cujo objetivo é obter de maneira concisa os aspectos essenciais da entidade sem considerar os seus detalhes. API ( Applicatio protocol os Application n Prog Programm ramming ing Inte Interfac rfacee) API é um conjunto de rotinas, bibliotecas, frameworks, protocolos e classes independentes de linguagem de programação disponibilizados para apoiar o desenv desenvolvimento olvimento de aplicações de software. Arquitetura Uma arquitetura representa uma visão dos elementos estruturais e comportamentais do sistema. Ator Ator é um papel de uma pessoa ou um usuário que inicia e interage com o sistema. BPM ( Business Business Proc Process ess Man Managem agement ent) BPM é uma abordagem sistemática para identificar, avaliar e melhorar os processos de negócio tornando-os mais efetivos e capazes de se adaptarem às mudanças do ambiente e às metas organizacionais. BPMN ( Business Business Process Process Modeling Modeling Notation) BPMN é uma representação gráfica para especificar fluxos de processos de negócio e Web Services. BPMS ( Business Business Process Management Management System) BPMS é uma ferramenta que permite modelar, analisar, implementar,, integrar, implantar e monitorar atividades e processos de negócio. implementar Caso de uso Caso de uso é uma técnica para especificar uma função do software do ponto de vista de um ator (usuário ou outro sistema). Ciclo de vida Ciclo de vida é o período de tempo que inicia quando um produto de software é concebido e termina quando o software não é mais disponível para o uso. O ciclo de vida de software tipicamente inclui uma fase de concepção, requisitos, design, implementação, teste, instalação e verificação, operação e manutenção, e, algumas vezes, retirada de operação. Cloud Services Cloud Services, no contexto de computação em nuvem, referem-se aos recursos de processamento e armazenamento disponibilizados como serviços, sem que o usuário conheça a localização dos provedoress destes serviços. provedore Pattern é uma solução para problemas comuns que ocorrem em desenvolvimento de Design Pat Pattern tern Design Pattern software. No contexto de SOA, é um template que pode ser usado em diversas situações no design de serviços. IDE ( Integrated Integrated Development Environment) IDE é um ambiente de desenvolvimento de software com recursos integrados para dar maior produtividade aos desenvolvedores. Exemplos: Eclipse, Net Beans, Microsoft Visual Visual Studio etc. ESB ( Enterpris Enterprisee Serv Service ice Bus) ESB é um middleware que possibilita a comunicação entre vários componentes de uma arquitetura SOA. Ferramenta CASE ( Computer Aided Software Engineering ) Ferramenta CASE é um programa de computador usado no desenvolvimento, teste, análise ou manutenção de um programa ou sua documentação. é um conjunto de suposições, conceitos, valores e práticas que constituem uma Framework Framework é maneira de ver o ambiente atual. KPIs ( Key Key Perf erforma ormance nce Indi Indicat cators ors) KPIs são indicadores quantitativos que refletem fatores críticos de sucesso de uma organização. As KPIs são utilizadas por organizações para aferir o progresso do atingimento de uma determinada meta de negócio. Mensagem (de serviço) Mensagem é uma tecnologia usada no design de serviços para permitir a interação entre eles. Esta tecnologia reduz os requisitos de acoplamento e remove a necessidade de conexões persistentes. Metadados Metadados são dados que descrevem dados ou informações (dados) que descrevem dados primários. 149

150

Glossário

Método Método é um padrão que descreve ordenadamente as características de um processo ou o u procedimento

usado na engenharia de um produto ou realização de um serviço. Middleware Middle ware Middleware é uma camada de software que permite conectar diferentes aplicações de software em sistemas distribuídos. Modelo de processo Modelo de processo é uma representaçã representaçãoo que reúne processos, métodos e ferramentas, e fases genéricas. É uma abstração do processo real que está sendo executado. Nuvem (computação em nuvem) Nuvem ou computação em nuvem (cloud computing) refere-se à disponibilização de recursos computacionais através da Internet. No contexto de SOA, estes recursos são disponibilizados como serviços. Operação (de serviço) Operação (também chamada de competência ou capacidade) é uma função executada por um serviço e que pode ser invocada através de mensagens. Um serviço é composto de uma ou mais operações, que são definidas em seu contrato. Orquestração de serviços Orquestração de serviços é um procedimento automatizado de composição de serviços para criar nova funcionalidade. Processo de negócio É um conjunto de atividades que são aplicadas a todos os projetos de software, sem considerar o seu tamanho ou complexidade. É uma série de estágios que env envolvem olvem atividades, controles e recursos para produzir uma saída de alguma espécie. Processo de software Processo de software é um conjunto de atividades voltadas ao desenvolvimento desenvolvimento e evoluçãoo de um software. O processo envolve a tradução das necessidades do usuário em requisitos de evoluçã software, transformação transformação de requisitos em design, implementação do design em código, teste de código e, algumas vezes, instalação e verifica verificação ção de software para uso operacional. Por exemplo, desenvolvimento desenvolvimento incremental, prototipação rápida, modelo espiral, modelo cascata. Produto de software Produto de software é um conjunto completo de programas de computador, procedimentos e possivelmente documentação associada e dados projetados para serem liberados para um usuário. Qualidade de serviço (QoS – Quality of Service ) Qualidade de serviço refere-se ao atendimento de requisitos não funcionais, tais como segurança de acesso, desempenho, disponibilidade, confiabilidade, escalabilidade, tolerância a falhas, integridade transacional, entre outros. Requisito Requisito é uma declaração de algo que precisa ser implementado no sistema. Um requisito funcional é uma característica ou função do software. Um requisito não funcional é uma restrição ou comportamento esperado que se aplica a todo o sistema. REST ( REpresentational REpresentational State Transfer) REST define um estilo de arquitetura para a Web, baseado no protocolo HTTP e é considerado uma alternativa à tecnologia Web Services Servic es para implementação de serviços. Reuso Reuso é uma tecnologia para aumentar a produtividade com o reuso de sistemas ou componentes existentes. ROI ( Return Return on In Inve vestme stment nt) ROI ou retorno do investimento é uma métrica de desempenho financeiro baseado no retorno de um dado investimento comparado ao custo deste investimento. No contexto de SOA, o ROI é afetado principalmente pela capacidade de reuso de serviços e de recursos existentes, pois possibilita a obtenção de novos retornos sobre um investimento já realizado no passado. RUP ( Rational Unified Unified Process) RUP ou processo unificado da empresa IBM/Rational é um processo de software iterativo iterativo voltado ao desenvolvimento orientado a objetos e usa a UML como linguagem de modelagem. SCA (Service Component Architecture ) SCA define um conjunto de especificações que descrevem um modelo para desenvolver desenvolver aplicações compostas que seguem os princípios do paradigma de orientação a serviços. A tecnologia SCA permite implementar componentes de serviços em uma variedade de linguagens e plataformas e integrá-los através de diversos protocolos de comunicação. Serviço No âmbito de uma arquitetura SOA, serviço é um elemento computacional que tem como propósito desempenhar uma função específica e que pode ser utilizado por um cliente. SLA (Service Level Agreement ) Um SLA é parte do contrato de serviços entre o provedor e o consumidor de serviços. O SLA é um acordo firmado entre ent re o provedor e o consumidor para definir a qualidade quali dade de serviço (QoS) a ser fornecido, principalmente abordando requisitos de desempenho e disponibilidade.

Glossário

151

SOA (Service Oriented Architecture ) SOA é uma tecnologia que torna possível, além do reuso de aplicações,

o acesso a informações diversas disponíveis em vários computadores ligados na Internet. SOAP (Simple Object Access Protocol ) SOAP é um protocolo baseado em XML que permite às aplicações trocarem informações estruturadas nas implementações de Web Services. Stakeholder Stakeholder é uma pessoa, área ou organização que está ativamente envolvida no projeto cujos interesses podem ser afetados durante a execução do projeto. Técnica Uma técnica descreve as características acumuladas na aplicação de habilidades e métodos técnicos e gerenciais na criação de um produto ou realização de um serviço. UDDI (Universal Description, Discovery, and Integration ) UDDI é um registro (catálogo) baseado em XML usado para que os consumidores de serviços possam descobrir e integrar Web Services publicados por seus provedores. UML (Unified Modeling Language ) UML é uma linguagem visual resultante de numerosos métodos orientados a objetos que existiam no início da década de 1990. Fornece diferentes visões de um sistema por meio de seus diversos tipos de modelos. Web Service Web Service é uma tecnologia que permite a interoperabilidade de máquinas na Internet. WS-BPEL (Web Services Business Process Execution Language ) WS-BPEL é uma linguagem executável padrão para especificar processos de negócio com Web Services. WSDL (Web Services Description Language) WSDL é uma linguagem baseada em XML para descrever as assinaturas das operações fornecidas por um Web Service e como acessá-lo. XML ( Extensible Markup Language) XML é um formato de texto simples e muito flexível originalmente projetado para atender aos desafios de publicação eletrônica em larga escala. A XML tem um papel importante no intercâmbio de uma extensa variedade de dados da Internet. Está presente na norma ISO 8879:1986. XSD (XML Schema Definition) XSD é uma linguagem formal para especificação de restrições de estrutura e conteúdo de documentos XML.

Índice Remissivo

A .NET, 14, 147 Abordagem bottom-up, 43 "do zero'', 47 incremental, 21, 47 iterativa, 58 meet-in-the-middle, 43 top-down, 43, 45 Abstração, 115, 149 princípio, 23 Adaptador de integração, 30, 109, 110 Administrador de serviços, 54 Alinhamento com o negócio, 37 Ambiente de execução, 27, 38 Ambiente de TI, 2 Análise de fase, 49, 140 de gap, 141 de realização, 91, 143 Analista de processos, 50-51 de serviços, 51-52 API – Application Programming Interface, 45, 149 Aplicação legada, 87-90 web, 15, 27–29 Arquiteto corporativo, 52, 116 de serviços, 52, 102, 140, 143, 144 Arquitetura de Informação, 19, 31, 34 camada, 15 Arquitetura Orientada a Serviços, 8-11, 13, 15-19, 2328, 31-32, 35-38, 44, 45 Arquitetura de referência, 13, 14, 52, 123, 124 de software, 7, 10 SOA, 8-11, 13, 15-19, 23-28, 31-32, 35-38, 44, 45 Artefatos, 54-57 Ator de processo, 54 Autonomia, 24, 146 princípio, 115

B Baixo acoplamento, 23 princípio, 115 BAM – Business Activity Monitoring, 27, 31, 33, 128

Banke, 131 Base de dados, 31, 32, 78, 102 Bell, 3, 18, 22-24 Bieberstein, 18, 36, 37 Boas práticas, 43 Booch, 132 Bottom-up, 43, 45, 101 BPM ( Business Process Management), 44, 49 BPMN ( Business Process Modeling Notation), 44, 46, 54, 62, 63, 149 BPMS ( Business Process Management System), 15, 25, 27, 28, 149 Business intelligence, 16, 31, 128 Business Process Management . Ver BPM

C Caixa-preta, 12, 103, 115, 124 Camadas de serviços, 18, 20, 46, 145 Canonical Schema (design pattern), 102 Canonical Versioning (design pattern), 95 capacidade de composição, 24 princípio, 116 Caso de uso, 56, 71, 149 Casos de Uso de Negócio, 45, 50, 71 CBD – Component Based Development , 46 Cenário de reuso, 85, 142 Centro de Excelência SOA, 52 Christensen, 131 Ciclo de vida, 149 de software, 3, 5 SOA, 43-58 Ciclo de vida iterativo, 58 Ciclo de vida orientado a serviços, 3 Cloud computing, 35, 150 Cloud service provider , 26 Cloud service, 84, 149 Cockburn, 108, 131 Competência agnóstica (design pattern), 114 Complextype, 101 Component Based Development , 46 Componente de serviço, 14, 93, 94, 96, 107, 108, 144, 148 camada, 14 Componentização de software, 12 Composição, Capacidade de, 24 princípio, 116 Composição de serviços, 20, 21 Computação em nuvem. Ver cloud computing

153

154

Índice Remissivo

Confiabilidade, 15, 35, 101 Construção, 49, 119 fase, 49 Consumidor de serviço, 57, 85, 101 Contract Centralization (design pattern), 114, 117 Contrato, 11, 12, 22 de serviço, 56-57, 99-107 Contrato padronizado, 22 princípio, 114 COTS - Commercial Off-The-Shelf , 2 CRM – Customer Relationship Management , 1, 89, 90, 96

D Dados, 69 DAO, 112, 113 Data warehousing, 31, 128 Decisões de Realização, 91, 95, 143, 144 Desempenho, 38 Desenvolvedor, 53, 119 Design fase, 49, 58, 99, 100 pattern, 52, 53, 149 Diagramas de implantação, 109 Disponibilidade, 13, 34 Dranidis, 3, 132

E Elementos, 25, 26 Encapsulamento, 12, 23, 39 Endrei, 40, 131 Engenharia de Software, 2 ERL, 3, 7, 18, 131 ERP – Enterprise Resource Planning, 1, 14 ESB – Enterprise Service Bus, 28, 149 Escalabilidade, 15, 28, 35 Especificação de contrato de serviços, 99 de processo, 55 de realização de serviços, 107 de requisitos, 140 de serviço, 57 Esquemas de mensagens, 13, 101 Estilo arquitetural, 5, 10 Evidências de teste, 122

F Fallside, 131 Ferramenta CASE – Computer Aided Software Engineering, 149 Ferramentas de Desenvolvimento, 27, 34 de Infraestrutura de Aplicações, 27, 35 Framework, 13, 149 Fugita, 131

G Gap de dados, 85, 93, 94 de formato, 85, 86 de lógica, 85-87, 92-94 de protocolo, 85 Gerenciamento, 49 fase, 49 Gerente de projeto, 53, 95 Gestor de processos, 54, 128 Gornik, 132 Governança, 39 camada, 16 Granularidade de serviço, 17

H Hirama, v, 131 Huhns, 10, 131

I IDE – Integrated Development Environment , 34, 149 Identificação de Serviços Candidatos, 56, 75, 140 Implantação, 49, 124 de Serviços, 126 fase, 49 Implementação de Serviços, 119, 146 Independência de estado, 24 princípio, 115 Informação, 15 Infraestrutura de TI, 1, 2, 14, 18, 27, 84 Integração camada, 15 Interface de serviço, 12, 102, 109 Interfaces consumidoras, 15, 78 camada, 25 Internet, 4, 10 Interoperabilidade, 16, 17, 22, 25 princípio, 116

J Jacobson, 132 Java, 14, 147 Jeston, 131

K Keen, 28, 131 Kenney, 131 KPIs – Key Performance Indicators, 31, 50, 149 Krafzig, 131 Krebs, 132 Krutchen, 131

L Logic Centralization (design pattern), 96, 114 Lógica, 13, 25 Lycett, 40, 132

Índice Remissivo

M Manutenção de serviços, 126, 127 Marks, 131 Mediação, 85, 93, 119 Meet-in-the-middle, 43, 101 Mensagem, 9, 101, 102 Metadados, 32, 124, 149 Método, 43-47 de análise e design, 13, 44-47 de desenvolvimento de serviços, 3 Metodologias de desenvolvimento, 3 Métricas, 62 de processo de negócio, 127 Middleware, 2, 16, 28, 150 Modelagem, 50, 59-74, 137 fase, 47, 59, 63 Modelo de dados, 19, 36, 101, 102, 108, 113 Modelo de processo as-is, 59, 137 de processo to-be, 64, 138 de referência, 2 de serviços, 56-58 Monitor de Atividade de Negócio (BAM), 31 Monitor de Atividade de Serviços (SAM), 33 Monitoração de Atividade de Negócio, 62, 127, 128 Monitoração de Serviços, 15

N Necessidades de negócio, 2, 5, 47, 64, 70 Nelis, 131 Nuvem. Ver cloud computing

O Oasis, 2, 5, 131 Objeto de software, 5 OMG – Object Management Group, 16 Open Group, 13, 14, 131 Operação candidata, 76-78, 81, 86, 87, 92-94, 96, 140-143 Operation, 102 Orientação a componentes, 40 a objetos, 39, 40 a serviços, 4, 22, 36 Orquestração de serviços, 121, 147, 150

P Pacotes de implantação, 126 Padrões abertos, 12, 16, 45, 46 Padronizado contrato, 22 princípio, 114 Papazoglou, 12, 13, 132 Papéis, 50, 64

155

Paradigma de desenvolvimento de software, 1, 39 de orientação a serviços, 18, 39, 41, 129 Perrey, 40, 132 Plataforma BPMS, 25, 28, 67, 138 Políticas, 13 Portal, 29 Portfólio de serviços, 21, 22 Portlets, 29 Porttype, 102 Princípios da orientação a serviço, 3, 4, 40 Processo de Negócio, 9, 10, 150 de Software, 150 Orquestrado, 121, 122 Processos de desenvolvimento, 3 Processos de negócio, 27 camada, 15 Produto de software, 5, 47, 150 Provedores de serviço, 11 Publicação de serviços, 124, 125

Q QoS – Quality of Service, 45, 150 Qualidade de Serviço, 150 camada, 15

R Ramollari, 3, 132 Realização, 11, 13, 91, 107, 143 de serviço, 145 Registro de Serviços, 45, 92, 107 Regras de Negócio, 66, 71, 72, 76 Repositório de serviços, 2, 141-143 de metadados, 12, 32 Requisitos de negócio, 3, 10, 37 funcionais, 64, 85, 103 não funcionais, 45, 72, 140, 144 REST – REpresentational State Transfer , 17, 150 RESTful – RESTful services ou RESTful web services, 17 Reusabilidade, 22, 23, 146 princípio, 114 Reuso, 44, 150 ROI – Return on Investment , 36, 150 Rumbaugh, 132 RUP – Rational Unified Process, 3, 150

S SAM – Service Activity Monit oring, 33 SCA – Service Component Architecture, 150 SCM – Supply Chain Management , 1 Segurança, 38 Service Decomposition (design pattern), 118

(Em Portuguese Do Brasil) Henrique Shoiti Fugita-SOA-CAMPUS - GRUPO ELSEVIER (2011)

Recommend Documents