Monografia

PONTIFCIA UNIVERSIDADE CATLICA DE MINAS GERAIS Programa de Ps-Graduao em Arquitetura de Softwares Distribudos
Claudecir Miranda da Silva
ARQUITETURA DE REFERENCIA SOA: Um estudo de caso utilizando princpios de design de servios e BPEL numa empresa de varejo
Belo Horizonte 2013
Monografia apresentada ao Programa de PsGraduao em Arquitetura de Softwares Distribudos da Pontifcia Universidade Catlica de Minas Gerais, como requisito parcial para obteno do ttulo de especialista.
Orientador: Zenilton K. G. Patrocnio Jnior
Belo Horizonte 2013
Monografia apresentada ao Programa de PsGraduao em Arquitetura de Softwares Distribudos da Pontifcia Universidade Catlica de Minas Gerais, como requisito parcial para obteno do ttulo de especialista.
__________________________________________________ Zenilton K. G. Patrocnio Jnior
Belo Horizonte, 31 de outubro de 2013.
Agradecimentos
A Deus em sua imensa bondade, que me permitiu concluir mais essa etapa na minha vida.
A minha esposa Sheila, que me apoiou durante todo esse tempo e que me incentiva a cada dia ser uma pessoa melhor e mais capacitada.
Ao meu filho Lucca, que muitas noites foi dormir sem ver o papai, porque ele chegava tarde das aulas.
E aos meus colegas de classe pela troca de experincias.
LISTA DE FIGURAS Figura 1 Motivao para uso do BPEL ................................................................... 11 Figura 2 - Figura Um servio web bsico ...............................................................18 Figura 3 Mensagens XML para servios web.........................................................18 Figura 4 - Papis servios web ................................................................................. 19 Figura 5 Pilha de protocolos ...................................................................................20 Figura 6 Estrutura da mensagem SOAP ................................................................24 Figura 7 Elementos WSDL: Types ......................................................................... 26 Figura 8 Elementos WSDL: Service e Port.............................................................27 Figura 9 Elementos WSDL: Binding ....................................................................... 27 Figura 10 Elementos WSDL: PortType e Operation ............................................... 28 Figura 11 Elementos WSDL: Message................................................................... 28 Figura 12 Aplicao dos Princpios de Design .......................................................31 Figura 13 Os oito Princpios de Design .................................................................. 32 Figura 14 Contrato de servios .............................................................................. 33 Figura 15 Acoplamento de servio ......................................................................... 35 Figura 16 Abstrao de servio .............................................................................. 36 Figura 17 Reuso de servio....................................................................................37 Figura 18 Autonomia de servio ............................................................................. 38 Figura 19 Independncia de estado ....................................................................... 40 Figura 20 Visibilidade de servio ............................................................................ 41 Figura 21 Composio de servio .......................................................................... 42 Figura 22 Como o modelo de referncia se relaciona com outros trabalhos.......... 45 Figura 23 Histrico da evoluo do BPEL ..............................................................46 Figura 24 Orquestrao de Processo BPEL ...........................................................48 Figura 25 Coreografia de Processo BPEL..............................................................49 Figura 26 Modelo padro de Integrao................................................................. 53 Figura 27 Arquitetura de referncia SOA The Open Group................................. 56 Figura 28 Arquitetura do Oracle BPEL Process Manager ...................................... 59 Figura 29 Advanced Queueing em ambientes de aplicativos integrados ............... 60 Figura 30 Fluxo de integrao do pedido de vendas .............................................. 62 Figura 31 Criando um servidor de aplicao no JDeveloper .................................. 65 Figura 32 - Configurando o servidor de aplicao apelido do servidor...................66
Figura 33 - Configurando o servidor de aplicao dados do usurio .....................66 Figura 34 - Configurando o servidor de aplicao dados da conexo....................67 Figura 35 Testando a configurao do servidor de aplicao ................................67 Figura 36 Criando um servidor de integrao no JDeveloper ................................68 Figura 37 Definindo o nome do servidor de integrao .......................................... 68 Figura 38 Ligando o servidor de integrao ao servidor de aplicao ...................69 Figura 39 Testando a conexo com o servidor de integrao ................................69 Figura 40 Criando uma conexo de banco de dados no JDeveloper .....................70 Figura 41 Definindo o nome e tipo da conexo ......................................................70 Figura 42 Informando usurio de senha para a conexo de banco de dados ........ 71 Figura 43 Especificando detalhes da conexo com o banco de dados .................. 71 Figura 44 Processo BPEL INT_FCN_Integracao_Pedidos .................................... 72 Figura 45 Processo BPEL INT_INTEGRA_PEDIDO_RE ....................................... 73 Figura 46 Processo BPEL BPELHPS ..................................................................... 74 Figura 47 Processo BPEL BPEL_Integra_Pedido_RE ........................................... 75 Figura 48 Processo BPEL AQ_integra_Pedido_RE ............................................... 77 Figura 49 Criando uma aplicao no JDeveloper...................................................78 Figura 50 Criar um projeto BPEL ........................................................................... 79 Figura 51 Configuraes do projeto BPEL .............................................................80 Figura 52 Diagrama inicial do projeto BPEL ...........................................................81 Figura 53 Configurao de um adaptador escolha do tipo .................................. 82 Figura 54 Arquivo XSD do adaptador de banco de dados ..................................... 83 Figura 55 Trecho do arquivo XSD do adaptador do banco de dados .....................84 Figura 56 Alterao realizada no arquivo XSD do projeto BPEL............................85 Figura 57 Criao de uma atividade Invoke ...........................................................86 Figura 58 Ligao da atividade Invoke com o Partner Link .................................... 87 Figura 59 Diagrama final do projeto BPEL com as atividades e partner link .......... 87 Figura 60 Criando um mapeamento na atividade Transform ................................. 88 Figura 61 Criando a operao de cpia na atividade Transform ............................88 Figura 62 Disponibilizando um processo BPEL no servidor ................................... 89 Figura 63 - Processo BPEL disponibilizado no servidor ............................................ 90 Figura 64 - Resultado do teste do servio INT_FCN_Integracao_Pedidos ............... 90
SUMRIO
1 INTRODUO ....................................................................................................... 10 1.1 Motivao ........................................................................................................... 11 1.2 Objetivo .............................................................................................................. 12 1.2.1 Objetivos especficos.....................................................................................12 1.3 Problema ............................................................................................................ 13 1.4 Contribuies .................................................................................................... 13 1.5 Organizao da monografia ............................................................................. 14 2 FUNDAMENTAO TERICA ............................................................................. 15 2.1 Definio de SOA Service Oriented Architecture ........................................ 15 2.2 Servios Web ..................................................................................................... 18 2.2.1 Introduo a Servios Web ........................................................................... 18 2.2.2 Arquitetura de Servios Web......................................................................... 19 2.3 XML Extensible Markup Language ...............................................................21 2.3.1 XML-RPC ......................................................................................................... 21 2.3.2 SOAP (Protocolo Simples de Acesso a Objetos) ........................................ 22 2.3.2.1 Partes principais da especificao SOAP ................................................. 23 2.3.2.1.1 Especificao envelope SOAP ................................................................... 23 2.3.2.1.2 Regras de codificao de dados ................................................................23 2.3.2.1.3 Convenes RPC .......................................................................................23 2.3.2.2 Elementos da mensagem SOAP ................................................................24 2.3.2.2.1 Elemento Envelope ....................................................................................24 2.3.2.2.2 Elemento Header........................................................................................24 2.3.2.2.3 Elemento Body ...........................................................................................25 2.3.2.2.4 O Elemento Fault........................................................................................25 2.4 WSDL Web Service Description Language .................................................. 25 2.4.1 Elementos WSDL ............................................................................................26 2.4.1.1 Tipos de dados (Types) .............................................................................. 26 2.4.1.2 Servio (Service) .........................................................................................26 2.4.1.3 Porta (Port)................................................................................................... 26 2.4.1.4 Vnculo (Binding) .........................................................................................27 2.4.1.5 Tipo de porta (Port Type) ............................................................................ 27 2.4.1.6 Operao (Operation).................................................................................. 28 2.4.1.7 Mensagem (Message) ................................................................................. 28 2.5 Registro UDDI Universal Description, Discovery and Integration.............. 29 2.6 Princpios de Design .........................................................................................31 2.6.1 Contrato de servio padronizado.................................................................. 33 2.6.2 Baixo acoplamento de servio ...................................................................... 34 2.6.3 Abstrao de servio .....................................................................................36 2.6.4 Reuso de servio ............................................................................................37
2.6.5 Autonomia de servio ....................................................................................38 2.6.6 Independncia de estado do servio ............................................................39 2.6.7 Visibilidade de servio ...................................................................................40 2.6.8 Composio de servio ................................................................................. 42 2.7 Arquitetura de Referncia SOA ........................................................................ 44 2.8 Definio de BPEL - Business Process Execution Language.......................46 3 METODOLOGIA .................................................................................................... 51 4 EXPERIMENTOS E RESULTADOS ...................................................................... 52 4.1 Introduo .......................................................................................................... 52 4.2 Definies da arquitetura de referncia SOA da empresa.............................53 4.3 Materiais e mtodos ..........................................................................................56 4.3.1 Configurao do ambiente ............................................................................ 57 4.3.2 Oracle BPEL Process Manager ..................................................................... 58 4.3.3 Oracle Advanced Queueing - AQ .................................................................. 60 4.4 Implementao de um processo de negcio com BPPEL .............................61 4.4.1 Configurao do ambiente para desenvolvimento...................................... 64 4.4.2. Apresentao dos processos BPEL do estudo de caso ............................72 4.4.2.1 Processo BPEL INT_FCN_Integracao_Pedidos ........................................ 72 4.4.2.2 Processo BPEL INT_Integra_Pedido_RE .................................................. 73 4.4.2.3 Processo BPEL BPELHPS .......................................................................... 74 4.4.2.4 Processo BPEL BPEL_Integra_Pedido_RE............................................... 74 4.4.2.5 Processo BPEL AQ AQ_Integra_Pedido_RE ............................................ 77 4.4.3 Desenvolvimento dos processos BPEL do estudo de caso .......................78 4.4.3.1 Desenvolvimento do projeto BPEL INT_FCN_Integracao_Pedido .......... 79 4.6 Como os conceitos de SOA esto sendo utilizados na empresa ................. 91 5 CONCLUSO ........................................................................................................ 92 6 REFERNCIAS ...................................................................................................... 94
RESUMO As empresas de varejo enfrentam um mercado muito competitivo e uma das maneiras de encarar a concorrncia aumentando o porte da mesma, atravs da aquisio de empresas concorrentes ou com produtos e servios complementares. Isto traz grandes desafios de integrao, tanto das linhas de produtos e servios oferecidos ao mercado, como dos processos e sistemas internos. Neste trabalho so tratados os conceitos, princpios e fundamentos do SOA, sendo demonstradas as prticas para design de servio, orquestrao de servios, arquitetura do SOA e seus principais componentes, dando uma viso prtica e simples do SOA, que ajudar as pessoas a entenderem o SOA e seus fundamentos. Ainda apresentado o padro para orquestrao de servios BPEL (Business Proccess Execution Language) com foco na descrio dos construtores essenciais ao seu uso, dentro dos princpios de design de servios. apresentado como uma grande a empresa de comrcio varejista usou o BPEL, como base para integrar os vrios sistemas, independente da plataforma ou linguagem que foram construdos.
Palavras-chave: SOA. Princpios de design de servios. Fundamentos do SOA. Orquestrao de servios. Arquitetura do SOA. BPEL (Business Proccess Execution Language). Integrao.
10
1 INTRODUO
Business Process Execution Language for Servios web (BPEL4WS) uma linguagem baseada em XML para padronizar a descrio de processos de negcio, bem como a padronizao de interao entre os processos de negcios em um ambiente distribudo. BPEL estende o modelo de interao de servios web e depende da Web Service Description Language (WSDL) para definir as mensagens enviadas e recebidas.
BPEL fornece uma noo de processos abstratos para descrever o comportamento visvel externamente, bem como processos executveis, que pode ser executado por algum intrprete ou compilando-os em uma forma executvel.
BPEL suportado pela maioria dos fornecedores de software, incluindo Oracle, Microsoft, IBM, BEA, SAP, Hewlett-Packard, Siebel, entre outros. A maioria deles j tem produtos que suportam BPEL, outros seguiro em breve. a pedra angular da Arquitetura Orientada a Servios (SOA). (JURIC; MATHEW; SARANG, 2006).
Arquitetura Orientada a Servio (SOA) uma abordagem arquitetural que permite a criao de servios interoperveis que podem facilmente ser reusvel e compartilhados entre aplicaes e sistema legados. SOA consiste em um conjunto composto de servios de negcios alinhados que suportam processo de negcio end-to-end flexvel e dinamicamente reconfigurvel usando descries de servios baseados em interface.
SOA mais do que apenas um conjunto de tecnologias. SOA no est diretamente relacionada com qualquer tecnologia, embora seja mais frequentemente aplicada com servios web. Os servios web so a tecnologia mais adequada para realizao de SOA. Entretanto, o uso de servios web no adequado para a construo de SOA. Temos que usar os servios web de acordo com os conceitos que SOA define.
11
Neste trabalho so tratados os conceitos, princpios e fundamentos do SOA, sendo demonstradas as prticas para design de servio, orquestrao de servios, arquitetura do SOA e seus principais componentes, dando uma viso prtica e simples do SOA, que ajudar as pessoas a entenderem o SOA e seus fundamentos.
Ainda apresentado o padro para orquestrao de servios BPEL (Business Proccess Execution Language) com foco na descrio dos construtores essenciais ao seu uso, dentro dos princpios de design de servios.
apresentado como uma grande a empresa de comrcio varejista usou o BPEL, como base para integrar os vrios sistemas, independente da plataforma ou linguagem que foram construdos.
1.1 Motivao
As empresas de varejo enfrentam um mercado muito competitivo e uma das maneiras de encarar a concorrncia aumentando o porte da mesma, atravs da aquisio de empresas concorrentes ou com produtos e servios complementares. Isto traz grandes desafios de integrao, tanto das linhas de produtos e servios oferecidos ao mercado, como dos processos e sistemas internos, conforme visto na Figura 1. (OASIS, 2007). Figura 1 Motivao para uso do BPEL
Fonte: OASIS, 2007
12
Esse cenrio foi o que motivou esse estudo de caso, onde a empresa estudada utilizou-se da tecnologia BPEL com uso de uma Arquitetura Orientada a Servios (SOA), para integrar seus vrios sistemas internos e de parceiros, aps sua fuso com outras empresas do mesmo setor, criando uma holding que se tornou a terceira maior do pas em seu segmento.
1.2 Objetivo
Apresentar o padro para orquestrao de servios BPEL (Business Proccess Execution Language) focando na descrio dos construtores essenciais ao seu uso, dentro dos princpios de design de servios, descrever como a empresa, objeto do estudo de caso, usou o BPEL, como base para integrar os vrios sistemas, independente da plataforma ou linguagem que foram construdos e como a arquitetura de referncia SOA foi definida para tanto.
1.2.1 Objetivos especficos
Em detalhes, os objetivos desse estudo de caso so:
a) Pesquisar e apresentar conceitos, caractersticas e tecnologias da Arquitetura Orientada a Servios (SOA); b) Pesquisar e apresentar os conceitos, tecnologias e padres relacionados a BPEL e implementao de servios (servios web); c) Descrever os princpios de design de servios; d) Implementar um processo de negcio com BPEL; e) Implementar um processo BPEL como servio (servio web); f) Testar e validar os processos de negcio e servios. g) Definir linguagem/ferramenta para implementao de servios (servios web) e ferramenta para implementao dos processos de negcio (orquestrao); h) Descrever o processo de definio da arquitetura de referncia SOA utilizado pela empresa;
13
1.3 Problema
O que acontece quando grandes e complexas organizaes se unem e necessitam de um alinhamento de sistemas, de culturas e de infra-estrutura de Tecnologia da Informao?
Um dos maiores desafios da TI considerado a integrao, que consome grande parte dos investimentos, para fazer funcionar conjuntamente os vrios sistemas construdos internamente, pacotes adquiridos do mercado, aplicaes herdadas nas aquisies/fuses com outras empresas e outros sistemas externos, podendo ser de clientes, parceiros ou fornecedores. Devem-se integrar sistemas construdos em pocas diferentes, baseados nas mais diversas tecnologias, padres e plataformas, de forma a manter a empresa competitiva, aumentando a produtividade e diminuindo os custos, tudo isso, com uso de mecanismos de controle e monitorao para aferir e garantir atributos como segurana, qualidade, e conformidade com normas do mercado e com acordos de nvel de servio.
1.4 Contribuies
Apresentar definies de SOA, servios e composio de servios. Detalhar os principais elementos utilizados na linguagem padro WS-BPEL. Descrever os princpios de design de servios. Descrever como implementar processos de negcio utilizando BPEL, e, consecutivamente, minimizar as dificuldades relativas aprendizagem da tecnologia.
Desenvolver processos BPEL, para integrao de uma interface de negcio.
Demonstrar em termos tericos e prticos que a utilizao de WS-BPEL em organizaes facilita a integrao de aplicaes, processos de negcio e a integrao entre parceiros de negcio, fazendo uma anlise crtica do padro, com os prs e contras, sem levar em conta a propaganda divulgada pelos entusiastas e principais fornecedores de soluo baseada em WS-BPEL.
14
1.5 Organizao da monografia
Os prximos captulos desse relatrio esto divididos como a seguir. No captulo 2 a definio de SOA e dos principais elementos que suportam essa arquitetura, uma introduo a servios web e sua arquitetura, definio de XML e de seus elementos, definio de WSLD e seus elementos, registro UDDI, princpios de design de servios, arquitetura de referncia SOA e a definio de BPEL (Business Process Execution Language).
No captulo 3 descrita a metodologia de pesquisa usada no trabalho.
No captulo 4 tratamos dos experimentos e resultados, com foco no estudo de caso realizado na empresa.
O captulo 5 responsvel pelas concluses obtidas na pesquisa realizada para elaborao desse trabalho.
15
2 FUNDAMENTAO TERICA
O mercado varejista est em forte crescimento e transformao, enfrentando muita competio e uma das maneiras de encarar a concorrncia aumentando o porte da mesma, atravs da aquisio de empresas concorrentes ou com produtos e servios complementares. Isto traz grandes desafios de integrao, tanto das linhas de produtos e servios oferecidos ao mercado, como dos processos e sistemas internos.
Aplicaes corporativas e sistemas de informao tornaram-se ativos fundamentais das empresas. As empresas contam com eles para ser capaz de realizar operaes de negcios. Sistemas de informao da empresa podem melhorar a eficincia das empresas atravs da automatizao de processos de negcio. O objetivo de quase todas as empresas que os aplicativos que ela usa devem fornecer um suporte abrangente para processos de negcios. Isso significa que os aplicativos devem estar alinhados com os processos de negcio de perto. (JURIC; MATHEW; SARANG, 2006, p. 5).
A arquitetura orientada a servios (SOA Service Oriented Architecture) uma abordagem que ajuda os sistemas a permanecerem escalveis e flexveis enquanto crescem, e que ajuda a aproximar a rea de negcio a TI. (JOSUTTIS, 2009).
2.1 Definio de SOA Service Oriented Architecture
SOA um meio para organizar as solues que promovem o reuso, crescimento e interoperabilidade, ele prprio no uma soluo para os problemas do domnio, mas um paradigma para esse fim. (MACKENZIE, 2006).
Para falarmos de SOA, temos antes que conceituar servios, que segundo o modelo de referncia de SOA da OASIS, um servio um mecanismo para habilitar o acesso a um conjunto de uma ou mais competncias, onde o acesso provido
16
usando uma interface que descrita e consistentemente exercitada com restries e polticas como especificados pela descrio de servio. (MACKENZIE, 2006).
De uma perspectiva de negcio, um servio uma funo executvel de negcios, de uma perspectiva tcnica, um servio uma pea que encapsula uma funcionalidade de uma aplicao, o qual construdo utilizando de forma padronizada.
Dentro do contexto de SOA, (JOSUTTIS, 2009), resume servio da seguinte forma:
a) Um servio a realizao da TI de alguma funcionalidade de negcio independente; b) Quanto aos aspectos de negcio, um servio esconde detalhes tcnicos, permitindo que pessoas de negcio lidem com ele; c) Em termos tcnicos, um servio uma interface para mltiplas mensagens que so trocadas entre fornecedor(es) e consumidor(es); d) Servio uma interface bem definida ou contrato, sendo o contrato um acordo individual de um fornecedor e um consumidor, que inclui seus aspectos funcionais como SLAs; e) Existem vrios atributos que os servios podem e/ou devem ter, de acordo com suas definies. Esses atributos dependem da situao, os servios quase sempre tero atributos e devem ser classificados de acordo com os mesmos.
SOA um paradigma de arquitetura para lidar com processos corporativos distribudos em um grande cenrio de sistemas heterogneos existentes e novos que esto sobre o controle de diferentes proprietrios. Servios, interoperabilidade e acoplamento fraco, so os principais conceitos tcnicos de SOA. Infra-estrutura, arquitetura e processos, incluindo governana, so os ingredientes chave de SOA.
A interao com o servio deve se basear somente nas diretrizes, no esquema e nos comportamentos baseados no contrato de um servio. O contrato de
17
um servio geralmente definido usando-se o WSDL, e contratos para agregaes de servios podem ser definidos usando-se o BPEL que, por sua vez, usa o WSDL para cada servio agregado.
SOA no uma tecnologia especfica nem uma bala de prata, SOA apropriada em certos momentos e em outros no. (JOSUTTIS, 2009).
Os Servios web so um jeito possvel para realizar os aspectos de infraestruturas de SOA. A utilizao de Servios web frequentemente recomendada porque parece que eles esto comeando a se estabelecer como uma tecnologia padro. (JOSUTTIS, 2009).
Resumindo SOA (SANTOS, 2009):
a) um estilo de arquitetura; b) orientada a servios; c) baseado em padres abertos e padres de mercado; d) Prov flexibilidade para responder as mudanas e agilidade para atender as novas demandas de negcio e oportunidade; e) Reduz o tempo de entrega de novos servios para atender o negcio; f) Aumenta a interoperabilidade entre sistemas legados e novos; g) Tende a melhoria de processos; h) Aumenta o reuso de servios (ativos), maximizando o valor dos ativos; i) Aumenta a estabilidade na operao de TI, com maior tolerncia a falhas; j) Reduz custos da Operao de TI; k) uma mudana de paradigma, de alinhamento para integrao, partindo de alinhamento entre o negcio e a TI para a integrao entre o negcio e a TI.
18
2.2 Servios Web 2.2.1 Introduo a Servios Web Um servio web qualquer servio que est disponvel atravs da Internet , usa um sistema de mensagens padronizado em XML e no est ligada a qualquer sistema operacional ou linguagem de programao, conforme visto na Figura 2. (CERAMI, 2002). Figura 2 - Figura Um servio web bsico
Fonte CERAMI, 2002
Existem vrias alternativas para enviar mensagens XML (Figura 3). Pode-se usar XML Remote Procedure Calls (XML- RPC) ou SOAP, ou voc pode simplesmente usar HTTP GET/POST e passar o documento XML. (CERAMI, 2002). Figura 3 Mensagens XML para servios web
Fonte CERAMI, 2002
19
CERAMI (2002) resume como sendo um servio web completo, qualquer servio que:
a) Est disponvel na rede privada (intranet) ou Internet; b) Utiliza um sistema de mensagens XML padronizado; c) No est vinculado a qualquer sistema operacional ou linguagem de programao; d) auto-descrio atravs de uma gramtica XML comum; e) detectvel atravs de um mecanismo simples encontrar.
2.2.2 Arquitetura de Servios Web Existem duas maneiras de se avaliar a arquitetura de servios web. A primeira examinando os papis de cada ator do servio web individualmente (Figura 4), o segundo pela pilha de protocolo de servio (Figura 5). Figura 4 - Papis servios web
Fonte Adaptado de CERAMI, 2002
Existem trs funes principais dentro da arquitetura de servios web (Figura 4):
a) Provedor de servios, que implementa e torna-o disponvel; b) Consumidor de servios, que o utiliza por meio de uma conexo de rede e envia uma solicitao XML; c) Registro de servios, onde se publica e se pode encontrar servios.
20
Na pilha de protocolo de servios, atualmente existem quatro camadas principais (Figura 5): Figura 5 Pilha de protocolos
Servio de transporte: Esta camada responsvel pelo transporte de mensagens entre as aplicaes. Esta camada inclui o protocolo de transferncia de hipertexto (HTTP), Simple Mail Transfer Protocol (SMTP), protocolo de transferncia de arquivos (FTP), e os protocolos mais recentes, como Blocos Extensible Exchange Protocol (BEEP).
Mensagens XML: Esta camada responsvel pela codificao de mensagens em um formato XML comum, de modo que as mensagens podem ser compreendidos em cada extremidade. Nela inclui XML-RPC e SOAP.
Descrio do servio: Esta camada responsvel por descrever a interface pblica para um servio web especfico. A descrio do servio feita atravs do Servio web Description Language (WSDL).
Descoberta de servios: Esta camada responsvel por centralizar servios em um registro comum, proporcionando a funcionalidade "publicar/encontrar" de maneira fcil. A descoberta de servios tratada via Universal Description, Discovery and Integration (UDDI).
21
2.3 XML Extensible Markup Language Permite que os sistemas de computadores diferentes compartilhem dados com mais facilidade, independentemente do sistema operacional ou linguagem de programao, sendo suportado por grande variedade de aplicaes. O XML um formato simples e flexvel para representar informao estruturada. Existem dois principais candidatos de mensagens XML: XML-RPC e SOAP. (CERAMI, 2002).
2.3.1 XML-RPC XML-RPC um protocolo simples que usa mensagens XML para executar chamadas remotas. Os pedidos so codificados em XML e enviado via HTTP POST.
Respostas XML so incorporadas no corpo da resposta HTTP. Como o XMLRPC independente de plataforma, isso permite que diversas aplicaes se comuniquem, por exemplo, um cliente Java pode falar XML-RPC para um servidor Perl. (CERAMI, 2002).
XML-RPC a maneira mais fcil de comear com servios web. Em muitos aspectos, mais simples do que o SOAP e mais fcil de adotar. No entanto, ao contrrio do SOAP, XML-RPC no tem correspondente descrio gramatical de servio. Isso evita a invocao automtica de servios XML-RPC, que, conforme CERAMI, 2002, um ingrediente-chave para permitir a integrao de aplicativos just-in-time.
XML-RPC surgiu no incio de 1998, quando foi publicado pela UserLand Software e inicialmente aplicada no seu produto Frontier. Ele se manteve praticamente estvel desde ento. (CERAMI, 2002).
Em um universo de programao aparentemente obcecado com objetos, XML-RPC pode parecer muito limitado para muitas aplicaes. Enquanto XML-RPC, certamente, tem limitaes, sua simplicidade inerente d algumas vantagens significativas quando os desenvolvedores precisam integrar sistemas de tipos muito diferentes. A seleo de tipos de dados do XML-RPC relativamente pequena, mas
22
oferece granularidade suficiente para que os desenvolvedores possam expressar informaes em qualquer linguagem de programao. (CERAMI, 2002).
XML-RPC usado em duas reas principais, que se sobrepem s vezes. Integradores de sistemas e programadores de construo de sistemas distribudos costumam usar XML-RPC como cdigo de cola, ligando diferentes partes dentro de uma rede privada. Usando XML-RPC, os desenvolvedores podem se concentrar nas interfaces entre os sistemas, e no o protocolo usado para conectar as interfaces. (CERAMI, 2002).
Desenvolvedores de servios pblicos tambm podem usar XML-RPC, definindo uma interface e implementando na linguagem de sua escolha. Uma vez que o servio publicado na Web, qualquer cliente capaz de consumir XML-RPC pode se conectar ao servio e os desenvolvedores podem criar seus prprios aplicativos que usam esse servio. (CERAMI, 2002).
2.3.2 SOAP (Protocolo Simples de Acesso a Objetos) SOAP um protocolo baseado em XML para troca de informaes entre computadores. Embora o SOAP possa ser usado em uma variedade de sistemas de mensagens, e pode ser entregue atravs de uma variedade de protocolos de transporte, o foco principal do SOAP so chamadas remotas transportadas via HTTP. Portanto, o SOAP permite que os aplicativos clientes se conectem facilmente a servios remotos e invoquem mtodos remotos. (CERAMI, 2002).
Outras estruturas, incluindo CORBA, DCOM e Java RMI, fornecem funcionalidades semelhantes para SOAP, mas as mensagens SOAP so inteiramente escritas em XML e so, portanto, independente de plataforma e, portanto, permite a comunicao entre diversas aplicaes. Por exemplo, o cliente Java SOAP rodando em Linux ou um cliente Perl rodando em Solaris podem se conectar a um servidor SOAP Microsoft rodando em Windows 2000. (CERAMI, 2002).
23
2.3.2.1 Partes principais da especificao SOAP A especificao SOAP define trs partes principais (CERAMI, 2002):
2.3.2.1.1 Especificao envelope SOAP O XML SOAP Envelope define regras especficas para encapsular dados que esto sendo transferidos entre computadores. Isso inclui dados especficos do aplicativo, como o nome do mtodo a chamar, parmetros de mtodos ou retorno de valores. Ele tambm pode incluir informaes sobre quem deve processar o contedo do envelope e, em caso de erro, como codificar mensagens de erro.
2.3.2.1.2 Regras de codificao de dados Para troca de dados, os computadores devem chegar a acordo sobre as regras para a codificao de tipos de dados especficos. Portanto, o SOAP inclui seu prprio conjunto de convenes para codificao de tipos de dados. A maioria dessas convenes so baseadas na especificao do esquema XML W3C.
2.3.2.1.3 Convenes RPC SOAP pode ser usada em uma variedade de sistemas de mensagens, incluindo mensagem de se sentido nico e de mensagens em dois sentidos. Para mensagens nos dois sentidos, SOAP define uma simples conveno para representar chamadas de procedimento remoto e respostas. Isso permite que um aplicativo cliente especifique um nome de mtodo remoto, incluindo qualquer nmero de parmetros, e receba uma resposta do servidor.
24
2.3.2.2 Elementos da mensagem SOAP Cada mensagem tem um elemento SOAP obrigatrio no envelope, um elemento de cabealho opcional, e um elemento de corpo obrigatrio. (Figura 6). Cada um destes elementos tem associado um conjunto de regras. Figura 6 Estrutura da mensagem SOAP
2.3.2.2.1 Elemento Envelope O elemento Envelope o elemento raiz da mensagem SOAP. Este elemento define o documento XML como uma mensagem SOAP.
2.3.2.2.2 Elemento Header O elemento Header contem informaes especificas do aplicativo da mensagem SOAP. um elemento opcional, se ele estiver presente deve ser o primeiro elemento filho do elemento Envelope
Atributo mustUnderstand - O atributo mustUnderstand pode ser usado para indicar se uma entrada de cabealho obrigatria ou opcional para o destinatrio processar.
25
Se adicionar mustUnderstand = "1" para um elemento filho do elemento Header indica que o receptor deve reconhecer o elemento ao processar o Header. Se o receptor no reconhece o elemento ir falhar ao processar o Header. O mustUnderstand aceita 0 ou 1.
Atributo Actor - Uma mensagem SOAP pode viajar do emissor ao receptor passando por diferentes pontos ao longo do caminho at seu ultimo ponto. No entanto uma ou mais partes da mensagem no so destinadas ao ultimo ponto. O Atributo Actor usado pelo Header para especificar este ponto.
2.3.2.2.3 Elemento Body O elemento Body contm a mensagem SOAP pretendida que o usurio espera. Elementos filhos do elemento Body podem conter namespace.
2.3.2.2.4 O Elemento Fault O elemento Fault do SOAP o elemento de falha onde possui erros e informaes de status de uma mensagem SOAP. Este elemento opcional e quando estiver presente deve aparecer como um elemento filho do elemento Body.
2.4 WSDL Web Service Description Language A Web Service Description Language (WSDL) uma linguagem baseada em XML utilizada para descrever Servios web funcionando como um contrato do servio. Trata-se de um documento escrito em XML que alm de descrever o servio, especifica como acess-lo e quais as operaes ou mtodos disponveis. (WIKPEDIA, 2013).
Foi submetido ao W3C por Ariba, IBM e Microsoft em maro de 2001. Um documento WSDL define servios como colees de terminais de rede ou portas. Em WSDL, a definio abstrata de endpoints e mensagens separado de sua implantao concreta de rede ou de ligaes de formato de dados. Isto permite a reutilizao de definies abstratas: message, que so descries abstratas dos
26
dados sendo trocados, e os port types que so colees abstratas de operaes. O protocolo concreto e especificaes de formatos de dados para um port type particular constitui uma ligao reutilizvel. Uma porta est definida associando um endereo de rede com uma ligao reutilizvel e um conjunto de portas definidas em um servio. (WC3, 2001).
2.4.1 Elementos WSDL Um documento WSDL usam os seguintes elementos na definio de servios de rede: 2.4.1.1 Tipos de dados (Types) Um recipiente para as definies de tipo de dados usando algum tipo de sistema (como XSD) (Figura 7).
Figura 7 Elementos WSDL: Types
Fonte: Oracle JDeveloper
2.4.1.2 Servio (Service) Pode ser visto como um container para conjunto de funes de sistema que foram expostos a protocolo baseado em web (Figura 8). 2.4.1.3 Porta (Port) No nada alm da definio do endereo ou ponto de conexo para o Servio web. representado tipicamente por uma URL simples com HTTP (Figura 8).
27
Figura 8 Elementos WSDL: Service e Port
Fonte: Criado pelo Autor pelo software Oracle JDeveloper
2.4.1.4 Vnculo (Binding) Especifica a interface, define o estilo de SOAP binding (RPC ou Document) e transporte (protocolo SOAP). Sees de binding tambm definem as operaes (Figura 9).
Figura 9 Elementos WSDL: Binding
2.4.1.5 Tipo de porta (Port Type) O elemento <portType> define um servio web, as operaes que podem ser executadas, e as mensagens trocadas para executar a operao (Figura 10).
28
2.4.1.6 Operao (Operation) Cada operao pode ser comparada a um mtodo ou chamada de funo em uma linguagem de programao tradicional. Aqui as aes SOAP so definidas e o tipo de mensagem codificado (Figura 10). Figura 10 Elementos WSDL: PortType e Operation
2.4.1.7 Mensagem (Message) Tipicamente, uma mensagem corresponde a uma operao. A mensagem contm as informaes necessrias para executar a operao (Figura 11). Figura 11 Elementos WSDL: Message
29
2.5 Registro UDDI Universal Description, Discovery and Integration Na sua essncia, UDDI consiste de duas partes. Primeiro, UDDI uma especificao tcnica para a construo de um diretrio distribudo de empresas e servios na web. Os dados so armazenados em um formato XML especfico, e a especificao UDDI inclui detalhes da API para a busca de dados existentes e publicao de novos dados. Em segundo lugar, o registro de empresas UDDI uma implementao totalmente operacional da especificao UDDI. Lanado em Maio de 2001 pela Microsoft e IBM, o registro UDDI agora permite a qualquer pessoa pesquisar dados UDDI existentes. Ele tambm permite qualquer empresa registrar os seus servios. (CERAMI, 2002).
UDDI um repositrio para descrever, descobrir e integrar servios. Esses servios no so necessariamente Web, ou at mesmo no esto relacionados a computadores, so estruturados de maneira semelhante a um catlogo telefnico:
a) Pginas brancas; b) Pginas amarelas; c) Pginas verdes; d) tModel.
Pginas Brancas, inclui informaes gerais sobre uma empresa especfica. Por exemplo, o nome da empresa, descrio do negcio, informaes de contato, endereo e nmeros de telefone. Tambm pode incluir identificadores de negcios nicas. (CERAMI, 2002).
Pginas amarelas, contm dados gerais de classificao para a empresa ou o servio oferecido. Por exemplo, estes dados podem incluir a indstria de produtos, ou classificao de servios e entidades de negcios baseada em taxonomiaspadro. (CERAMI, 2002).
Pginas verdes, uma categoria que contm informaes tcnicas sobre um servio web, em nvel de detalhe suficiente para se escrever uma aplicao que use esse servio. (CERAMI, 2002).
30
tModels so usados primariamente para fornecer indicaes a especificaes tcnicas externas. Por exemplo, o bindingTemplate para o XMethods de um servio qualquer, fornece informaes sobre onde acessar a ligao SOAP, mas no fornece informaes sobre como interagir com ele. O elemento tModel preenche esta lacuna, fornecendo um ponteiro para uma especificao externa. (CERAMI, 2002)
tModels so de vital importncia, pois permitem identificar as especificaes tcnicas implementadas. Mais importante, se duas empresas fazem referncia ao mesmo tModel, voc pode ter certeza de que ambas as empresas implementam a mesma especificao.
A especificao UDDI define:
a) APIs SOAP utilizadas para publicar e obter informaes de um registro UDDI; b) esquemas XML do modelo de dados do registro e do formato das mensagens SOAP; c) definies WSDL das APIs SOAP; d) definies de registro UDDI (modelos tcnicos - tModels) de diversos sistemas de identificao e categorizao, que podem ser utilizados para identificar e categorizar registros UDDI.
31
2.6 Princpios de Design Um princpio uma prtica generalizada e aceita pelo mercado, algo que feito ou promovido para um objetivo comum. Um princpio de design pode ser comparado a uma boa prtica, porque ambos propem um meio para alcanar algo com base na experincia ou aceitao por todo o mercado. (EARL, 2005).
Um princpio de design representa uma orientao altamente recomendvel para dar forma lgica de soluo, da maneira e objetivos certos. Esses objetos so associados no estabelecimento das caractersticas da estrutura, como resultado da aplicao do princpio.
Figura 12 Aplicao dos Princpios de Design
Fonte: Adaptado de EARL, 2005
Conforme visto na Figura 12, a aplicao repetida dos princpios de design aumenta a quantidade de caractersticas comuns do design. Nesse caso, o acoplamento de A e B foi diminudo, como indicado por uma reduo dos pontos de conexo. (EARL, 2005).
32
Pode-se ter um princpio to fundamental como aquele que indica que a lgica da soluo deve ser distribuda. Esse princpio pode ser aplicado de forma que a lgica da soluo seja dividida em unidades distribudas individualmente, estabelecendo-se caractersticas distintas da lgica que sero formadas por componentes.
Existem oito princpios de design (Figura 13), documentados em SOA: Principles of Service (EARL, 2005), que estabelecem regras e orientaes para ajudar a determinar como, exatamente, a lgica da soluo ser decomposta em unidades e em forma de sistema distribudos. Ao estudarmos esses princpios, nos so revelados caractersticas de construo dessas unidades, permitindo classificlas quanto qualidade dos servios capazes de cumprir a viso e objetivos associados a SOA e computao orientada a servios. A aplicao desses oito princpios resulta na realizao de caractersticas de design bem especficas. (EARL, 2005). Figura 13 Os oito Princpios de Design
33
Conforme visto na Figura 13, cinco desses oito princpios de design estabelecem caractersticas concretas do design de servio enquanto os outros trs princpios de design alm de introduzirem essas mesmas caractersticas, agem mais como influncias reguladoras. (EARL, 2005).
2.6.1 Contrato de servio padronizado
O contrato o artefato principal da arquitetura de um servio, que estabelece os termos pelos quais um servio ser visto, provendo todas as restries tcnicas, requisitos e informaes que o dono do servio desejar publicar.
Comparando-se com orientao a objetos, assume-se que um contrato est para um servio da mesma forma que uma interface pblica est para uma classe.
O contrato de um servio pode ser descrito atravs de um conjunto de documentos (Figura 14). Quando falamos de servios web baseados em SOAP, por exemplo, temos o WSDL. Essas definies servem descritivos tcnicos, que colaboram para o consumo do servio.
Os contratos dos servios devem manter alguma conformidade com padres utilizados na elaborao dos demais servios do inventrio.
Ao planejar um servio, devemos iniciar o projeto pela definio cuidadosa do contrato. Figura 14 Contrato de servios
34
Na Figura 14, vemos os possveis documentos de descrio de servios que podem compor um contrato de servio implementado como Servio web. O subconjunto desses documentos, que estabelece a interface tcnica do servio, pode ser considerado o contrato de servios tcnicos. (EARL, 2005).
Dependendo de como o contrato de servio projetado, ele influencia diretamente na maneira em alguns dos mais importantes princpios da orientao a servios podem ser realizados: a) Afetando a qualidade atingvel do baixo acoplamento de servio; b) Afetando a extenso atingvel da abstrao de servio; c) Estabelecendo convenes que afetam o potencial atingvel da capacidade de reuso do servio; d) Introduzindo convenes de design de contrato que podem aprimorar ou forar a visibilidade do servio; e) Podendo introduzir requisitos de contedo de contrato que suporta a composio de servios.
2.6.2 Baixo acoplamento de servio
Este princpio enfatiza a reduo de acoplamento entre as partes de uma soluo, especialmente quando comparadas a forma como aplicativos so tradicionalmente projetados (Figura 15). Especificamente, o acoplamento fraco garantido pelo isolamento da implementao de um servio atravs de seu contrato.
Sempre que possvel, o contrato deve ocultar a lgica do servio, a tecnologia e a implementao.
Ao planejar um servio, principalmente o seu contrato, devemos baixar ao mximo o acoplamento
35
Figura 15 Acoplamento de servio
O acoplamento de servios acaba apoiando e afetando vrios aspectos de outros princpios:
a) podendo influenciar os padres de design para contratos de servios padronizados; b) enfatizando algumas formas de abstrao de servio; c) estabelecendo uma forma complementar da centralizao que maximiza oportunidades para capacidade de reuso de servio; d) aumentando os nveis de autonomia de servios atingveis pela autonomia de servio; e) regulando metainformaes publicadas para o uso da visibilidade de servio; f) ajudando a impedir dependncias que inibem a composio de servio;
36
2.6.3 Abstrao de servio
Dentro deste contexto, abstrao que nenhuma informao sobre um servio fique pblica, sem que seja realmente necessria para quem venha usar esse servio (Figura 16).
A abstrao de um servio garante o seu reuso. Para aumentar as possibilidades de acoplamento, mais informaes devem ser publicadas sobre esse servio.
Apenas informaes essenciais devem estar contidas nos contratos, todas as informaes sobre o servio, devem se limitar ao que estiver publicado nos contratos.
Sempre se deve manter o maior nvel de abstrao ao se planejar um servio. Figura 16 Abstrao de servio
A abstrao de servio influencia diretamente o contrato de servios padronizados e o princpio de baixo acoplamento de servio, modelando a aplicao de outros princpios, contrapondo-se a certas tendncias de publicar mais contedo em apoio a seus objetivos especficos: a) podendo influenciar, ainda, padres de design usados para contrato de servio padronizado;
37
b) regulando a qualidade e a natureza de metainformaes publicadas em suporte : reuso de servios, composio de servios e visibilidade de servios; c) podendo influenciar tambm, a extenso do atingvel baixo acoplamento de servio;
2.6.4 Reuso de servio
importante planejar os servios para que eles possam ser utilizados para mais do que um nico propsito (Figura 17).
Planejar um servio de forma que este seja til em mais de um contexto possibilita um melhor ROI.
Priorizar a reutilizao implica em um cuidado maior com os demais princpios. Um servio ser mais reutilizvel na medida em que tiver menor acoplamento, maior abstrao, autonomia e suporte a composio.
Ao planejar um servio, garanta que ele seja til em outros cenrios. Figura 17 Reuso de servio
38
O reuso de servio um princpio fundamental para a orientao a servios, que afeta todos os outros princpios de diferentes maneiras: a) estimulando o design de contratos altamente genricos de contrato de servios padronizados b) desafiando a abstrao de servios; c) enfatizando o baixo acoplamento de servios, a visibilidade de servio, a autonomia de servio, a independncia de estado de servio e a composio de servio.
2.6.5 Autonomia de servio
Autonomia representada pela capacidade de um servio de funcionar independentemente (Figura 18). Manter um servio autnomo permite que ele possa atuar de forma independente, sem qualquer necessidade de aprovao ou acompanhamento.
Quanto maior for autonomia de um servio quanto a seu ambiente, mais fcil ser sua manuteno e evoluo. Ao planejar um servio, pense em alternativas que diminuam suas dependncias externas.
Figura 18 Autonomia de servio
39
Ao estabelecer nveis significativos de autonomia de servios, vrios outros princpios so suportados: a) estimulando a normalizao do contrato padro de servio padronizado; b) suportando diretamente o baixo acoplamento de servio; c) podendo influenciar o nvel de abstrao de servio; d) aumentando o potencial de capacidade de reuso de servio, de independncia de reuso de servio e de composio de servio.
2.6.6 Independncia de estado do servio
Quando falamos em estados, estamos nos referindo a condio de uma coisa. Em um paralelo com objetos, o estado corresponde ao conjunto de valores de seus atributos.
O problema mais evidente com estados a dificuldade de proporcionar escalabilidade horizontal. Servios que preservam estados o fazem para tentar proporcionar transaes de muitas etapas (muitas interaes) (Figura 19).
Servios que lembram precisam gerenciar a transio de estados.
A necessidade de manter e gerenciar transies entre estados nos obrigam optar por apenas dois dos seguintes atributos: consistncia, disponibilidade e tolerncia a particionamento (escalabilidade horizontal).
Ao planejar um servio, evite estados favorecendo escalabilidade.
40
Figura 19 Independncia de estado
A independncia de estado do servio afeta outros princpios: a) aumentando a escalabilidade de servio e a disponibilidade no suporte de capacidade de reuso de servio; b) podendo estabelecer caractersticas de design que podem tanto suportar quanto impedir a autonomia de servio.
2.6.7 Visibilidade de servio
De nada adianta ter um servio se ningum sabe que esse servio est disponvel.
Suporte a descoberta implica na capacidade de determinar quais requisitos de automao precisamos atender para poder utilizar um servio que exista em um inventrio.
Os servios devem prover meta-informao suficiente para que possam ser efetivamente descobertos e interpretados. O suporte adequado a descoberta potencializa que um servio seja utilizado sem que seja necessrio envolvimento direto entre os times de desenvolvimento (Figura 20).
41
Garantir que um servio possa ser descoberto evidencia o compromisso com a reusabilidade.
Ao planejar um servio, garanta que ele possa ser descoberto.
Figura 20 Visibilidade de servio
A aplicao desse princpio d clareza e comunicao a uma empresa orientada a servios, podendo suportar e afetar outras partes da orientao a servios:
a) influenciando padres de design e contedo para o contrato de servio padronizado; b) precisando ser balanceado em relao abstrao de servio; c) suportando a capacidade de reuso por toda a empresa; d) suportando, tambm, a criao e evoluo da composio de servios.
42
2.6.8 Composio de servio
Servios
devem
ser
participantes
eficazes
de
composio,
independentemente do tamanho e da complexidade da composio.
A capacidade de combinar as capacidades de diferentes servios para resolver problemas maiores um dos fundamentos do SOA e da computao distribuda (Figura 21).
Poder combinar diversos servios para criar um novo servio completo (fundamento de SOA).
A capacidade de composio autoriza melhor gesto de granularidade.
Ao planejar um servio, considere favorecer composio como alternativa para gesto da granularidade.
Figura 21 Composio de servio
43
A composio de servios pode modelar a aplicao de todos os outros princpios: a) influenciando padres de design para o contrato de servio padronizado; b) introduzindo a considerao membros de composio ocultos que requer posicionamento cuidadoso da abstrao de servio; c) enfatizando o baixo acoplamento de servio; d) introduzindo consideraes especiais porque uma forma sofisticada de capacidade de reuso de servio; e) amplificando a necessidade de altos nveis de autonomia de servio; f) requerendo alta padronizao da independncia de estado de servio; g) estimulando os metadados centrados na composio em suporte visibilidade do servio.
44
2.7 Arquitetura de Referncia SOA A OASIS - Advanced Open Standards of the Information Societe (2006), descreve a arquitetura de referncia SOA como um framework que visa facilitar o entendimento dos relacionamentos significativos de um ambiente, permitindo o desenvolvimento de arquiteturas especficas utilizando padres consistentes ou especificaes de suporte para este ambiente. Um modelo de referncia constitudo por um conjunto de conceitos unificados, axiomas e as relaes dentro de um domnio de problema particular. independente de normas, tecnologias, ou outros detalhes que sejam especficos de uma plataforma.
Como ilustrao do relacionamento entre um modelo de referncia e as arquiteturas que podem derivar de um modelo deste tipo, considere o que poderia estar envolvido na modelagem de "construo de casas". Sabemos que as reas de alimentao, de higiene e espaos para descanso so reas importantes dentro de uma casa. Existem relaes entre estes espaos bem como regras que devem ser seguidas para sua construo, por exemplo, pode haver necessidade de separao fsica entre as ares de higiene e de alimentao.
De acordo com OASIS (2006), o papel da arquitetura de referncia seria identificar solues abstratas para problemas comuns para um domnio de aplicaes. Um padro geral de construo que atenda s necessidades de harmonizao da construo de espaos. Este conceito pode ser utilizado como base para construo de uma arquitetura de referncia.
O propsito de um modelo de referncia fornecer um quadro conceitual unificado que possa ser utilizado de forma coerente em diferentes ambientes de implementao, podendo ser de uso na modelagem de solues especficas (OASIS, 2006).
A Figura 22 mostra como um modelo de referncia para SOA refere-se a outros sistemas distribudos com caractersticas arquiteturais semelhantes. O objetivo deste modelo estabelecer uma referncia para definir a essncia das caractersticas de arquiteturas orientadas a servio, emergindo com um vocabulrio
45
e conceitos para um melhor entendimento de SOA. Estes modelos de arquitetura de referncia fornecem elementos normativos bastantes relevantes para
implementao de SOA em uma organizao (OASIS, 2006). Figura 22 Como o modelo de referncia se relaciona com outros trabalhos
Fonte: Adaptado de OASIS 2008
46
2.8 Definio de BPEL - Business Process Execution Language
BPEL (Business Process Execution Language for Servios web - Linguagem de Execuo de Processos de Negcio), tambm conhecida como WS-BPEL ou BPEL4WS uma linguagem usada para desenvolver composio, orquestrao e coordenao de servios web, fornecendo um rico vocabulrio para expressar o comportamento dos processos de negcio (JURIC, 2006).
Conforme visto na Figura 23, o BPEL4WS foi concebido em julho de 2002, com a liberao da especificao BPEL4WS 1.0, que foi um esforo conjunto entre as empresas IBM, Microsoft e BEA System Inc. Nesse documento foi proposta uma linguagem de orquestrao, como o WSFL (Servio web Flow Language) da IBM e a especificao XLANG da Microsoft (EARL, 2005).
Menos de um ano depois, em maio de 2003, foi liberada a verso 1.1 da especificao BPEL4WS, com contribuies das empresas SAP e Siebel Systems. Nessa nova verso, foram implementados vrios mecanismos de orquestrao compatveis, comercialmente, com BPEL4WS. Antes de ser liberada, a
especificao foi submetida ao comit tcnico da OASIS, para que pudesse ser desenvolvida em padro aberto oficial. Figura 23 Histrico da evoluo do BPEL
Fonte: Adaptado de JURIC; MATHEW; SARANG, 2006
47
Com BPEL podemos definir processos de negcio simples e complexos. At certo ponto, BPEL semelhante a outras linguagens de programao tradicionais. Oferece construes, como loops, desvios, variveis, atribuies, etc., que nos permitem definir processos de negcio de uma forma algortmica. BPEL uma linguagem especializada focada na definio de processos de negcios. Portanto, por um lado, oferece construes, que fazem a definio de processos relativamente simples, por outro lado, menos complexa do que as linguagens de programao tradicionais, o que simplifica a aprendizagem.
O mais importante na construo BPEL est relacionado com a invocao de servios web. BPEL faz com que seja fcil invocar operaes de servios web de forma sncrona ou assncrona.
As funcionalidades mais importantes de WSBPEL (JURIC, 2006) esto listadas logo abaixo:
a) descrever a lgica dos processos de negcio atravs da composio de servios; b) tratar as invocaes de operaes de modo sncrono ou assncrono; c) c) invocar servios de maneira sequencial ou paralela. d) prover mecanismos para tratar erros durante a invocao de servios; e) manter atividades de longa durao (transacionais), assim como as interromper; f) reiniciar uma composio que foi interrompida ou apresentou erros; g) agendar a execuo de atividades e definir a ordem em que elas iro executar.
BPEL incorpora tecnologias como a Servios web Description Language (WSDL), XML e comunicaes SOAP. Um processo WS-BPEL pode ser exposto como um servio definido por WSDL e pode ser invocado como qualquer outro Servio web. Alm disso, WS-BPEL considera que todo Servio web externo esteja includo em uma composio de Servios web, utilizando um contrato de servio WSDL.
48
O BPEL foi criado para orquestrar e coordenar os Servios web de forma que eles possam atuar no comportamento transacional e colaborativo, quem usou um processo de negcio definido em WS-BPEL no tem a cincia que na verdade est usando vrios servios para realizar uma determinada operao.
Dependendo dos requisitos, a composio de servios pode tratar processos privado ou pblico, para a qual so usados dois termos: Orquestrao e Coreografia.
Na orquestrao (Figura 24), um processo central (que pode ser outro servio web) assume o controle sobre os servios web envolvidos e coordena a execuo de operaes diferentes sobre os servios web envolvidos na operao. Isto feito de acordo com os requisitos da orquestrao. Os servios Web envolvidos no sabem (e no precisa saber) que eles esto envolvidos em uma composio e que fazem parte de um processo de negcio superior. Apenas o coordenador central da orquestrao sabe disso, ento a orquestrao centralizado com definies explcitas de operaes e a ordem de invocao de servios web. Orquestrao normalmente usado em processos de negcios privados, esse esquema representado na figura abaixo: Figura 24 Orquestrao de Processo BPEL
Fonte: JURIC; MATHEW; SARANG, 2006
A coreografia (Figura 25), por outro lado no se baseia em um coordenador central. Em vez disso, cada servio web envolvidos na coreografia sabe exatamente quando executar suas operaes e com quem interagir. Coreografia um esforo
49
colaborativo focado na troca de mensagens nos processos de negcios pblicos. Todos os participantes da coreografia precisam estar ciente do processo de negcio, operaes a executar, a troca de mensagens, e o momento de troca de mensagens. Figura 25 Coreografia de Processo BPEL
Fonte: JURIC; MATHEW; SARANG, 2006
A orquestrao tem as seguintes vantagens:
a) Sabemos exatamente quem responsvel pela execuo de todo o processo de negcios. b) Ns podemos incorporar servios web, mesmo aqueles que no esto cientes de que eles so uma parte de um processo de negcio. c) Ns tambm podemos fornecer cenrios alternativos em caso de falhas.
A viso geral do funcionamento do WS-BPEL segue com uma requisio a um processo, sendo este feito atravs de um XML com dois envelopes, o mais externo do SOAP e o interno segue a especificao de como efetuar a requisio.
A resposta da requisio pode ser sncrona, bloqueando o cliente que est usando o processo, at que o processo termine e retorne um resultado para quem o chamou, ou assncrono, que no bloqueia o cliente, em vez disso, usa um retorno de chamada para retornar o resultado, caso haja. Os processos assncronos, na sua
50
maioria, so usados para processos de longa durao, e os sncronos so usados para processos que retornam um resultado em um tempo relativamente curto.
A estrutura geral de um Processo de Negcio especificado em WS-BPEL formada por quatro sees: PartnerLinks, Variables, FaultHandlers e Activities, conforme descritas a seguir:
a) PartnerLinks: seo que define os diferentes parceiros (partes envolvidas) que interagem com o Processo de Negcio durante toda sua execuo. Eles so usados para identificar a funcionalidade que deve ser oferecida por cada servio parceiro. As ligaes de parceiros (partner link) devem estar associadas a um tipo de ligao entre parceiros (partner link type) definidos na especificao de servios Web em WSDL; b) Variables: seo que define as variveis de dados usadas pelo Processo de Negcio. As definies so feitas em termos de tipos de mensagem WSDL, elementos ou tipos simples de esquemas XML. Elas so usadas para manter os dados de estado e o histrico do processo com base nas mensagens trocadas. As variveis devem estar associadas a tipos de mensagens (messages) definidos na especificao WSDL; c) FaultHandlers: seo que contm os tratadores de falhas que definem as atividades a ser executadas em resposta s falhas resultantes da invocao de servios de avaliao e de aprovao; d) Activities: seo que contm a descrio do comportamento normal para a execuo do Processo de Negcio, sendo bsicas, que correspondem a uma invocao de uma operao WSDL de um servio ou estruturadas, que definem orquestrao das atividades bsicas.
51
3 METODOLOGIA
Foram levantadas informaes em livros, artigos, e na Internet, para os temas tratados, sendo avaliados e adaptados quando possvel viso e experincia do autor. O autor utilizou-se tambm da instalao e experimentao com ferramentas de modelagem de processos comerciais disponveis na empresa objeto do estudo de caso.
O estudo est dividido nas seguintes fases:
a) Estudo da base terica de Arquitetura Orientada a Servios - SOA e Business Proccess Execution Language BPEL; b) Descrio do processo de definio da arquitetura de referncia SOA utilizado pela empresa; c) Definio da linguagem e ferramenta para implementao de servios (servios web) e ferramenta para implementao dos processos de negcio (orquestrao); d) Implementao de um processo de negcio com BPEL; e) Implementao de um processo BPEL como servio (servio web); f) Teste e validao dos processos de negcio e servios; g) Descrio de como os conceitos de SOA esto sendo utilizados na organizao objeto do estudo de caso.
52
4 EXPERIMENTOS E RESULTADOS 4.1 Introduo Como o mercado de varejo de eletroeletrnicos um mercado muito agressivo, em que as maiores redes conseguem melhores negociaes com os fornecedores, podendo, a partir da, fazer uma poltica de preos para alavancar as vendas, a empresa, objeto desse estudo de caso, resolveu se juntar a outra rede do mesmo ramo, do Estado da Bahia, que considerada uma das maiores da regio nordeste do Brasil.
A partir daqui iremos tratar a empresa, objeto do estudo de caso, como Empresa-1 e a empresa da Bahia como Empresa-2, isso ir facilitar o entendimento do sentido das integraes.
Por uma questo estratgica, as empresas resolveram que quando um produto de um determinado pedido de vendas da Empresa-1 pudesse ser atendido pelo centro de distribuio da Empresa-2, seria feito uma reserva de produto no estoque desse centro de distribuio e o pedido de vendas seria integrado para a base de dados de retaguarda da Empresa-2.
Foi decidido que todas as transaes deveriam ocorrer utilizando bases de dados Oracle como origem/destino dos dados e que BPEL seria o padro para as integraes.
Todas as interaes dos sistemas da Empresa-2 seriam independentes, ou seja, mesmo que os processos BPEL estejam inoperantes, as funes dos sistemas seriam executadas normalmente no gerando impactos nas operaes da Empresa-2.
Foi criado um modelo padro de integrao, para atender os requisitos e servir como um workflow, conforme ilustrado na Figura 26.
53
4.2 Definies da arquitetura de referncia SOA da empresa
Figura 26 Modelo padro de Integrao
Fonte: Criado pelo Autor
Como foi ilustrado na Figura 26, um modelo padro de integrao foi criado. Nesse modelo os itens a e b so pertinentes somente para as transaes iniciadas a partir do sistema de vendas, j dos itens c ao j, um modelo genrico para toda integrao que necessite de um controle das transaes. Esse modelo genrico explicado em mais detalhes a seguir:
a) base de dados origem (item c da Figura 26). base de dados do sistema de origem das informaes que sero integradas. Banco de dados Oracle; b) tabela do sistema (item d da Figura 26). Tabela de banco de dados que contm as informaes do sistema de origem responsveis pela
54
inicializao da integrao. Esta tabela inicia o processo de integrao atravs de uma trigger que ser detalhada adiante; c) trigger de enfileiramento (item e da Figura 26). Trigger vinculada tabela do sistema. Essa trigger deve conter toda a regra de negcio responsvel pela inicializao do processo de integrao. Nessa trigger deve-se observar o uso de nomenclatura padro, de tratamento de excees e de tratamento para no permitir duplicidade na tabela de fila; d) tabela de fila (item f da Figura 26). Tabela de banco de dados contendo a chave da informao que ser integrada. Essa tabela tambm, responsvel por manter todo o histrico relacionada integrao daquele registro. Nessa tabela deve-se observar o uso de nomenclatura padro e deve conter alguns campos obrigatrios, conforme ser apresentado no Quadro 1; e) trigger vinculada tabela de fila (item g da Figura 26). Esta trigger responsvel pelo enfileiramento (enqueue) do registro na fila de mensagem Oracle AQ. Quando o registro for enfileirado na fila de mensagem com sucesso o campo FLAG_STATUS da tabela de fila deve ser alterado para "R" e o campo MENSAGEM_ERRO para "REGISTRO ENFILEIRADO NO AQ", caso ocorra erro no enfileiramento o campo FLAG_STATUS da tabela de fila deve ser alterado para "E" e o campo MENSAGEM_ERRO para "ERRO AO ENFILEIRAR NO AQ." concatenado com a string de erro capturada pela trigger. Nessa trigger deve-se observar o uso de nomenclatura padro e de tratamento de excees; f) fila de mensagem AQ (item h da Figura 26). Fila de mensagem Oracle AQ, consumida pelo processo BPEL para integrao do registro da tabela de fila A mensagem na fila Oracle AQ deve conter a chave da informao que ser integrada, mais o ndice primrio da tabela de fila, para posterior controle da integrao; g) processos BPEL (item i da Figura 26). Deve ser criado um processo BPEL com caractersticas mo nica (one-way) que ser responsvel por consumir a mensagem na fila Oracle AQ. Esse processo aps consumir a mensagem ir chamar um novo processo BPEL assncrono, que far a
55
orquestrao da integrao, da base de dados de origem at a base de dados de destino. Quadro 1 Campos obrigatrios da tabela de fila
NOME DO CAMPO NRO_SEQ_FILA CIKEY FLAG_STATUS TIPO number number char(1) DESCRIO ndice primrio da tabela - sequencial identificador da instncia do processo BPEL status do registro: U - registro no integrado, aciona trigger de enfileiramento no AQ; R - registro enfileirado na fila AQ; E erro ao enfileirar registro na fila AQ; P - registro em processamento pelo processo BPEL; C - registro integrado com sucesso; H - ocorreu algum erro na integrao do registro. MENSAGEM_ERRO varchar2(250) mensagem de concluso da integrao, seja de sucesso ou do erro ocorrido. DT_INCLUSAO DT_ALTERACAO date date data de incluso do registro na tabela de fila data de alterao do registro na tabela de fila
Para atender a este modelo padro de integrao, foi necessrio definir uma arquitetura de referncia SOA.
Em abril de 2010, o Open Group publicou uma Arquitetura de Referncia SOA (Figura 27), que visa fornece diretriz e opes para fazer arquitetura, design e implementao de decises quando da adoo de uma abordagem orientada a servios de tecnologia da informao. Seu objetivo ser um modelo para a criao ou avaliao de arquitetura. Alm disso, ele fornece insights, padres e os blocos de construo para a integrao de elementos fundamentais de SOA em uma empresa ou arquitetura da soluo. (OPENGROUP, 2010).
56
A empresa sendo um cliente Oracle e possuir as licenas dos softwares necessrios para a adoo de SOA, resolveu usar os produtos do Oracle SOA Suite 10g nessa arquitetura de referncia, na camada de integrao, da seguinte forma:
a) Interfaces de consumo - Aplicativos Desktop, Web Services, Sistema Web, Portal B2B; b) Processos de Negcio - BPEL e Enterprise Service Bus; c) Servios - desenvolvidos usando o Oracle BPEL; d) Servio de Componentes - Oracle SOA Enterprise Manager; e) Sistemas Operacionais - Oracle AS. Figura 27 Arquitetura de referncia SOA The Open Group
Fonte: OPENGROUP, 2010
4.3 Materiais e mtodos Todos os experimentos realizados neste trabalho foram executados na empresa do estudo de caso.
57
4.3.1 Configurao do ambiente Para o experimento foi usado um servidor Linux, com processador Intel Xeon CPU X5570 Processor 8380, quad-core com frequncia de 2,93 GHz e com 8.192 Kb de cache por ncleo, 8 GB de memria RAM, com disco de 50 GB, sendo 20 GB para sistema operacional e 30 GB para dados.
O sistema operacional do servidor Linux o Red Hat Enterprise Linux Server release 3 (Tikanga), kernel 2.6.18-128.el5PAE.
Nesse servidor foi instalado o Oracle SOA Suite 10.1.3.1, com aplicao do patch 10.1.3.4.
Os componentes instalados no Oracle SOA Suite foram:
a) OPMN - Oracle Process Manager, responsvel pelo gerenciamento das instncias OAS; b) Oracle HTTP Server - Servidor web baseado em apache com suporte J2EE e XML; c) OC4J - Oracle Containers for J2EE - Um container menos carregado do J2EE (semelhante ao TomCat); d) ASCONTROL - Application Server Control - console de gerenciamento das instncias e/ou cluster OAS; e) BPEL - Componentes de interpretao dos modelos BPM com um console de administrao e um de monitoramento; f) ESB - Enterprise Service Bus - container dos fluxos de processo com um console de gerenciamento; g) WSM - Web Services Manager - componentes de publicao de Web Services com um console de gerenciamento; h) Rule Author - Editor de Regras de Negcio.
Para desenvolvimento dos pocessos BPEL, foi usado a IDE (Integrated Development Environment) JDeveloper 10.1.3.4. A ferramenta JDeveloper um ambiente de desenvolvimento integrado gratuito da Oracle que oferece
58
funcionalidades para o desenvolvimento em Java, XML, SQL e PL/SQL, HTML, JavaScript, BPEL e PHP. Esse IDE cobre todo o ciclo de desenvolvimento desde a anlise at a codificao, a manuteno, a otimizao e a implantao.
A IDE PL/SQL Developer foi utilizada para desenvolvimento de programas (functions, procedures, triggers, packages) armazenados no banco de dados Oracle. Atravs dele podemos construir todo o mdulo executado no servidor de uma aplicao cliente-servidor. uma ferramenta grfica que auxilia muito nas tarefas de desenvolvimento e tambm de administrao de um banco de dados Oracle.
4.3.2 Oracle BPEL Process Manager O Oracle BPEL Process Manager facilita o desenvolvimento de aplicaes baseadas em SOA pela composio de servios sncronos e assncronos em fluxo de processo BPEL.
Segundo seu fornecedor, a ferramenta Oracle BPEL Process Manager prov uma soluo confivel e de fcil uso pelo desenvolvedor para desenhar, disponibilizar e gerenciar processos de negcio BPEL.
A arquitetura do BPEL Process Manager tem os seguintes elementos, conforme apresentada na Figura 28 (OBPM, 2006): a) JDeveloper um ambiente de desenvolvimento integrado que oferece funcionalidades para o desenvolvimento em Java, XML, SQL e PL/SQL, HTML, JavaScript, BPEL e PHP, cobrindo todo o ciclo de desenvolvimento desde a anlise at a codificao, a manuteno, a otimizao e a implantao; b) o BPEL designer a ferramenta grfica para elaborao dos processos BPEL; c) Core BPEL Engine prov a implementao de um servidor BPEL; d) Dehydrate Oracle DB corresponde a um SGBD Oracle responsvel por armazenar o estado de processos de longa durao;
59
e) o built-in integration services disponibiliza recursos avanados de conectividade e transformao. Estes recursos incluem suporte para transformaes XSLT e XQuery bem como bindings para sistemas legado atravs de adaptadores JCA e protocolos nativos; f) O framework extensvel WSDL binding (DOS WSIF1 - Web Services Invocation Framework) permite a conectividade com protocolos e formatos de mensagem diferente de SOAP. Ligaes so disponvel para Java, JMS, email, JCA, HTTP GET e POST e muitos outros protocolos permitindo a conectividade simples para centenas de sistemas de back -end; g) BPEL Console prov a interface para gesto (por exemplo, monitoramento visual da execuo de um processo BPEL, auditoria), administrao e depurao de processos disponibilizados no servidor BPEL. Figura 28 Arquitetura do Oracle BPEL Process Manager
Fonte: OBPM, 2006
60
4.3.3 Oracle Advanced Queueing - AQ Oracle Advanced Queueing fornece a funcionalidade de enfileiramento de mensagens do banco de dados integrado. Advanced Queueing aproveita as funes do banco de dados Oracle para que as mensagens possam ser armazenadas persistentemente, propagada entre filas em diferentes mquinas e bancos de dados e transmitidas usando Oracle Net Services, HTTP(s) e SMTP.
O Oracle Advanced Queueing implementado em tabelas de banco de dados, com isso, todos os benefcios operacionais de alta disponibilidade, escalabilidade e confiabilidade so aplicveis aos dados de fila. As caractersticas padro de banco de dados, tais como recuperao e segurana so suportados em Advanced Queueing e as tabelas de fila podem ser importadas e exportadas. Podese tambm usar o desenvolvimento de banco de dados e ferramentas de gesto, tais como Oracle Enterprise Manager para monitorar as filas. (BRADSHAW, 2002).
Figura 29 Advanced Queueing em ambientes de aplicativos integrados
Fonte: BRADSHAW,2002
61
A Figura 29 mostra Advanced Queueing em ambientes de aplicativos integrados. Advanced Queueing fornece a funcionalidade de gerenciamento de mensagens e comunicao assncrona necessria para a integrao de aplicativos. Em um ambiente integrado, o servidor de banco de dados Oracle age como o eixo, com mensagens que viaja ao longo dos raios e as aplicaes e os utilizadores na extremidade dos raios.
Usando o Oracle Net Services, as mensagens podem ser trocadas entre o cliente e o servidor de banco de dados Oracle ou entre dois servidores Oracle. Oracle Net Services tambm propaga mensagens de uma fila de Oracle para outro. Ou, podem-se executar operaes de enfileiramento avanado atravs da Internet usando protocolos de transporte, tais como HTTP, HTTPS, ou SMTP. Neste caso, o cliente, um aplicativo de usurio ou Internet, produz mensagens XML estruturado. Durante a propagao atravs da Internet, servidores Oracle comunicam usando XML estruturado tambm. 4.4 Implementao de um processo de negcio com BPPEL Vrios servios foram identificados para a realizao do processo de integrao entre as lojas da Empresa-1 e o centro de distribuio da Empresa-2.
Alguns pontos geraram mudanas em operaes do sistema de frente de lojas da Empresa-1 e no sistema de retaguarda da Empresa-2, responsvel pela operao dos depsitos.
Os servios foram moldados para que os processos BPEL realizassem o menor nmero de operaes com os dados, dessa forma algumas aplicaes foram criadas para que as informaes fossem utilizadas/trafegadas apenas entre bancos de dados Oracle.
Para esse estudo de caso vamos tratar da integrao da interface de pedidos de vendas realizados nas lojas da Empresa-1 que devem ser integrados na retaguarda da Empresa-2.
62
Figura 30 Fluxo de integrao do pedido de vendas
A integrao de pedidos de vendas seguiu o modelo padro de integrao, definido pela empresa, conforme visto na Figura 30 e detalhado a seguir:
a) um processo no banco de dados de origem grava um registro na tabela de fila MV_FILA_INTEGRACAO_PEDIDO, contendo a chave necessria para buscar os dados do pedido a ser integrado, quando um registro na tabela MV_FILA_INTEGRACAO_PEDIDO for inserido ou o campo
IND_INTEGRADO, do registro dessa tabela, for alterado para 0 (zero), acionado a trigger TRG_AQ_FILA_INTEGRACAO_PEDIDO, a trigger
TRG_AQ_FILA_INTEGRACAO_PEDIDO enfileira um registro na fila de mensagens AQ AQ_Integra_Pedido_RE; b) um processo BPEL assncrono do tipo one-way consome da fila AQ AQ_Integra_Pedido_RE e chama o processo BPEL assncrono de
orquestrao BPEL_Integra_Pedido_RE;
63
c) o processo BPEL assncrono BPEL_INTEGRA_PEDIDO_RE, orquestra a chamada de outros processos BPEL como servios, para integrao dos dados do pedido de vendas; d) o processo BPEL sncrono INT_Integra_Pedido_RE chamado pelo processo BPEL assncrono BPEL_Integra_Pedido_RE; e) e. ele faz uma chamada na procedure SEND_PEDIDO, na base de dados de origem; f) que retorna uma mensagem para o processo BPEL contendo os parmetros a serem passados na chamada do processo BPEL sncrono
INT_Fcn_Integracao_Pedidos; g) o processo BPEL sncrono INT_FCN_Integracao_Pedidos chamado pelo processo BPEL de orquestrao BPEL_Integra_Pedido_RE e faz uma chamada na procedure FCN_INTEGRACAO_PEDIDOS, na base de dados de destino, passando como parmetro de entrada o retorno do servio INT_Integra_Pedido_RE h) a funo FCN_Integracao_Pedido integra os dados do pedido de vendas na base de dados de destino e retorna mensagem de sucesso ou de erro; i) o processo BPEL sncrono BPELHPS chamado pelo processo BPEL de orquestrao BPEL_Integra_Pedido_RE; j) e altera o status da tabela de fila, MV_FILA_INTEGRACAO_PEDIDO, na base de origem, de acordo com o retorno do processo BPEL
INT_FCN_Integracao_Pedidos.
Para a integrao de pedidos de vendas foram criados os seguintes processos BPEL:
a) AQ AQ_Integra_Pedido_RE; b) BPEL_Integra_Pedido_RE; c) INT_Integra_Pedido_RE; d) INT_FCN_Integracao_Pedidos; e) BPELHPS.
Esses processos sero mais detalhados adiante.
64
4.4.1 Configurao do ambiente para desenvolvimento Foi usado a IDE JDeveloper 10.1.3.4, para construir os processos BPEL, pois ela permite um ambiente de desenvolvimento integrado oferecendo todas as funcionalidades para o criao de processos BPEL, alm de cobrir todo o ciclo de desenvolvimento desde a anlise at a codificao, a manuteno, a otimizao e a implantao dos processos.
A configurao do ambiente de desenvolvimento feita da seguinte forma:
a) abrir a IDE JDeveloper 10.1.3.4; b) aps abrir a IDE, clicar na guia a guia Connections Navigator, depois clicar com o boto direito em Application Server e em seguida clicar em New Application Server Connection (Figura 31); c) na guia Type Informar um nome para a Conexo (Figura 32); d) na guia Authentication Informar o usurio e senha para conexo (Figura 33). Essas informaes devem ser solicitadas ao administrador do sistema. e) na guia connection, marcar a opo Single Instance, informar o nome do host, a porta OPMN e o nome da instncia (Figura 34); f) na guia Test clicar em Test Connection (Figura 35). Caso tudo esteja correto o Status ser sucess. Caso ocorra algum erro rever os passos b a f; g) em connections Navigator clique com o boto direito sobre a pasta Integration Server, depois clique em New Integration Server Connection (Figura 36); h) na guia Name informe um nome para o Integration Server (Figura 37); i) Na guia Connection escolha o servidor de aplicao configurado nos passos b a f anteriores, informe o nmero da porta HTTP do servidor, deixe o resto como est (Figura 38); j) para criar uma conexo com banco de dados, no painel Connection Navigator clique com o boto direito sobre a pasta Database, clique em New Database Connection (Figura 40), na prxima tela que abrir clique em prximo.
65
k) na guia Test Connection clique no boto Test Connection. Caso tudo esteja configurado corretamente o Status ser igual ao da Figura 39; l) Informe um nome para a conexo, escolha o Connection Type (para conexo Oracle escolha Oracle (JDBC)) e clique em prximo (Figura 41); m) Informe o nome do usurio e a senha para conexo e clique em Prximo (Figura 42); n) Informe o Host Name, a porta JDBC, o SID ou o Service Name, ou caso queira usar Custom JDBC Url use a = seguinte sintaxe: = jdbc:oracle:thin:@(DESCRIPTION =(ADDRESS (PROTOCOL
TCP)(HOST = xxx.xxx.xxx.xxx)(PORT = XXXX))(CONNECT_DATA = (SERVER = DEDICATED)(SERVICE_NAME = XXXX))). Clique em prximo e teste as configuraes da conexo (Figura 43);
Figura 31 Criando um servidor de aplicao no JDeveloper
Fonte: Criado pelo Autor com software Oracle JDeveloper
66
Figura 32 - Configurando o servidor de aplicao apelido do servidor
Figura 33 - Configurando o servidor de aplicao dados do usurio
67
Figura 34 - Configurando o servidor de aplicao dados da conexo
Figura 35 Testando a configurao do servidor de aplicao
68
Figura 36 Criando um servidor de integrao no JDeveloper
Figura 37 Definindo o nome do servidor de integrao
69
Figura 38 Ligando o servidor de integrao ao servidor de aplicao
Figura 39 Testando a conexo com o servidor de integrao
70
Figura 40 Criando uma conexo de banco de dados no JDeveloper
Figura 41 Definindo o nome e tipo da conexo
71
Figura 42 Informando usurio de senha para a conexo de banco de dados
Figura 43 Especificando detalhes da conexo com o banco de dados
72
4.4.2. Apresentao dos processos BPEL do estudo de caso O objetivo dessa integrao enviar os pedidos de vendas da Empresa-1 para o sistema de retaguarda da Empresa-2.
Aps ter configurado o ambiente de desenvolvimento com a IDE JDeveloper 10.1.3.4, foram construdos os processos BPEL. 4.4.2.1 Processo BPEL INT_FCN_Integracao_Pedidos Figura 44 Processo BPEL INT_FCN_Integracao_Pedidos
Na
Figura
44
temos
diagrama
do
processo
BPEL
INT_FCN_Integracao_Pedido. Esse servio foi implementado como um processo BPEL sncrono e responsvel por integrar um novo pedido de vendas na base do sistema de retaguarda da Empresa-2. A integrao do pedido feita atravs da funo de banco de dados Oracle FCN_Integracao_Pedidos, na base de dados do sistema de retaguarda da Empresa-2.
73
Foi definido um modelo cannico para essa interface de integrao. A funo FCN_Integracao_Pedidos tem como parmetro de entrada um object type do Oracle contendo os dados referentes ao cabealho do pedido, lista dos itens do pedido, endereo do cliente do pedido dentre outras informaes necessrias para que um pedido de vendas seja inserido na base do sistema de retaguarda da Empresa-2. Essa assinatura usada como parmetro de entrada do processo BPEL INT_FCN_Integracao_Pedido e tem como retorno uma string, que em caso de erro exibe a mensagem do erro capturado pela funo. 4.4.2.2 Processo BPEL INT_Integra_Pedido_RE Figura 45 Processo BPEL INT_INTEGRA_PEDIDO_RE
Na
Figura
45
temos
diagrama
do
processo
BPEL
INT_INTEGRA_PEDIDO_RE, esse servio foi implementado como um processo BPEL sncrono e responsvel por buscar os dados do pedido de vendas da base do sistema da Empresa-1. Tem como parmetro de entrada o nmero do pedido e o nmero da loja de vendas do pedido.
74
Esses dados so usados para chamar uma procedure do oracle na base de dados do sistema de vendas da Empresa-1 (pkg_integra_pedido.send_pedido). Essa procedure retorna um object type do oracle contendo os dados referentes ao cabealho do pedido, lista dos itens do pedido, endereo do cliente, conforme o que esperado na entrada do servio INT_FCN_INTEGRACAO_PEDIDO.
4.4.2.3 Processo BPEL BPELHPS Figura 46 Processo BPEL BPELHPS
O processo BPEL BPELHPS (Figura 46), foi implementado como um servio web e utilizado em todos os processos de orquestrao que usam uma fila de mensagem para integrao das interfaces de negcio da Empresa-1 para a Empresa-2. responsvel por manter o status da integrao do processo aps ser executado, com sucesso ou erro, podendo, em caso de erro, corrigir e reenviar. 4.4.2.4 Processo BPEL BPEL_Integra_Pedido_RE Esse processo BPEL assncrono o responsvel pela orquestrao da integrao do pedido de vendas desde a base de dados da Empresa-1 at a base de dados da Empresa-2.
75
Figura 47 Processo BPEL BPEL_Integra_Pedido_RE
Como visto na Figura 47, esse processo BPEL faz a orquestrao da integrao. Ele tem como parmetro de entrada:
a) NRO_PEDIDO, referente ao nmero do pedido de vendas; b) NRO_LOJA, referente ao nmero da loja do pedido de vendas, esses dois primeiros parmetros formam a chave do pedido; c) NRO_SEQ_FILA, referente chave primria da tabela de fila de integrao do pedido, na base de dados do sistema da Empresa-1
(MV_FILA_INTEGRACAO_PEDIDO).
76
O primeiro servio chamado pelo processo BPEL BPEL_Integra_Pedido_RE o INT_Integra_Pedido_RE, que tem entrada e retorno conforme descrito no item 4.4.2.2 e responsvel por buscar os dados da base do sistema de vendas da Empresa-1
Em seguida chamado o servio INT_FCN_Integracao_Pedidos, responsvel por integrar os dados do pedido de vendas na base do sistema de retaguarda da Empresa-2. Ele recebe os dados retornados pelo servio INT_Integra_Pedido_RE.
Como usado um modelo cannico, sendo um facilitador para troca de dados entre servios, o retorno do servio INT_Integra_Pedido_RE igual entrada do servio INT_FCN_Integracao_Pedidos.
Se o servio INT_FCN_Integracao_Pedidos concluir com sucesso, ento chamado o servio BPELHPS que recebe os parmetros de entrada:
a) Status = 1; b) Idtabela = 3 (referente a tabela MV_FILA_INTEGRACAO_PEDIDO); c) Cikey = id da instncia do processo BPEL BPEL_Integra_Pedido_RE, retornado pelo servidor que processou o servio; d) Nroseqfila = parmetro de entrada NRO_SEQ_FILA do processo BPEL BPEL_Integra_pedido_RE; e) Mensagem = Integrado com sucesso.
Caso ocorra alguma falha, em qualquer ponto da integrao, levantado uma exceo e o servio BPELHPS tambm chamado passando os seguintes parmetros:
a) Status = 2; b) Idtabela = 3 (referente a tabela MV_FILA_INTEGRACAO_PEDIDO); c) Cikey = id da instncia do processo BPEL BPEL_Integra_Pedido_RE, retornado pelo servidor que processou o servio;
77
d) Nroseqfila = parmetro de entrada NRO_SEQ_FILA do processo BPEL BPEL_Integra_pedido_RE; e) Mensagem = string de falha capturada pelo processo BPEL
BPEL_Integra_Pedido_RE.
4.4.2.5 Processo BPEL AQ AQ_Integra_Pedido_RE Figura 48 Processo BPEL AQ_integra_Pedido_RE
Esse processo BPEL, ilustrado na Figura 48, responsvel por consumir os dados da fila de mensagem AQ e chamar o processo BPEL de orquestrao BPEL_Integra_Pedido_RE. Ele foi implementado como um servio one-way.
Esse foi o ltimo processo BPEL construdo e implantado, porque ele quem inicia automaticamente a integrao, atravs de um evento que o consumo da fila de mensagem AQ.
78
4.4.3 Desenvolvimento dos processos BPEL do estudo de caso Um projeto BPEL criado no JDeveloper dentro de uma aplicao. Para criar uma aplicao no JDeveloper basta clicar no menu File, depois em New, escolher a categoria Geral e o item Aplicao e clicar no boto OK.
Ser aberto uma nova janela. Deve ser informado o nome da aplicao e o nome do diretrio, conforme a Figura 49.
Figura 49 Criando uma aplicao no JDeveloper
Aps essa etapa os projetos BPEL j podem ser criados dentro da aplicao.
Para exemplificar a construo dos projetos, ser detalhado desenvolvimento do processo BPEL INT_FCN_Integracao_Pedido, em todas as suas fases at a implantao e teste. Todos os processos BPEL foram descritos no item 4.4.2 desse trabalho.
79
4.4.3.1 Desenvolvimento do projeto BPEL INT_FCN_Integracao_Pedido Para a construo de um novo projeto BPEL no JDeveloper, tem que clicar com o boto direito do mouse no nome da aplicao, em seguida clicar em New Project e na janela que se abre escolher BPEL Process Project e clicar no boto OK, conforme a Figura 50. Figura 50 Criar um projeto BPEL
aberta uma nova janela onde deve ser informado o nome e o namespace do projeto, com opes de se escolher o local de criao do projeto e um dentre vrios templates, tanto dafaults, quanto definidos pelo usurio a partir de outro projeto (Figura 51).
80
Figura 51 Configuraes do projeto BPEL
Nesse projeto foi escolhido o template Synchronous Bpel Process, para criao de um processo BPEL sncrono.
Depois de configurar essas propriedades do projeto, clica no boto Finish e na prxima janela aberta, clica-se tambm no boto Finish.
Ser criado o projeto e exibido o diagrama do projeto BPEL contendo um Partner Link, na rea de services do diagrama, nomeado como client, um receive e um input, ligados ao Partner Link client, conforme visto na Figura 52.
81
Figura 52 Diagrama inicial do projeto BPEL
Como o objetivo desse projeto BPEL fazer a chamada de uma funo do Oracle, na base de dados dos sistema de retaguarda da Empresa-2, foi criado um novo Partner Link na rea Services do diagrama. Para isso foram seguidos os seguintes passos:
a) Clicar com o boto direito na rea Services do diagrama do projeto; b) Clicar em Create Partner Link...; c) Na janela que se abre na guia General clicar no boto Define Adapter Service...; d) Clicar no boto Prximo, na prxima janela; e) Ser exibido uma lista de adaptadores nativos do JDeveloper; f) Escolher Database Adapter e clicar no boto Prximo (Figura 53); g) Na prxima janela informar em Service Name o nome do adaptador e clicar no boto Prximo; h) Ser aberta uma nova janela onde dever escolher a conexo de banco de dados. Essa conexo configurada conforme descrito no item 4.4.1
82
Configurao do ambiente para desenvolvimento, letras "k" a "n". Nesse ponto importante observar o campo JNDI Name, o valor nesse campo deve corresponder a configurao realizada no Enterprise Manager do Application Server Control do Oracle Soa Suite. Isso necessrio, porque em tempo de desenvolvimento a configurao do banco de dados geralmente diferente da configurao em tempo de execuo, que pode apontar para base de dados diferente do desenvolvimento. Essa configurao da JNDI feita no servidor e no no JDeveloper; i) Na prxima etapa, escolher Call a Stored Procedure or Function e no boto Prximo, pois esse adaptador chama uma funo do banco de dados Oracle. j) Na janela que se abre, clicar no boto Browse; k) Ser aberta uma janela com a lista de todas stores porocedures acessveis para aquela conexo de banco de dados. Escolher a funo
FCN_INTEGRACAO_PEDIDO e clicar no boto OK; l) Clicar no boto Finish na prxima janela.
Figura 53 Configurao de um adaptador escolha do tipo
83
Depois de seguir esses passos o adaptador de banco de dados que chama a funo do Oracle FCN_INTEGRACAO_PEDIDO est concludo.
Quando um adaptador de banco criado, automaticamente gerado um arquivo XSD (XML Schema Definition), conforme visto no diagrama da Figura 54.
Figura 54 Arquivo XSD do adaptador de banco de dados
Esse arquivo XSD, ser usado como parmetros de entrada e sada do processo BPEL, pois o servio ter a mesma assinatura da funo
FCN_INTEGRACAO_PEDIDO.
Para isso foi copiado todo trecho mostrado na Figura 55, do arquivo XSD do adaptador de banco e foi colado no arquivo XSD do projeto BPEL
INT_FCN_Integracao_Pedidos.
84
Figura 55 Trecho do arquivo XSD do adaptador do banco de dados
O arquivo XSD do projeto BPEL, foi alterado, tambm, incluindo os elementos do arquivo XSD do adaptador de banco de dados, InputParameters e OutputParameters nos elementos ProcessRequest e ProcessResponse do XSD do projeto BPEL. E para fechar as alteraes, foi inserida uma linha no elemento schema (xmlns:db) do arquivo XSD, para referenciar aos tipos complexos inseridos no arquivo, conforme visto na Figura 56.
85
Figura 56 Alterao realizada no arquivo XSD do projeto BPEL
Depois de configurar o arquivo XSD do projeto BPEL para ter a mesma assinatura do adaptador de banco de dados que chama a funo do Oracle, vamos para os prximos passos:
a) Agora devemos associar uma atividade Invoke ao PartnerLink, clicando com o boto direito do mouse no receive do projeto e escolher Insert After, Activities, Invoke (Figura 57). b) Depois de adicionar a atividade invoke d um duplo clique sobre ela, na janela que se abre escolha o Partner Link. Clicando no desenho da lanterna ser exibida a lista de todos os partners links do projeto (Figura 58); c) Escolher a operao a ser chamada (Figura 58); d) Especificar variveis de entrada e variveis de sada que representam as variveis passada e recebida do adaptador chamado (Figura 58). Pode-se criar novas variveis ou utilizar variveis existentes. Para o caso de se ter criado novas variveis, necessrio incluir no diagrama atividades assign com o intuito de realizar as transformaes necessrias para copiar os dados do processo para as variveis que sero utilizadas na invocao do adaptador; e) Como os parmetros de entrada e de retorno do servio, so idnticos aos parmetros de entrada e retorno do adaptador de banco de dados, inserir
86
uma atividade transform para copiar os dados da entrada do servio para a entrada do adaptador e outra atividade transform para copiar os dados do retorno do adaptador para o retorno do servio (Figura 59); f) Dar um duplo clique na primeira atividade transform e escolher na varivel de origem inputVariable, correspondente a varivel de entrada do servio e em varivel de destino, FCN_INTEGRACAO_PEDIDOS_InputVariable, correspondente a varivel de entrada do adaptador de banco de dados, nomear o arquivo de mapa e clicar no boto Create Mapping (Figura 60); g) Ligar os elementos da origem aos elementos do destino (Figura 61); h) Salvar o arquivo; i) Repetir os passos f a h para a outra atividade transform sendo que a varivel de origem ser FCN_INTEGRACAO_PEDIDOS_InputVariable e a varivel de destino ser OutputVariable.
Figura 57 Criao de uma atividade Invoke
87
Figura 58 Ligao da atividade Invoke com o Partner Link
Figura 59 Diagrama final do projeto BPEL com as atividades e partner link
88
Figura 60 Criando um mapeamento na atividade Transform
Figura 61 Criando a operao de cpia na atividade Transform
89
Para um servio ser utilizado, necessrio compil-lo e instal-lo (deploy) no servidor BPEL, seguindo os seguintes passos:
a) A publicao de um processo BPEL pode ser feita atravs do JDeveloper ou pelo console do servidor BPEL. Usamos a primeira opo, com o JDeveloper, por j termos configurado o ambiente de desenvolvimento, conforme descrito no item 4.4.1 Configurao do ambiente para desenvolvimento. Na guia Applications clicar com o boto direito do mouse sobre o nome do projeto BPEL; b) Clicar em Deploy (Figura 62); c) Escolher o servidor na lista que exibida (Figura 62); d) Escolher o domnio no servidor e clicar sobre o nome dele (Figura 62).
Figura 62 Disponibilizando um processo BPEL no servidor
90
Conforme vimos na Figura 63, o processo foi disponibilizado no servidor e j est pronto para ser usado. Vimos o endereo da localizao do WSDL, bem como do ponto final. Figura 63 - Processo BPEL disponibilizado no servidor
Fonte: Criado pelo Autor pela captura de tela do Oracle Enterprise Manager 10g
Para testar o servio:
a) copiar o endereo da localizao do ponto final do servio; b) abrir um navegador; c) colar o endereo na barra de endereos do navegador; d) preencher os parmetros de entrada do servio; e) clicar no boto Invoke.
O resultado do teste exibido como uma mensagem SOAP, conforme visto na Figura 64. Figura 64 - Resultado do teste do servio INT_FCN_Integracao_Pedidos
91
4.6 Como os conceitos de SOA esto sendo utilizados na empresa A empresa objeto desse estudo de caso tem hoje em seu portflio de servios cerca de 500 processos desenvolvidos em BPEL, divididos em 18 projetos diferentes. Toda integrao entre os vrios sistemas feita atravs de BPEL.
Os processos de governana de SOA criados na empresa foram os seguintes:
a) capacitao das equipes em SOA; b) identificao dos possveis servios a serem criados do ponto de vista corporativo (portflio de servios); c) desenvolvimento de novos servios; d) anlise do aproveitamento dos servios existentes; e) modificao/evoluo dos servios existentes; f) desativao de servios; g) garantia do desempenho e estabilidade dos servios em operao; h) estimular/recompensar o reuso e a criao de novos servios que tragam ganhos; i) planejamento das iniciativas SOA; j) gesto de projetos SOA; k) gesto da inovao; l) definio de metodologia e padres; m) gesto dos acordos de nvel de servio (SLA).
Foram criados sistemas de monitoramento das integraes, bem como sistema para documentao dos processos.
O que se percebe que SOA uma realidade na empresa e que todos os processos de negcio da mesma dependem disso para o melhor funcionamento.
Esse modelo ser usado em todas as empresas adquiridas para o grupo.
92
5 CONCLUSO
Neste trabalho procurou-se tratar os conceitos, princpios e fundamentos do SOA, demonstrando as prticas para design de servio, orquestrao de servios, arquitetura do SOA e seus principais componentes, dando uma viso prtica e simples do SOA, objetivando ajudar as pessoas a entenderem o SOA e seus fundamentos.
Foi apresentado ainda, o padro para orquestrao de servios BPEL (Business Proccess Execution Language) com foco na descrio dos construtores essenciais ao seu uso, dentro dos princpios de design de servios.
Foi apresentado como uma grande a empresa de comrcio varejista usou o BPEL, como base para integrar os vrios sistemas, independente da plataforma ou linguagem que foram construdos.
Tambm, foi apresentado como essa empresa definiu a arquitetura de referncia e um modelo de desenvolvimento de servios, que a partir da propiciou que essa arquitetura servisse de base para todo projeto que previa integraes.
A empresa tem um ativo de cerca de 500 servios em 18 projetos, todos desenvolvidos com BPEL.
Foi demonstrada a importncia do papel do BPEL na SOA e conceitos bsicos relacionados com a composio de servios e a definio de processos de negcios. Vimos que BPEL fornece um vocabulrio rico para a definio de processos e tem vrias caractersticas no encontradas em linguagens de programao. Isso faz com que BPEL seja a escolha preferida para a composio de servios.
Grandes fornecedores de software em Java e plataformas Microsoft provm suporte a BPEL, e existe at mesmo implementaes de cdigo aberto. Vimos que BPEL desempenha papel importante na composio de servios.
93
BPEL se encaixa muito bem no SOA, e com BPEL, podemos definir processos de negcios executveis e processos de negcio abstratos. Processos executveis so os mais importantes e nos permite definir a ordem exata em que os servios so compostos.
A empresa hoje tem uma maturidade de governana SOA, tendo implantado vrios processos, desde a capacitao da equipe at processos de monitoramento, em tempo real, dos processos dos 18 projetos de integrao, que existem hoje na empresa.
94
6 REFERNCIAS
BRADSHAW, D.K. et al. Oracle9i Application Developer's Guide. Advanced Queueing. Mar. 2002. Disponvel em http://docs.oracle.com/cd/A97630_01/appdev.920/a96587/qintro.htm. Acesso em: 27 out. 2013. EARL, Thomas. SOA: Princpios de design de servios. Traduo Carlos Schanfranski e Eduardo Furmankiewicz. So Paulo: Pearson Prentice Hall, 2009. HOHPE, Gregor; WOOLF, Bobby. Enterprise integration patterns: designing, building and deploying messaging solutions. Pearson Education, 2004. JORDAN, Diane; EVDEMON ,John. Servios web business process execution language version 2.0. abr. 2007. Disponvel em: http://docs.oasisopen.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html. Acesso em: 31 jul. 2013. JOSUTTIS, Nicolai M. Soa na prtica: a arte da modelagem de sistemas distribudos. Traduo Ivan Bosnic. Rio de Janeiro: Alta Books Ltda., 2009. JURIC, Matjaz B; MATHEW, Benny; SARANG, Poornachandra. Business process execution language for servios web: an architect and developers guide to orchestrating servios web using BPEL4WS. 2. ed. Birmingham Mumbai: Packt Publishing, 2006. MACKENZIE, C. Matthew et al. (Ed.). Reference model for service oriented: architecture 1.0. ago.2006. Disponvel em: https://www.oasisopen.org/committees/download.php/19679/. Acesso em: 31 jul. 2013. OASIS. Reference Architecture for Service Oriented Architecture Version 1.0. out. 2006. Disponvel em: http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.html. Acesso em: 10 out. 2013. OASIS. WS-BPEL 2.0. abr. 2007. Disponvel em: http://tinyurl.com/ba2s49j. Acesso em: 04 set. 2013. OBPM. Oracle BPEL Process Manager 10.1.2.0.x. Quick Start Tutorial. Jan. 2006. Disponvel em http://download.oracle.com/otndocs/products/bpel/quickstart.pdf. Acesso em: 18 out. 2013. OPENGROUP. SOA Reference Architecture Technical Standard. Abr. 2010. Disponvel em http://www.opengroup.org/soa/source-book/soa_refarch/. Acesso em: 10 out. 2013. SANTOS, Rildo. SOA Fundamentos. jul. 2009. Disponvel em: http://www.rildosan.com/search?q=soa+fundamentos. Acesso em: 02 set. 2013.
95
WC3. Servios web Description Language (WSDL) 1.1. Mar. 2001. Disponvel em http://www.w3.org/TR/wsdl. Acesso em: 04 out. 2013. WIKIPEDIA. Servios web Description Language. Jun. 2013. Disponvel em http://pt.wikipedia.org/wiki/Web_Services_Description_Language. Acesso em: 04 out. 2013.

Monografia

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Monografia

Enviado por

Direitos autorais:

Formatos disponíveis

PONTIFCIA UNIVERSIDADE CATLICA DE MINAS GERAIS Programa de Ps-Graduao em Arquitetura de Softwares Distribudos

Claudecir Miranda da Silva

Belo Horizonte 2013

Claudecir Miranda da Silva

Orientador: Zenilton K. G. Patrocnio Jnior

Belo Horizonte 2013

Claudecir Miranda da Silva

__________________________________________________ Zenilton K. G. Patrocnio Jnior

Belo Horizonte, 31 de outubro de 2013.

E aos meus colegas de classe pela troca de experincias.

Fonte: OASIS, 2007

1.2.1 Objetivos especficos

Em detalhes, os objetivos desse estudo de caso so:

Desenvolver processos BPEL, para integrao de uma interface de negcio.

1.5 Organizao da monografia

No captulo 3 descrita a metodologia de pesquisa usada no trabalho.

2.1 Definio de SOA Service Oriented Architecture

Dentro do contexto de SOA, (JOSUTTIS, 2009), resume servio da seguinte forma:

Resumindo SOA (SANTOS, 2009):

Fonte CERAMI, 2002

Fonte CERAMI, 2002

Fonte Adaptado de CERAMI, 2002

Fonte Adaptado de CERAMI, 2002

Fonte Adaptado de CERAMI, 2002

Figura 7 Elementos WSDL: Types

Fonte: Oracle JDeveloper

Figura 8 Elementos WSDL: Service e Port

Fonte: Criado pelo Autor pelo software Oracle JDeveloper

Figura 9 Elementos WSDL: Binding

Fonte: Criado pelo Autor pelo software Oracle JDeveloper

Fonte: Criado pelo Autor pelo software Oracle JDeveloper

Fonte: Criado pelo Autor pelo software Oracle JDeveloper

a) Pginas brancas; b) Pginas amarelas; c) Pginas verdes; d) tModel.

A especificao UDDI define:

Figura 12 Aplicao dos Princpios de Design

Fonte: Adaptado de EARL, 2005

Fonte: Adaptado de EARL, 2005

2.6.1 Contrato de servio padronizado

Fonte: Adaptado de EARL, 2005

2.6.2 Baixo acoplamento de servio

Ao planejar um servio, principalmente o seu contrato, devemos baixar ao mximo o acoplamento

Figura 15 Acoplamento de servio

Fonte: Adaptado de EARL, 2005

O acoplamento de servios acaba apoiando e afetando vrios aspectos de outros princpios:

2.6.3 Abstrao de servio

Fonte: Adaptado de EARL, 2005

2.6.4 Reuso de servio

Fonte: Adaptado de EARL, 2005

2.6.5 Autonomia de servio

Figura 18 Autonomia de servio

Fonte: Adaptado de EARL, 2005

2.6.6 Independncia de estado do servio

Servios que lembram precisam gerenciar a transio de estados.

Ao planejar um servio, evite estados favorecendo escalabilidade.

Figura 19 Independncia de estado

Fonte: Adaptado de EARL, 2005

2.6.7 Visibilidade de servio

Ao planejar um servio, garanta que ele possa ser descoberto.

Figura 20 Visibilidade de servio

Fonte: Adaptado de EARL, 2005

2.6.8 Composio de servio

independentemente do tamanho e da complexidade da composio.

A capacidade de composio autoriza melhor gesto de granularidade.