View
0
Download
0
Category
Preview:
Citation preview
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE EDUCAÇÃO SÃO JOSÉ
CURSO DE CIÊNCIA DA COMPUTAÇÃO
TRABALHO DE CONCLUSÃO DE CURSO
ARQUITETURA ORIENTADA A SERVIÇO : UMA ANÁLISE DAS PROPOSIÇÕES
TECNOLÓGICAS COM FOCO NA AUTOMAÇÃO DE PROCESSOS DE
NEGÓCIOS
Fábio Mattos de Barros Acadêmico
Paulo Roberto Riccioni Gonçalves Professor orientador
São José, junho de 2005
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE EDUCAÇÃO SÃO JOSÉ
CURSO DE CIÊNCIA DA COMPUTAÇÃO
ARQUITETURA ORIENTADA A SERVIÇO : UMA ANÁLISE DAS PROPOSIÇÕES
TECNOLÓGICAS COM FOCO NA AUTOMAÇÃO DE PROCESSOS DE NEGÓCIOS
Sistemas Distribuídos
Fábio Mattos de Barros Acadêmico
Proposta de trabalho apresentada ao Responsável pela Coordenação de Trabalho de Conclusão do Curso de Ciência da Computação da Universidade do Vale do Itajaí - São José, para o desenvolvimento durante as disciplinas de Trabalho de Conclusão de Curso I e II.
São José, junho de 2005
FÁBIO MATTOS DE BARROS
ARQUITETURA ORIENTADA A SERVIÇO : UMA ANÁLISE DAS PROPOSIÇÕES TECNOLÓGICAS COM FOCO NA AUTOMAÇÃO DE PROCESSOS DE
NEGÓCIOS
Este Trabalho de Conclusão de Curso foi julgado adequado como requisito parcial para a obtenção do título de Bacharel em Ciência da Computação, tendo sido aprovado pelo Curso de Ciência da Computação, Centro de Educação São José da Universidade do Vale do Itajaí (SC).
São José, 19 de dezembro de 2005.
_____________________________ ___________________________________ Prof. Esp. Alecir Pedro da Cunha Prof. M. Eng. Fernanda dos Santos Cunha Responsável pela Coord. do TCC Coordenadora do Curso
Apresentada à Banca Examinadora formada pelos professores:
________________________________ Orientador Prof. Msc. Paulo Roberto Riccioni Gonçalves
___________________________________________________ Profa. Dra. Eliza Coral
__________________________________________________ Prof . Msc. Paulo Henrique de Souza Bermejo
SUMÀRIO
1 INTRODUÇÃO .............................................................................................................. 11 1.1 Contextualização ......................................................................................................11 1.2 Justificativa...............................................................................................................15 1.3 Objetivos...................................................................................................................16
1.3.1 Objetivo Geral ..................................................................................................16 1.3.2 Objetivos Específicos........................................................................................16
1.4 Metodologia..............................................................................................................17 1.5 Delimitações da Pesquisa .........................................................................................17
2 ARQUITETURA ORIENTADA A SERVIÇOS (SOA) ............................................. 19 2.1 Serviços ....................................................................................................................20 2.2 Definindo a SOA ......................................................................................................24 2.3 Evolução da Arquitetura de Sistemas.......................................................................26 2.4 Os Elementos da SOA ..............................................................................................30 2.5 SOA e Web Services .................................................................................................32
3 A GESTÃO DE PROCESSO DE NEGÓCIOS - BPM ............................................... 37 3.1 Processos de Negócios .............................................................................................37 3.2 Gerenciando Processos .............................................................................................39 3.3 Evolução dos Sistemas de Informação frente à adequação dos Processos de Negócios ...............................................................................................................................44 3.4 BPM versus WFMS..................................................................................................47 3.5 Processo de Desenvoilvimento BPM versus RUP ...................................................49 3.6 BUSINESS PROCESS MANAGEMENT SYSTEMS – BPMS .............................51 3.7 UTILIZANDO SOA COM BPMS...........................................................................57 3.8 Critérios para Avaliação de BPMS...........................................................................60
4 MODELANDO E EXECUTANDO PROCESSOS ..................................................... 65
4.1 Identificação dos Processos ......................................................................................65 4.2 Definição do Modelo de Referência.........................................................................66 4.3 Modelos de Referência e Padrões para Processos ....................................................68
4.3.1 SCOR - Supply Chain Operations Reference Model ........................................68 4.3.2 RosettaNet.........................................................................................................71
4.4 Captura e Identificação dos Processos......................................................................75 4.5 Elaboração dos Processos.........................................................................................77 4.6 Colaboração de Negócio...........................................................................................78 4.7 Definição das Transações de Negócio......................................................................80 4.8 Linguagens e Notações para Modelagem em nível de Execução.............................82 4.9 A Linguagem BPEL .................................................................................................84 4.10 Elementos da Linguagem BPEL ..............................................................................87
5 PROJETO DE DEMONSTRAÇÃO DE USO DA ARQUITETURA ....................... 92 5.1 Metodologia..............................................................................................................94 5.2 Ferramentas e aplicações de infra-estrutura tecnológica..........................................95 5.3 Análise dos Processos...............................................................................................96
5.3.1 Definição do Modelo de Referência .................................................................96 5.3.2 Definição das Áreas de Negócio ......................................................................96
5.3.3 Definição das Áreas de Processos ...................................................................97 5.3.4 Identificação dos Processos .............................................................................97 5.3.5 Elaboração de Processos de Negócio ..............................................................98 5.3.6 Transação de Negócios ..................................................................................100
5.4 Especificação dos Serviços.....................................................................................104 5.4.1 Serviço de Vendas...........................................................................................104 5.4.2 Serviço Gerenciamento de Estoque................................................................104 5.4.3 Serviço de Compras........................................................................................104
6 CONCLUSÃO............................................................................................................... 106
REFERÊNCIAS ................................................................................................................... 109
RESUMO
Atualmente, o modelo globalizado e altamente competitivo dos negócios sugere a
adoção de sistemas de informações altamente adaptáveis às mudanças nos processos
organizacionais. Desta forma, para agilizar a disponibilização de serviços computacionais, é
necessária a reutilização otimizada dos sistemas existentes, partindo-se da idéia que utilizar
elementos de sistemas legados é mais rápido do que refazê-los dentro de um processo de
desenvolvimento de software. Assim, esta pesquisa tem como objetivo analisar os elementos
pertinentes a Arquitetura Orientada a Serviços bem como os elementos do Gerenciamento de
Processos de Negócios como abordagens para a concepção de sistemas de tecnologia da
informação em ambientes onde os processos de negócios são altamente suscetíveis a
mudanças e a diversidade de plataformas de software é presente no parque tecnológico da
organização. Assim, a primeira parte da pesquisa irá abordar os elementos da SOA e da
plataforma Web Service. Em uma segunda etapa, serão apresentados os elementos do BPM
bem como a definição dos servidores que suportam a automação dos processos de negócios,
designados como BPM Systems. Em seguida propõe-se o estudo de metodologias para
identificação e modelagem de processos de negócios, juntamente com padrões e modelos que
podem ser utilizados em tais atividades. Finalmente, compete também a esta pesquisa, a
implementação de uma aplicação de teste que terá como objetivo fornecer dados para uma
análise prática da utilização das tecnologias apresentadas.
LISTA DE FIGURAS Figura 2-1 – Acessando e combinando serviços. .....................................................................20 Figura 2-2 - Sistema de equipamentos de Áudio e Vídeo ........................................................22 Figura 2-3 - Alinhamento dos serviços SOA com os serviços oferecidos pela organização. ..25 Figura 2-4 - Diferentes implementações da SOA.....................................................................26 Figura 2-5 - Evolução da Arquitetura de Sistemas...................................................................27 Figura 2-6 Crescimento Horizontal de Disponibilização de Aplicações..................................29 Figura 2-7 - Elementos da SOA. ..............................................................................................31 Figura 2-8 - Componentes de uma descrição de serviço usando WSDL .................................34 Figura 2-9 - Estrutura UDDI ....................................................................................................35 Figura 2-10 - Composição da SOA com a plataforma Web Service........................................36 Figura 3-1 - Composição de Processos ....................................................................................38 Figura 3-2 - Disciplinas do BPM..............................................................................................43 Figura 3-3 - Separação da Lógica dos Processos de Negócio. .................................................44 Figura 3-4 – Processos em Sistemas Legados. .....................................................................................45 Figura 3-5 - Processos no ERP. ........................................................................................................45 Figura 3-6 - Funções de um Sistema de Gerenciamento de Workflows.....................................................47 Figura 3-7 - Integração de processos internos e externos.........................................................49 Figura 6-1 - Comparação Disciplinas BPM versus RUP .........................................................50 Figura 3-8- Diferentes Visões dos Fornecedores de BPMS.....................................................52 Figura 3-9 - Modelo Simplificado de um BPMS. ....................................................................53 Figura 3-10 - Ferramenta de Modelagem de Processos Microsoft BizTalk Server .................53 Figura 3-11 - Esquema de um servidor de regras de negócio. .................................................55 Figura 3-12 - Painel de Indicadores Chave de Performance ...................................................56 Figura 3-13 – Estrutura padrão de distribuição de sistemas.....................................................57 Figura 3-14 – Inclusão da camada de serviços .........................................................................58 Figura 3-15 – Adicionando a camada de processo de negócio.................................................59 Figura 3-16 - Evolução Contínua das soluções BPMS. ...........................................................61 Figura 3-17 – Detalhamento dos elementos de um BPMS em cada nível de evolução do
produto..............................................................................................................................62 Figura 4-1 - SCOR: Nível de Configuração .............................................................................69 Figura 4-2 – Detalhamento do SCOR Nível 3..........................................................................70 Figura 4-3 – Nível de Implementação do Modelo SCOR ........................................................71 Figura 4-4 Estrutura dos Elementos de Processo (RosettaNet)................................................73 Figura 4-5 – Diagrama Conceitual de Processo PIP 3A4.........................................................74 Figura 4-6 – Processo Públicos e Privados (PIP) .....................................................................75 Figura 4-7 Documentos de apoio para Identificação de Processos. .........................................76 Figura 4-8 - Detalhamento de Processo....................................................................................77 Figura 4-9 - Elaboração dos Processos.....................................................................................78 Figura 4-10 - Colaboração dos Processos.................................................................................79 Figura 4-11 - Diagrama de Atividades de Colaboração entre Processos .................................80 Figura 4-12 - Transação de Negócio ........................................................................................80 Figura 4-13 - Diagrama de Atividades de Transações de Negócio ..........................................81 Figura 4-14 - Esquema Genérico de Linguagens de Automação de Processos para Web
Services.............................................................................................................................82 Figura 4-15 Tcnologias de Automação de Processos...............................................................83 Figura 4-16 - Integração BPEL com Web Services .................................................................85 Figura 4-17 - Orquestração versus Coreografia de Serviços....................................................86
Figura 4-18 - Mapeamento de participantes BPEL – WSDL...................................................89 Figura 4-19 - Definição de Variáveis BPEL e WSDL .............................................................91
LISTA DE TABELAS
Tabela 3-1- Funcionalidades do BPMS ..............................................................................................51 Tabela 4-1 - Objetivos de um Modelo de Referência para Processos ......................................66 Tabela 4-2 - Elementos e Objetivos do Modelo de Referência................................................67 Tabela 4-3 - Conjuntos do Modelo RosettaNet ........................................................................73
LISTA DE ABREVIATURAS E SIGLAS ATM - Automatic Teller Machine B2B – Business to Business BAM – Business Activity Monitoring BPEL – Business Processo Execution Language BPM – Business Process Management BPMS – Business Process Management System CICS - Customer Information Control System COBOL - Common Business Oriented Language CORBA - Common Object Request Broker Architecture ERP – Enterprise Resource Planing HTTP - HyperText Transfer Protocol IMS - Information Management System J2EE – Java 2 Platform, Enterprise Edition JMS – Java Messaging System KPI – Key Performance Indicator MSMQ – Microsoft Message Queuing PL/I - Programming Language One SCOR – Suplly-Chain Operations Reference SGDB – Sistema de Gerenciamento de Banco de Dados SOA – Service Oriented Arquitecture SOAP - Simple Object Access Protocol TI – Tecnologia da Informação UDDI - Universal Description, Discovery, and Integration UDP - User Datagram Protocol UML – Unified Model Language WFMS – Workflow Management System WS – Web Service WS-I – Web Service Interoperability Organization WSDL – Web Servoce Description Language XML – Extensive Markup Language XSD – XML Schema Definition XSLT - Extensible Stylesheet Language Transformation
1 INTRODUÇÃO
1.1 Contextualização
O desenvolvimento de soluções integradas para grandes corporações sempre implicará
em desafios para todos os colaboradores envolvidos nas tarefas de análise e projeto de
arquitetura de sistemas. Em muitos casos, um destes desafios resume-se em um complicado
problema antagônico: ao mesmo tempo em que se procura reduzir os custos e maximizar a
utilização de sistemas legados, a estrutura de TI1 deve continuadamente oferecer melhores
serviços para os clientes, incrementando a competitividade e adequando-se às prioridades
estratégicas da empresa. Uma dicotomia que se estrutura então, em uma necessidade de
prover maiores facilidades aos consumidores frente à exigência de investir-se menos recursos
financeiros.
Dentro deste cenário, surgem duas características fundamentais que o mercado exige
de uma arquitetura de sistemas de grande porte : Heterogeneidade e Adaptabilidade.
Atualmente encontram-se, no cotidiano das maiores empresas, uma série de sistemas,
arquiteturas e aplicações, implantadas em diferentes épocas e desenvolvidas com tecnologias
diversas, definindo um ambiente heterogêneo.
Assim, a Heterogeneidade é definida por uma infra-estrutura de tecnologia da
informação que abriga sistemas concebidos em plataformas e linguagens de programação
distintas.
Contudo, adotar tecnologia de um único fornecedor, para o alcance de uma infra-
estrutura tecnológica homogênea, também não é uma abordagem recomendada, pois as suítes
de aplicativos e o suporte oferecido muitas vezes não são flexíveis o suficiente para adequar-
se ao modelo de negócio da organização. 1 Tecnologia da Informação
12
A Adaptabilidade torna-se uma característica necessária devido ao alto dinamismo do
mercado, imposto pela economia neoliberal. A globalização e a adoção do comércio
eletrônico estão, gradualmente, acelerando o ritmo das mudanças dos processos comerciais. O
mercado competitivo induz as empresas a reduzirem o ciclo de vida de seus produtos,
aumentando a diversidade das ofertas dos mesmos. Isto também acaba causando mudanças
rápidas das necessidades dos clientes, em relação aos produtos.
Como é inquestionável o impacto que mudanças inseridas nos processos comerciais,
produtivos e operacionais causam na estrutura de TI que os suportam, é imprescindível a
adoção de uma arquitetura de sistema altamente adaptável, que responda rapidamente a todas
estas mudanças, em curto ou longo prazo.
Neste contexto, a Arquitetura Orientada a Serviços (SOA1) vem ganhando destaque
como uma solução para transpor a dificuldade pertinente ao desenvolvimento e integração de
sistemas em ambientes tecnológicos heterogêneos e suscetíveis a mudanças.
Como muitas das abordagens reconhecidas como padrão, a SOA é um
desenvolvimento contínuo de um conjunto de práticas e técnicas, não possuindo um marco
temporal para sua criação, podendo também ser considerada como uma evolução da
Arquitetura de Componentes. Assim sendo, muitas soluções projetadas desde meados da
década de noventa já utilizam alguns conceitos básicos da SOA, mesmo assim, a mesma é
considerada uma tecnologia emergente, pois os esforços para a padronização da arquitetura
caracterizam-se em projetos recentes.
Na SOA, os serviços interagem entre si localmente ou remotamente, utilizando uma
abordagem de comunicação do tipo “passagem de mensagem” ou “orientada a documentos”.
Tal abordagem garante uma grande facilidade de manutenção da interoperabilidade entre os
serviços distribuídos.
O conjunto de serviços propostos pela SOA, aliado a padrões e técnicas destinadas a
elaboração coerente de um projeto de arquitetura, podem oferecer uma solução de projeto ágil
e adequado para a implementação de sistemas em ambientes heterogêneos.
Paralelamente aos conceitos de SOA, o termo Gestão de Processos de Negócios
(BPM1), comumente utilizado em publicações destinadas ao estudo da Ciência da
Administração, está sendo introduzido na indústria de Tecnologia da Informação.
1 Service Oriented Architecture
13
Enquanto “Gerenciar Processos” para os administradores está relacionado com a
análise, projeto e tomada de decisões referentes à manutenção dos processos organizacionais,
na indústria de software tal atividade se refere à automação e formalização dos processos,
bem como as regras de negócios associadas aos mesmos.
Retornando ao conceito evolutivo, o BPM primeiramente surgiu como uma melhoria
de projeto em arquiteturas de três camadas. Esta caracteriza-se por uma separação lógica ou
física dos componentes de apresentação, de negócios e de acesso a dados. Para Putte (2000,p.
4), o BPM foi concebido como o próximo passo em ambientes de três camadas, onde a idéia
principal foi extrair a lógica e as regras da camada de negócio e estruturá-las em uma
aplicação baseada em workflow, mostrando graficamente os vários passos inclusos nos
processos de negócio. Em cada nó de um workflow, as regras de negócio são utilizadas para a
definição do próximo nó, executando uma seqüência lógica do negócio.
Como conseqüência da implantação do BPM para automatizar os processos de
negócios, as regras de negócio tornam-se explícitas, mais visíveis e adaptáveis a mudanças,
sendo uma prática indicada para atender ao critério Adaptabilidade de um sistema distribuído.
Atualmente, existe um grande esforço de fornecedores de tecnologia para prover
componentes de middleware2 capazes de facilitar o desenvolvimento de aplicações utilizando
o BPM. Tais componentes são empacotados em aplicativos denominados BPM Systems e
oferecem serviços centralizados que implementam e gerenciam as chamadas de início e fim
do processo de negócio automatizado.
Em um desenvolvimento de um sistema BPM, os processos de negócios são
modelados graficamente e seus fluxos podem ser facilmente convertidos em uma linguagem
de automação de processos. Isto tende a agilizar desenvolvimento de um sistema, pois o
script3 de linguagem de automação executado no BPM System pode substituir a codificação
dos algoritmos de serviços de negócios em uma arquitetura SOA.
É fato que as distintas conceituações de BPM e SOA abordam diretamente as
vantagens da utilização das mesmas, mas devido ao caráter inovador em que se encontram
1 Business Process Management
2 Aplicativo que contem um conjunto de bibliotecas e componentes que dão suporte ao desenvolvimento
de sistemas distribuídos.
3 Procedimentos escritos em uma determinada linguagem que podem ser executados passo a passo por
um processo computacional.
14
em relação às demais soluções arquitetônicas de TI, não existe uma metodologia unificada
para o desenvolvimento de sistemas que os utilizem.
Cada fornecedor de TI atuante no novo mercado de produtos para BPM e SOA sugere
uma abordagem própria de desenvolvimento, além disto, os padrões e especificações técnicas
dos componentes das tecnologias são elaborados por consórcios distintos, dentre eles W3C1,
OASIS2 e BPMI3, e muitas vezes existem soluções técnicas diferentes para o mesmo caso, de
forma redundante.
Neste contexto, quaisquer projetos que queiram utilizar-se dos benefícios do BPM e da
SOA implicarão na problemática da escolha ou da elaboração de procedimentos, ferramentas
e técnicas que apóiem o desenvolvimento coerente do sistema.
Assim, o problema de pesquisa, pode ser definido da seguinte forma :
Quais os procedimentos, ferramentas e técnicas necessárias para suportar o projeto e
a implementação de um sistema distribuído altamente adaptável e interoperável, utilizando a
automação facilitada pelo BPM em uma arquitetura SOA ?
1 World Wide Web Consortium (Consórcio da Rede de Abrangência Mundial)
2 Organization for the Advancement of Structured Information Standards (Organização para a Evolução
de Padrões de Informações Estruturadas)
3 Business Process Management Initiative (Iniciativa para a Gestão de Processos de Negócios)
15
1.2 Justificativa
A relevância do projeto de pesquisa apresentado pode ser delineada analisando suas
possíveis contribuições técnicas e científicas, bem como a importância dada aos objetos de
pesquisa na mídia especializada.
No contexto da contribuição técnica, o problema de pesquisa proposto sugere o
levantamento de procedimentos, ferramentas e técnicas para projeto e implantação de BPM
em uma arquitetura SOA. Sendo assim, os dados levantados resultantes da necessidade desta
“busca” poderão consolidar um guia inicial para a adoção destas tecnologias em um ambiente
de produção. Profissionais de TI que assumem o papel de arquitetos poderão encontrar
informações para o auxílio de tomadas de decisões de projeto, escolha de produtos
disponibilizados no mercado e conhecimento das melhores práticas já adotadas em projetos
bem sucedidos.
Outra justificativa associada a este projeto de pesquisa é a própria relevância que
profissionais do meio científico e mercadológico de tecnologia da informação estão atribuindo
e atestando à SOA e ao BPM. Relevância comprovada por estudos e relatórios de renomados
institutos de pesquisa, como o Gartner Group, que apontam a SOA e o BPM como tecnologias
que proporcionarão um alto retorno de investimento, definindo-as como emergentes e de
utilização a longo prazo (FERGUSON, 2005).
Finalmente, é importante ressaltar a existência de poucas publicações nacionais sobre
o tema desta pesquisa. Portanto, qualquer projeto envolvendo SOA e BPM torna-se
importante para promover a diminuição da latência entre as publicações estrangeiras e a
produção científica brasileira.
16
1.3 Objetivos
1.3.1 Objetivo Geral
Demonstrar elementos e características pertinentes aos conceitos de SOA e BPM,
definindo um relacionamento entre os mesmos, enumerando e analisando os procedimentos,
ferramentas e técnicas atreladas ao desenvolvimento de um projeto que utiliza tais conceitos.
1.3.2 Objetivos Específicos
Os objetivos específicos definidos para este projeto são:
a) Estudar os elementos da SOA visando o entendimento do funcionamento macro e
global da tecnologia.
b) Apresentar as proposições teóricas relacionadas à tecnologia BPM, bem como os
seus componentes comuns e a interação entre os mesmos;
c) Apresentar os aspectos referentes às atividades envolvidas no projeto de sistemas
utilizando o BPM, em nível de processos e padrões de projetos;
d) Analisar o conceito de BPM System e algumas soluções oferecidas pelos
fornecedores da tecnologia;
e) Apresentar as opções de linguagens de automação de processos, bem como as
vantagens e desvantagens relacionadas à utilização das mesmas; e
f) Definir um processo de negócio fictício, para ser utilizado em uma implementação
de um aplicativo para teste da arquitetura.
17
1.4 Metodologia
Este projeto será composto por uma etapa de pesquisa bibliográfica, seguida por uma
implementação prática que servirá como prova de conceito. Com base nos resultados e
informações obtidos, será feita uma análise conclusiva que buscará as respostas do problema
de pesquisa.
Em relação à coleta de informações para a revisão bibliográfica, serão consultados
principalmente:
a) os livros e artigos publicados que abordem os conceitos de Arquitetura de Sistemas,
BPM , WebService e SOA;
b) as especificações de padrões tecnológicos dos elementos pertinentes a SOA, BPM e
Web Service; e
c) As publicações de fornecedores de soluções tecnológicas para os objetos de
pesquisa.
A implementação prática será constituída pela análise, especificação e construção de
uma pequena aplicação de demonstração utilizando SOA e BPM. Pretende-se na análise e
especificação da aplicação, utilizar as metodologias abordadas na revisão bibliográfica que
sejam específicas para o desenvolvimento de softwares arraigados nestes dois objetos de
pesquisa. Quando forem necessários outros métodos e documentos de especificação, não
inerentes aos temas principais da pesquisa, serão utilizados os elementos do processo
unificado (RUP) e os artefatos da UML.
A aplicação de demonstração será projetada e construída para operar em uma solução
de um fornecedor de produtos para BPM e utilizando a linguagem de automação de processos
escolhida como mais representativa no conceito de padrão de mercado.
1.5 Delimitações da Pesquisa
Em relação à pesquisa bibliográfica, os seguintes tópicos serão considerados de
pequena relevância neste projeto e, portanto, passíveis de não serem abordados:
a) Detalhamento dos elementos tecnológico de qualidade de serviço, como controle de
acesso, gerenciamento de segurança e política de utilização, controle de transação.
18
b) Detalhamento de protocolos de comunicações e de processamento remoto, como por
exemplo HTTP1, SOAP2, UDP3.
c) Tópicos relacionados a desempenho e performance de aplicações.
d) Tópicos relacionados a infra-estrutura tecnológica, como sistemas operacionais,
gerenciamento e topologia de redes e gerenciamento de banco de dados.
As delimitações de pesquisa bibliográfica também serão refletidas para a construção da
aplicação de demonstração. Assim, a mesma deverá ter poucas funcionalidades e atender a
uma pequena quantidade de processos simples. Para isto, será elaborado um problema fictício
para subsidiar a coleta dos requisitos funcionais necessários. Ressalta-se então, que os
processos modelados não terão validade no contexto de uma utilização produtiva em uma
organização real.
Neste mesmo sentido, questões de performance computacional, segurança,
performance de rede, transação e integridade dos dados serão ignoradas tanto em tempo de
análise e especificação quanto em tempo de análise conclusiva da aplicação.
Assim, o esforço deste projeto de pesquisa estará mais concentrado no estudo e na
análise de conceitos e proposições relativas às tecnologias SOA e BPM, do que na
implementação prática.
1 Hyper Text Transfer Protocol
2 Simple Object Access Protocol
3 User Datagram Protocol
19
2 ARQUITETURA ORIENTADA A SERVIÇOS (SOA)
Primordialmente, uma determinada tecnologia ou metodologia de implementação de
sistema distribuído era comumente definida apenas pelo conjunto de seus elementos
computacionais e pela forma de comunicação entre os mesmos. Porém, diante do cenário
atual, onde as decisões tomadas na área de TI estão ganhando uma grande importância no
planejamento estratégico das organizações, observa-se uma preocupação dos autores em
introduzir, na definição, considerações relacionadas - aos benefícios que tal tecnologia provê
e às diferentes formas e motivos para utilização da mesma.
Neste sentido, Erl (2004, p. 482), considera que : “A Arquitetura Orientada a Serviços
pode ser definida em diversas perspectivas : uma arquitetura técnica, uma abordagem de
modelagem de negócio, um recurso de integração e um novo meio de visualizar as unidades
de automação da empresa”.
Esta primeira conceituação, apesar de ser muito vaga, torna-se útil para reforçar que
ainda não existe uma definição única e formal para SOA. Percebe-se que uma definição de
SOA pode ser fundada somente em uma das “perspectivas” enumeradas por Erl, ou em todas
elas concomitantemente. Outro fator que justifica a existência de diversas linhas de definição
é o próprio estado inovador em que a SOA se apresenta no contexto atual.
Dentro deste contexto, buscar-se-á neste capítulo apresentar os conceitos de SOA de
forma a seguir uma única linha de definição, permeando entre textos de vários autores para o
alcance desta, ou seja, ao invés de mostrar as várias definições divergentes sobre um tema,
serão apresentadas somente aquelas que se adaptam melhor ao alcance do problema de
pesquisa proposto.
20
2.1 Serviços
Para um completo e fácil entendimento da SOA, primeiramente faz-se necessário
definir o termo serviço. Este pode ser visto sob duas perspectivas distintas, a de negócio e a de
arquitetura de sistemas.
Na perspectiva de negócio, as organizações oferecem vários tipos de serviços aos seus
stakeholders, dentre eles: consumidores, clientes, cidadãos, funcionários, fornecedores e
empresas parceiras. Como exemplo, Newcomer (2004) cita uma agência bancária que dispõe
de vários caixas para oferecer diferentes serviços, sendo alguns destes especializados para só
atenderem certos tipos de solicitação. Dentre os serviços oferecidos incluem-se : criação e
cancelamento de contas; empréstimos; retiradas, depósitos e transferências; serviços de
câmbio, seguros; entre outros. Muitos dos caixas oferecem paralelamente o mesmo tipo de
serviço, para otimizar o atendimento aos clientes, ao mesmo tempo em que um procedimento
complexo pode requerer que o cliente passe por diversos atendentes, conseqüentemente
implementando um fluxo de processo de negócio.
Por trás dos serviços oferecidos estão os sistemas de TI que automatizam os processos
que suportam os mesmos. Uma abordagem eficiente de definição de tais sistemas consiste em
alinhar os projetos de TI com as funcionalidades, serviços e os processos de negócio,
promovendo que a infraestrutura de TI suporte os objetivos da organização e adapte-se
facilmente para prover os mesmos serviços através de diferentes canais, como atendentes,
ATM´s e aplicações Web (NEWCOMER, 2004). Na Figura 2-1, apresenta-se um esquema de
acesso aos serviços bancários através dos sistemas de TI.
Figura 2-1 – Acessando e combinando serviços.
FONTE: NEWCOMER (2004)
21
Alinhando o conceito de serviço em uma perspectiva de negócio, Endrei (2004, p.28)
aponta que em uma Arquitetura Orientada a Serviços, cada serviço mapeia as funções de
negócio que são identificadas durante o processo de análise.
Tais serviços podem ser acessados de acordo com uma política definida pelo negócio,
determinando quem ou qual sistema está autorizado a utilizar o serviço, quando o serviço
estará disponível, o custo de utilização do serviço, o nível de disponibilidade do serviço, os
níveis de segurança e a performance, em termos de tempo de resposta (NEWCOMER 2004).
Em um primeiro momento, pode parecer que a determinação de tais políticas de
utilização dos serviços é algo pertinente a um nível técnico ou de implementação de sistemas.
Mas pensando no contexto em que foram definidas, torna-se claro que as políticas são
orientadas pelo negócio, podendo também ser aplicadas a serviços disponibilizados por
agentes humanos.
Em uma perspectiva de arquitetura de sistemas, (NEWCOMER 2004) define:
Um serviço da SOA consiste em um recurso de sistema que possui uma interface muito bem definida, separando claramente a interface externa e acessível do serviço de sua implementação técnica. Tal separação possibilita o desacoplamento entre o requerente e o provedor do serviço, assim, ambos podem evoluir independentemente desde que o contrato do serviço mantenha-se inalterado.
A interface do serviço possibilita que o mesmo possa ser publicado, localizado e
invocado. Pode-se optar por publicar os serviços externamente, para serem utilizados por
sistemas B2B, ou internamente, servindo como um elemento participante da estrutura de TI
utilizada dentro da organização.
Barry (2003), complementa ao observar que um serviço não depende do contexto ou
do estado que se encontra um outro serviço, fazendo uma analogia interessante a um sistema
de equipamentos de áudio e vídeo (Figura 2-2).
22
Figura 2-2 - Sistema de equipamentos de Áudio e Vídeo
Cada equipamento é autônomo e tem suas funções básicas definidas pela indústria. Um
usuário, por exemplo, não necessita de um vídeo cassete (VCR) para escutar um CD de áudio.
Assim, os componentes tornam-se independentes entre si. A televisão não precisa estar ligada
para o VCR gravar um programa. É claro que se o usuário der o comando para a leitura da fita
gravada com a televisão desligada, o mesmo não conseguirá assistir ao conteúdo que gravou,
mas mesmo assim , o VCR cumpre sua função enviando o sinal para a TV sem se preocupar
com o estado que a mesma se encontra.
Segundo (NEWCOMWER,2004) , em uma SOA o serviço deve possuir as seguintes
características chaves :
a) Fraco Acoplamento
O acoplamento do serviço pode ser distinguido em três categorias : acoplamento de
interface, acoplamento de tecnologia e acoplamento de processo.
O acoplamento de interface mede o nível de dependência que o provedor do serviço
impõe no serviço requerente. Quanto menor for a dependência, mais fraco será o
acoplamento. A interface deve encapsular todos os detalhes de implementação, tornando-o
irrelevante para o requerente.
O acoplamento de tecnologia define o quanto um serviço depende de uma tecnologia,
produto ou plataforma de desenvolvimento (sistema operacional, servidores de aplicação,
frameworks e middlewares). Os serviços estando intimamente acoplados a uma plataforma
específica limitam sua extensão, em termos de requerentes que o acessam e de
desenvolvimento por outras equipes (outsourcing). Estrategicamente, isto poderia ocasionar
uma dependência da organização a um único fornecedor de tecnologia proprietária. Assim, o
acoplamento de tecnologia define a interoperabilidade que o serviço irá oferecer.
23
O acoplamento de processo define o quanto um serviço está amarrado a um único
processo de negócio. Sempre quando possível, os serviços não devem ser específicos para um
problema de domínio único, assim, podem ser estendidos e utilizados por vários processos e
por várias aplicações distintas.
b) Contratos bem Definidos
Cada serviço deve ter uma interface bem definida, chamada de “contrato do serviço” ,
que define claramente as funcionalidades do serviço bem como a forma de invoca-lo , de uma
maneira interoperável e elegante. O contrato deve ser definido baseando-se no conhecimento
do domínio do negócio, assim, o mesmo não pode ser uma simples derivação da
implementação do serviço. Os contratos devem ser definidos e gerenciados como artefatos
independentes da implementação do serviço, pois a mudança do um contrato é bem mais
onerosa que a mudança da implementação, podendo causar novas mudanças em centenas de
serviços requerentes. Assim, torna-se importante a adoção de um mecanismo formal para
estender e controlar as versões dos contratos, de forma a gerenciar o custo e dependência da
mudança.
c) Significância para o serviço requerente
Os serviços e seus contratos devem ser definidos em um nível de abstração que faça
sentido para os serviços requerentes, capturando a essência do negócio da organização.
Assim, deve-se utilizar um vocabulário orientado ao negócio, definindo os documentos de
entrada e saída dos serviços. O contrato deve capturar um determinado tema do negócio
independentemente da implementação do serviço, o que facilita a substituição do serviço
provedor por um outro já existente, sem afetar os serviços requerentes.
d) Utilização de padrões abertos
Os serviços e seus elementos devem ser concebidos utilizando padrões abertos, ou
seja, tecnologias não proprietárias. A utilização de padrões abertos garante: independência de
fornecedores de tecnologia; maior oportunidade dos serviços requerentes de terem acesso a
serviços provedores alternativos; maior oportunidade dos serviços provedores oferecerem
funcionalidades a um maior número de serviços requerentes; oportunidade de tirar proveito de
implementações de código aberto e das comunidades de desenvolvedores que dão suporte a
estas implementações.
24
Tais características implicam em uma mudança drástica na concepção dos
componentes, onde a definição dos contratos dos serviços é dirigida pelo conteúdo e pela
forma das mensagens que os serviços trocam entre si. Conclui-se, então, que definir um
serviço torna-se diferente de definir um objeto distribuído. O serviço deve ser definido em um
nível mais alto de abstração, dando a possibilidade do mesmo ser mapeado a objetos
distribuídos (J2EE1, .NET2), rotinas de linguagens de procedimento (COBOL3, PL/I4) e
sistemas de serviços de mensagem (JMS5, MSMQ6).
2.2 Definindo a SOA
Tendo a definição de serviço, de uma forma genérica e dentro do contexto da SOA,
NEWCOMER (2004) define que uma Arquitetura Orientada a Serviços é um estilo de projeto
que guia todos os aspectos de criação e utilização dos serviços de negócio durante seu ciclo de
vida, definindo uma infraestrutura de TI que permite diferentes aplicações atuarem
conjuntamente, trocando informações e participando do processo do negócio. A SOA pode ser
vista como uma abordagem de projetar sistemas onde os serviços de negócio se tornam o
ponto focal para buscar o alinhamento dos sistemas com as necessidades da organização
(Figura 2-3).
1 Java 2 Enterprise Edition – plataforma para desenvolvimento de aplicações distribuídas da Sun.
2 Plataforma para desenvolvimento de aplicações distribuídas da Microsoft.
3 Common Business Oriented Language - linguagem utilizada para aplicações comerciais em sistemas
monolíticos.
4 Programming Language One – linguagem de programação para sistemas monolíticos
5 Java Message Service – serviço de gerenciamento de fila de mensagens da plataforma Java.
6 Microsoft Message Queuing - serviço de gerenciamento de fila de mensagens da plataforma Microsoft
25
Figura 2-3 - Alinhamento dos serviços SOA com os serviços oferecidos pela organização.
FONTE: (NEWCOMER; 2004, p.4)
Ao contrário disto, as abordagens antecessoras priorizam a especificação do ambiente
de implementação (como orientação a objetos, orientação a procedimentos, orientação a
mensagens) para solucionar os problemas de negócio, resultando em sistemas amarrados a
funcionalidades e funções de um ambiente de execução particular, como CICS1, IMS2,
CORBA3, J2EE, COM4, DCOM5, entre outros.
Nota-se que tal definição é elaborada em um nível muito mais próximo ao negócio da
organização, ao invés de um nível de arquitetura de sistemas. Assim, a SOA não pode ser
1 Customer Information Control System – sistema de processamento de transações desenvolvido para os
servidores monolíticos (mainframes) da IBM
2 Information Management System – junção de banco de dados hierárquico e sistema de gerenciamento
de dados com suporte a processamento de transações, desenvolvido pela IBM
3 Common Object Request Broker Architecture – padrão para componentes distribuídos de software,
mantido pelo Object Management Group (OMG)
4 Component Object Model – modelo de componentes de software da Microsoft.
5 Distribuited Component Object Model - modelo de componentes distribuídos de software da
Microsoft
26
considerada como somente mais uma arquitetura de sistemas, mas também e como uma nova
abordagem de estruturação e projetos de aplicações distribuídas .
A definição de SOA não implica em um vínculo de dependência da mesma em
elementos computacionais, como formas de publicação e localização das interfaces e padrões
de troca de mensagens entre os componentes distribuídos. Ao contrário disto, alguns autores,
como Erl (2004), sugerem uma forte dependência da SOA com a tecnologia Web Service, em
nível de conceituação. Apesar de ser uma definição difundida, não se trata de uma verdade
única.
Endrei (2004, p. 28), propõe que a SOA não é uma grande novidade, apontando que
várias implementações, que utilizam tecnologias como CORBA, DCOM e J2EE adotam
alguns conceitos da SOA com sucesso, muitas delas utilizando o serviço de Message Queue
para dar suporte a mensagens assíncronas e a integração com sistemas legados, conforma a
Figura 2-4. Porém cabe ressaltar que não se pretende atenuar a importância e o impacto que a
tecnologia Web Service trouxe para a SOA, mas sim que a mesma não é a única e exclusiva
solução técnica de implementação.
Figura 2-4 - Diferentes implementações da SOA
FONTE: ENDREI (2004, p. 28)
2.3 Evolução da Arquitetura de Sistemas
Desde os primeiros sistemas computacionais monolíticos, a industria de TI vem
ciclicamente apresentando novas soluções de arquiteturas. Impulsionada pelos desafios de
concepção de sistemas de grande porte, evidenciada pela crise do software, foram
desenvolvidas várias concepções para facilitar a implantação dos sistemas. Tal evolução
também teve como facilitadores a alta velocidade em que os componentes de hardware
evoluíram. O surgimento dos micro-pocessadores, cada vez mais potentes, e dos modernos
27
componentes de comunicação, favoreceram a implantação de redes de alto desempenho,
propondo uma estrutura distribuída e de crescimento horizontal.
Torna-se claro que para um bom aproveitamento deste novo ambiente computacional,
a forma de definição e de utilização dos componentes de softwares teve que evoluir
drasticamente, pois os antigos paradigmas monolíticos e estruturados não teriam suporte, ou
não teriam o desempenho desejado no ambiente computacionalmente distribuído.
Endrei (2004, p.19), define uma seqüência evolutiva das arquiteturas de software,
desde os primeiros sistemas monolíticos até a Arquitetura Orientada a Serviços (Figura 2-5).
Figura 2-5 - Evolução da Arquitetura de Sistemas. Fonte: ENDREI (2004, p.19)
Convém ressaltar que tal representação é meramente cronológica, pois apesar das
arquiteturas mais recentes serem mais complexas e terem um alto valor tecnológico agregado,
não se pode dizer que as mais antigas são substituíveis, umas pelas outras.
Tal fato é comprovado pela ampla utilização dos mainframes atualmente, juntamente
com linguagens de procedimento (COBOL, PL/I, Natural, etc..) e protocolos como CICS e
IMS.
Em sua primeira geração, os sistemas monolíticos concentram as regras de negócio, os
Bancos de Dados e as interfaces do usuário em uma única camada, disposta em um único
servidor centralizado de alto poder de processamento, sendo que as funcionalidades são
disponibilizadas aos usuários por vários terminais sem processadores “terminais burros”
(RICCIONI 2000, p.8).
28
Atualmente, a arquitetura monolítica agrega diversas evoluções, como protocolos que
permitem a troca de mensagens entre aplicações clientes e o mainframe (CICS, IMS), o que
possibilita sua integração com aplicações desenvolvidas sob sistemas distribuídos.
Muitas empresas, principalmente as financeiras, ainda optam em investir de forma
vertical nos mainframes, pois o altíssimo custo de substituição por sistemas distribuídos não
viabiliza tal troca. Embutidos neste custo, além dos equipamentos de hardware, estão o custo
de softwares, de treinamento e de adaptação da estrutura de TI e do processo de
desenvolvimento.
O que acontece normalmente nestas organizações, é uma evolução heterogênea da sua
estrutura de TI, onde os mainframes apresentam-se formando um núcleo central de
processamento e juntamente a eles, os sistemas distribuídos servem como apoio para
disseminação das aplicações dentro e fora da organização.
Com o advento do surgimento dos microcomputadores, oferecendo processamento
local a um baixo custo, deu-se o surgimento dos sistemas estruturados. Estes são definidos
como sistemas que agregam a interface com o usuário e o processamento das regras de
negócio em uma aplicação local. Tais aplicações, através de um serviço de rede, acessam um
Banco de Dados composto por arquivos remotos, sem a utilização de um SGBD (Sistema de
Gerenciamento de banco de Dados). São provenientes desta arquitetura os sistemas
desenvolvidos em Clipper, Dbase e Turbo Pascal.
A evolução da arquitetura estruturada para a arquitetura cliente / servidor foi
impulsionada pelo surgimento dos SGDB´s. Os clientes têm a funcionalidade de recuperar
dados do servidor, através de algum protocolo de recuperação que é transmitido ao SGDB. O
servidor, aceitando as conexões, retorna a resposta e os dados aos clientes. A execução da
regra de negócio pode ser atribuída á estação cliente, ao servidor, caso o SGDB suporte store
procedures1 ou para ambas as partes.
Segundo MENDES (2002, p. 110), “Este tipo de sistema é fácil de ser gerenciado
quando há uma pequena quantidade de usuários, e também quando o volume de transações é
baixo. Contudo este tipo de arquitetura não é apropriado em sistemas que tenham a
necessidade de suportar um elevado volume de transações ou que tenha um grande número de
usuários”.
1 Procedimentos embutidos no sistema de gerência de banco de dados
29
Para resolver os problemas encontrados na arquitetura cliente servidor, foi proposto
como solução uma arquitetura baseada em múltiplas camadas. Nesta, define-se uma camada
central que concentra a parte lógica específica da aplicação. A camada central assume o papel
de servidor de aplicação, sendo encarregada de fazer a mediação entre clientes e recursos
(MENDES 2002, p.111).
Assim, as camadas além de uma separação lógica podem possuir uma separação física,
ao passo que a interface do usuário, o servidor de aplicação e o servidor de banco de dados
são executados em máquinas distintas, com processamento separado. Esta abordagem permite
aos projetistas terem um maior controle no desempenho das aplicações, pois cada servidor,
que mantém uma das camadas, pode ser estendido através de clusters ou por balanço de carga.
Assim, cada camada pode demandar projetos distintos de crescimento horizontal.
Encontrar sistemas heterogêneos nas organizações torna-se um fato comum, sendo
possível encontrar todas formas de arquiteturas em um único ambiente de TI, e um dos
benefícios trazidos pela SOA é baseado neste contexto, pois a exposição dos componentes
legados como serviços de uma SOA acaba fortalecendo a reutilização eficiente dos mesmos.
Desta forma, é possível criar novas aplicações, altamente escaláveis e com crescimento
horizontal utilizando os sistemas legados existentes (Figura 2-6).
Figura 2-6 Crescimento Horizontal de Disponibilização de Aplicações
FONTE: Adaptado de NEWCOMER (2004, p.121)
30
2.4 Os Elementos da SOA
Do mesmo modo que existem várias linhas de definição para o conceito de SOA, o
mesmo acontece com a enumeração de seus elementos, onde os autores mostram diferentes
maneiras de detalhamento dos componentes técnicos da arquitetura.
Endrei (2004, p. 25-26), propõe uma classificação que atende muito bem aos objetivos
deste projeto, definindo que os elementos da SOA dividem-se em Elementos Funcionais e
Elementos de Qualidade de Serviços. Os Elementos Funcionais são derivados em:
a) Serviço de Comunicação de Protocolos: mecanismo utilizado pelos serviços
consumidores e provedores para estabelecer o que está sendo requisitado e o que
será retornado;
b) Serviço de Descrição: é um esquema padronizado que descreve o serviço, como
pode ser invocado e quais parâmetros precisam ser passados para o sucesso da
chamada ;
c) Serviços Funcionais ou Reutilizáveis: serviço funcional e disponível para uso. Provê
funcionalidades coesas e restritas para contemplar uma determinada parte do
negócio;
d) Serviços de Negócios: coleção de serviços executados em uma seqüência lógica
obedecendo a um conjunto de regras, para atender os requisitos de negócio. Um
processo de negócio pode ser composto por serviços de diversas granularidades; e
e) Serviço de Registro: repositório de descrição de serviços usado pelo provedor para
publicação dos mesmos e pelos consumidores para localizarem serviços disponíveis.
Os Elementos de Qualidade de Serviços formam uma infra-estrutura responsável pela
robustez , segurança e integridade de um Sistema Orientado a Serviços, são eles :
a) Serviços para Política de Utilização: definem um conjunto de condições ou regras
para a disponibilidade dos serviços aos consumidores.
b) Serviços de Segurança: conjunto de regras aplicadas para autenticar, autorizar e
controlar o acesso dos consumidores aos serviços.
c) Serviços de Transação: conjunto de atributos aplicado a um grupo de serviços
objetivando manter um resultado consistente.
31
d) Serviços de Gerenciamento: serviços de apoio destinado ao gerenciamento dos
serviços, consumidores e provedores.
A Figura 2-7 representa um esquema dos elementos que compõe uma Arquitetura
Orientada a Serviços, bem com a disponibilização dos elementos dentro das classificações
funcional de qualidade de serviço.
Figura 2-7 - Elementos da SOA. Fonte: ENDREI (2004,p.25)
Os serviços funcionais, juntamente com os serviços de negócio, são os responsáveis
em prover as funcionalidades para o atendimento aos requisitos levantado na etapa de análise.
Utilizando as facilidades oferecidas pelos servidores de aplicações mais modernos,
todos os outros elementos da arquitetura SOA podem ser criados e gerenciados de maneira
automatizada e transparente. Tal fato pode ser constatado pela tendência atual da computação
descritiva, onde os controles de transação, autenticação e autorização não precisam ser
codificados por linguagem de programação.A invés disto, criam-se arquivos descritores,
geralmente em XML, que definem o comportamento transacional e de segurança de uma
determinada classe, componente ou serviço.
Assim, em tempo de instalação, o servidor de aplicação captura os comportamentos
descritos e instanciam classes auxiliares que são invocadas pela máquina virtual ao perceber
que algum método ou procedimento da classe instalada está sendo requerido, e que este
necessita de algum controle de transação ou de segurança.
32
2.5 SOA e Web Services
A tecnologia Web Service é relativamente emergente e tem sido aceita como uma
implementação ideal para a SOA. Fruto de uma iniciativa para padronização de aplicações
distribuídas utilizando protocolos da Internet e linguagem XML. Inicialmente o padrão Web
Service tinha como objetivo substituir a abordagem EDI 1(troca eletrônica de dados),
propondo uma maneira mais eficiente de integrar informações entre organizações distintas.
Devido as suas características e o benefício de sua adoção, sua utilização foi estendida à
quaisquer sistemas heterogêneos que requerem uma solução interoperável, independente de
plataforma e protocolo, objetivando a integração de seus componentes.
Através de AUSTIN (2002), a W3C define Web Services como :
Um Web Service consiste em uma aplicação identificada por um URI, cujas interfaces e conexões são capazes de serem definidas, descritas e descobertas por artefatos XML, suportando interação direta com outras aplicações utilizando mensagens baseadas em XML através de protocolos utilizados pela internet.
As especificações Web Services são completamente independentes de linguagem de
programação, sistema operacional e hardware, e têm como base tecnologias abertas como :
a) Extensible Markup Language (XML);
b) Simple Object Acess Protocol (SOAP);
c) Web Services Description Language (WSDL); e
d) Universal Description, Discovery an Integration (UDDI);
A linguagem XML é a sintaxe padrão utilizada para a troca de mensagens entre Web
Services provedores e consumidores, possibilitando a representação de dados em um formato
padronizado e estruturado. Os dados são categorizados por tags2, que funcionam como meta-
dados que indicam o significado dos valores dispostos no documento.
A estrutura do documento XML pode ser validada através de um outro arquivo (DTD)
que contêm as regras de formação, ou seja, contêm as tags que podem ser utlizadas no
documento e a estrutura hierárquica de disposição destas tags. Apesar de ampla utilização, o
padrão DTD além de possuir limitações de validação de tipos de dados, como datas e
1 Electronic Data Interchange
2 Marcador que qualifica a informação
33
números, é de difícil manipulação por programação. Assim, a W3C definiu um novo formato
para definir a estrutura do documento XML, chamado XML Schema. Trata-se de um
documento onde as regras de formação são definidas também por tags XML padronizadas,
que possui mais recursos que o DTD, como forte tipificação de elementos e atributos e
mecanismos de validação de relacionamentos, análogos ao mecanismo de controle de chaves
estrangeiras implementado pelo SGDB (ENDREI 2004, p.121).
Outra facilidade que o padrão XML provê consiste em recursos para o tratamento e
transformação dos dados. O XSLT define uma linguagem para transformar dados XML em
outros documentos de quaisquer formatos, inclusive XML. Para acessar as partes do arquivo
XML em transformação, o XSLT utiliza uma sintaxe de busca denominada XPath.
O Simple Object Access Protocol (SOAP) é um protocolo de rede, de transporte e de
linguagem natural de programação que possibilita que um Web Service consumidor invoque
operações remotas em um Web Service provedor. O SOAP provê um framework para
descrever o conteúdo das mensagens, as instruções de processo e um conjunto de regras para
representação de definições de tipos de dados, onde suas mensagens são codificadas em
XML. Por ser um independente do protocolo de transporte torna-se independente de sistema
operacional e totalmente desacoplado a qualquer linguagem de programação ou tecnologia,
sendo comum ser transportado pelos protocolos HTTP, JMS e UDP .
Como desvantagens, o SOAP não suporta passagens de parâmetro por referência e
possui um desempenho relativamente menor aos outros protocolos de acesso remoto a
componentes, devido ao overhead gerado pelo formato XML das mensagens.
Existem diferentes maneiras de codificar as mensagens no protocolo SOAP :
a) SOAP Remote Procedure Call (RPC encoding)
b) SOAP Remote Procedure Call (SOA RPC-literal), que utiliza métodos definidos
pelo usuário para serializar e deserializar os dados XML.
c) SOAP Document Style Encoding, conhecido como codificação estilo mensagem, ou
estilo documento.
O serviço de descrição de um Web Serviçe é denominado WSDL, consistindo em um
documento XML que oferece um padrão para descrever as operações e mensagens de maneira
abstrata. Basicamente, o WSDL especifica as características operacionais do Web Service,
34
definindo do que se trata o serviço, onde ele reside e como o mesmo pode ser invocado, ou
seja, o WSDL provê a definição da interface externa do Web Service (ENDREI 2004, p.123).
Um Web Service pode ser considerado com um conjunto de pontos de acesso,
operando em mensagens orientada a documentos ou orientada a procedimentos (RPC).
Através do WSDL, as operações e as mensagens de troca são descritas de maneira abstrata
através da Definição de Interface de Serviço. Estas descrições são vinculadas a um protocolo
específico de comunicação e de formatação de mensagem, através da Definição de
Implementação do Serviço ENDREI (2004, p.124). O esquema de um WSDL pode ser
representado pela Figura 2-8.
Figura 2-8 - Componentes de uma descrição de serviço usando WSDL FONTE: ENDREI (2004, p.124)
A separação da definição de implementação da definição da interface pode ser
considerada como o maior diferencial do WSDL, pois tal divisão permite que uma seja
completamente independente da outra. A definição dos métodos, procedimentos e seus
parâmetros são definidos de forma independente do protocolo de rede e de transporte,
garantindo a alta interoperabilidade de um sistema desenvolvido na plataforma Web Service.
Embora o WSDL seja uma excelente solução para publicar as interfaces dos serviços,
este não provê algumas informações úteis para o consumidor do serviço, como: quem é o
provedor do serviço, qual tipo de negocio é atendido pelo serviço ou qual a expectativa de
qualidade do serviço.
Desta maneira, o padrão UDDI1 foi estabelecido pelo grupo OASIS com a intenção de
ser um intermediador das informações necessárias para o provedor e para o consumidor dos
1 Universal Description, Discovery, and Integration
35
serviços, especificando um padrão para armazenar e recuperar informações a respeito dos
mesmos.
Segundo Endrei (2004, p.141), estruturalmente o UDDI é composto pelas entidades de
negócios - businessEntity, pelos serviços de negócios - businessService, pelo modelo de
conexão - bindingTemplate e pelo modelo técnico - tModel. Tais elementos fazem um
mapeamento das interfaces dos serviços, possibilitando que um consumidor tenha acesso aos
mesmos de forma centralizada (Figura 2-9).
Figura 2-9 - Estrutura UDDI FONTE: ENDREI (2007, p. 142)
Pela sua alta interoperabilidade, a plataforma Web Service atualmente é a mais
adequada para a implementação de uma arquitetura SOA, tanto é sua importância que alguns
autores, como Erl (2004), definem a própria SOA de uma maneira intimamente relacionada a
esta plataforma.
Assim elemento da arquitetura SOA pode ser perfeitamente especificado e
implementado em um componente da plataforma Web Service, garantindo assim uma
estrutura robusta e altamente interoperável para as aplicações da organização.
A Figura 2-1 apresenta os elementos da SOA a sua relação com os componentes
tecnológicos da plataforma Web Services.
36
Figura 2-10 - Composição da SOA com a plataforma Web Service FONTE: ENDREI (2004, p.108)
Conclui-se neste capítulo, que a Arquitetura Orientada a Serviços oferece uma grande
possibilidade de estruturação de sistemas de informações que utilizem o conceito de serviços
como foco direcionador de projeto. A alta interoperabilidade da arquitetura, provida pela
adoção tecnológica da plataforma Web Service, já justifica sua utilização, promovendo a
construção de aplicações onde a integração em nível computacional e de negócio podem ser
facilmente conquistadas.
Finda a apresentação de alguns dos conceitos referentes à Arquitetura Orientada a
Serviços, o próximo capitulo será destinado a abordagem das proposições conceituais, das
metodologias, dos métodos e ferramentas relacionadas ao Gerenciamento de Processo de
Negócios.
37
3 A GESTÃO DE PROCESSO DE NEGÓCIOS - BPM1
3.1 Processos de Negócios
Segundo Newcomer (2004), um processo de negócio consiste em um conjunto de
atividades logicamente relacionadas, que ao serem executadas em uma determinada seqüência
e de acordo com as regras do negócio, produz um determinado resultado.
Para Davenport (1994), o processo é um conjunto de atividades estruturadas e
definidas para produzir uma saída específica para um cliente ou mercado em particular. Tais
atividades inter-relacionadas que cruzam fronteiras entre as áreas funcionais com entradas e
saídas próprias. Ao processo, podem ser designadas dimensões de performance que podem ser
medidas e melhoradas, como custo, qualidade e tempo.
Tais resultados podem diretamente oferecer valor a qualquer stakeholder2 da
organização ou podem contribuir para a otimização dos procedimentos organizacionais da
empresa.
Como o fluxo entre o início e o fim do processo de negócio raramente dispensa
condições de caminhos duais, torna-se necessário uma definição prévia dos conjuntos de
condições que determinam o caminho a ser percorrido dentro das possibilidades de cada
fluxo. Assim, cada conjunto de condições utilizado como parâmetro para uma tomada de
decisão, relacionada a qual caminho percorrer dentro das possibilidades que o fluxo provê, é
denominado Regras de Negócio.
As atividades que compõe um processo de negócio podem ser executadas em série ou
em paralelo uma com as outras. Em um processo produtivo por exemplo, é muito comum que
1 Business Process Management
2 Entidade física, econômica ou humana que pode ser atingidos pelos atos e fatos administrativos de
uma organização.
38
as atividades de controle e monitoração sejam definidas de forma paralela, não interferindo na
execução das atividades de produção.
Um processo de negócio definido, pode ser um componente de um outro maior.
Conseqüentemente a isto, a representação de todos os processos existentes em uma
organização em um único modelo mostrará um relacionamento hierárquico e complexo, entre
os processos de nível mais alto até os processos de granularidade mais fina.
Na Figura 3-1, destaca-se um processo principal no centro do diagrama, composto por
uma cadeia de vários sub-processos de granuralidade mais fina, em uma formação hierárquica
de alta complexidade.
Figura 3-1 - Composição de Processos
FONTE: http://www.bpm3.com/picalculus
Em muitas organizações, esta interdependência entre os processos e sub-processos
passa desapercebida, ora por falta de documentação, ora por falta de conhecimento dos
processos existentes. Assim, as mudanças nos processos não podem ser gerenciadas de
maneira concisa e eficiente.
Apesar dos processos de negócio serem definidos de maneira muito distinta nas
diferentes organizações, SMITH (2002, p.4) identifica características comuns aplicadas aos
mesmos, citando que um processo de negócio geralmente é :
a) Longo e complexo, envolvendo o fluxo de materiais, informações e compromissos
de negócios;
b) Dinâmico, respondendo a demanda das necessidades dos clientes e às mudanças das
condições de mercado;
39
c) Extensamente distribuído e customizado pelos limites internos e externos da
organização;
d) Longo em sua duração – uma simples instância de um processo pode durar dias,
meses ou até anos;
e) Passível de automação – a maioria dos processos, no todo ou em sua parte podem
ser suportados por sistemas computacionais, objetivando o ganho de velocidade e
confiabilidade;
f) Difícil de ser identificado – nem todas as empresas possuem processos explícitos de
forma consciente aos seus colaboradores. Muitas possuem processos não
documentados e implícitos, mergulhados na rotina e na cultura organizacional da
empresa.
Ao supor que um processo pode ser automatizado, não significa que o mesmo será
executado plenamente por um sistema computacional, desde o início até seu fim. Tal
automação implica que sistemas computacionais podem prover funcionalidades para agilizar,
organizar e gerenciar a execução do processo, mesmo que este tenha vários pontos de
intervenção humana.
3.2 Gerenciando Processos
Gerenciar processos organizacionais obviamente não se trata de uma panacéia. Durante
todo o século XX foram elaborados inúmeros conceitos, técnicas e metodologias para a
manutenção e melhoria dos processos produtivos, sempre vinculados as drásticas mudanças
ocorridas no comportamento mercadológico e nas inovações tecnológicas de produção e
industrialização.
Entender a evolução destes conceitos é uma tarefa árdua e digna de muitos estudos
para especialistas em Ciências Administrativas, todavia, mesmo não sendo abordado como
um objetivo deste projeto de pesquisa, a citação de alguns conceitos, tidos como “divisores de
águas”, torna-se importante para entender o surgimento do BPM.
A teoria gerencial de Fredrick Taylor pode ser considerada como o primeiro marco na
ciência do gerenciamento de processos. Datada de 1920, esta sugeria que os processos
estariam implícitos nas práticas executadas no trabalho e poderiam ser padronizados por
40
manuais de regras e políticas que definiam a forma de execução das atividades. Assim, a
gerência de processos abordada por Taylor tornou-se conhecida como Análise de Métodos e
Procedimentos.
Outro marco importante na evolução de gerência de processos foi a concepção da
teoria da Reengenharia. Proposta no início da década de 90 pelos cientistas James Champy e
Micheal Hammer na obra “Reengineering the Corporation”, a reengenharia sugere uma
mudança radical dos processos de negócio contidos na organização, ou seja, redefini-los e
redesenha-los praticamente da estaca zero, buscando-se assim uma melhoria nos aspectos de
custo operacional, qualidade de serviço e tempo.
Os processos são re-engenhados através de uma única atividade manual e pontual. Tais
mudanças foram implementadas e amarradas rigidamente em sistemas de softwares não muito
flexíveis, tais como o sistema ERP1, designado como tecnologia de TI emergente no início da
década passada (SMITH,H; FINGAR,P. 2003, p.1) .
A reengenharia tornou-se um procedimento importante na adaptação das organizações
frente às mudanças na economia mundial na década passada. Entre elas, destacou-se um
crescimento, sem precedentes, de ofertas de produtos e serviços. Conseqüentemente a isto,
houve uma inversão do comportamento do mercado. O mercado que antes era controlado pela
produção - impulsionado pela oferta, passou a ser controlado pelas regras de consumo -
puxado pela demanda (SMITH,H.; FINGAR,P 2003).
Neste contexto, a reengenharia torna-se o paradigma que permitiu uma evolução do
pensamento relativo aos processos, resultando na concepção do BPM. Ao adotar a
reengenharia, a organizações começaram a posicionar os processos de negócios no centro de
suas estratégias, estendendo e gerenciando os mesmos por toda a cadeia produtiva e
administrativa da organização.
Smith, H. e Fingar, P. (2003, p.1), consideram o BPM como a terceira onda do
gerenciamento de processos, permitindo as organizações criarem e aperfeiçoarem os mesmos
de uma forma ininterrupta e contínua , elegendo a suscetibilidade ás mudanças como principal
objetivo de projeto dos processos, fazendo com que os mesmos possam ser monitorados e
melhorados continuadamente por toda a cadeia de valor da empresa.
1 Enterprise Resource Planning
41
Uma importante característica do BPM é que o mesmo é fundado intimamente com
inovações dos sistemas de informações, assim sendo, o BPM provê uma arquitetura de
sistemas. Como os objetivos desta pesquisa estão vinculados as questões relativas a TI, na
continuidade deste trabalho o BPM será tratado simplesmente como uma arquitetura de
sistemas, e não como um conjunto de princípios e técnicas administrativas.
Smith (2002, p.4) sugere a seguinte definição para BPM :
BPM é a capacidade de localizar, projetar, disponibilizar, executar, interagir, operar, otimizar e analisar processos fim a fim, em um nível de mapeamento do negócio, e não em um nível de implementação técnica. O BPM se preocupa tanto com a conclusão confiável de transações de negócios pontuais, quanto com a execução de seqüências complexas, que podem durar semanas, meses ou anos.
Tal definição não se torna completa sem a explicitação das disciplinas que constituem
o BPM, assim, Smith (2002, p.4) propõe os seguintes conceitos para tais disciplinas :
a) Localização – significa tornar explícito os processos de negócios da organização. Os
processos devem ser capturados e catalogados dentro das perspectivas dos seus
participantes, incluindo: colaboradores, organizações externas e os sistemas
computacionais que dão suporte a execução.
b) Projeto – significa modelar, simular, desenhar e redesenhar os processos. Tais
atividades devem ser exercidas em um ambiente computacional que represente os
processos graficamente, permitindo que o analista de negócios reestruture os
processos de maneira ágil, em resposta a pressões competitivas ou novas
oportunidades de negócios. O modelo deve suportar a composição e decomposição
dos processos, bem como a reutilização, generalização e especialização dos
elementos componentes dos processos.
c) Disponibilização – os novos processos devem ser disponibilizados para todos os
participantes, incluindo pessoas, aplicações e outros processos, de uma forma que as
mudanças de versões sejam realizadas com pouca, ou nenhuma atividade de
programação. Na disponibilização, o processo deve ser mapeado automaticamente
para interfaces públicas e padronizadas, para dentro ou fora da organização, caso
esta seja a necessidade.
d) Execução – garante que o processo será executado ponto a ponto, abrangendo todos
os participantes. A execução deve gerenciar transações que utilizam tanto as novas
42
aplicações, projetadas especialmente para a arquitetura BPM, quanto os sistemas
legados da organização. O estado da execução deve ser protegido da estrutura
tecnológica heterogênea e do comportamento das aplicações. Se possível, o
ambiente de execução deve ser desacoplado das camadas de “middleware”,
garantindo assim que o processo distribuído poderá ser executado por aplicações e
componentes de divergentes tecnologias.
e) Interação – possibilita os usuários manipularem as interfaces entre os processos que
necessitam intervenção humana e os processos automatizados. Um sistema
implementado na arquitetura BPM deve prover facilidades para interação, como
uma entrada de dados de forma ágil e confiável e um acompanhamento de quais
passos de um processo estão alocados para um determinado usuário. Outra
possibilidade reside na geração automática de formulários para entrada de dados nos
processos.
f) Operação e manutenção – prove funcionalidades para: tratamento de exceções, troca
de visibilidade de um processo interno para ser utilizado por outras organizações,
atualização de um processo, gerenciamento do acesso dos participantes de um
processo e re-alocação dos passos de um processo. Tais funcionalidades devem ser
executadas sem a interrupção do sistema.
g) Otimização – significa o aperfeiçoamento dos processos. Um sistema BPM deve
detectar automaticamente os gargalos, deadlocks e outras inconsistências nos
processos através de toda a organização.
h) Análise – mede a performance dos processos dando suporte a estratégias de
melhoria nos mesmos. A análise prove uma visão ampla do tempo dos recursos
consumidos pelos processos de negócio.
43
Figura 3-2 - Disciplinas do BPM
FONTE: , SMITH (2002, p.5)
Uma das grandes vantagens do BPM reside nas disciplinas relacionadas à automação
dos processos de negócio (Figura 3-2).
Tal automação pode ser definida como a conversão da maneira de execução das
atividades da organização, passando de uma forma de execução manual, ou parcialmente
assistida por sistemas computacionais, para uma forma totalmente automatizada, através de
um sistema centralizado encarregado de executar e gerenciar os processos em toda a extensão
da empresa (NEWCOMER 2004, p.113).
As disciplinas de automação podem ser consideradas como o cerne funcional de um
sistema BPM. Através de uma máquina de execução, os processos são requeridos e
executados passo a passo, permeando todas as atividades definidas nos mesmos.
De certa maneira, todos os sistemas de TI suportam e implementam os processos de
negócios da organização, não importando a arquitetura de sistema utilizada no seu
desenvolvimento. Mas o que torna o BPM uma arquitetura única é a existência de uma
separação explícita da lógica dos processos de negócio dos demais procedimentos de sistema
(Figura 3-3), o que gera um contraste com as formas usuais de desenvolvimento, onde a
lógica dos processos está embaralhada e embutida nos códigos fontes das aplicações
(NEWCOMER 2004, p. 113).
44
Figura 3-3 - Separação da Lógica dos Processos de Negócio.
FONTE: SMITH (2004, p.49)
Tal separação permite uma adaptabilidade às mudanças sem precedentes.
Conservando-se os parâmetros de entrada e saída de um processo, a sua lógica de execução
pode ser alterada ou até mesmo decomposta em vários sub-processos, de forma transparente
aos requerentes do mesmo, sem interrupções na disponibilidade do sistema. É possível manter
duas versões distintas do mesmo processo, permitindo o teste individual dos novos processos
no ambiente de produção. Assim, ao invés de configurar dois servidores, um de produção e
outro de testes, pode-se utilizar um único servidor com processos em produção e processos
em testes, definindo políticas diferenciadas para o acesso aos mesmos.
Outro benefício provido pelo BPM é a redução de inconformidades entre o
levantamento de requisitos e as funcionalidades implantadas no sistema, pois os processos
podem ser modelados por usuários e analistas de negócios, em um altíssimo nível de
abstração tecnológica, deixando o departamento de TI apenas com a responsabilidade de
prover a infraestrutura para executar e controlar os processos (NEWCOMER 2004, p.113).
3.3 Evolução dos Sistemas de Informação frente à adequação dos Processos de Negócios
Até o início da década de noventa, os processos de negócios eram suportados por
sistemas desenvolvidos na arquitetura monolítica ou estruturada. Apesar de serem altamente
confiáveis, tais sistemas eram demasiadamente inflexíveis. Neles, os processos de negócios
eram codificados juntamente com rotinas de sistema, e muitas vezes, um mesmo processo era
suportado por diferentes aplicações, não tornando possível um fluxo eficiente dos dados.
45
Em alguns casos, dados de saída de uma aplicação tinham que ser re-digitados como
entrada de uma segunda aplicação. Mesmo quando existiam formas automatizadas de troca de
informações entre as aplicações, estas não eram eficientes e nem confiáveis. Por estas
características, tais sistemas não forneciam informações gerenciais com qualidade suficiente
para tomada de decisões.
Assim, uma organização que possuía centenas de aplicações legadas não poderia
facilmente alterar os seus processos de negócios, pois os processos não poderiam ser
desacoplados da lógica computacional das aplicações legadas que o suportavam (SMITH
2002, p.4).
Cronologicamente, o ERP surgiu como proposta para superar as deficiências dos
sistemas legados, trazendo uma arquitetura um pouco mais flexível, dando suporte a vários
processos organizacionais.
O ERP consiste em um conjunto de pacotes, estes constituídos por aplicações
designadas a suportar as funções essenciais da organização, como: Vendas, Produção,
Finanças, Recursos Humanos, Manutenção, Logística, Almoxarifado, entre outras.
Por utilizar uma mesma base de dados para todas as aplicações, o ERP torna-se mais
muito mais flexível e ágil do que os sistemas legados, suportando processos complexos e
inter-relacionados entre as diversas funções da organização (SMITH 2002, p.4).
Figura 3-4 – Processos em Sistemas Legados. FONTE: SCHMITT,C.A p.5
Figura 3-5 - Processos no ERP. FONTE: SCHMITT,C.A p.6
Assim, uma implantação de um sistema ERP consegue oferecer informações de forma
instantânea, dando suporte às tomadas de decisões gerenciais, permitindo que as informações
sejam introduzidas em uma única vez e que estejam disponíveis para todos os colaboradores
em tempo real (SCHMITT, p.13).
Apesar de prover uma excelente flexibilidade para retirada de informações gerenciais,
geralmente os sistemas ERP são instalados em um único processo, no qual o mesmo é
configurado ou customizado para adequar-se aos processos de diferentes organizações, sendo
46
que a customização tem como conseqüência a reprogramação de componentes das aplicações,
gerando um custo adicional imposto pelo fornecedor da solução.
Assim, o ERP apresenta uma falsa flexibilidade, pois alterar a configuração ou sugerir
novas inovações após a fase de implantação acarreta um alto fator de risco, tornando o ERP
pouco adaptável às mudanças nos processos de negócios. Todavia, o princípio de implantação
do ERP casa-se de certa forma com o conceito de Reengenharia, pois em muitos casos,
organizações substituíram todos seus sistemas legados pelos pacotes ERP, em um único e
longo processo de avaliação de soluções, configuração e implantação.
Outra característica negativa dos sistemas ERP é a dificuldade de sua integração com
outros sistemas, como os legados e os sistemas distribuídos modernos. Tal característica
torna-se um fator limitante à disponibilização e ao consumo de serviços de forma externa, o
que promoveria a integração entre a organização e às suas empresas parceiras. Atualmente, tal
integração externa é uma estratégia muito comum e que vêm dando bons resultados para as
Recommended