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:

54

http://www.pr.senai.br/posgraduacao/uploadAddress/Introducao%20ao%20SOA%5B31574%5D%5B4843%5D.pdf. Última consulta em 002/05/2010. N&S Negócios e Serviços Ltda. 2010. "Business Process Management (BPM)". Disponível em: http://www.ns.srv.br/artigos/FolhetoFull.pdf. Última consulta em 31/05/2010. NGC (NEXT GENERATION CENTER). 2010. "BPM". Apostila de curso. Disponível em: http://www.livrosfaculdade.com/2010/05/curso-completo-bpm-next-generation.html. Última consulta em 27/05/2010. OLIVEIRA, Saulo Barbara (Org.). “Gestão por Processos - Fundamentos, Técnicas e Modelos de Implementação”. 1ª ed. Rio de janeiro: Quaitymark, 2006. v. 01. 310 p, 2007. In: PAIM et. al., 2007. PAIM, Rafael; PINHO, Bruno; SANTOS, Daniel; e CAMEIRA, Renato. "O que são BPMS: Sistemas de Suporte às Tarefas para Gestão de Processos". Artigo publicado em http://www.cescage.edu.br/site/pagina/arquivos/revista/innovare/artigos/0f20O_QUE_SAO_BPMS_SISTEMAS_DE_SUPORTE_AS_TAREFAS_PARA_GESTAO_DE_PROCESSOS.pdf. 2007. Última consulta em 26/05/2010. PIJANOWSKI, Keith. “Construindo Aplicativos Distribuídos”. Artigo publicado em: http://msdn.microsoft.com/pt-br/library/bb507204.aspx em 10/09/2007. Última consulta em 21/05/2010. PROCNET Informática (2010). “BPM”. Disponível em: http://www.procnet.com.br/website/index.asp?novoserver1&start=1&endereco_site=www.procnet.com.br&par=&email=. Última consulta em 10/05/2010. PROCNET Informática. 2010. “Projeto BPM”. Disponível em: http://www.procnet.com.br/website/conteudo.asp?id_website_categoria_conteudo=1768&cod=725&idi=1. Última consulta em 30/05/2010. PUC-Rio (Pontífica Universiadade Católica – Rio de Janeiro). “Arquitetura Orientada a Serviços”. Certificação digital número 0210486/Ca. 2004. Rio de Janeiro, RJ. RECKZIEGEL, Mauricio. “Entendendo os WebServices”. Artigo disponível em: http://imasters.uol.com.br/artigo/4245/webservices/entendendo_os_webservices. Data de publicação: 23/06/2006. Última consulta em 17/04/2010. ROCHA, Cláudio A., “Um Estudo Sobre os Desafios de Segurança na Adoção da Arquitetura Orientada a Serviços (SOA)”. Trabalho Final de M.Sc., UNICAMP, Campinas, SP, Brasil 2006. ROSEN, Mike. "BPM and SOA - Where Does One End and the Other Begin?”. Publicado em www.bptrends.com. Publicado em Janeiro de 2006. EUA. RSC (RATIONAL SOFTWARE CORPORATION). 2001. http://www-01.ibm.com/software/rational/.

55

SANTOS, Rildo F. "Mapeamento e Modelagem de Processos de Negócios com BPMN". 2009. Disponível em: http://www.slideshare.net/Ridlo/mapeamento-e-modelagem-de-processos-de-negcio-com-bpmn. Última consulta em 26/05/2010. SANTOS (2007) – SANTOS, Rildo F. “SOA Fundamentos – Arquitetura Orientada a Serviços, Fundamentos, Princípios de Design, Melhores Práticas e Governança”. Workshop: SOA Fundamentos, 2007. Disponível em: http://www.slideshare.net/Ridlo/soa-fundamentos. Última consulta em 11/05/2010. SMITH, H. & FINGAR, P. “Business Process Management – The Third Wave”. Tampa: Meghan Kiffer, 2003. In: PAIM et. al., 2007. STEVENS, M. “Understanding Service-Oriented Achitecture”. 2005. In: 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. SUN Microsystems. “Arquitetura Orientada a Serviços (SOA)”. Disponível em: http://br.sun.com/practice/software/soa. Última consulta em 21/05/2010. TESSARI, Rogério. “Processos para desenvolvimento de software orientado a objetos”. Projeto, CARVI/ UCS (Campus Universitário da Região dos Vinhedos Bento Gonçalves / Universidade de Caxias do Sul), Rio Grande do Sul, 2003.

TURTSCHI, A.; WERRY, J.; HACK, G., ALBAHARI, J., NANDU, S.; LEE, W., “C# .NET - Guia do Desenvolvedor Web”. Rio de Janeiro, Alta Books, 2002. WARD-DUTTON, Neil. “Bringing BPM and SOA Together for Maximum Business Value”. Artigo publicado no site SOAInstitute.org em 10/06/2009. Disponível em http://www.soainstitute.org/articles/article/article/bringing-bpm-and-soa-together-for-maximum-business-value.html. Comentários traduzidos disponível em: http://www.infoq.com/br/news/2009/07/bpm-soa-business-value. Última consulta em 24/05/2010. WIKIPEDIA. “Enterprise Service Bus”. Disponível em: http://pt.wikipedia.org/wiki/Enterprise_Service_Bus. 2009. Última consulta em 21/05/2010. WIKIPEDIA. “Web Service”. Disponível em: http://pt.wikipedia.org/wiki/Web_service. 2009. Última consulta em 12/04/2010. WORKINGMINDS. 2008. "SOA e BPM". Disponível em: http://www.workingminds.com.br/data/pages/FF8080811C2C224E011C2C23E46F0187.htm. Última consulta em 30/05/2010.

56

7. GLOSSÁRIO

Artefato: Termo usado para qualquer produto do trabalho de desenvolvimento de software. Chief Executive Officer - Para quem não gosta de traduzir termos, CEO é um termo elegante. Significa, na prática (e em português) diretor-executivo. Chief Information Officer - Comandante Chefe de Informação. Algo como Diretor ou Vice-Presidente de Informática. É a função de mais alto nível, na área de informática, de uma organização. Responsável pela infraestrutura e manutenção da rede. Estereótipo: Permite classificar elementos "com algo em comum" através de símbolos ou nomenclaturas especiais. Um estereótipo é representado por um nome entre << >>. Framework: (ou arcabouço) é uma abstração que une códigos comuns entre vários projetos de software provendo uma funcionalidade genérica. Ao contrário das bibliotecas, é o framework quem dita o fluxo de controle da aplicação, chamado de Inversão de Controle. Implementação: (Neologismo) é a fase do Ciclo de Vida de um software (programa computacional, documentação e dados), no contexto de um Sistema de Informação, que corresponde à elaboração e preparação dos módulos necessários à sua execução. Metadados: grande quantidade de dados. Middleware: representa uma camada intermediária entre o sistema operacional e as aplicações distribuídas, objetivando abstrair a heterogeneidade na comunicação. RUP: Abreviação de Rational Unified Process (ou Processo Unificado da Rational), é um processo proprietário de Engenharia de software criado pela Rational Software Corporation, adquirida pela IBM, ganhando um novo nome IRUP que agora é uma abreviação de IBM Rational Unified Process e tornando-se uma brand na área de Software, fornecendo técnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade. Software: Inclui não só o programa de computador propriamente dito, mas também manuais e especificações. Stakholders: todos os envolvidos em um processo. Representa todos que são atingidos ou atingem de forma positiva ou negativa um processo ou negócio. www - abreviação em inglês de World Wide Web, uma espécie de superteia de alcance mundial, também denominada de Web.

BPM vs. SOA

Technology

Transcript of BPM vs. SOA