BPM vs. SOA

BPM X SOA (BUSINESS PROCESS MANAGEMENT X SERVICE ORIENTED
ARCHITECTURE – GERENCIAMENTO DO PROCESSO DE NEGÓCIO X
ARQUITETURA ORIENTADA A SERVIÇO)
Grupo: GADSR
(GRUPO DE ANÁLISE E DESENVOLVIMENTO DE SOFTWARE REUTILIZÁVEL)
DÁVISSON HÚDSON CHAVES BERNADETE (6º - SI)
JOÃO LUIZ MARQUES GUIMARÃES (5º - SI)
THAÍS COSTA DE MESQUITA (5º - SI)
PROJETO SEMESTRAL SUBMETIDO AO CORPO DOCENTE DA FACULDADE
PROFESSOR MIGUEL ÂNGELO DA SILVA SANTOS (FeMASS) COMO PARTE DA
SISTEMÁTICA DE AVALIAÇÃO POR PROJETOS (SAP).
Banca Examinadora:
_______________________________________________
_______________________________________________
MACAÉ, RJ – BRASIL.
JUNHO DE 2010

RESUMO
Muito tem se discutido sobre os processos nas empresas atualmente. Os processos de negócio
de uma empresa hoje devem integrar pessoas, tecnologias e processos. A gerência deve estar
alinhada com o pessoal de TI, para assim conseguir que todas as expectativas de um sistema
atendam ao processo de negócio. Por isso é apresentado aqui o conceito de BPM (Business
Process Management) com o intuito de ajudar a área de negócios principalmente na
modelagem e criação de processos para que realmente se adequem à realidade do negócio. E
ainda apresenta-se a Arquitetura Orientada a Serviços (SOA) para o oferecimento de serviços
providos pelos processos de negócio, tornando mais claro o relacionamento entre as camadas
de negócio de uma empresa. Para melhor interligação SOA deve utilizar-se ainda de Web
Services e barramentos corporativos de serviço (ESB) propiciando ganho na união de BPM
com SOA.
Palavras-Chaves: BPM.SOA, Processos de Negócio, Serviços, Web Service.

LISTA DE FIGURAS
Figura 1. Ciclo de Vida do Serviço (SANTOS, 2007). .............................................................12
Figura 2. Funcionamento básico de um Web Service (fonte:
http://imasters.uol.com.br/artigo/4245/webservices/entendendo_os_webservices) ................13
Figura 3. Arquitetura de um Web Service (retirado de:
http://imasters.uol.com.br/artigo/4245/webservices/entendendo_os_webservices ) ...............14
Figura 4. Representação das tecnologias utilizadas em um Web Service (retirado de :
http://pt.wikipedia.org/wiki/Web_service)................................................................................14
Figura 5. Exemplo de funcionamento de um Web Service (CAPELARI, 2004).......................15
Figura 6 Exemplo de SOAP (FARO & FERRAZ, 2004). .........................................................17
Figura 7. Estrutura de uma mensagem SOAP (CUNHA, 2002)..............................................18
Figura 8. Exemplo de WDSL (FARO & FERRAZ, 2004) ........................................................18
Figura 9. Exemplo de funcionamento de um UDDI (in FARO & FERRAZ, 2004) .................20
Figura 10. Fluxo de dados da modelagem de negócios (RSC, 2001) ......................................21
Figura 11. Processo de Negócio (WIKIPEDIA, 2009) ............................................................23
Figura 12. Ciclo de vida BPM (N&S, 2010)............................................................................26
Figura 13. Exemplos de tipos de negócio (adaptado de SANTOS, 2007)................................28
Figura 14. Representação de subprocessos fechado e aberto (SANTOS, 2009) .....................29
Figura 15. Exemplo de Lane (SANTOS, 2009) ........................................................................31
Figura 16. Segmento de processo com artefatos (SANTOS, 2009)..........................................32
Figura 17. Alguns Tipos de BPMS (retirado de PAIM, 2007).................................................34
Figura 18. Elementos de um BPEL (NADER, 2007)................................................................36
Figura 19. Exemplo agência de viagens (NADER, 2007)........................................................37
Figura 20. Exemplo de Processo BPEL (NADER, 2007).........................................................37
Figura 21. Componentes da SOA (SANTOS, 2007).................................................................41
Figura 22. Processo de desenvolvimento de software atual (Digital Assets - 2007)...............42
Figura 23. O Paradigma Find-Bing-Execute (ROCHA, 2006)................................................43
Figura 24. Dinâmica de funcionamento SOA (Digital Assets - 2007).....................................45
Figura 25. Fases de adoção SOA (Adaptado de DIGITAL ASSETS, 2007) ............................46
Figura 26. Representação de um ESB (DIGITAL ASSETS, 2007)...........................................47
Figura 27. Representação de seleção dinâmica ESB (DIGITAL ASSETS, 2007)....................48
Figura 28. Relação BPM x SOA (ROSEN, 2006).....................................................................50

LISTA DE TABELAS
Tabela 1 - Objetos de Fluxo – Simbologia base.......................................................................29
Tabela 2 - Objetos de Conexão – Simbologia base..................................................................30
Tabela 3 - Swimlanes – Simbologia. ........................................................................................30
Tabela 4 - Artefatos Simbologia...............................................................................................31
Tabela 5 – Comparação entre orientação a serviços e orientação a objetos..........................40

LISTA DE SIGLAS
AD Análise de Domínio
API Application Programming Interface
BI Business Intelligence
BP Business Process
BAM Business Activity Monitoring
BPD Business Process Diagram
BPEL Business Process Execution Language
BPM Business Process Management
BPMI Business Process Management Institute
BPML Business Process Management Language
BPMN Business Process Modeling Notation
BPMS Business Process Management System
CEO Chief Executive Officer
CIO Chief Information Officer
EAI Enterprise Application Integration
ED Engenharia de Domínio
ERP Enterprise Resource Planning
ESB Enterprise Service Bus
HTML Hyper Text Markup Language
OMG Object Management Group
OOP Oriented Object Programming
PDCA Plan, Do, Check and Action
PMC Process Management Center
RPC Remote Procedure Calls
SI Sistemas de Informação
SOA Service Oriented Architecture
SOAP Simple Object Access Protocol
TI Tecnologia da Informação
UDDI Universal Discovery Description Language
UML Unified Modeling Language
W3C World Wide Web Consortium
WS Web Service
WSDL Web Service Definition Language
WWW World Wide Web
XML Extensible Markup Language

SUMÁRIO
LISTA DE FIGURAS ........................................................................................................................................ III
LISTA DE TABELAS.........................................................................................................................................IV
LISTA DE SIGLAS.............................................................................................................................................. V
1. INTRODUÇÃO ........................................................................................................................................7
1.1. OBJETIVOS .............................................................................................................................................8
1.1.1. OBJETIVOS GERAIS..............................................................................................................................8
1.1.2. OBJETIVOS ESPECÍFICOS....................................................................................................................8
1.2. JUSTIFICATIVA......................................................................................................................................9
1.3. METODOLOGIA .....................................................................................................................................9
1.4. REFERENCIAL TEÓRICO ...................................................................................................................10
1.4.1. SERVIÇO ...............................................................................................................................................10
1.4.2. WEB SERVICES....................................................................................................................................12
1.4.2.1. XML - EXTENSIBLE MARKUP LANGUAGE.......................................................................................16
1.4.2.2. SOAP - SIMPLE OBJECT ACCESS PROTOCOL .................................................................................16
1.4.2.3. WSDL - WEB SERVICES DEFINITION LANGUAGE ..........................................................................18
1.4.2.4. UDDI - UNIVERSAL DISCOVERY DESCRIPTION INTEGRATION....................................................19
1.4.3. MODELAGEM DE NEGÓCIO..............................................................................................................20
2. BPM (BUSINESS PROCESS MANAGEMENT – GERENCIAMENTO DO PROCESSO DE
NEGÓCIO)............................................................................................................................................................23
2.1. BP (BUSINESS PROCESS – PROCESSO DE NEGÓCIO)..................................................................23
2.2. BPM (BUSINESS PROCESS MANAGEMENT)..................................................................................24
2.3. BPMN (BUSINESS PROCESS MODELING NOTATION – NOTAÇÃO DE MODELAGEM DO
PROCESSO DE NEGÓCIO) ................................................................................................................................27
2.4. BPMS (BUSINESS PROCESS MANAGEMENT SYSTEM – SISTEMA DE GESTÃO DE
PROCESSOS DE NEGÓCIO)..............................................................................................................................32
2.5. BPEL (BUSINESS PROCESS EXECUTION LANGUAGE – LINGUAGEM DE EXECUÇÃO DE
PROCESSOS DE NEGÓCIO)..............................................................................................................................34
3. SOA (SERVICE ORIENTED ARCHITECTURE – ARQUITETURA ORIENTADA A SERVIÇOS) 38
3.1. ENTIDADES DA SOA...........................................................................................................................43
3.2. INFRAESTRUTURA E FASES DE ADOÇÃO.....................................................................................45
3.2.1. FASES DE ADOÇÃO ............................................................................................................................45
3.2.2. ESB (ENTERPRISE SERVICE BUS – BARRAMENTO CORPORATIVO DE SERVIÇOS) ............46
4. BPM X SOA ...........................................................................................................................................49
5. CONSIDERAÇÕES FINAIS..................................................................................................................51
5.1. CONCLUSÕES GERAIS .......................................................................................................................51
5.2. PROPOSTAS DE TRABALHOS FUTUROS........................................................................................51
6. REFERÊNCIAS BIBLIOGRÁFICAS....................................................................................................52
7. GLOSSÁRIO ..........................................................................................................................................56
8. CD-ROM CONTENDO PROJETOS ANTERIORES....................................................................... 57

1. INTRODUÇÃO
Este trabalho aborda os contextos de Gerenciamento do Processo de Negócio (BPM)
e de Arquitetura Orientada a Serviços (SOA) como formas de integração entre pessoas,
processos, serviços e informações tecnológicas buscando benefícios do processo de negócio
aliados a essas tecnologias.
O surgimento de aplicações distribuídas, cada vez mais aumenta a necessidade de
compartilhamento de informações, assim tem-se aumentado a necessidade de
interoperabilidade entre sistemas.
É abordado nesse projeto o conceito de SOA e de BPM, e ainda conceitos afins, com
o intuito de demonstrar a aplicabilidade de sua utilização e a sua ligação com a reutilização de
software, principal foco de todo esse trabalho deste os primeiros projetos. O BPM trata da
questão agilidade e flexibilidade para a gestão dos processos de negócio das empresas
expressos por um conjunto de serviços que são unidos, ao passo que em SOA defini-se como
uma abordagem arquitetural corporativa permite a criação de serviços de negócios
interoperáveis, podendo ser facilmente reutilizados e compartilhados entre aplicações e
empresas.
Ainda são expressos assuntos relativos à BPM e SOA como linguagens de
modelagem de processos, e sistemas que apliquem essa modelagem para interação com
serviços e processos de negócios, com o intuito final de integração com a Arquitetura
Orientada a Serviços.
Tem-se como referencial teórico as abordagens de serviço, Web Services, e
modelagem de negócio, assim definiu-se conceitos chave para iniciar os assuntos principais.
Em seguida são abordados os temas principais começando por BPM, depois SOA e por fim a
relação entre eles.
Este trabalho segue princípios abordados em projetos anteriores por isso foi
disponibilizado um CD-ROM com projetos anteriores ao final para comparações quando
necessárias.

8
1.1. OBJETIVOS
1.1.1. Objetivos Gerais
Explorar ao longo dos semestres o desenvolvimento de software voltado à
reutilização, considerando as áreas de Engenharia de Software (ES) aplicáveis neste contexto,
e possivelmente usar como estudo de caso um domínio a ser selecionado para aplicar as áreas
de conhecimento adquiridas. Visa-se principalmente aplicar um ambiente de modelagem
baseado em reutilização, estruturado através de princípios da Engenharia de Domínio (ED) e
Análise de Domínio (AD), mas usufruindo-se da criação de modelos de negócio baseados nos
conhecimentos do Gerenciamento do Processo de Negócio (BPM) e da Arquitetura Orientada
a Serviços (SOA), além de outros conceitos que surgirem ao logo do aprendizado, e assim
modelar e construir um framework para uma parte do estudo de casos proposto. Vale ressaltar
que esta é uma pretensão futura e como o princípio é a modelagem de dados, o projeto pode
ser implementado em qualquer linguagem de programação que atenda às necessidades de
reutilização e análise.
1.1.2. Objetivos Específicos
Apresentar conceitos de BPM e SOA, abordando conceitos relacionados, como ESB,
WebService, BPML, BPMN, BAM, BPEL, Assets, entre outros.
Descrever assuntos intrínsecos aos conceitos de BPM e SOA que fazem relação com
o negócio e tecnologias envolvidas, como middlewares, Business Process, serviços entre
outros.

9
1.2. JUSTIFICATIVA
A utilização conjunta de SOA com BPM trás ganhos para o negócio da empresa, pois
enquanto o BPM provê a abstração de alto nível para definir processos de negócio entre outras
capacidades importantes de monitorar e administrar esses processos, o SOA provê as
capacidades para que os serviços sejam combinados para apoiar e criar um empreendimento
flexível. Em resumo, um bom projeto de BPM e SOA tem a capacidade de aprender a
identificar os serviços e suas granularidades, além de prover uma boa interação entre a
camada de serviços e a camada de negócios. Nota-se que o BPM se utiliza de conceitos
anteriormente popularizados na administração, como reengenharia e qualidade total e de
tecnologias como ERP (Sistemas Integrados de gestão), além de novos conceitos para se
integrar à estrutura de TI existente na empresa.
1.3. METODOLOGIA
Este trabalho baseia-se principalmente em artigos técnicos e trabalhos de graduação,
além de fontes baseadas em Web. É fundamentado em princípios de reutilização de software e
práticas de modelagem de negócio e visão de negócios aliados à tecnologia que implemente
esses conceitos. Os meios de pesquisa mais utilizados são a Internet e documentos
acadêmicos impressos ou digitais, apesar de também serem utilizados alguns livros.

10
1.4. REFERENCIAL TEÓRICO
1.4.1. Serviço
O que é um serviço?
Segundo Koch (2006) um serviço é uma porção ou componente de software
construído de forma que possa ser facilmente vinculado a outros componentes. Ele ainda
afirma que a idéia por trás destes serviços é a tecnologia expressa de forma que o pessoal de
negócio possa entender, e não como um aplicativo enigmático.
Segundo o Oasis (2006):
“Um serviço é um mecanismo para habilitar o acesso a um conjunto de uma
ou mais competências, onde o acesso é provido usando uma interface que
descrita é consistentemente exercitada com restrições e políticas como
especificados pela descrição de serviço. Um serviço é oferecido por uma
entidade – o provedor de serviço – para uso pelos outros, mas os
consumidores eventuais do serviço podem não saber do provedor de serviço
e podem demonstrar o uso do serviço além do escopo original concebido
pelo provedor.”
Serviços podem ser caracterizados como funções de negócio bem definidas e auto-
contidas que recebem requisições de clientes (consumidores) (FARO & FERRAZ, 2004).
Serviço é um componente que atende a uma função de negócio, o qual recebe e
responde requisições ocultando os detalhes de sua implementação (SANTOS, 2007).
A definição do Gartner Group diz que um serviço é um pedaço de software que
oferece uma interface bem definida podendo ser acessada por plataformas independentes e
outros pedaços de software. Este acesso pode ser conseguido através de um processo Runtime
Discovery, isto é, algo como uma descoberta em tempo real onde o usuário do serviço não
necessita ter um conhecimento prévio do serviço ou sua definição da interface antes de
requisitar o acesso ao serviço.
Um serviço é a lógica do negócio (servidor), capaz de ser acessado por outro
processo (cliente) (PIJANOWSKI, 2007).
Há três conceitos fundamentais importantes para o entendimento do que está
envolvido na interação com serviços: a visibilidade entre provedores de serviços e
consumidores, e a interação entre eles, e os efeitos no mundo real da interação com um
serviço (OASIS, 2006).

11
Um serviço deve representar o processo de negócio da empresa decomposto, ou seja,
um serviço representa uma parte de um todo do negócio da empresa. Eles podem ser
reutilizados, modificados e aplicados em diferentes áreas de uma empresa, dentro ou fora dela
na verdade, sem a necessidade de ajuste ou troca de tecnologia.
Apesar de um serviço ser projetado para ser autônomo, nenhum serviço está isolado,
eles devem interagir uns com os outros provendo serviços entre si. Um serviço deve possuir
granularidade grossa, ou seja, o nível de detalhes deve ser o menor possível para que o reuso
seja favorecido em uma arquitetura SOA (Arquitetura Orientada a Serviço) por exemplo.
Para se descobrir os processos candidatos a serviços são utilizadas algumas
metodologias: Decomposição de processos (Análise Top Down), decomposição de domínio,
análise Bottom-Up, Traccking (rastreamento) de eventos de negócio, gerenciamento do
portifólio e meet in the middle (SANTOS, 2007).
A análise Top Down (ou decomposição de serviços) divide um processo em partes
ou tarefas, tornando mais fácil a identificação de candidatos a serviços. Em uma análise
Bottom-Up ao se verificar as interfaces do Backend (sistemas legados) é possível identificar
os serviços que podem encapsular essas interfaces. O rastreamento de eventos de negócio por
sua vez considera que os eventos são o que estimulam os processos de negócio, por isso
monitora os eventos que disparam funcionalidade de negócio. Gerenciamento de portfólio
ajuda na modelagem e na identificação dos candidatos a serviços quando existe um portfólio
de serviços. Meet in the middle é uma mistura entre Análise Top-Down e Bottom-Up, onde
primeiro a análise Top-Down e depois a Bottom-Up são utilizadas para sustentar a integração
entre a TI e o negócio que é o objetivo primário da SOA (SANTOS, 2007).
A figura 1 apresenta o ciclo de vida de um serviço, nela é possível observar que no
status construção é feito a identificação e descoberta de um serviço, a modelagem e
implementação e a distribuição de um serviço como entradas. No status de ativo existe um
catálogo de serviços e há o gerenciamento da entrega e suporte, deve-se gerenciar através do
ciclo de operação, monitoração e avaliação, e usar do PDCA para melhoria contínua desse
gerenciamento, lembrando que todas as etapas devem ter qualidade do serviço seguindo
regras definidas. Ainda nesse status estão envolvidos as políticas e procedimentos e o
portfólio de serviço. Quando um serviço se torna obsoleto é feito a sua retirada, e quando fica
inativo é feito o seu arquivamento, esses status caracterizam a saída de um serviço.

12
Figura 1. Ciclo de Vida do Serviço (SANTOS, 2007).
1.4.2. Web Services
Web Services servem para integrar componentes ou serviços de software. Eles são um
conjunto de mecanismos-padrão de comunicação criados sobre a World Wide Web, como uma
metodologia para conectar e comunicar, principalmente entre sistemas distribuídos.
Em um Web Service a comunicação entre os serviços é padronizada, o que torna
possível a independência de plataforma e de linguagem de programação (RECKZIEGEL,
2006).
De acordo com Menéndez (2002) o Web Service é uma aplicação que aceita
solicitações de outros sistemas através da Internet, possuindo interfaces acessíveis de rede
para a funcionalidade da aplicação.
Um serviço promovido por um Web Service facilita o processamento distribuído em
sistemas heterogêneos. Estes serviços são baseados em um conjunto de padrões da Internet
definidos pelo W3C. O W3C é um consórcio, destinado a desenvolver tecnologias

13
interoperantes, de domínio público, para a World Wide Web (RECKZIEGEL, 2006). O W3C
(World Wide Web Consortium) serve como um padrão de desenvolvimento web, de forma que
um sistema desenvolvido funcione em navegadores e tecnologias diferentes.
Os Web Services são utilizados para disponibilizar serviços interativos na Web,
podendo ser acessados por outras aplicações usando, por exemplo, o protocolo SOAP (Simple
Object Access Protocol – Protocolo de Acesso a Objeto Simples), que é explicado mais a
frente. O intuito principal é facilitar a comunicação de um EAI (Enterprise Application
Integration), isto é, a integração das aplicações de uma empresa, assim há uma
interoperabilidade entre a informação que circula numa organização nas diferentes aplicações
como, por exemplo, o comércio eletrônico com os seus clientes e seus fornecedores
(WIKIPEDIA, 2009).
Um exemplo que demonstra melhor o conceito de um Web Service seria um sistema
desenvolvido em Java e rodando em um servidor Linux, podendo acessar, com transparência,
um serviço feito em .Net rodando em um servidor Microsoft.
A figura 2 apresenta um exemplo de um Web Service, onde é possível observar o que
foi dito no exemplo anterior.
Figura 2. Funcionamento básico de um Web Service (fonte:
http://imasters.uol.com.br/artigo/4245/webservices/entendendo_os_webservices)
É importante observar que o reuso dos componentes é proveniente de sistemas
integrados, podendo cada um deles representar um serviço distinto, e ainda sendo capaz de
participar de múltiplos sistemas provendo maiores benefícios imediatos e aumento da
agilidade do negócio (RECKZIEGEL, 2006).
Segundo Kreger (2001) a arquitetura dos Web Services é baseada na interação entre
Provedor de Serviços, Consumidor de Serviços e Registro dos Serviços, envolvendo as
operações de publicação, pesquisa e ligação.
O provedor de serviços deve definir a descrição do serviço para o Web Service e
publicar esta para o consumidor de serviços no registro de serviços, então o consumidor de

14
serviços utiliza a descrição do serviço publicada para se ligar ao provedor de serviços e
invocar ou interagir com a implementação do Web Service, conforme observado na figura 3.
Figura 3. Arquitetura de um Web Service (retirado de:
http://imasters.uol.com.br/artigo/4245/webservices/entendendo_os_webservices )
Toda e qualquer comunicação entre sistemas é dinâmica e principalmente segura, e
sem intervenção humana. Os Web Services permitem enviar e receber dados em formato
XML (Extensible Markup Language). Uma aplicação pode ter sua própria linguagem, pois
será traduzida para o formato XML tornando possível a comunicação entre aplicações
diferentes. Os Web Services deixam os recursos disponíveis para que qualquer aplicação
cliente possa operar e extrair os recursos fornecidos.
Os Web Services se utilizam de quatro camadas para fazer a comunicação entre suas
aplicações, que empacotam a requisição e a resposta entre o servidor e o cliente. As quatro
camadas básicas são: XML (Extensible Markup Language), SOAP (Simple Object Access
Protocol), WSDL (Web Services Definition Language) e UDDI (Universal Discovery
Description Integration). As definições são apresentadas nas subseções. A seguir é
apresentada a relação entre esses padrões.
Figura 4. Representação das tecnologias utilizadas em um Web Service (retirado de :
http://pt.wikipedia.org/wiki/Web_service)

15
A figura 4 apresenta a representação de como as tecnologias se relacionam em um
WS, que pode ser explicado da seguinte forma: A estruturação dos dados nas mensagens
recebidas e enviadas é feito através de XML, enquanto que as chamadas às operações são
codificadas no protocolo SOAP, incluindo parâmetros de entrada/saída. O serviços, como
operações e mensagens, por exemplo, são descritos utilizando linguagem WSDL e o processo
de publicação fica por conta do protocolo UDDI.
Exemplo prático de funcionamento de um WS pode ser visto na figura 5, retirado de
Reckziegel (2006).
Figura 5. Exemplo de funcionamento de um Web Service (CAPELARI, 2004)
A figura 5 é um exemplo de portal Internet de turismo expressado por Capelari
(2004), onde a entrada é um destino turístico. Com a informação, o sistema procura serviços
oferecidos para determinada localidade destino, com passagens, hospedagens, aluguel de
veículos, entre outros, assim comparando preços, horários, descrevendo os serviços oferecidos
de modo geral. Contudo, é necessário que as empresas relacionadas criem seus WSs que
devem ser acessados pelo portal, podendo as consultas ser feitas de forma concorrente. Essa
implementação gera um controle descentralizado, assim uma companhia área, por exemplo,
pode alterar seus horários de embarque, sem a necessidade de informar a um sistema de
controle central sobre a alteração.
Um WS só é realmente útil se os clientes puderem descobrir que serviços estão
disponíveis, onde encontrá-los e como eles podem ser chamados (TURTSCHI et. al., 2002).

16
1.4.2.1. XML - Extensible Markup Language
Uma explicação bastante simplificada do que é XML é que ele consiste em texto
estruturado. Sua simplicidade é o termo relevante, e o texto é suportado em todas as
plataformas. A representação de dados em formato texto facilita a leitura por outras
plataformas, podendo ler os dados sem a necessidade de conversões especializadas de um
formato para outro (TURTSCHI et. al., 2002).
Os dados são descritos por elementos e atributos. Os elementos possuem tags, assim
como no HTML (Hyper Text Markup Language). Traduzindo fielmente o significado de
XML afirma-se que ele é uma linguagem de marcação de dados com formato para descrever
dados estruturados.
O XML permite a definição de um número infinito de tags. Enquanto no HTML, se
as tags podem ser usadas para definir a formatação de caracteres e parágrafos, o XML provê
um sistema para criar tags para dados estruturados (GTA/UFRJ). Ou seja, no XML há a
possibilidade de extensão, podendo-se criar uma tag de acordo com a necessidade.
1.4.2.2. SOAP - Simple Object Access Protocol
O SOAP é um padrão de Internet aberto baseado em XML, que permite que dois
sistemas troquem dados. O SOAP é o padrão utilizado pelos WS para trocar dados pela
Internet, sendo considerado como um protocolo de interligação.
Esse padrão é independente de plataforma podendo ser implementado em mais de 60
linguagens e 20 plataformas (FARO & FERRAZ, 2004). As mensagens são modeladas como
um envelope SOAP. A especificação do SOAP define um framework ao qual se constrói
mensagens que trafegam através de diversos protocolos, ele é especificado de forma a ser
independente de qualquer implementação específica, sendo, portanto uma plataforma
descentralizada e distribuída.

17
Figura 6 Exemplo de SOAP (FARO & FERRAZ, 2004).
A figura 6 apresenta uma forma de funcionamento do SOAP onde uma aplicação
cliente requisita uma mensagem SOAP para um servidor Web com um SOAP request, este se
comunica com o servidor SOAP que pode fazer uma requisição RPC (Remote Procedure
Calls – Chamadas Remotas de Procedimento) caso necessário, o servidor SOAP se comunica
com o servidor Web de forma paralela, assim o Servidor SOAP envia uma mensagem SOAP
através de um SOAP response para a aplicação cliente com o que ele requisitou.
Segundo Cunha (2002), uma mensagem SOAP consiste basicamente dos elementos
envelope, header e body, conforme apresentado na figura 7. O envelope é o elemento raiz do
documento XML, contendo as declarações de nomes e atributos adicionais; o header é um
cabeçalho opcional e quando utilizado deve ser o primeiro elemento do envelope; um body é
obrigatório e contém a informação a ser transportada para o destino, podendo conter um
elemento opcional chamado fault para carregar mensagens de status e erros retornados ao se
processar a mensagem.

18
Figura 7. Estrutura de uma mensagem SOAP (CUNHA, 2002)
1.4.2.3. WSDL - Web Services Definition Language
Em um WS o papel de uma biblioteca de tipo é desempenhado pela descrição WSDL
de um Web Service. O WSDL é uma linguagem XML que não necessita ser compilada,
trazendo algumas vantagens, porém é um padrão complexo que ainda sofre mudanças
(TURTSCHI et. al., 2002).
É usado para descobrir a localização dos serviços, suas chamadas de funções e como
acessá-los. Ele define interfaces (operações, tipos de dados, etc), protocolos de acesso (SOAP
sobre HTTP) e localização dos serviços (URL do Web Service) (FARO & FERRAZ, 2004).
Figura 8. Exemplo de WDSL (FARO & FERRAZ, 2004)

19
O que é apresentado na figura 8 é explicado basicamente da seguinte forma: com um
registro de um Web Service um cliente faz uma busca através de SOAP do serviço UDDI
publicado, o parceiro de negócio invoca o WS através da tecnologia disponível no provedor
WS (exemplo Servlets JSPs) e recupera a definição do documento WSDL, a partir daí um
serviço chamado JAXR registra o WS durante o desenvolvimento.
Quando o cliente envia uma mensagem para um determinado WS, ele obtém a
descrição do serviço (utilizando a localização do documento WSDL), assim em seguida
constrói a mensagem com os tipos de dados corretos de acordo com a definição encontrada.
Essa mensagem é enviada para o endereço onde o serviço está localizado, sendo processado.
O WS por sua vez, recebe a mensagem e valida-a de acordo com as informações contidas no
WSDL. O serviço remoto trata a mensagem e processá-a, após isso mostra a resposta ao
cliente (CUNHA, 2002).
1.4.2.4. UDDI - Universal Discovery Description Integration
O UDDI é uma maneira mais completa de localizar WS, ele é, em si mesmo, um
Web Service e permite que empresas e indivíduos publiquem informações sobre si e sobre os
WS que estão oferecendo, sendo considerado um diretório de domínio global, totalmente
aberto, de simples uso e completo (TURTSCHI et. al., 2002).
Faz especificação com definição dos mecanismos para publicação e busca de WS em
repositórios de serviços. Um UDDI é baseado em XML e SOAP, no qual em XML utiliza as
estruturas de dados que definem os WS em um registro UDDI, enquanto em relação ao
SOAP, é utilizada a API para comunicação com um registro UDDI (FARO & FERRAZ,
2004). O UDDI ainda não foi submetido ao W3C.
A organização dos registros UDDI (UDDI Registry) acontece da seguinte forma:
páginas brancas para informações de contato (nome, endereço, URL, etc.); páginas amarelas
para categorização dos serviços baseado em taxonomias padrões, e registra informações de
códigos de indústrias, produtos, etc.; páginas verdes apresentam informações técnicas sobre o
serviço publicado, como especificações do WS e localização (FARO & FERRAZ, 2004).

20
Figura 9. Exemplo de funcionamento de um UDDI (in FARO & FERRAZ, 2004)
A figura 9 apresenta o funcionamento do UDDI onde o um provedor WS publica
informações de serviços Web no registro UDDI usando Web Service Description Language
(WSDL), assim é verificado o registro UDDI (Público ou Privado) de acordo com a cor do
registro (leia-se página), o solicitante do serviço Web procura o registro UDDI e encontra uma
descrição do serviço desejado, então o registro UDDI envia a descrição do serviço Web
solicitado. Assim o solicitante do serviço Web se conecta ao provedor WS através do
protocolo SOAP para obter o Web Service, logo após o serviço Web é entregue via SOAP à
aplicação/cliente solicitante.
1.4.3. Modelagem de Negócio
A modelagem de negócios se baseia em entender a estrutura e a dinâmica da
organização na qual um sistema deve ser implantado, assim como os problemas atuais da
organização-alvo, e identificar as possibilidades de melhoria. É importante que seja
assegurado que os clientes, usuários e desenvolvedores tenham um entendimento comum da
organização-alvo e derivar os requisitos de sistema necessários para sustentá-la (RSC, 2001).

21
Para que essas metas expressadas sejam atingidas, a modelagem de negócios
descreve como desenvolver uma visão da nova organização-alvo, definindo-se assim os
processos, papéis e responsabilidades dessa organização em modelos de casos de uso de
negócios e modelos de objetos de negócios.
A modelagem de negócio explicita a estrutura e dinâmica da organização gerando
assim uma visão comum da organização por clientes, usuários e desenvolvedores (TESSARI,
2003). Para Stutz (2006) a modelagem de negócio pode agregar valor ao processo modelado,
e assim ao software, na medida em que há a possibilidade de que sejam identificadas as
atividades, oportunidades de melhoria dos processos e relações de negócios.
Figura 10. Fluxo de dados da modelagem de negócios (RSC, 2001)
Dependendo da finalidade no esforço da modelagem, vários caminhos podem ser
percorridos, assim como a etapa disposta no ciclo de vida de desenvolvimento. A seguir tem-
se uma explicação de cada fase do fluxo apresentado na figura 10 com base nos conceitos da
Rational Software Corporation (2001).
No fluxo avaliar status do negócio é avaliado o status da organização na qual o
sistema resultante deve ser implantado. Nesse momento é entendido como o projeto deve ser
classificado e identificado o que é mais adequado para a modelagem de negócios. O principal

22
objetivo de reunir informações é promover entendimento claro dos problemas e potenciais do
negócio e sua forma de trabalho. Deve-se ter em mente que a continuidade do trabalho na
iteração é tomada nesse momento, assim como a definição de como será o trabalho nas
próximas iterações com os artefatos produzidos. É preciso entender as metas e os objetivos e a
visão do negócio da organização-alvo que podem ser aprovados pelos envolvidos e
responsáveis.
No fluxo identificar processos de negócio, as fronteiras da organização são
definidas, além de ser feita uma análise determinando-se quais processos serão descritos em
mais detalhes, tornando-os prioritários de acordo com a necessidade.
Em descrever o negócio atual, é necessidade entender os processos e a estrutura da
organização. Nesse fluxo são refinadas as metas do esforço para modelagem de negócio.
Detalha-se aqui o necessário para priorizar as partes que devem ser enfatizadas no restante do
projeto, além de descrever os detalhes da organização.
No fluxo refinar definições do processo de trabalho cada caso de uso de negócios
é detalhado e revisado, não somente por membros da equipe, mas por representantes
envolvidos também. Aqui é verificado se o caso de uso do negócio reflete corretamente a
maneira como os negócios são feitos.
Cabe ao fluxo projetar realizações do processo de negócio descrever como as
realizações de casos de uso de negócios serão executadas pelos envolvidos no processo. Além
disso, também é de sua responsabilidade identificar os papéis, produtos liberados e eventos de
negócio.
No ponto refinar papéis e responsabilidades uma entidade de negócios é definida e
detalhada, como também as responsabilidades de um colaborador de negócio. Neste fluxo é
relevante verificar formalmente se os resultados da modelagem de objetos de negócio são
compatíveis com a visão que os envolvidos têm do negócio.
O fluxo explorar a automação do processo explora as partes dos processos de
negócios que deverão ser automatizadas, sendo que é necessário entender como os sistemas
existentes (sistemas legados) se encaixam na organização, assim os requisitos de sistema
devem ser derivados nesse fluxo de dados.
Em desenvolver um modelo de domínio desenvolve-se um modelo de objeto de
negócio não muito complexo, pois se preocupa apenas com os produtos liberados e eventos
para o domínio do negócio, constituindo-se o modelo de domínio.

23
2. BPM (BUSINESS PROCESS MANAGEMENT – GERENCIAMENTO DO
PROCESSO DE NEGÓCIO)
2.1. BP (BUSINESS PROCESS – PROCESSO DE NEGÓCIO)
Um processo consiste de atividades inter-relacionadas para se chegar a um
determinado resultado esperado, consistindo de etapas bem definidas. Os processos ocorrem
em diferentes níveis de uma organização desde operacionais até estratégicos ou gerenciais.
Compreender como os processos de um negócio ocorrem nas organizações e buscar
potencializar os benefícios de sua adoção colabora para elevação do nível da organização
(NETO & JUNIOR, 2008).
Processos de negócios resultam em produtos ou serviços entregues pelas empresas,
mostrando-se importantes por integrarem diferentes atividades em áreas funcionais distintas e
englobam funcionários, clientes, parceiros e todos os envolvidos com objetivo comum
(NETO & JUNIOR, 2008).
O nível de complexidade de um processo define a sua dinamicidade, pois facilitam
alterações, adaptações e composição mesmo em longo prazo, ao passo que processos mais
simples possuem características estáticas dificultando alterações.
A palavra processo leva a pensar em “como fazer”, entretanto não se pode esquecer
do “quê” deve ser realizado (MENDES, 2010). Mendes afirma que o ideal é entender a
capacidade do negócio como o que precede um processo de negócio.
Um BP deve espalhar a visão para toda empresa dada pela modelagem de negócio. A
capacidade de aprendizado da organização também é um dos elementos a ser considerado por
um BP.
Figura 11. Processo de Negócio (WIKIPEDIA, 2009)

24
A figura 11 indica que os BPs podem ser entendidos como atividades desenvolvidas
a partir de um objetivo pré-estabelecido tornando-se um resultado específico, mas que
também envolve pessoas, equipamentos e informação no decorrer, os quais devem estar
alinhados. Também são verificados os procedimentos, prioridades e tarefas específicas até
alcançar o resultado.
Processos de negócio devem ser estruturados com a cooperação, integração e
alinhamento entre todas as áreas da organização para que obtenha sucesso. Nota-se ainda que
os processos estão cada vez mais automatizados, utilizando-se para tanto softwares, passando
a ter uma natureza tecnológica e de negócios. As regras de negócio estão embutidas nas
tecnologias portanto (NETO & JUNIOR, 2008).
É válido ressaltar que processos operacionais referenciam processos de rotina, ou
seja, processos repetitivos e processos estratégicos são os desempenhados pela alta direção.
2.2. BPM (BUSINESS PROCESS MANAGEMENT)
Segundo a IT7 (2010), BPM é um conceito que une gestão de negócio e tecnologia
da informação buscando a melhoria dos processos de negócio das organizações, e utilizando
para isso métodos, técnicas e ferramentas no intuito de modelar, publicar, controlar e analisar
processos operacionais. Deve envolver pessoas, aplicações, documentos e outros fatores
relacionados.
BPM deve prover melhoria, gerenciamento e controle dos processos essenciais da
empresa. Segundo Moura (2010), BPM depende de nove passos: Identificar os principais
stakeholders; Identificar os requisitos de cada stakeholder; Definir importância e prioridade
dos stakeholders para atender requisitos; Identificar os gaps de desempenho (externos),
verificando como a empresa está se saindo na prestação de serviços e as prioridades para
atendimento; Definir prioridades para melhorias; Ligar seleção AIBD (Alta Importância +
Baixo Desempenho) aos BPs internos; Definir prioridades para melhoria dos BPs; Definição
de métricas e metas; ciclo PDCA (Planejar, Fazer, Checar e Agir) para tratar 80% das causas
dos problemas.
BPM faz com que os processos modelados sejam facilmente transformados em
softwares além de possibilitar a integração dos aplicativos, e ainda elimina o processamento
redundante, pois com a integração dos processos consegue-se uma melhor visão do negócio.
Ele busca de forma geral a gestão da performance de seu escopo.

25
De acordo com a Procnet (2010) os principais objetivos do BPM são: obter a
automação do fluxo de trabalho, integrando seus passos aos aplicativos existentes; converter
processos manuais em processos eficientes informatizados; incorporar características de
controle para assegurar a integridade do fluxo de trabalho; prover feedback em tempo real
através de monitoramento; buscar melhoramentos contínuos, medir o tempo e custo dos
processos; orquestrar os BPs, melhorando a cooperação inter-departamental e inter-
empresarial; entender as fronteiras da organização a partir da integração de seus processos aos
processos de outras entidades externas (clientes, fornecedores, etc).
A WorkingMinds (2008) ainda acrescenta: BPM melhora a visão dos processos de
negócio; traz maior agilidade, flexibilidade de tempo de resposta nos serviços de TI; alavanca
o aproveitamento de sistemas legados; padroniza a execução de processos e integração com
os clientes, parceiros e fornecedores; reduz os custos de manutenção; otimiza os processos.
BPM se apóia no profundo conhecimento do negócio para garantir o sucesso da
automação das atividades (GRIMAS, 2008). BPM acompanha sistematicamente como os
recursos de uma organização são alocados e convertidos em ações operacionais, definindo-se
prioridades e metas organizacionais. Basicamente, BPM promove o alinhamento dos
processos de negócio com a estratégia, os objetivos e a cadeia de valor das organizações.
Segundo a Next Generation Center – NGC - (2010) a meta do BPM é padronizar
processos corporativos e ganhar pontos em produtividade e eficiência, assim as ferramentas
de BPM servem como aplicações com o propósito de medir, analisar e otimizar a gestão de
negócio e os processos da empresa.
Para que o BPM seja realmente efetivo as organizações devem deixar de focar
unicamente em dados e informações, e passar a gerir a melhoria de seus processos. O ponto
básico do BPM é a automação de processos na empresa, ou melhor, por toda a empresa, mas
com a consciência de que não existe uma combinação única e exata de processos e
metodologias.
Estando os processos modelados pode-se controlar sua execução, analisar seu
desempenho e identificar pontos de melhoria, proporcionando-se assim uma grande
flexibilidade e agilidade na otimização dos processos (WORKINGMINDS, 2008).
BPM deve atuar de forma que se repense as tarefas do dia-a-dia, e que se trabalhe
lado-a-lado com o pessoal de informática ao menos na fase de implementação, com o intuito
de automatizar fluxos de forma rápida e simples (NGC, 2010). Ainda de acordo com a NGC
(2010) as ferramentas de BPM utilizam a linguagem dos executivos de negócios e as peças
fundamentais são as pessoas, o que faz com que a visão vertical e departamental seja

26
substituída pela visão horizontal, automatizando, integrando e otimizando processos do
negócio com clientes, parceiros e colaboradores.
O ideal é formar uma equipe de executivos aliada a profissionais de tecnologia, como
um tipo de centro de gerenciamento de processos (PMC – Process Management Center), onde
todos se voltassem para o desenho e redesenho de processos, assim cuidando dos riscos,
indicadores e métricas de desempenho (NGC, 2010). Soluções BPM disponibilizam acesso
simplificado a consultas, análises e relatórios corporativos, pois integra bases de dados
diferentes unificando as informações em uma interface comum. Nas soluções BPM deve-se
usar um diretório de usuários para definir o perfil e nível de acesso (autoridade) para cada
usuário envolvido.
Para se implementar BPM, segundo a Procnet (2010) o primeiro passo é desenhar a
situação atual, sendo necessário a integração das áreas de negócio com a TI, aqui deve-se
priorizar os processos que serão implementados a partir de visões específicas, logo após deve-
se fazer um medição das tarefas do processo desenhado considerando tempo, custo,
probabilidades e freqüência dos fluxos. O terceiro passo é a análise e simulação, que consiste
em analisar os modelos gerados com a medição, assim avaliando-se a performance e
identificando os gargalos e meios de otimizar os processos. A seguir tem-se o processo de
melhoramento onde o processo é redesenhado, eliminando-se processos desnecessários e
simplificando a automação de tarefas, onde é feito uma comparação entre o modelo atual e os
modelos do novo desenho. Em quinto tem-se a automação com uma solução BPM escolhida,
aqui deve estar bem identificados os pontos de contato do processo com os sistemas existentes
ou externos e especificados os serviços complementares conforme necessidade. O ideal é
inter-relacionar BPM com SOA nesse ponto.
A figura 12 apresenta o ciclo de vida do BPM expressado pela N&S (2010), onde se
percebe as fases de operação, controle e construção de acordo com as regras acima.
Figura 12. Ciclo de vida BPM (N&S, 2010).

27
2.3. BPMN (BUSINESS PROCESS MODELING NOTATION – NOTAÇÃO DE
MODELAGEM DO PROCESSO DE NEGÓCIO)
Para Bitencourt (2007), BPMN está se consolidando como o mais importante padrão
de notação gráfica aberta para desenhar e modelar processos de negócios e, esta notação deve
permitir diminuir as distâncias entre o mapeamento dos processos nas áreas de negócio e a
adaptação técnica destes processos na TI, se tornando assim um padrão comum de
entendimento dos requisitos alinhados com os objetivos do negócio.
O BPMN é um padrão que foi criado pelo BPMI (Business Process Management
Initiative), uma organização independente que propicia o desenvolvimento de especificações
abertas para o gerenciamento de processos empresariais. A BPMI se uniu a OMG (Object
Management Group) em 2005, ficando conhecido como Business Modeling & Integration
Domain Task Force (BMI DTF), e além do BPMN para modelar processos de negócios, criou
ainda o BPML (Business Process Modeling Language) como linguagem padrão de
desenvolvimento e o BPQL (Business Process Query Language) como interface de
manutenção para a distribuição e execução de processos e-business, com o intuito de facilitar
o BPM (GRIMAS, 2008).
Para se expressar os processos de negócio o BPMN fornece uma notação em um
diagrama de processo de negócio (BPD – Business Process Diagram), que deve ser entendido
por todos os utilizadores, analistas e envolvidos, utilizando-se para tal, uma notação comum.
Os processos podem ser formados por sub-processos dentro do processo de negócio.
Com base em Santos (2009) afirma-se que com o BPMN pode-se modelar os tipos de
processo interno, abstrato e de colaboração. Processo interno é o tipo mais comum, contendo
uma série de atividades realizadas dentro da empresa. Os processos abstratos algumas vezes
incluem processos realizados fora da empresa sem que a empresa tenha gerencia sobre as
atividades realizadas, assim deve-se usar um modelo abstrato para representar uma
organização independente, ou seja, não se pode modelar por não conhecer o processo, ou não
importa modelar, por isso representa-se em branco. Processos de colaboração descrevem
processos B2B (Business to Business) e as interações entre duas ou mais entidades de
negócio, apresentando diagramas de ponto de vista global. A figura 13 representa os tipos de
processo pela notação.

28
Figura 13. Exemplos de tipos de negócio (adaptado de SANTOS, 2007).
Para Bitencourt (2007) é possível capturar e modelar os BPs capturando e
documentando modelos atuais (AS-IS) em diagramas de fácil entendimento, projetar e
descrever modelos ideais (TO-BE), estender detalhes técnicos, monitorar e mensurar o
negócio com indicadores de desempenho baseados nas atividades dos fluxos de processos
automatizados.
A especificação BPMN é dividida em três áreas: Core Elements, Full Elements e
Atributes. Onde os core elements representam um conjunto de elementos comuns e
simplificados, capazes de modelar a maior parte dos processos do negócio. Os full elements é
formado pelo conjunto de todos os elementos da especificação, incluindo os core elements,
modelando qualquer processo do negócio. Os atributes são o conjunto de propriedades e
informações de cada elemento (SANTOS, 2009).
Segundo Grimas (2008) e Santos (2009) existe quatro categorias básicas de
elementos a serem simbolizados em BPMN, que são objetos de fluxo, objetos de conexão,
swimlanes e artefatos.
A tabela 1 apresenta a simbologia para os objetos de fluxo.

29
Tabela 1 - Objetos de Fluxo – Simbologia base.
Objeto Descrição Figura
Evento É algo que acontece durante um processo
do negócio. Estes eventos afetam o fluxo
do processo e têm geralmente uma causa
(trigger) ou um impacto (result). Há três
tipos de eventos, baseados sobre quando
afetam o fluxo: Start, Intermediate, e
End.
Atividade É um termo genérico para um trabalho
executado. Os tipos de atividades são:
Tarefas e sub-processos. O sub-processo
é distinguido por uma pequena cruz no
centro inferior da figura.
Gateway É usado para controlar a divergência e a
convergência da seqüência de um fluxo.
Assim, determinará decisões tradicionais,
como juntar ou dividir trajetos.
Fonte: (SANTOS, 2009)
Uma tarefa é a menor unidade de um processo e geralmente não pode ser
subdividida. Um sub-processo em um BPD é uma atividade composta por uma série de outras
atividades que formam um novo fluxo, e que segundo Santos (2009) pode ser dividida em
aberta ou fechada. Um subprocesso aberto é representado com um novo subprocesso interno
enquanto um subprocesso fechado pode estar ou não dentro do mesmo pool. Veja a figura 14:
Figura 14. Representação de subprocessos fechado e aberto (SANTOS, 2009)

30
A seguir a tabela que demonstra a simbologia dos objetos de conexão.
Tabela 2 - Objetos de Conexão – Simbologia base.
Fluxo de
seqüência
É usado para mostrar a ordem
(seqüência) com que as atividades
serão executadas em um processo.
Fluxo de
mensagem
É usado mostrar o fluxo das
mensagens entre dois participantes
diferentes que os emitem e recebem.
Associação É usada para associar dados, texto, e
outros artefatos com os objetos de
fluxo. As associações são usadas para
mostrar as entradas e as saídas das
atividades.
Fonte: (GRIMAS, 2008)
Swimlanes funcionam como um mecanismo de organização das atividades em
categorias visuais separadas. Vide tabela a seguir.
Tabela 3 - Swimlanes – Simbologia.
Pool Um pool representa um participante em um
processo. Ele atua como um container gráfico
para dividir um conjunto de atividades de outros
pools, geralmente no contexto de situações de
B2B.
Lane Uma lane é uma subdivisão dentro de um pool
usado para organizar e categorizar as atividades.

31
Um pool é utilizado quando o diagrama envolve duas entidades de negócio ou
participantes que estão separados fisicamente no diagrama, especificando o que faz o que
colocando os eventos e os processos em áreas protegidas (pool) (SANTOS, 2009). Lane
separa as atividades associadas para uma função ou papel específico, representa normalmente
um departamento dentro de um pool.
Figura 15. Exemplo de Lane (SANTOS, 2009)
Os artefatos representam as entradas e saídas das atividades de um processo.
Tabela 4 - Artefatos Simbologia.
Objetos de dados O objeto de dado é um mecanismo para
mostrar como os dados são requeridos ou
produzidos por atividades. São conectados às
atividades com as associações.
Grupo Um grupo é representado por um retângulo e
pode ser usado para finalidades de
documentação ou de análise.

32
Anotações As anotações são mecanismos para fornecer
informações adicionais para o leitor de um
diagrama BPMN.
Exemplo de uso de artefato.
Figura 16. Segmento de processo com artefatos (SANTOS, 2009)
Essas foram as simbologias base, porém existem outras mais específicas não citadas
nesse projeto.
2.4. BPMS (BUSINESS PROCESS MANAGEMENT SYSTEM – SISTEMA DE
GESTÃO DE PROCESSOS DE NEGÓCIO)
Um BPMS é um sistema que automatiza a gestão de processos de negócio com
execução, controle e monitoração. Deve incluir o mapeamento de BPs, desenho dos fluxos e
formulários, regras de negócio, integradores, monitoração em tempo real das atividades e
alertas. Isso permitirá a execução efetiva dos processos exclusivamente como modelados.

33
BPMS nada mais é do que a representação dada para softwares que colaboram com a
gestão por processos aumentando a capacidade dos gestores e envolvidos na troca de idéias e
conhecimento. Esses sistemas devem propiciar um ambiente de integração de sistemas
definindo o fluxo de integração, regras, eventos e especificações inerentes ao BPM, além de
ser totalmente flexível.
Business Process Management System ou Business Process Management Suite é
uma categoria de software empresarial que capacita as empresas a modelar, automatizar e
gerenciar uma série de atividades inter-relacionadas, tanto departamentais como toda a
empresa, e ainda se estendem à participação de clientes, fornecedores e outros envolvidos
(AURAPORTAL, 2010).
Os BPMS possibilitam que as organizações modelem, disponibilizem e gerenciem
processos críticos, podendo ser distribuídos entre múltiplos aplicativos da empresa,
departamentos e parceiros de negócio (SMITH & FINGAR, 2003). Esses sistemas devem
complementar as estruturas tradicionais de SI (Sistemas de Informação), buscando a
satisfação dos envolvidos no processo.
Para Paim et. al. (2007) incorporar e implantar BPMS requer metodologia para
prover os conceitos, técnicas e ferramentas adequadas para suportar as várias tarefas de
modelagem, análise, desenho, simulação, avaliação e redesenho das aplicações, e ainda afirma
que ele contribui para a gestão organizacional facilitando a comunicação e integração das
pessoas em todos os setores da organização.
Existem muitos tipos de sistemas BPMS, este trabalho não apresentará os tipos por
considerar desnecessário visto que depende do que cada organização realmente requer de um
sistema desse tipo, mas uma ilustração pode ser vista na figura 17. Entretanto algumas
características importantes que devem estar presentes em um BPMS instalado são, segundo
Oliveira (2007): Capturar e identificar os processos críticos e necessários à gestão do negócio;
Entender, aceitar e operar o esquema de identificação, o seqüenciamento e a interação desses
processos; Tornar possível a integração do sistema de gestão de processos com o ambiente de
TI; Aceitar o conjunto de critérios e métodos (metodologia) adotados pela organização,
visando assegurar a efetiva operação e o monitoramento desses processos; Fornecer e colocar
disponível, a tempo e na hora certa, informações sobre esses processos; Possibilitar o
monitoramento de atividades do negócio (BAM – Business Activity Monitoring), monitorando
o funcionamento e desempenho dos processos; Fornecer ferramentas para análise da estrutura
atual, simulação e otimização de processos; Fornecer recursos e facilidades para a

implementação de ações, visando á obtenção de resultados planejados e à melhoria contínua
desses processos.
Figura 17
Segundo Ghalimi (2006) um BPMS
principais dentre ou em adição as apresentadas por Oliveira (2007) que são: suporte a regras
de negócio complexas, monitoramento das atividades de negócio (BAM) e uma maneira de
controlar versões de documentos ane
oferecidas de forma nativa ou por serviços, ou componentes externos. Ele afirma ainda que se
quiser ir mais a fundo ainda pode
Service Bus – Barramento de Serviços Corporativos), um repositório de metadados e um
conjunto para BI (Business Inte
que saem da infra-estrutura de BAM.
2.5. BPEL (BUSINESS PROCESS
EXECUÇÃO DE PROCESSOS DE NEG
17. Alguns Tipos de BPMS (retirado de PAIM, 2007)
Segundo Ghalimi (2006) um BPMS completo deve possuir três potencialidades
de documentos anexados às instâncias dos processos, podendo ser
quiser ir mais a fundo ainda pode-se utilizar mais três coisas em adição: Um ESB (
o de Serviços Corporativos), um repositório de metadados e um
Business Intelligence – Inteligência do Negócio) que ajude a filtrar os dados
estrutura de BAM. Um exemplo de BPMS é o Intalium.
L (BUSINESS PROCESS EXECUTION LANGUAGE
DE PROCESSOS DE NEGÓCIO)
34
. Alguns Tipos de BPMS (retirado de PAIM, 2007)
completo deve possuir três potencialidades
ncias dos processos, podendo ser
se utilizar mais três coisas em adição: Um ESB (Enterprise
o de Serviços Corporativos), um repositório de metadados e um
Inteligência do Negócio) que ajude a filtrar os dados
Um exemplo de BPMS é o Intalium.
– LINGUAGEM DE

35
A BPEL, também conhecida como WS-BPEL, foi construída em substituição à
BPML que foi uma linguagem criada para modelar processos de negócio, desenvolvida pelo
BPMI. A BPML não superou as expectativas, pois trazia consigo a idéia de orquestração de
processos em nível muito genérico (LAWISCH, 2008). Segundo Lawisch os detalhes de cada
tarefa do processo simplesmente não interessavam para a especificação, assim apenas fazia
chamadas, envio e resposta de mensagens entre web services. Também houve a questão
política para a troca de linguagem.
BPEL foi originalmente construído pela Microsoft e pela IBM, com o apoio das
empresas SAP e Siebel, mas esse consórcio passou o controle para a empresa OASIS
(BORTOLINI, 2007). BPEL é um padrão técnico em formato XML, onde seu principal
objetivo é descrever um BP que interaja com WSs, internos ou externos à organização.
BPEL é uma linguagem baseada em WS específica para executar BPs que envolvam
integração de sistemas. Se usada a ferramenta certa, uma analista de negócio implementará
poucas linhas de código, pois a ferramenta gerará o restante necessário. Em uma comparação
unicamente para entendimento pode-se dizer que BPEL é como o SQL (Structured Query
Language – Linguagem de Consulta Estruturada), ou seja, as bases de dados trabalham graças
ao SQL, e BPEL segue a mesma linha.
Os analistas de negócio não terão que escrever uma única linha de BPEL, pois em
vez disso devem utilizar uma ferramenta de modelagem de processos que gere o código para
eles (GHALIMI, 2006). Não é preciso se importar em como o código é gerado segundo
Ghalimi por três razões: Em primeiro lugar usar um motor que suporte BPEL de forma nativa
assegura que os processos que são distribuídos nele poderão ser distribuídos em outro motor
de processos também. BPEL suporta definição proprietária de extensão. Em segundo, é certo
que os processos que vão ser distribuídos visando um servidor executável de BPEL terão as
interfaces WS que interagirão em qualquer momento com os processos em sua execução, e os
dados para auditoria terão certo formato. Em terceiro lugar, quando a maioria dos
fornecedores de TI, como IBM, Microsoft, Oracle e SAP, concordam com o padrão fornecido,
não há muito espaço para outro.
BPMN pode gerar código BPEL, porém ainda não é perfeito. Existe a notação Aris,
porém é uma notação muito proprietária, que não permite ser suportada por nenhuma
ferramenta senão uma específica denominada IDS Scheer Aris. Portando o BPMN é a melhor
opção atualmente. Os digramas UML também não são utilizados para modelar processos, pois
são limitados, não acomodando exigências de uma arquitetura orientada a serviços (SOA).
BPMN gera BPEL, porém ainda não há como fazer o caminho inverso (GHALIMI, 2006).

36
Segundo Ghalimi, BPMN e BPEL fazem uma combinação extremamente poderosa porque
apresentam um caminho do diagrama ao código sem ter que realmente escrever o código.
Códigos BPEL antes utilizavam um gerador de código Java, mas isso se tornou
muito complexo, então atualmente com o BPM versão 2.0 o código é interpretado de forma
nativa de BPEL 2.0.
Um processo BPEL se estrutura em passos, chamados de atividade. Ele suporta
atividades como: chamar outro WS com <invoke>; manipular dados das variáveis usando
<assing>; terminar o processo com <terminate>; criar estruturas de repetição com <while>;
aguardar um tempo usando <wait>, entre outras.
A figura 18 apresenta um exemplo de elementos de um BPEL, apenas para ilustrar o
funcionamento.
Figura 18. Elementos de um BPEL (NADER, 2007)
As figuras 19 e 20 apresentam exemplos de uma agência de viagem e de um processo
BPEL para esse exemplo respectivamente. No processo da agência de viagens são oferecidos
os pacotes de viagens para o Canadá, Estados Unidos e outro lugar com uma previsão. Caso a
reserva seja feita para o Canadá (reserva AC) ou para os Estados Unidos (reserva AA) será
feito o aluguel de um carro para a designação um, e após deve-se ir para a designação dois,
mas também se tem a opção de ir direto para a designação dois, os outros lugares (reserva
BA) deverão ir obrigatoriamente para dois, obtém-se a resposta e finaliza-se.

37
Figura 19. Exemplo agência de viagens (NADER, 2007).
Figura 20. Exemplo de Processo BPEL (NADER, 2007)

38
3. SOA (SERVICE ORIENTED ARCHITECTURE – ARQUITETURA
ORIENTADA A SERVIÇOS)
De forma geral a Arquitetura Orientada a Serviços (SOA) descreve duas coisas um
tanto quanto diferentes. Uma está relacionada a metodologias para desenvolvimento de
software e outro descreve um panorama de todos os ativos de software de uma empresa, assim
como uma planta arquitetônica é uma representação de todas as peças que, junto, formam uma
construção (KOCH, 2006). SOA utiliza, portanto, metodologia de programação orientada a
serviços para criação dos softwares relacionados aos serviços de uma empresa.
Uma arquitetura de software é um conceito abstrato, mas sua melhor definição neste
paradigma trata basicamente como os componentes fundamentais de um sistema se
relacionam através de serviços, intrínseca e extrinsecamente, ou seja, componente principal é
o serviço.
Idéias expressadas em um fórum da IBM (SOA – Infraestrutura para Inovação -
2006), afirmam que para o desenvolvedor, SOA é um framework baseado em web services
que permite invocar objetos remotamente utilizando protocolo SOAP, baseado em XML. E na
visão gerencial seria uma tecnologia que cria um ambiente de negócio rápido e atinge
vantagem competitiva ou maior valor.
Em uma arquitetura orientada a serviço a tecnologia da informação (TI) deve alinhar-
se às necessidades do negócio. As atividades de negócio são realizadas através de serviços
com formas variadas de requisitar e enviar informações. Destaca-se que um serviço deve ser
seguro e confiável, além de rápido. SOA deve garantir a segurança, sigilo e integridade do
modelo de negócio.
Soluções devem adaptar-se a novos contextos de utilização para acompanhar a
evolução do negócio, isso provém da flexibilidade empregada pela tecnologia e que é
discutida na implantação do SOA.
A Arquitetura Orientada a Serviços é basicamente instituída pela troca de mensagens
SOAP entre serviços e também pela utilização dos protocolos XML, WSDL, UDDI, etc.
Muitos conceitos de SOA foram baseados em modelos já existentes como processamento
distribuído e orientação a objetos (DCOM, CORBA, etc. – vide projeto semestral anterior
Desenvolvimento Baseado em Componentes) além de outros (ROCHA, 2006). Além disso,
SOA utiliza-se de aliados como XML digital signature e XML encryption para garantir a
segurança da mensagem.

39
Segundo a Digital Assets (2007) SOA é uma abordagem arquitetural corporativa que
permite a criação de serviços de negócio interoperáveis que podem facilmente ser reutilizados
e compartilhados entre aplicações e empresas.
Web Services (WS) são uma boa maneira de implementar SOA, mas WS não é SOA.
Segundo Koch (2006) SOA é uma arquitetura ou estratégia de TI que cria padrões dentro de
uma empresa, utilizando-se uma metodologia específica de desenvolvimento de software, ou
seja, através de programação orientada a serviço, enquanto WSs são um conjunto de
mecanismos-padrão de comunicação criados sob a World Wide Web (www), ou seja, servem
para conectar e comunicar.
Segundo Rocha (2006) alguns tendem a definir SOA como um conjunto de Web
Services, o que não deve ser feito, pois apesar desta afirmação não ser totalmente errada,
deve-se ter em mente que SOA independe de ambiente WS para existir, pois é entendido
como um modelo conceitual de arquitetura, sendo baseado em protocolos, conceitos, regras,
padrões e acordos contratuais para troca de informações entre serviços. Contudo WS está se
tornando a plataforma preferida para implantação de SOA.
Para a IBM (2010), dentro de uma arquitetura SOA, aplicativos, informações e
recursos de TI são serviços ou blocos de construção, os quais podem ser misturados e
combinados para criar novos e flexíveis processos de negócios, assim como devem atender
aos requisitos prioritários de mudança, por isso destacando-se o seu nível de reuso.
Utilizar orientação a objeto e uma arquitetura de componentes é um facilitador para
adoção de SOA, mas não é um pré-requisito. Porém a utilização de UML (Unified Modeling
Language) permite projetar a arquitetura em questão, assim é possível modelar um serviço
utilizando-se os diagramas conhecidos da UML.
De acordo com Neto (2006) os padrões adotados nessa arquitetura garantem
interfaces bem definidas, sem a interferência de padrões proprietários limitando a utilização,
afirmando ainda que antes os canais de comunicação e o vocabulário não se encaixavam. O
foco dos serviços está nas atividades no nível de negócio e suas interações e são ligados
dinamicamente e de maneira flexível.
A reusabilidade é um fator importante, pois podem ser bastante reutilizados os
serviços, porém segundo dados da IBM a falta de confiança e de incentivos desestimula o
reuso desses serviços, ressalta-se ainda a visibilidade limitada sobre informações de negócio.
A Governança de TI é um fator a ser considerado, pois para que os serviços sejam
reutilizados, tem que haver uma metodologia de desenvolvimento centralizada e única. O
ideal seria um repositório centralizado de serviços, bem documentados, assim fica fácil a

40
procura por um serviço e integração dos mesmos com outros necessários. Dessa forma, para
Koch (2006) SOA envolve um portfólio de serviços criados pelos CIOs (Chief Information
Officer) para uma arquitetura corporativa, uma metodologia de desenvolvimento centralizada
e uma equipe centralizada de gerentes de projetos, arquitetos e desenvolvedores, e ainda
requer um CEO (Chief Executive Officer) e uma equipe executiva dispostos, que preparem o
necessário para que a equipe de TI possa analisar processos mais pesados da empresa.
Entender estes processos e conquistar adesão para o compartilhamento corporativo são
significantes em uma transformação do negócio baseada em SOA.
Um CIO é algo como uma direção de informática ao passo que um CEO é uma
gerência executiva. É necessário que o CIO e o CEO tenham uma relação de proximidade
para que tudo dê certo, como apresentado na seção BPM x SOA.
SOA representa um paradigma para a organização e utilização de competências
distribuídas que estão sob o controle de diferentes domínios proprietários (OASIS, 2006).
Diferente da orientação a objeto, onde o foco é o empacotamento de dados com operações,
SOA foca na tarefa ou função de negócio. Ainda segundo o Oasis (2006) SOA oferece uma
base mais viável para sistemas de grande escala porque ele se enquadra melhor na forma
como as atividades humanas são gerenciadas, ou seja, por delegação, senão não haveria
diferença entre serviços e objetos. A tabela 5 apresenta uma comparação de Orientação a
Serviços com a Orientação a Objetos de forma geral. Nota-se que a principal diferença é que
SOA foca na função do negócio e OOP foca no empacotamento de dados com operações.
Tabela 5 – Comparação entre orientação a serviços e orientação a objetos.
Fonte: (adaptado de SANTOS, 2007)

41
Destaca-se que os conceitos-chave relacionados com o SOA são: baixo acoplamento,
abstração, assets. Baixo acoplamento refere-se à capacidade dos ativos de TI trabalharem
integrados embora existam independentemente; a abstração leva em consideração a interação
com sistemas complexos de forma simples, pelo menos na maneira de uso; assets são
elementos de software que encapsulam o conhecimento, podendo ser reutilizados.
Em SOA visa-se obter o máximo de desacoplamento entre os serviços, porém deve
haver a flexibilidade de inter-relacionamento entre os serviços, pois os serviços atuam como
serviços consumidores e/ou serviços provedores (servidores), dependendo de quem consome
ou provê o serviço numa composição de serviços.
Mas quais benefícios esperar de SOA na prática? De acordo com a Digital Assets
(2007): Redução de custo em novos projetos; Time-to_market/ Agilidade; facilidade/
flexibilidade de manutenção; melhoria da qualidade de serviço; otimização dos processos;
transformação dos negócios / oportunidades de receita.
Principais Desafios estão relacionados com três principais fatores: Organização e
pessoas, processos e políticas, tecnologia e ferramentas. De forma resumida, pessoas são
eficientes através da iteração e colaboração, processos SOA fornecem serviços para tornar os
BPs eficientes e eficazes, e a tecnologia viabiliza a realização dos processos, conforme figura
21.
Figura 21. Componentes da SOA (SANTOS, 2007)
Organização e pessoas requerem mudança de mentalidade, apoio executivo,
incentivos. Um componente ou serviço, flexível, bem documentado e que resolve um

problema recorrente será um bom componente se for possível encontrá
lo e reusá-lo. A administração de componentes deve ter um perfil semelhante à administração
de dados, além de amplo conhecimento d
Processos e políticas devem torna
dificuldade de identificar como
como em um processo RUP
Figura 22. Processo de desenvolvimento de software atual (Digital Assets
A tecnologia deve expressar volatilidade, com arquitetura padronizada, massa de
serviços e middleware para invocação dos serviços.
Não é aconselhável a utilização de SOA nos casos em que a empresa não oferece
serviços para parceiros, clientes ou fornecedores, e também como SOA está relacionado ao
baixo acoplamento, para os casos de utilização
Sistemas baseados em SOA geralmente são sistemas distribuídos abertos (PUC
CD 0210486/CA). De forma geral os serviços são executados em máquinas distintas, mesmo
que sejam máquinas virtuais, e necessitam se comunicar, o que é feito através de prot
padronizado bem definido.
Dentro do que foi visto, conclui
ligação entre a tecnologia da informação e os BPs, ajudando a aumentar a flexibilidade de
negócios e a capacidade de uma empresa cumprir meta
pode ser considerado uma evolução do Desenvolvimento Baseado em Componentes (DBC).
O impacto de SOA nos negócios, fora da indústria de TI, reside no aumento de
produtividade relativa às mudanças de processos de negócio
recorrente será um bom componente se for possível encontrá-
lo. A administração de componentes deve ter um perfil semelhante à administração
de dados, além de amplo conhecimento do negócio.
Processos e políticas devem tornar SOA uma prática sistemática,
dificuldade de identificar como os serviços encaixam-se no modelo de desenvolvimento atual
RUP (Rational Unified Process), por exemplo, mostrado na figura 22
Processo de desenvolvimento de software atual (Digital Assets
para invocação dos serviços.
baixo acoplamento, para os casos de utilização real-time, essa pode não ser uma boa escol
Sistemas baseados em SOA geralmente são sistemas distribuídos abertos (PUC
que sejam máquinas virtuais, e necessitam se comunicar, o que é feito através de prot
Dentro do que foi visto, conclui-se que o principal objetivo do SOA é fornecer uma
negócios e a capacidade de uma empresa cumprir metas de negócio. Em aspectos gerais SOA
produtividade relativa às mudanças de processos de negócio (GARTNER
42
-lo, entendê-lo, avaliá-
lo. A administração de componentes deve ter um perfil semelhante à administração
r SOA uma prática sistemática, mas ainda se tem
se no modelo de desenvolvimento atual,
mostrado na figura 22.
Processo de desenvolvimento de software atual (Digital Assets - 2007)
, essa pode não ser uma boa escolha.
Sistemas baseados em SOA geralmente são sistemas distribuídos abertos (PUC-RIO,
que sejam máquinas virtuais, e necessitam se comunicar, o que é feito através de protocolo
se que o principal objetivo do SOA é fornecer uma
Em aspectos gerais SOA
(GARTNER in ROCHA, 2007).

43
3.1. ENTIDADES DA SOA
SOA é composto praticamente por várias funcionalidades conceituais e
fundamentais, e quando implementadas juntas proporcionam embasamento para o paradigma
do find, bind e execute (ROCHA, 2006). A figura 23 apresenta o paradigma find-bind-execute
(Encontrar-Vincular-Executar).
Figura 23. O Paradigma Find-Bing-Execute (ROCHA, 2006)
A figura acima apresenta a SOA com as entidades básicas e conceituais, todavia,
nem sempre essas entidades conceituais estão presentes ao mesmo tempo na arquitetura
(ROCHA, 2006). Um exemplo é a entidade Registry onde a localização dos serviços e os
contratos são armazenados, na maioria das vezes pode não ser utilizada na arquitetura.
As entidades têm funcionalidade específica e as interações entre elas ocorrem de
forma a proporcionar o máximo de desacoplamento (ROCHA, 2006). Um acoplamento fraco
é uma característica de sistema que reduz a interdependência e riscos de conflitos entre as
entidades, propiciando flexibilidade de inclusão, alteração e modificação sem causar danos. A
seguir uma breve explicação dessas entidades (consumidor de serviço, provedor de serviço,
registro de serviço, contrato de serviço, proxy de serviço).

44
Consumidor de Serviço (Service Consumer) - proporcionado por qualquer módulo
de software que requer serviços (STEVENS, 2005). Um service consumer efetua a busca no
registro de serviços (registry) para localizar um dado serviço, assim, ao encontrar o serviço
essa entidade dispara uma requisição de abertura de conexão contra a interface de serviço
procurado conforme formato e regras de contratos exigidos pelo serviço provedor (ROCHA,
2006). Na falta do registry, outra forma de descobrir como chegar ao serviço esperado deverá
ser utilizada.
Provedor de Serviço (Service Provider) - disponibilizado por qualquer módulo de
software ou sistema que executa requisições de serviços provenientes de consumidores de
serviços. Esta entidade é um serviço endereçável que aceita e executa requisições enviadas
por consumidores de serviços contanto que as requisições sigam regras de contrato e
descrições do serviço contidas no arquivo WSDL (ROCHA, 2006). Segundo Stevens (2005)
os detalhes dos serviços são publicados em um registry juntamente com a localização do
contrato os quais contém as regras e requisitos de segurança para acesso aos serviços
providos. É responsável pela implementação do serviço.
Registro de Serviço (Registry) – serve como um diretório para localizar páginas
HTML, Web Services entre outros. Um registry contém a localização dos serviços
disponíveis, ou seja, aponta a localização do WSDL do serviço, e ainda provê a localização
dos contratos e requisitos de segurança. Nele além de ser armazenada a configuração do
serviço, tem-se também a rastreabilidade de suas dependências. De acordo com Faro & Ferraz
(2004) esta entidade é responsável pelo registro e consultas a serviços publicados,
funcionando como um diretório ou página amarela.
Segundo Rocha (2006) uma das características básicas do registro de serviço é
determinar o tipo de segurança e protocolo suportado pelos serviços requisitados, e prover a
localização dos WSDLs e políticas de acessos dos mesmos para consumidores e serviços que
os requisitam.
Contrato de Serviço (Service Contract) – um contrato fornece ao service consumer
detalhes para estrutura de requisição do serviço e detalhes da estrutura de resposta que o
service provider proporcionará (ROCHA, 2006). Um contrato de serviço oferece listas de
prováveis condições excepcionais, requerimentos de segurança, incluindo criptografia e
assinatura digital, informação de qualidade de serviço (QoS) que descreve métricas, entre
outros.
Proxy de Serviço (Service Proxy) – um Proxy de serviços não é requisito em SOA,
porém a sua presença implica em ganho de performance e ambiente mais seguro. O Proxy de

45
serviço funciona como em um Proxy de internet, com a diferença que para a arquitetura SOA
ele atende aplicações XML. Um exemplo apresentado por Stevens (2005) mostra uma idéia
melhor a respeito do assunto: um processo de negócio baseado na arquitetura orientada a
serviço, que não requer dados atualizados em tempo real, pode simplesmente se beneficiar do
armazenamento local de um serviço no Proxy de serviço, proporcionando assim um ganho no
tempo de resposta do serviço solicitado.
A figura 24 apresenta um exemplo mais prático do funcionamento do SOA.
Figura 24. Dinâmica de funcionamento SOA (Digital Assets - 2007)
Um provedor de serviços registra um serviço no diretório de serviços, no exemplo os
Correios registram o código de rastreamento de um produto, o consumidor do serviço (Loja
Virtual Submarino) solicita o serviço desejado no diretório de serviços (um código de
rastreamento para um produto), que retorna o contrato de serviço e endereço para o
Submarino, aqui o consumidor de serviço vincula o serviço com o provedor de serviço
(Correios) que retorna uma resposta do serviço de rastreamento para o consumidor.
3.2. INFRAESTRUTURA E FASES DE ADOÇÃO
3.2.1. Fases de Adoção
A implantação estruturada de SOA é feita de maneira corporativa, através de fases de
adoção conforme figura 25. Na seqüência é apresentado um resumo dos processos
pertencentes a cada fase.

46
Figura 25. Fases de adoção SOA (Adaptado de DIGITAL ASSETS, 2007)
Na fase de iniciação ocorrem os processos de entendimento e conceituação,
capacitação, análise de Gap, Business Case e venda interna. Em planejamento e design
apresenta-se o estabelecimento do processo de governança, definição da arquitetura
tecnológica, definição da infra-estrutura SOA e seleção de projeto-piloto. Na fase de
implementação faz-se a identificação dos serviços já existentes, implantação da infra-estrutura
e realização dos serviços do projeto-piloto. Na monitoração e tendência tem-se a coleta de
indicadores, e análise crítica e propostas de melhoria.
É importante observar que para se adotar SOA é recomendado se utilizar da
Governança como forma de garantir a implantação adequada de SOA, esse deve ser um dos
primeiros passos segundo Barbosa (2009), pois as empresas cada vez mais estão se
interligando através de uniões e aquisições, e cada uma dessas relações possuem sistemas
heterogêneos, tornando a Governança um fator a ser considerado.
Ao se implantar SOA o pessoal de negócio pode visualizar como a empresa é em
termos de tecnologia, assim quando projetos de TI são apresentados em relação às atividades
e processos de negócio e não na forma de aplicativos (KOCH, 2006). De acordo com a Sun
(2010) os dados para as atividades do processo de negócios são oferecidos como um serviço
integrado.
3.2.2. ESB (Enterprise Service Bus – Barramento Corporativo de Serviços)
O ESB se refere a uma arquitetura de construção de software implementado em
tecnologias encontradas em infra-estrutura de middleware. Ele se baseia em reconhecimento
de padrões, os quais fornecem base de serviços para arquiteturas mais complexas via driver de
evento e padrões baseados em mensagens (BUS). A base de um ESB é construída da quebra
de funções de funções básicas em partes, distribuídas onde for necessário.
Em termos, ESB não implementa SOA, entretanto fornece as características para que
isso ocorra, e não necessariamente precisa ser implementado com WS (WIKIPEDIA, 2009).

47
Um ESB é na verdade um mediador, podendo fazer conversões de formatos para
comunicação de diferentes plataformas. O sistema de origem não precisa conhecer o sistema
destino, além disso ele provê controles de acesso de sistemas externos e permite configurar a
segurança das mensagens. Assim se existisse um sistema X em um empresa que adquiriu uma
outra empresa que utiliza um sistema Y implementado com tecnologia diferente, e a empresa
X necessita obter dados de ambos os sistemas de forma integrada, ela se utilizaria de um ESB
para conectar os sistemas, pois o ESB seria um negociador ou interface ao qual seria
solicitada a execução dos processos ou consultas, sem que as tecnologias tomassem
conhecimento umas das outras. ESB pode ser considerado o coração do SOA (Forum GUJ,
2007).
Segundo Cruz (2006), ESB serve como ligação entre SOA e BPM, pois não é
possível realizar um BPMS sem haver um ESB. Para ele enquanto se tem poucos serviços,
não há problemas em não se utilizar ESB, mas quando esse número aumenta
exponencialmente cada um deles vai ter necessidade de autenticação e autorização dos seus
clientes, registro de pedidos e respostas efetuadas, proteção de pedidos mal-formados, cache
para aumentar a disponibilidade e escalabilidade, entre outros, necessitando-se assim do ESB.
Ao invés de haverem clientes solicitando serviços diretamente, existe uma espécie de
hub para enviar e receber mensagens dos serviços, centralizando todas as funcionalidades que
eram da responsabilidade de cada serviço, assim tornando possível a redução de tempo e
complexidade do desenvolvimento cada vez que seja necessário um novo serviço (CRUZ,
2006), como pode ser visto na figura 26. Um ESB gera interações entre os serviços, assim
constitui uma ferramenta poderosa para basear um negócio de uma organização.
Figura 26. Representação de um ESB (DIGITAL ASSETS, 2007)

48
O funcionamento de um ESB é ilustrado na figura a seguir.
Figura 27. Representação de seleção dinâmica ESB (DIGITAL ASSETS, 2007)
De acordo com a figura 27, o funcionamento de um ESB basicamente consiste nas
seguintes etapas: O provedor registra o serviço no Registry e no ESB, onde regras e políticas
podem ser incluídas. O Cliente invoca o serviço solicitando a infra-estrutura de ESB, que
solicita informações sobre o serviço a ser executado no diretório de serviços (Registry). O
registro responde então com as informações básicas e os metadados (como port type,
endpoint, policies, etc), então o ESB executa algo chamado match client-provider aplicando
as transformações, políticas, para troca de informações. A mensagem é transformada e roteada
para o provedor correto.
O ESB pode ser dividido em dois tipos: Orientado a Protocolo e Orientado a API.
Um ESB orientado a protocolo define um protocolo que os fornecedores e clientes
devem satisfazer, mas cabe aos fornecedores e clientes fazê-lo. Os sistemas conectados são
desacoplados de forma que não compartilham nenhum código, assim não é necessário fazer a
distribuição de bibliotecas para as aplicações ou sistemas. Entretanto a desvantagem é que
qualquer mudança de protocolo exige que os fornecedores e consumidores a atualizem
(SANTOS, 2007).
Um ESB orientado a API fornece uma API para fornecedores e clientes usarem na
implementação ou em uma chamada de serviços, permitindo que os detalhes do protocolo
sejam transparentes, porém requer uma forma para que o ESB faça a distribuição do código
gerado ou das bibliotecas para todos os fornecedores e clientes (SANTOS, 2007).

49
4. BPM X SOA
Segundo Evangelista (IGP Informática - 2010) deve-se ter em mente que a adoção de
SOA requer mudança cultural da organização, da forma como as pessoas trabalham juntas e
da forma como pensam em arquitetura e principalmente da forma como elas fornecem
funcionalidades ao negócio. A área de TI deve ser vista como uma expressão concreta dos
processos de negócio.
Para entender a relação entre esses paradigmas é necessário perceber onde um
termina e o outro começa, ou a sobreposição entre eles. BPM permite que um analista de
negócios alinhe sistemas de TI com os objetivos estratégicos através da criação de processos
bem definidos, monitorando sua performance e otimizando eficiências operacionais. Cada BP
é modelado como um conjunto de tarefas individuais, e essas tarefas são normalmente
implementadas como serviços da empresa (ROSEN, 2006).
Segundo Rosen (2006) SOA oferece a plataforma de aplicativos que atuam como
pontes entre os processos de negócio e os recursos operacionais. Como apresentado na figura
28. No nível de processos de negócio fornecem-se interfaces que suportam diretamente a
execução das tarefas do processo, porém a definição dessas interfaces no contexto empresarial
deve suportar consistência e reuso. No nível operacional, SOA expõe as capacidades como
serviços integrados, mas isto não é feito por mapeamento direto de aplicações existentes como
serviços, pois na verdade, ele provê novas interfaces de serviços baseado na semântica e
requerimentos funcionais da empresa, onde os mapeia para sistemas existentes. Por fim, as
camadas superior e inferior são unidas através da composição de serviços para criar a camada
da plataforma de aplicação.
Juntas BPM e SOA provêem uma grandiosa combinação para a informatização dos
negócios de uma empresa, onde o uso de BPM fornece uma abstração de alto nível para a
definição dos BPs, além da capacidade de monitoramento dos processos. Os serviços
suportam os processos, ou seja, fornece as funções necessárias para apoiá-los. SOA fornece a
capacidade para que esses serviços sejam combinados e apóia a criação flexível da empresa.
BPM e SOA são distintos, um não depende do outro, mas atuam melhor se usados
em conjunto. Segundo Evangelista (IGP Informática - 2010) BPM sem SOA serve para
construir aplicações, porém com dificuldades de estender todo o processo organizacional, e
SOA sem BPM cria serviços reutilizáveis e consistentes, porém perde-se a flexibilidade do
negócio e a competitividade.

50
Figura 28. Relação BPM x SOA (ROSEN, 2006)
Um projeto de BPM deve considerar a utilização futura de um ESB entre a camada
de negócios e serviços, criação de lugar para registrar e descobrir serviços, além de identificar
os serviços e a granularidade deles.
Ward-Dutton (2009) afirma que a combinação do BPM e SOA é vista como
complementar tecnicamente, ele sustenta que há sinergia suficiente entre eles para aumentar o
valor empresarial. Ainda segundo ele em SOA a abordagem é de baixo para cima, que é
basicamente impulsionado pela TI, e BPM possui abordagem de cima para baixo
impulsionado pelo negócio, mas muitas vezes há interesses divergentes entre os
impulsionadores dessas iniciativas o que dificulta a integração.
Para Ward-Dutton (2009) deve-se entender em alto nível os compromissos de
serviços de negócio que uma organização faz, onde os modelos de serviços atuam em
diferentes níveis de granularidade e abstração, aqui se decompõe os serviços de alto nível de
serviços de negócio e informam-se os requerimentos para os acordos de serviço nos diferentes
níveis entre a organização e seus sistemas.

51
5. CONSIDERAÇÕES FINAIS
5.1. CONCLUSÕES GERAIS
Este projeto apresenta as características do Gerenciamento do Processo de Negócio e
da Arquitetura Orientada a Serviço no contexto da interação do negócio com a tecnologia e
utilização de possível reutilização de software. O tema reutilização de serviços é bastante
discutido atualmente, mas é necessário técnicas que possam facilitar ou aprimorar o
desenvolvimento. O que é apresentado aqui é uma maneira de se projetar software seguindo
padrões do negócio propriamente dito, através de BPM e dos serviços oferecidos pelo SOA.
Apresentam-se ainda algumas notações do BPMN para utilização com a linguagem BPEL, e o
conceito de Sistemas de Gestão de Processos de Negócio, além do embasamento em Web
Services. É importante um escopo bem definido, para que ocorra a modelagem voltada para
reutilização do serviço.
O que foi apresentado serve de base para as pretensões futuras do projeto como um
todo, mesmo ainda não estando o estudo de caso definido.
5.2. PROPOSTAS DE TRABALHOS FUTUROS
Nos próximos semestres, almeja-se especificar um estudo de caso e aplicar os
conceitos de Engenharia de Domínio, BPM e SOA e alguma ferramenta para auxiliar na
modelagem do domínio (provavelmente Odyssey) alinhado a outra para modelagem de
negócio, chegando-se assim aos serviços a serem implementados.
Intensiona-se modelar esse estudo de caso como um framework para o domínio a ser
analisado, visando a modelagem de serviços reutilizáveis e demonstração das práticas de ED e
SOA no BPM. Como geralmente esses estudos são realizados em domínios muito
abrangentes, o estudo de caso deve utilizar apenas uma parte do domínio ou um domínio
menor apenas para demonstração, já que essas técnicas em sua maior parte são recomendadas
para sistemas de maior porte.

52
6. REFERÊNCIAS BIBLIOGRÁFICAS
AURAPORTAL. "O que é BPMS?". 2010. Disponível em:
http://www.auraportal.com/PT/PT0-What-is-BPMS.aspx. Última consulta em 26/05/2010.
BARBOSA, Ricardo de Castro. Entrevista ao site Meta Análise: “SOA: Erros, Acertos e
Desafios em sua Adoção”. Publicado em vídeo em 30/11/2009 no site:
http://www.metaanalise.com.br/inteligenciademercado/palavra-aberta/entrevista/soa-erros-
acertos-e-desafios-em-sua-adoc-o.html#top.Último acesso em 21/05/2010.
BITENCOURT, Maurício. "Modelagem de Processos com BPMN". 2007. Disponível em:
http://www.baguete.com.br/artigos/270/mauricio-bitencourt/19/07/2007/modelagem-de-
processos-com-bpmn. Úlrima consulta em 25/05/2010.
BORTOLINI, Rafael. "O Mundo das Siglas e Padrões: Parte III - BPEL". 2007.
Disponível em: http://blog.cryo.com.br/2007/08/27/o-mundo-das-siglas-e-padroes-parte-iii-
bpel/. Última consulta em 21/05/2010.
CAPELARI, João Cláudio Junior; FORNARI, Miguel Rodrigues. “WebClipping utilizando
WebServices”. ULBRA-Canoas 2004. In Reckziegel, 2006.
CIVA, Gláucia. “CEO x CIO: As Armas para Vencer a Guerra”. Disponível em:
http://www.baguete.com.br/noticias/negocios-e-gestao/08/08/2008/ceo-x-cio-as-armas-para-
vencer-a-guerra. 08/08/2008. Última consulta em 25/05/2010.
CRUZ, Antônio. “SOA, ESB e BPM”. Disponível em:
http://www.arquitecturadesoftware.org/blogs/antoniocruz/archive/2006/07/21/405.aspx.
Publicado em 21/06/2006. Última consulta em 23/05/2010.
CUNHA, Davi., “Web Services, SOAP e Aplicações Web”. Artigo publicado em
http://devedge-temp.mozilla.org/viewsource/2002/soap-overview/index_pt_br.html. Data de
publicação 10/12/2002. Última consulta em 18/05/2010.
Digital Assets. WorkShop SOA (Service Oriented Architecture). 2007. Disponível em:
www.digitalassets.com.br.
EVANGELISTA, Carlos. "Usar BPM ou SOA ou BPM e SOA?”. Disponível em:
http://www.igpinformatica.com.br/docs/BPMSOA.pdf. Última consulta em 20/04/2010.
FARO, Marcelo; FERRAZ, Carlos., “Service Oriented Architectures (SOA)”. Sistemas
Distribuídos - CIn/UFPE (Centro de Informática/ Universidade Federal de Pernambuco).
Material de aula, Pernambuco, 2004.
GHALIMI, Ismael Chang. "BPM 2.0". Disponível em:
http://www.projeler.com.br/download/pdf/bpm20_ptbr.pdf. Última consulta em 26/05/2010.
Tradução IT/Redux. 2006.

53
GRIMAS, Washington. "Business Process Modeling Notation (BPMN)". 2008. Disponível
em: http://www.ebah.com.br/introducao-ao-estudo-de-bpmn-ppt-a8800.html. Último acesso
em 25/05/2010.
GTA/UFRJ, Grupo de Teleinformática e Automação / Universidade Federal do Rio de
Janeiro. XML – Extensible Markup Language. Disponível em:
http://www.gta.ufrj.br/grad/00_1/miguel/. Última consulta em 12/05/2010.
GUJ (Grupo de Usuários Java). “Arquitetura Orientada a Serviço (SOA)”. Disponível em:
http://www.guj.com.br/posts/downloadAttach/1458.java. Última consulta em 13/05/2010.
GUJ (Grupo de Usuários Java). Resposta ao fórum “O que é ESB?”. Disponível em:
http://www.guj.com.br/posts/list/77933.java.2007. Última consulta em 23/05/2010.
IBM (2010) –IBM Software sobre tecnologia – Arquitetura Orientada a Serviços, disponível
em http://www-01.ibm.com/software/br/info/topic/openenvironment/soa/. Último acesso em
02/05/2010.
IT7 (2010). "BPM - Gerenciamento de Processos de Negócios". Disponível em:
http://www.it7.com.br/bpm-gerenciamento-de-processos-de-negocios.php. Última consulta
em 26/05/2010.
KREGER, H.. “Web Services Conceptual Architecture (WSCA 1.0)”, IBM Software
Group, 2001.
LAWISCH, Eduardo André. "BPEL: Uma Padronização para Especificação Técnica de
Processos". Trabalho de Conclusão de Curso. Universidade de Santa Cruz do Sul, Santa Cruz
do Sul, RS, Brasil, 2008.
MENÉNDEZ, Andrés Ignácio Martínez. “Uma ferramenta de apoio ao desenvolvimento de
Web Services”. Dissertação de Mestrado, Universidade Federal de Campina Grande, curso de
Pós-Graduação em Informática, 2002.
MENDES, Marco A. S. “Além do BPM – Menos Foco em Processos e mais Foco em
Capacidades”. Artigo de blog. Data de publicação: 06/02/2010. Disponível em:
http://blog.marcomendes.com/2010/02/06/alem-do-bpm-menos-foco-em-processos-e-mais-
foco-em-capacidades/. Última consulta em 25/05/2010.
MOURA, J. A. B. “Business Process Management (BPM) – Valorando a TI pelos BPs”.
Apresentação de projeto a UFCG/CCT/DSC. Disponível em:
http://www.dsc.ufcg.edu.br/~antao/disciplinas/eti/slides/ETI-
7BusinessProcessManagement(BPM).ppt. Última consulta em 20/04/2010.
NETO, Manoel V. S.; JUNIOR, Josué V. M. “Afinal, o que é Business Process
Management (BPM)? Um Novo Conceito para um Novo Contexto”. Artigo de pós-
graduação publicado em 8/11/2008 na Revista Eletrônica de Sistemas de Informação. UFRN
(Universidade Federal do Rio Grande do Norte), RN, Brasil.
NETO, Rodolpho U. Forum “Arquitetura Orientada a Serviços – SOA Infraestrutura
para a Inovação (IBM)”. 2006. Disponível em:

BPM vs. SOA

Recommended

Recommended

More Related Content

Similar to BPM vs. SOA

Similar to BPM vs. SOA (20)

Recently uploaded

Recently uploaded (9)

BPM vs. SOA