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