os termos de SOA Desmistificando SOA, a arquitetura orientada a serviços, possui um

Tamanho: px
Começar a partir da página:

Download "os termos de SOA Desmistificando SOA, a arquitetura orientada a serviços, possui um"

Transcrição

1 soa_ Desmistificando os termos de SOA Tire suas dúvidas a respeito dos termos mais comuns referentes a SOA Alexandre é formado em Sistemas de Informação pela USP. Trabalha com SOA e correlatos desde 2008, e é autor do livro SOA Aplicado: Integrando com web services e além, publicado pela Casa do Código. SOA, a arquitetura orientada a serviços, possui um ecossistema vasto em termos e ferramentas próprias. Muitas vezes, problemas complexos a serem resolvidos em SOA podem requerer o conhecimento destas ferramentas. Quando isto acontece, vale a pena conhecer onde o desenvolvedor/arquiteto está se metendo. Como monitorar a performance do seu negócio eficientemente? Como estabelecer correlações entre os serviços sendo invocados, e tomar atitudes em relação a isso? Como prover uma arquitetura SOA altamente escalável? A partir do conhecimento sobre os termos que serão apresentados, você terá condições de conduzir suas próprias pesquisas a respeito destas e outras questões que poderão surgir quando estiver projetando sua própria arquitetura orientada a serviços. SOA SOA significa Service-Oriented Architecture, ou arquitetura orientada a serviços. Trata-se de um paradigma arquitetural que define técnicas para modelagem, desenvolvimento e gerenciamento de serviços. Orientar alguma coisa, em desenvolvimento de software, significa desenvolver utilizando as melhores práticas e técnicas da tecnologia à qual seu sistema é orientado. Quando desenvolvemos um software orientado a serviços, portanto, devemos utilizar as melhores práticas desta técnica. Algumas dessas práticas são:» Desenvolver os contratos antes das implementações (contratos estes que, assim como o desenvolvimento com uma linguagem orientada a objetos por exemplo representam a maneira como o cliente do serviço interage com o mesmo);» Utilizar serviços agnósticos de implementações (ou seja, desenvolver serviços que, de fato, são interoperáveis por exemplo, um serviço construído em Java que possa ser consumido em C#);» Analisar os níveis corretos de granularidade (ou seja, analisar quais as capacidades exatas que um único serviço deve ter). Em relação ao design dos serviços, estes devem seguir os seguintes princípios:» Ter contratos padronizados; / 54

2 Muito se fala em SOA, e tanto iniciantes quanto os mais experientes podem ficar perdidos em meio a tantos termos. O que é BPEL? O que é ESB? O que é CEP? Neste artigo, você conhecerá tanto termos SOA quanto alguns correlacionados.» Ter baixo acoplamento em relação a outros serviços;» Serem abstratos em relação às implementações;» Devem ser reutilizáveis;» Devem ser independentes de outros serviços;» Não devem armazenar estado;» Oferecer mecanismos de descoberta;» Não oferecer impedimento à utilização em uma composição. Vale lembrar que estes não são obrigatórios, porém, altamente recomendados. isso porque todos estes princípios vão ser responsáveis, cada um à sua maneira, de promover uma arquitetura eficiente e reutilizável. Vários destes princípios são seguidos por diversas tecnologias. As mais proeminentes, no entanto, são REST e SOAP (WS-*). Serviço Um serviço é um componente de lógica de negócios, ou seja, qualquer componente que ofereça uma funcionalidade do negócio. Além disso, estes componentes devem seguir os princípios de design citados acima. Em SOA, estes serviços são o centro do universo, ou seja, as aplicações devem ser pensadas em termos destes serviços. isto porque estas aplicações devem ter conhecimento de que estão em um ecossistema completo de aplicações, onde existe interação entre estas. Em uma arquitetura orientada a serviços, os serviços serão os responsáveis por prover os pontos onde as aplicações podem interagir umas com as outras. Na prática, serviços podem ser web services tradicionais, REST, EJBs etc. - sendo que os mais tradicionais, nesta área, são aqueles baseados em WS-* e SOAP. REST também tem sido uma abordagem bastante promissora, dada a capacidade de interação com serviços desse tipo. REST É um estilo de desenvolvimento de serviços proposto por Roy Fielding em sua tese de doutorado. Roy Fielding foi um dos desenvolvedores do protocolo HTTP e, como tal, uma das maiores autoridades sobre o assunto. Quando ele propôs o modelo REST, ele claramente intencionava transmitir todo o conhecimento adquirido no desenvolvimento do protocolo HTTP como diretivas para um modelo que pudesse ser utilizado no desenvolvimento de aplicações modernas (e não apenas na web, como era o caso até então). Possui uma sequência de princípios básicos:» Utilização adequada de MiME Types (como text/html, text/xml, text/json etc.) nas transferências de dados;» Utilização de URLs condizentes com o que se procura (por exemplo, /pessoa para tratar pessoas e /veiculos para tratar veículos);» Utilização de métodos HTTP (GET, POST, PUT, DELETE etc.) adequadamente;» Utilização de hiperligações entre dados;» Utilização de códigos de status do HTTP. Um dos principais impactos de REST, no entanto, foi a contraposição ao estilo RPC (Remote Procedure Call), predominante no segmento até então. Por exemplo, uma das características do RPC é informar ao servidor qual método estamos invocando. Em REST, essa prática é abolida, partindo do pressuposto de que o trio URL bem definida + método HTTP adequado + MiME type correto são suficientes para encontrar o método correto. Por exemplo, o método GET é comumente utilizado para recuperar informações. Em REST, caso o cliente queira recuperar informações de clientes, basta enviar o método GET 55 \

3 com a URL /clientes e o MiME type adequado para o servidor. Uma limitação do estilo, no entanto, está na modelagem de modelos mais complexos, como busca com informações complexas, re-adaptação de cenários RPC para REST, segurança (limitada ao já existente no HTTP/HTTPS ou implementações customizadas), e outros. Para estes cenários, o mais recomendado é utilizar WS-* e SOAP. WADL É um descritor para aplicações baseadas em REST. Este descritor tem por objetivo endereçar questões relacionadas à dinâmica de serviços REST, como URis não específicas, diferentes MIME types etc. Um exemplo de WADL está apresentado na Listagem 1. Listagem 1. Exemplo de WADL. <application xmlns= > <doc xmlns:jersey= jersey:generatedby= Jersey: /02/ :17 AM /> <grammars> <include href= application.wadl/xsd1.xsd > <doc title= Generated xml:lang= en /> </include> <include href= application.wadl/xsd0.xsd > <doc title= Generated xml:lang= en /> </include> </grammars> <resources base= > <resource path= /person > <method id= create name= POST > <request> <ns2:representation xmlns:ns2= xmlns= element= person mediatype= application/xml /> </request> <response> <representation mediatype= <?xml version= 1.0 encoding= UTF-8 standalone= yes?> application/xml /> </response> </method> <resource path= /{id} > <param xmlns:xs= name= id style= template type= xs:long /> <method id= retrieve name= GET > <response> <representation mediatype= application/xml /> </response> </method> </resource> </resource> </resources> </application> No WADL, é possível observar duas seções distintas, grammars e resources. A primeira vai especificar os formatos de dados que serão utilizados como entrada e saída dos serviços. A segunda vai especificar as URLs utilizadas para consumo dos serviços (em REST, também conhecidos como recursos), URLs derivadas, tipos de dados aceitos como entrada e saída, métodos HTTP utilizados etc. Vale ressaltar que o WADL não é uma unanimidade entre a comunidade. Alguns são favoráveis ao uso do mesmo, outros são contra. Argumentos a favor dizem que o mesmo facilita no consumo destes serviços, já que não há necessidade de realizar descoberta prévia do que os serviços expõem já que tudo está especificado no WADL. Argumentos contrários dizem que o uso de um WADL poderia engessar o cliente, tirando o dinamismo pretendido por REST. SOAP / WS-* SOAP e WS-* são os elementos fundamentais dos agora chamados web services clássicos. Estes foram adotados já há vários anos pelo mercado em geral, e tiveram suas especificações definidas por vários consórcios, dentre os quais os mais proeminentes são a W3C (World Wide Web Consortium) e a OASiS (Organization for the Advancement of Structured Information Standards). SOAP significa Simple Object Access Protocol. É um protocolo de aplicação largamente utilizado em grandes empresas para realizar comunicação entre sistemas. É fortemente baseado em padrões e técnicas de XML, como XSD, XPath, Xquery e outras. Contém três partes principais: Envelope (a raiz do conteúdo), Header (utilizado para tráfego de meta-informações) e Body (utilizado para tráfego de informações de requisição, respostas e mensagens de falha). É fortemente ligado a um WSDL e a WS-* como um todo. O WSDL (Web Services Description Language) descreve o formato de entrada e saída de serviços num formato geral, e SOAP dá corpo a essa entrada e saída. O WSDL possui cinco partes principais (sendo extensível, ou seja, podendo possuir mais partes): types, message, porttype, binding e service. O WSDL pode conter apenas as três primeiras, e se assim o fizer, é chamado de WSDL abstrato. Essas três primeiras partes descrevem o formato da entrada e saída do serviço, utilizando XSDs (XML Schema Definition). Até esse momento, o WSDL é independente de SOAP, podendo também descrever outros formatos (sendo que o segundo mais formato é o que se convencionou chamar de POX Plain Old XML). Ele passa a descrever um documento SOAP apenas nas seções binding e service. Se o WSDL contém estas seções, ele é chamado de WSDL concreto. Quanto à descrição do formato do envelope SOAP, / 56

4 existem pelo menos cinco formatos mais conhecidos: RPC literal, RPC encoded, document literal, document encoded e document literal wrapped. No formato RPC (Remote Procedure Call) literal, a definição dos métodos a serem chamados no servidor fica descrita apenas no WSDL, e não na implementação do serviço. Neste modelo, o servidor deve se encarregar de receber a requisição do cliente, fazer parse da mesma, identificar qual é o método que está sendo invocado e, então, despachar a mensagem para a implementação. É um formato complexo, visto que as validações da mensagem geralmente são dependentes do contrato (WSDL). O formato RPC encoded é parecido com o RPC literal, com a adição de que os tipos dos dados devem ser passados na própria requisição, como o exemplo mostrado na Listagem 2. Listagem 2. Exemplo de requisição RPC. <soap:envelope> <soap:body> <mymethod> <x xsi:type= xsd:int >5</x> <y xsi:type= xsd:float >5.0</y> </mymethod> </soap:body> </soap:envelope> Note que, na maior parte dos casos, este tipo de informação é desnecessária, já que a tipagem está presente nos XSDs. Além disso, este formato foi declarado não-interoperável (ou seja, que não se adequa bem a ambientes com múltiplas linguagens de programação) pela WS-i, uma organização responsável por definir padrões de interoperabilidade entre web services. No formato document literal, não há definição formal de qual método está sendo invocado. Neste ponto, o corpo da requisição SOAP é um pouco mais semelhante ao de uma requisição REST. No entanto, pela dificuldade de se entregar esta mensagem para a implementação, geralmente algum mecanismo de endereçamento fica implícito, como o uso do header HTTP SOAPAction ou alguma especificação formal como WS-Addressing (que explicarei mais à frente). O formato document encoded é semelhante ao document literal, com a adição de exigir que a tipagem dos dados seja fornecida em conjunto (assim como acontece em RPC Encoded). Este formato também não é interoperável. O formato document literal wrapped atua de maneira que o método é, novamente, inserido na requisição, mas ao contrário do RPC, esta definição do método fica inserida em um XSD, facilitando a validação do corpo da mensagem e até mesmo melhorando o mecanismo de entrega. Este formato de dados é o padrão utilizado pelo JAX-WS (o framework padrão para definição de web services em Java), e é o que possui menos falhas, de acordo com [1]. Quanto a WS-*, trata-se de um nome comumente atribuído ao conjunto de especificações definidas para web services clássicos. Estas especificações compreendem uma série de mecanismos úteis para uso em cenários que envolvem web services, como mecanismos de segurança (WS-Security), transações (WS- -Transaction), endereçamento (WS-Addressing), e assim por diante. WS-Policy É uma especificação utilizada para definir políticas (ou seja, maneiras de utilizar) web services clássicos. Estas políticas podem envolver praticamente qualquer coisa, como o protocolo de transporte que deve ser utilizado pelo web service (HTTP/HTTPS, por exemplo); SLA do serviço etc. Em geral, é utilizada para descrever o uso de outras especificações. WS-Security É a especificação padrão para endereçar questões relacionadas à segurança. Estas questões envolvem o já citado protocolo de transporte, o sistema de autenticação/autorização etc. Pode incluir outras especificações/extensões, como WS-SecureConversation (utilizada para estabelecer contextos de segurança, ou seja, mecanismos seguros a serem utilizados em várias trocas de mensagens) e WS-Trust (utilizada para definir mecanismos de utilização de tokens seguros). WS-Transaction É uma especificação guarda-chuva para questões relacionadas a transações. Engloba WS-Atomic- Transaction (para transações de curta duração) e WS- -BusinessActivity (para transações de longa duração). WS-Addressing É uma especificação para tratar endereçamento de dados. Pode ser utilizada tanto para tratamento de requisições dinâmicas (ou seja, para especificar, em tempo de execução, o endereço de um determinado web service), quanto para tratamento de web services assíncronos (ou seja, é o mecanismo que o cliente vai utilizar para informar ao servidor o endereço para resposta de uma mensagem). MTOM / xop MTOM significa Message Transmission Optimization Mechanism, e XOP significa XML-binary Optmized Packaging. São mecanismos usados em conjunto para tratar da transmissão de dados binários em SOAP. Basicamente, o mecanismo funciona em conjunto com HTTP, de maneira que o conteúdo binário é 57 \

5 trafegado separado do envelope SOAP e, depois, ambos são recombinados através de um ID da mensagem. Diferenças entre REST e WS-* Para ficarem claras as diferenças entre REST e WS-*, listo aqui algumas delas: CONTExTO REST WS-* CONTRATO TIPOS DE DADOS SEGURANÇA Qualquer formato endereçado pela WS-Security ou extensões proprietárias INTEROPERABI- LIDADE FACILIDADE DE USO MODELAGEM MANUTENIBILI- DADE PERFORMANCE WADL + Interface Uniforme (padronização de métodos HTTP + códigos de status + URLs) Qualquer um que possa ser definido por um MIME Type Baseada no modelo HTTP / HTTPS ou extensões proprietárias Sim Tende a ser fácil Orientada a recursos tende a ser difícil Clientes podem deixar de funcionar silenciosamente após uma alteração no serviço Mais rápido pode trafegar apenas o estritamente necessário WSDL SOAP (baseado em XML) e binário (endereçado pela especificação MTOM/XOP) Possui variantes não-interoperáveis (ou seja, não homologadas pela WS-I) Tende a ser difícil Similar a RPC tende a ser fácil Em geral, os clientes são compilados por geradores de código fazendo com que eles deixem de funcionar caso o serviço não seja mais compatível Mais lento inclui overhead do protocolo SOAP ESB Significa Enterprise Service Bus. É um padrão de projeto SOA (catalogado por Thomas Erl em [2]) utilizado para endereçar, de uma única vez, padrões de integração de sistemas [3]. Um ESB tem uma posição central em uma arquitetura orientada a serviços. Suas atribuições incluem roteamento de mensagens, transformação, enriquecimento, composição, monitoração, entre outras. Por possuir todas estas atribuições, geralmente ele é o ponto de comunicação entre o cliente e o serviço final, sendo que este serviço final pode ser tanto um web service simples (WS-* ou REST), quanto uma composição de serviços. Em caso de uma composição, é bastante comum encontrar cenários em que a própria composição não entrega mensagens diretamente aos serviços, mas sim, invoca o ESB novamente. isso facilita o monitoramento da saúde da arquitetura como um todo. Existem várias implementações de ESB (na casa de dezenas). Para mencionar algumas, temos:» Oracle Service Bus;» ibm Websphere ESB;» Progress Sonic ESB;» Mule ESB;» Apache ServiceMix;» Fuse ESB. Um caso curioso é o do Apache Camel. Este framework contém todas as funcionalidades de um ESB, sem ser considerado um. isto porque o Apache Camel não possui um papel centralizado, ou seja, fica embutido na aplicação. Para que isto fique mais claro, veja a figura 1. A figura 1 mostra o papel de um ESB; observe que é uma posição central, ou seja, deve contar com o próprio servidor de aplicação no próprio conjunto de máquinas. O Apache Camel não tem essa posição central, sendo várias vezes embutido em outras aplicações, ao invés de ter esse papel centralizador. Quanto à forma, não existe padronização em relação a como os ESBs expõem suas regras. Cada um tem seu próprio mecanismo (e, muitas vezes, sua própria nomenclatura) para isso. Por exemplo, o Apache ServiceMix utiliza o Apache Camel para definição de suas rotas. O Apache Camel, por sua vez, trabalha com a definição das rotas tanto na forma de arquivos XML (integrados com o Spring) quanto em puro Java. Listagem 3. Fragmento de definição de rotas do Camel. <camel:route> <camel:from uri= file:src/data?noop=true /> <!--Print the message to standard out, just as a test--> <camel:convertbodyto type= java.lang.string /> <camel:to uri= stream:out /> <camel:to uri= activemq:personnel.records /> </camel:route> A Listagem 3 mostra um fragmento de definição de roteamento utilizando o Apache Camel. Nesta listagem (definida dentro de um arquivo Spring), é possível ver as tags from e to. Estas tags mostram, respectivamente, o consumo de uma mensagem (no caso, do sistema de arquivos, da pasta src/data) e a entrega da mesma a um determinado ponto. Neste / 58

6 Figura 1. Papel de um ESB em SOA (fonte: soasimples.com). caso, a mensagem tanto foi entregue para a saída padrão do sistema (ou seja, para ser impressa no console) quanto para uma fila JMS do ActiveMQ. BPM / BPMN / BPMS BPM significa Business Process Management. É um conceito utilizado para realizar análise de processos de negócio e otimizá-los. É comumente habilitado através de uma notação chamada BPMN (Business Process Modeling Notation), e pode ser dividido em fluxo abstrato ou concreto, sendo que o concreto é automatizado através de um BPMS Business Process Management Suite. Estas suítes geralmente recebem como entrada um fluxo BPMN e, através de extensões, permitem a um desenvolvedor programar o comportamento de cada definição no fluxo. A figura 2 mostra um exemplo de um fluxo definido no Oracle BPM Studio. Figura 2. Definição de fluxo BPM no Oracle BPM Studio (fonte: docs.oracle.com). Cada uma das caixas representa uma atividade diferente, dentro do contexto de um mesmo processo de negócios. O desenvolvedor pode receber o fluxo BPMN definido em qualquer ferramenta (como,k por exemplo, o Bizagi BPM Suite) e então, portar este fluxo para o Oracle BPM Studio, onde o processo poderá ser automatizado. Após a definição do que cada atividade deve fazer, o BPM Studio receberá um pacote com o fluxo e, geralmente, disponibilizá-lo para a empresa como um web service. Diferenças entre os ESBs Cada tipo de ESB apresenta vantagens e desvantagens que justificam o modelo de precificação. Assim como Application Servers, existem diferenças fundamentais entre cada um, em termos de funcionalidade, escalabilidade, performance, compatibilidade com outros produtos etc. BPEL Significa Business Process Execution Language. Na prática, trata-se de um XML que define um conjunto de operações a serem efetuadas com um conjunto de web services e expô-los como um único serviço. O formato deste XML é regido pela OASiS. Existem muitas comparações de BPEL com BPM. No começo, muitos acreditavam que deveria ser o BPEL quem automatizaria os fluxos BPMN, e muitos acreditaram na ideia. Com o passar dos anos (e as empresas ganhando mais maturidade em SOA), esta ideia foi descartada. Hoje, o BPEL serve apenas como motor de orquestração de serviços ou seja, uma engine centralizada capaz de atuar como máquina de estados para estas composições, realizando procedimentos complexos de comunicação entre vários web services diferentes. Vale ressaltar que a maioria das engines BPEL lida apenas com web services WS-*. Existem diversas engines BPEL atualmente. Para citar algumas, temos:» Oracle BPEL Process Manager;» Apache ODE;» Websphere Process Server. A figura 3 mostra um exemplo de definição de fluxo BPEL (no JDeveloper 11g, ferramenta utilizada para definição BPEL para o Oracle BPEL 11g). Assim como em BPM, cada caixa neste fluxo conterá a definição de uma atividade diferente. A grande diferença é que o BPEL contém atividades muito mais técnicas, que não devem sofrer interferência de analistas de negócio ou correlatos. 59 \

7 when Uma pessoa tem somente dor-de-cabeca. then O diagnostico e Enxaqueca end Figura 3. Exemplo de definição BPEL no Oracle BPEL (fonte: docs. oracle.com). BRMS Significa Business Rules Management Suite. É um tipo de ferramenta utilizada para gerenciar e executar regras de negócio, que são tipicamente definidas através de linguagem específicas de domínio (Domain-Specific Language - DSL). Existem várias ferramentas deste tipo disponíveis no mercado, dentre as quais alguns exemplos são o JBoss BRMS / JBoss Guvnor (respectivamente, versão paga e aberta do mesmo produto), o Websphere ilog e o Oracle Business Rules. O JBoss BRMS utiliza como mecanismo de execução o Drools. Um exemplo de arquivo Drools é o apresentado na Listagem 4. Listagem 4. Exemplo de regra Drools (fonte: docs. jboss.org). rule Hello World dialect mvel when m : Message( status == Message.HELLO, message : message ) then System.out.println( message ); modify ( m ) { message = Goodbyte cruel world, status = Message.GOODBYE }; end Esta é uma regra definida em um dos dialetos embutidos do Drools (no caso, o mvel). No entanto, é possível definir as DSLs até ficar como o exemplo mostrado na Listagem 5. Listagem 5. Exemplo de regra com DSL no Drools (fonte: rule Enxaqueca Note que o uso de um BRMS, em SOA, facilita a flexibilização de fluxos de dados, dado que as regras ficam definidas num formato que é mais facilmente editável e que tem mais afinidade com o negócio em si. O BRMS é responsável por expor estas regras como web services ou algum outro formato de fácil interação, e as outras aplicações podem consumir estas regras e alterar a lógica de acordo com os resultados, transformando o BRMS num sistema que apenas acrescenta flexibilidade às aplicações como um todo. CEP Significa Complex Events Processing. São ferramentas utilizadas para habilitar a reação de uma arquitetura a eventos, ao invés de requisições puras. Estes eventos são parecidos com requisições, mas as ferramentas CEP os utilizam para realizar correlações em busca de padrões. Estes padrões podem ser utilizados para re-ordenar um fluxo de vendas, detectar intrusos, ataques DDoS, falhas de componentes etc. Um exemplo do mundo real sobre este tipo de processamento é um carro. Carros têm diversos tipos de sensores para medir velocidade, temperatura do motor, nível de combustível etc. Um sistema computadorizado poderia tirar proveito de um sensor de nível de pressão do ar nos pneus e, a partir de correlações entre as medições recebidas num determinado período de tempo, indicar se o pneu está furado ou não. Note que esta informação pode, também, ser correlacionada com outras, a fim de determinar problemas mais graves. Por exemplo, se o computador detectar que uma medição não foi disponibilizada em certo período de tempo, pode inferir que o pneu nem sequer está no carro! Alguns exemplos de ferramentas CEP:» Oracle CEP;» Esper / Nesper (versão Java e.net, respectivamente). Geralmente, as ferramentas são aderentes a uma linguagem chamada EPL Events Processing Language. Esta linguagem é bastante parecida com SQL, no sentido de filtrar eventos a partir de uma nuvem de eventos com certas cláusulas. Por exemplo, para filtrar a média de preço dos papéis da ibm na bolsa, levando em consideração um espaço de tempo de 30 segundos, pode-se utilizar o comando apresentado na Listagem 6. Listagem 6. Exemplo de query EPL (fonte: esper. codehaus.org). / 60

8 select avg(price) from StockTick.win:time(30 sec) where symbol= IBM Em relação a SOA, o processamento de eventos pode ser utilizado para interceptar as requisições a serviços para gerar estes eventos, que podem ser utilizados para desvendar padrões complexos e, de acordo com os resultados, invocar outros serviços. No exemplo da Listagem 6, por exemplo, o sistema de CEP pode ser utilizado para invocar um serviço de compra de papéis caso o preço médio (em certo período de tempo) atinja um valor mínimo, por exemplo. BAM Significa Business Activity Monitoring. O BAM realiza interceptação dos dados (da mesma maneira que as engines de CEP) para manter rastreamento de KPis (Key Performance Indicators - Indicadores chave de performance). Esses KPis representam números que são essenciais para o funcionamento da empresa - total de vendas em um dia, número de vendas de determinado produto no mês, rendimento bruto e líquido dessas vendas etc. Com o uso de um BAM, é possível visualizar dashboards (gráficos indicadores) desses números. Dependendo da ferramenta, estes dashboards podem ser visualizados em tempo real, ou seja, eles se movimentam de acordo com a performance do negócio. Alguns exemplos de BAM:» Oracle BAM;» Websphere Business Monitor;» WSO2 BAM. A figura 4 mostra estes dashboards no Oracle BAM. outros protocolos, como SOAP. isto facilita a exposição destes tipos de componentes em outros formatos sem a necessidade de utilizar um ESB. implementações incluem a utilizada no Oracle Fusion Middleware (que contém outros componentes, como Oracle BPEL, Oracle BAM, Oracle WebLogic), assim como implementações abertas como o Apache Tuscany. Algumas vezes, é utilizada com frameworks parecidos como o JBi Java Business Integration. Arquiteturas Correlatas SOA possui uma relação íntima com vários tipos de arquitetura. Como o leitor deve ter percebido, a arquitetura orientada a serviços em si não tem por intuito promover escalabilidade no entanto, isto é facilmente alcançado através do emprego de outras arquiteturas. A seguir, você confere algumas destas. Shared-Disk Shared-disk é uma alternativa a um sistema de clusters tradicional, onde o servidor espalha para outros nós as sessões de usuário. Em shared-disk, cada nó desconhece a própria existência dos outros nós. Tudo o que estes sistemas compartilham, uns com os outros, é o disco. Note que, neste caso, o disco pode ser qualquer coisa, desde o próprio sistema de arquivos de uma máquina, até um NAS (Network-Attached Storage). Note que isto inclui um banco de dados, ou seja, se você possui um banco de dados compartilhado entre várias máquinas que não conhecem umas às outras, você está usando uma arquitetura shared-disk. Figura 4. Exemplos de dashboards no Oracle BAM (fonte: www. oracle.com). SCA Significa Service Component Architecture. Suas implementações habilitam a exposição de componentes de serviços (como EJBs, filas JMS etc.) com Figura 5. Formato geral de uma arquitetura shared-disk. Onde isso se encaixa em SOA? No próprio fato das máquinas não conhecerem umas às outras. isso requer que a aplicação não mantenha estado ou persista o estado em locais que não no próprio servidor de aplicação - o que é um casamento perfeito com a 61 \

9 teoria de orientação a serviços, especificamente em relação ao princípio de design de não armazenar estado. Com máquinas que não mantêm estado, é possível distribuir componentes de uma mesma aplicação (ou várias) por várias instâncias, sem problemas de escalabilidade ou performance. Ao contrário, ao fazer isso, a escalabilidade é alcançada através da escalabilidade horizontal, ou seja, através da adição de mais máquinas no conjunto, é possível obter mais poder de processamento. Quanto à performance, a distribuição da aplicação em serviços equaliza as necessidades de processamento para todos, fazendo com que todas as máquinas ajudem umas às outras. A grande desvantagem desta é que a máquina (ou máquinas) que são responsáveis pelos bancos de dados tornam-se pontos únicos de falha, além do fato da escalabilidade do banco de dados ser limitada. Para contornar este tipo de problema, a arquitetura shared-nothing foi desenvolvida. Shared-Nothing Shared-nothing é similar a shared-disk, com a adição de que as máquinas não compartilham nada - nem mesmo o banco de dados. Perceba que é um conceito mais abstrato e substancialmente mais complexo para ser implementado. No entanto, este sistema tem a adição de não possuir um ponto único de falhas, ou seja, se um banco de dados falha, as outras máquinas não dependem de apenas um. quando se faz uso de bancos de dados que também tenham arquitetura shared-nothing, como Cassandra ou HBase. Neste tipo de arquitetura, deve ser necessário que a aplicação decida em qual (ou quais) máquinas armazenar quais dados e onde. Se os dados forem distribuídos em regiões geográficas distintas, por exemplo, diminuem as chances de indisponibilidade. Além disso, se um conjunto de dados de um tipo (por exemplo, de clientes) forem armazenados em uma máquina e de outro tipo (por exemplo, veículos) em outro, se houver indisponibilidade de uma máquina a aplicação não estará inteiramente comprometida (ou seja, se o banco que contém dados de veículos sair do ar, ainda será possível consultar clientes). Event-Driven Architecture (EDA) EDA é um tipo de arquitetura que pode complementar uma arquitetura SOA tradicional. isto é relativo ao uso que se faz de ferramentas de análise e processamento de eventos (ver CEP). Quando o uso de eventos é extensivo, o resultado é uma arquitetura orientada a eventos EDA. O que isto tem a ver com SOA? Estes eventos podem ser utilizados para disparar serviços. Ou seja, as implementações dos serviços disparam eventos que, por sua vez, alimentam engines de eventos que por sua vez invocam serviços com os resultados dos processamentos dos eventos. Conclusão O universo SOA é imensamente vasto, tendo um ecossistema rico em ferramentas com os mais diversos usos possíveis. Neste artigo, você pôde vislumbrar tanto os termos mais comuns em SOA (como REST, SOAP e WSDL) quanto termos pouco utilizados e restritos a nichos, como CEP e SCA. Vale lembrar que todas estas ferramentas têm usos distintos e todos muito importantes. Todas são ferramentas que resolvem necessidades reais de mercado. Um bom profissional, com conhecimento destas ferramentas, estará sempre apto a resolver os problemas mais complexos. /referências Figura 6. Formato geral de uma arquitetura shared-nothing. Em uma arquitetura shared-nothing, as máquinas que servem à aplicação em si decidem o local onde realizar o armazenamento das informações. isso é particularmente útil para aplicações de nível global, pois as máquinas podem decidir armazenar dados em bancos que estejam geograficamente mais próximos. Este tipo de tomada de decisão é mais simples > [1] Which style of WSDL should I use? com/developerworks/webservices/library/ws-whichwsdl/ > [2] SOA Design Patterns Thomas Erl, Prentice Hall, > [3] EAI Patterns / 62

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 13 Web Services Web Services

Leia mais

REST Um Estilo de Arquitetura de Sistemas Distribuídos

REST Um Estilo de Arquitetura de Sistemas Distribuídos REST Um Estilo de Arquitetura de Sistemas Distribuídos Márcio Alves de Araújo¹, Mauro Antônio Correia Júnior¹ 1 Faculdade de Computação Universidade Federal de Uberlândia (UFU) Monte Carmelo MG Brasil

Leia mais

Consumindo um Web Service através de uma Aplicação Comercial em Android. Alex Malmann Becker www.alex.porthal.com.br alex@porthal.com.

Consumindo um Web Service através de uma Aplicação Comercial em Android. Alex Malmann Becker www.alex.porthal.com.br alex@porthal.com. Consumindo um Web Service através de uma Aplicação Comercial em Android Alex Malmann Becker www.alex.porthal.com.br alex@porthal.com.br 08/2014 Agenda Introdução Conceitos Web Service Por que utilizar

Leia mais

RestFull WebServices. Rafael Nunes Arquiteto de Software / Instrutor Globalcode. Globalcode Open4Education

RestFull WebServices. Rafael Nunes Arquiteto de Software / Instrutor Globalcode. Globalcode Open4Education RestFull WebServices Rafael Nunes Arquiteto de Software / Instrutor Globalcode 1 REST Integrando aplicações e disponibilizando serviços sem complicar a vida de ninguém. 2 Agenda > Integrando Aplicações

Leia mais

Introdução a Web Services

Introdução a Web Services Introdução a Web Services Mário Meireles Teixeira DEINF/UFMA O que é um Web Service? Web Service / Serviço Web É uma aplicação, identificada por um URI, cujas interfaces podem ser definidas, descritas

Leia mais

UNIVERSIDADE. Sistemas Distribuídos

UNIVERSIDADE. Sistemas Distribuídos UNIVERSIDADE Sistemas Distribuídos Ciência da Computação Prof. Jesus José de Oliveira Neto Web Services Web Services Existem diferentes tipos de comunicação em um sistema distribuído: Sockets Invocação

Leia mais

2 Conceitos relativos a Web services e sua composição

2 Conceitos relativos a Web services e sua composição 15 2 Conceitos relativos a Web services e sua composição A necessidade de flexibilidade na arquitetura das aplicações levou ao modelo orientado a objetos, onde os processos de negócios podem ser representados

Leia mais

Service Oriented Architecture SOA

Service Oriented Architecture SOA Service Oriented Architecture SOA Arquitetura orientada aos serviços Definição: Arquitetura de sistemas distribuídos em que a funcionalidade é disponibilizada sob a forma de serviços (bem definidos e independentes)

Leia mais

3 Serviços na Web (Web services)

3 Serviços na Web (Web services) 3 Serviços na Web (Web services) 3.1. Visão Geral Com base na definição do Word Wide Web Consortium (W3C), web services são aplicações autocontidas, que possuem interface baseadas em XML e que descrevem

Leia mais

COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP

COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP Cleber de F. Ferreira¹, Roberto Dias Mota¹. ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil cleberferreirasi@hotmail.com, motaroberto@hotmail.com Resumo.

Leia mais

REST. Caio Nakashima caio.nakashima@mds.gov.br caionakashima@gmail.com

REST. Caio Nakashima caio.nakashima@mds.gov.br caionakashima@gmail.com REST Caio Nakashima caio.nakashima@mds.gov.br caionakashima@gmail.com 1 RESTful REpresentation State Transfer Estilo de arquitetura de software para sistemas distribuídos Termo proposto por Roy Fielding

Leia mais

Arquitetura Orientada a Serviço

Arquitetura Orientada a Serviço Arquitetura Orientada a Fabio Perez Marzullo IEEE Body of Knowledge on Services Computing Sponsored by Technical Committee on Services Computing, IEEE Computer Society 1 SOA e Web Services SOA é um modelo

Leia mais

Web Services. Integração de aplicações na Web. Sistemas Distribuídos

Web Services. Integração de aplicações na Web. Sistemas Distribuídos Web Services Integração de aplicações na Web Integração de Aplicações na Web Interoperação entre ambientes heterogêneos desafios diversidade de componentes: EJB, CORBA, DCOM... diversidade de linguagens:

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 14 SOA e ESB Service-Oriented

Leia mais

Web Services. Tópicos. Motivação. Tecnologias Web Service. Passo a passo Business Web Conclusão. Integração de aplicações SOAP, WSDL, UDDI, WSFL

Web Services. Tópicos. Motivação. Tecnologias Web Service. Passo a passo Business Web Conclusão. Integração de aplicações SOAP, WSDL, UDDI, WSFL Web Services Antonio Dirceu adrvf@cin.ufpe.br Tópicos Motivação Integração de aplicações Tecnologias Web Service SOAP, WSDL, UDDI, WSFL Passo a passo Business Web Conclusão Motivação Integração de Aplicações

Leia mais

Trabalho de Sistemas Distribuídos

Trabalho de Sistemas Distribuídos Cássio de Olivera Ferraz Trabalho de Sistemas Distribuídos Petrópolis 2015, v-1.0 Cássio de Olivera Ferraz Trabalho de Sistemas Distribuídos Trabalho sobre sistemas distribuídos e suas tecnologias. Universidade

Leia mais

SOA Introdução. SOA Visão Departamental das Organizações

SOA Introdução. SOA Visão Departamental das Organizações 1 Introdução A Organização é a forma pela qual nós coordenamos nossos recursos de todos os tipos para realizar o trabalho que nos propusemos a fazer. A estrutura de nossas organizações manteve-se basicamente

Leia mais

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Tópicos Motivação e Objetivos LP e SOA Processo ADESE

Leia mais

Integração Orientada a Serviços

Integração Orientada a Serviços Integração Orientada a Serviços Porto Alegre, Agosto de 2006 Agenda Sobre a e-core SOA O que é? Web Services x SOA Principal Motivação - Integração SOI ESB BPEL JBI ServiceMix Solução Proposta A Empresa

Leia mais

Arquitetura Orientada a Serviços (SOA) Copyright e-core LTDA, 2010. Todos os direitos reservados.

Arquitetura Orientada a Serviços (SOA) Copyright e-core LTDA, 2010. Todos os direitos reservados. Arquitetura Orientada a Serviços (SOA) Visão Geral e-coree Estabelecida em 1999 Escritórios rios no Brasil e EUA Aproximadamente 100 profissionais Atua em prestação de serviços offshore desde 2004 Roteiro

Leia mais

PROJELER. Solução de código aberto para gerenciamento de processos de negócio

PROJELER. Solução de código aberto para gerenciamento de processos de negócio Otimização e Automação de Processos de Negócio Abril/2008 Solução de código aberto para gerenciamento de processos de negócio Maurício Bitencourt, PMP Diretor Executivo mauricio.bitencourt@projeler.com.br

Leia mais

Web Services. (Introdução)

Web Services. (Introdução) Web Services (Introdução) Agenda Introdução SOA (Service Oriented Architecture) Web Services Arquitetura XML SOAP WSDL UDDI Conclusão Introdução Comunicação distribuída Estratégias que permitem a comunicação

Leia mais

Introdução ao BPEL utilizando o Oracle SOA Suíte 10g

Introdução ao BPEL utilizando o Oracle SOA Suíte 10g Introdução ao BPEL utilizando o Oracle SOA Suíte 10g 1. Introdução Neste artigo serão apresentados alguns conceitos inerentes a SOA Service Oriented Architecture e um exemplo prático de construção de processo

Leia mais

INT-9: Implementing ESB Processes with OpenEdge and Sonic David Cleary

INT-9: Implementing ESB Processes with OpenEdge and Sonic David Cleary Implementando Processos ESB com OpenEdge e Sonic Paulo Costa Global Field Services Agenda Desenvolvendo Processos de Negócio Visão geral da tecnologia Desenvolvendo um processo de negócio do início ao

Leia mais

Arquiteturas SOA, WOA, e REST

Arquiteturas SOA, WOA, e REST Arquiteturas SOA, WOA, e REST Aplicação de Software Social Fred Figueiredo Luiz Borges Pedro Pires Arquiteturas SOA, WOA e REST Desenvolvimento de aplicações orientadas ao fornecimento de serviços que

Leia mais

Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA) São Paulo, 2011 Universidade Paulista (UNIP) Service Oriented Architecture (SOA) Prof. MSc. Vladimir Camelo vladimir.professor@gmail.com 04/09/11 vladimir.professor@gmail.com 1 04/09/11 vladimir.professor@gmail.com

Leia mais

SOA na Prática Ricardo Limonta

SOA na Prática Ricardo Limonta SOA na Prática Ricardo Limonta Arquiteto JEE Objetivo Apresentar os conceitos de Arquiteturas Orientadas a Serviços; Entender a relação entre SOA e a tecnologia Web Services; Implementar SOA com Web Services

Leia mais

SOA: Service-oriented architecture

SOA: Service-oriented architecture SOA: Service-oriented architecture Roteiro Breve História O que é Arquitetura de Software? O que é SOA? Serviços Infraestrutura Composição Sua empresa está preparada para SOA? Breve História Uma empresa

Leia mais

Fase 1: Engenharia de Produto

Fase 1: Engenharia de Produto Fase 1: Engenharia de Produto Disciplina: Análise de Requisitos DURAÇÃO: 44 h O objetivo principal da disciplina é realizar uma análise das necessidades e produzir um escopo do produto. Representará os

Leia mais

Combinação de serviços já existentes para criar um novo serviço. jcd@cin.ufpe.br. cin.ufpe.br. cin.ufpe.br. Composição de Serviços Com WS-BPEL

Combinação de serviços já existentes para criar um novo serviço. jcd@cin.ufpe.br. cin.ufpe.br. cin.ufpe.br. Composição de Serviços Com WS-BPEL Introdução à Composição de serviços Web Júlio César Damasceno jcd@ Agenda Definição Motivação Background Arquitetura Orientada a Serviço (SOA) Computação Orientada a Serviço (SOC) Web Services Composição

Leia mais

Extensões MIDP para Web Services

Extensões MIDP para Web Services Extensões MIDP para Web Services INF-655 Computação Móvel Universidade Federal de Viçosa Departamento de Informática MIDP Architecture MIDP = Mobile Information Device Profile Connection Framework HttpConnection

Leia mais

Implementação de uma Alçada Decisória usando a Suíte SOA IBM BPM

Implementação de uma Alçada Decisória usando a Suíte SOA IBM BPM Implementação de uma Alçada Decisória usando a Suíte SOA IBM BPM Juan Manuel Bonomi Garay 10 de Outubro de 2013 WebSphere Agenda Modelagem do processo Websphere Business Modeler (BPMN) Implementação da

Leia mais

SOA 2.0 ou Event-Driven SOA

SOA 2.0 ou Event-Driven SOA SOA SOA 2.0 ou Event-Driven SOA 1 Introdução Recentemente, a Oracle anuciou o termo SOA 2.0. E já deu para imaginar a repercussão que isto teve. Estamos em um momento onde SOA (Service-Oriented Architecture),

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 5 Servidores de Aplicação

Leia mais

Oracle BPM 11g. Análise à Plataforma

Oracle BPM 11g. Análise à Plataforma Oracle BPM 11g Análise à Plataforma Maio de 2010 Tive o privilégio de ser convidado a participar no "EMEA BPM 11g beta bootcamp" em Abril de 2010, no qual tive contacto mais próximo com a última versão

Leia mais

PROJELER. Componentes da Solução Intalio BPMS 5.2. Maurício Bitencourt 51 21171872 / 51 84087798 mauricio.bitencourt@projeler.com.

PROJELER. Componentes da Solução Intalio BPMS 5.2. Maurício Bitencourt 51 21171872 / 51 84087798 mauricio.bitencourt@projeler.com. Componentes da Solução Intalio BPMS 5.2 Maurício Bitencourt 51 21171872 / 51 84087798 mauricio.bitencourt@projeler.com.br Platinum Implementation Partner 1 Enterprise Edition Software de Código Aberto

Leia mais

IBM Business Process Manager Versão 8 Release 5. Visão Geral do IBM Business Process Manager

IBM Business Process Manager Versão 8 Release 5. Visão Geral do IBM Business Process Manager IBM Business Process Manager Versão 8 Release 5 Visão Geral do IBM Business Process Manager ii Visão Geral Manuais PDF e o Centro de Informações Os manuais PDF são fornecidos como uma conveniência para

Leia mais

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Aula 2 Computação em Nuvem Desafios e Oportunidades A Computação em Nuvem

Leia mais

BPM e SOA. Grinaldo Lopes de Oliveira (grinaldo@gmail.com) Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas

BPM e SOA. Grinaldo Lopes de Oliveira (grinaldo@gmail.com) Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas BPM e SOA Grinaldo Lopes de Oliveira (grinaldo@gmail.com) Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas Como funcionam as organizações? O que ébpm Business Process Management (BPM)

Leia mais

XML e Banco de Dados. Prof. Daniela Barreiro Claro DCC/IM/UFBA

XML e Banco de Dados. Prof. Daniela Barreiro Claro DCC/IM/UFBA XML e Banco de Dados DCC/IM/UFBA Banco de Dados na Web Armazenamento de dados na Web HTML muito utilizada para formatar e estruturar documentos na Web Não é adequada para especificar dados estruturados

Leia mais

2. Gerar um arquivo XSD e referenciá-lo no WSDL, fazendo com que seja possível catalogar o XML Schema no catálogo de XML Schemas da e-ping;

2. Gerar um arquivo XSD e referenciá-lo no WSDL, fazendo com que seja possível catalogar o XML Schema no catálogo de XML Schemas da e-ping; Guia de Orientação para Implementação de Web Services Este documento apresenta alguns direcionamentos referentes à implementação de web services. É uma versão preliminar da construção do Guia de Orientação

Leia mais

Projeto: Plataforma de Integração. Data: 01/08/2014

Projeto: Plataforma de Integração. Data: 01/08/2014 Manual do Usuário - Autenticação Plataforma de Integração Arquitetura de Software 1.0 20/03/2014 1 de 8 Histórico de Revisões Data Versão Descrição 01/08/2014 1.0 Criação do documento 04/08/2014 1.1 Revisão

Leia mais

Interoperabilidade em SOA

Interoperabilidade em SOA c o l u n a Marcílio Oliveira (marcilio.oliveira@sensedia.com): Gerente de consultoria da Sensedia (http://www.sensedia.com/br), empresa especializada em implantação corporativa de SOA. Participou de diversos

Leia mais

Arquiteturas Orientadas a Serviços ESB. Enterprise Service Bus. Prof. Ricardo J. Rabelo DAS5316 Integração de Sistemas Corporativos

Arquiteturas Orientadas a Serviços ESB. Enterprise Service Bus. Prof. Ricardo J. Rabelo DAS5316 Integração de Sistemas Corporativos ESB Enterprise Service Bus Prof. Ricardo J. Rabelo DAS5316 Integração de Sistemas Corporativos Resumo Introdução Definição Problemas atuais e Vantagens Evolução do ESB ESB versus EAI, MOM, Workfow, SOA

Leia mais

acoplamento Exprime o grau de conexão entre os módulos; os módulos de um software devemapresentar um baixo coeficiente de acoplamento.

acoplamento Exprime o grau de conexão entre os módulos; os módulos de um software devemapresentar um baixo coeficiente de acoplamento. SOA Arquitetura Orientada a Serviços Conceitos e Aplicações Prof. MSc. Edilberto Silva edilms@yahoo.com/ http://edilms.eti.br Gestão de TI Conceitode SOA SOA - Service OrientedArchitecture (Arquitetura

Leia mais

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Basedos na Web Capítulo 12 Agenda Arquitetura Processos Comunicação Nomeação Sincronização Consistência e Replicação Introdução

Leia mais

ENTERPRISE JAVABEANS 3. Msc. Daniele Carvalho Oliveira

ENTERPRISE JAVABEANS 3. Msc. Daniele Carvalho Oliveira ENTERPRISE JAVABEANS 3 Msc. Daniele Carvalho Oliveira Apostila Servlets e JSP www.argonavis.com.br/cursos/java/j550/index.html INTRODUÇÃO Introdução Enterprise JavaBeans é um padrão de modelo de componentes

Leia mais

WORKFLOW. Mapeamento de Processos de Negócio 26/11/2009. Tadeu Cruz, Prof. M.Sc. TODOS OS DIREITOS RESERVADOS

WORKFLOW. Mapeamento de Processos de Negócio 26/11/2009. Tadeu Cruz, Prof. M.Sc. TODOS OS DIREITOS RESERVADOS WORKFLOW Mapeamento de Processos de Negócio Tadeu Cruz, Prof. M.Sc. TODOS OS DIREITOS RESERVADOS É proibido a reprodução total ou parcial de qualquer forma ou por qualquer meio sem a expressa autorização

Leia mais

SOA Service Oriented Architecture. Fabiano Oss fabiano.oss@gmail.com

SOA Service Oriented Architecture. Fabiano Oss fabiano.oss@gmail.com SOA Service Oriented Architecture Fabiano Oss fabiano.oss@gmail.com 1 Roteiro SOA Serviços Tecnologias para o desenvolvimento de serviços Modelagem de Negócios 2 O que é SOA É uma arquitetura de desenvolvimento

Leia mais

Web services. Um web service é qualquer software que está disponível através da Internet através de uma interface XML.

Web services. Um web service é qualquer software que está disponível através da Internet através de uma interface XML. Web services Um web service é qualquer software que está disponível através da Internet através de uma interface XML. XML é utilizado para codificar toda a comunicação de/para um web service. Web services

Leia mais

Soluções de integração: SOA, web services e REST + XML/XSD

Soluções de integração: SOA, web services e REST + XML/XSD Soluções de integração: SOA, web services e REST + XML/XSD WWW.DOMINANDOTI.COM.BR Acesse nosso site em WWW.DOMINANDOTI.COM.BR Cursos Livros Fórum Simulados Blog Materiais Turmas em Brasília, na sua cidade,

Leia mais

Success doesn't just happen. Success is planned.

Success doesn't just happen. Success is planned. EUISMOD ELEMENTUM Success doesn't just happen. Success is planned. Como expandir suas possibilidades técnicas e financeira? SOA adiciona em média 37% ao valor do salário. O livro My Job Went to India,

Leia mais

Serviços Web: Introdução

Serviços Web: Introdução Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e Tecnologia do Maranhão Objetivos Nesta aula

Leia mais

FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação

FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação 1 Ruironaldi dos Santos Cruz ARTIGO ARQUITETURA ORIENTADA A SERVIÇO SOA SERVICE

Leia mais

Desenvolvendo e Integrando Serviços Multiplataforma de TV Digital Interativa

Desenvolvendo e Integrando Serviços Multiplataforma de TV Digital Interativa Desenvolvendo e Integrando Serviços Multiplataforma de TV Digital Interativa Agenda Introdução Aplicações interativas de TV Digital Desafios de layout e usabilidade Laboratório de usabilidade Desafios

Leia mais

Porque adotar SOA. (Service Oriented Architecture) SOA. Por Ricardo de Castro Barbosa. Publicado Setembro/2008. 1 Portal BPM - www.portalbpm.com.

Porque adotar SOA. (Service Oriented Architecture) SOA. Por Ricardo de Castro Barbosa. Publicado Setembro/2008. 1 Portal BPM - www.portalbpm.com. SOA Porque adotar SOA (Service Oriented Architecture) Por Ricardo de Castro Barbosa Publicado Setembro/2008 Ricardo de Castro Barbosa é sócio da SOA- Savoir Faire (www.soa-savoirfaire.com.br) empresa dedicada

Leia mais

Desenvolvimento de Sistemas BPMS. Jhonatas Vicente de Jesus

Desenvolvimento de Sistemas BPMS. Jhonatas Vicente de Jesus Desenvolvimento de Sistemas BPMS Jhonatas Vicente de Jesus Roteiro de apresentação FastBPM TCC Recapitulando alguns Conceitos Sistemas BPMS Um Processo na prática Conclusão TCC - 2011 Desenvolvimento de

Leia mais

UNIVERSIDADE. Sistemas Distribuídos

UNIVERSIDADE. Sistemas Distribuídos UNIVERSIDADE Sistemas Distribuídos Ciência da Computação Prof. Jesus José de Oliveira Neto Web Services (continuação) WSDL - Web Service Definition Language WSDL permite descrever o serviço que será oferecido

Leia mais

PROGRAMA DE MBA em Gestão e Engenharia do Produto. O Produto Internet e suas Aplicações

PROGRAMA DE MBA em Gestão e Engenharia do Produto. O Produto Internet e suas Aplicações Universidade de São Paulo Escola Politécnica Programa de Educação Continuada em Engenharia PROGRAMA DE MBA em Gestão e Engenharia do Produto O Produto Internet e suas Aplicações Tecnologias de Informação

Leia mais

Casa do Código Livros para o programador Rua Vergueiro, 3185-8º andar 04101-300 Vila Mariana São Paulo SP Brasil

Casa do Código Livros para o programador Rua Vergueiro, 3185-8º andar 04101-300 Vila Mariana São Paulo SP Brasil 2012, Casa do Código Todos os direitos reservados e protegidos pela Lei nº9.610, de 10/02/1998. Nenhuma parte deste livro poderá ser reproduzida, nem transmitida, sem autorização prévia por escrito da

Leia mais

Gerenciamento e Interoperabilidade de Redes

Gerenciamento e Interoperabilidade de Redes EN-3610 Gerenciamento e Interoperabilidade de Redes Gerenciamento baseado na Web Prof. João Henrique Kleinschmidt Gerenciamento baseado na Web Web browser Acesso ubíquo Interface Web vs Gerenciamento baseado

Leia mais

Abstraindo as Camadas de SOA & Aplicações Compostas

Abstraindo as Camadas de SOA & Aplicações Compostas Abstraindo as Camadas de SOA & Aplicações Compostas Serviço Service Requisitante Consumer Service Serviço Provider Provedor consumidores processos business e processes negócios Coreografia process choreography

Leia mais

Integração de sistemas utilizando Web Services do tipo REST

Integração de sistemas utilizando Web Services do tipo REST Integração de sistemas utilizando Web Services do tipo REST Jhonatan Wilson Aparecido Garbo, Jaime Willian Dias Universidade Paranaense (Unipar) Paranavaí PR Brasil jhowgarbo@gmail.com jaime@unipar.br

Leia mais

Programação WEB Introdução

Programação WEB Introdução Programação WEB Introdução Rafael Vieira Coelho IFRS Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Sul Campus Farroupilha rafael.coelho@farroupilha.ifrs.edu.br Roteiro 1) Conceitos

Leia mais

Universidade Federal de Juiz de Fora Ciência da Computação Sistemas Distribuídos Professor Ciro Barbosa

Universidade Federal de Juiz de Fora Ciência da Computação Sistemas Distribuídos Professor Ciro Barbosa Universidade Federal de Juiz de Fora Ciência da Computação Sistemas Distribuídos Professor Ciro Barbosa Web Service Plínio Antunes Garcia Sam Ould Mohamed el Hacen Sumário Introdução conceitual O Web Service

Leia mais

Cliente/Servidor. Conceitos Gerais. Graça Bressan. Graça Bressan/LARC 2000 1

Cliente/Servidor. Conceitos Gerais. Graça Bressan. Graça Bressan/LARC 2000 1 Cliente/Servidor Conceitos Gerais Graça Bressan Graça Bressan/LARC 2000 1 Forças de marketing que conduzem à arquitetura cliente/servidor "Cliente/Servidor é um movimento irresistível que está reformulando

Leia mais

Prática da Disciplina de Sistemas Distribuídos Serviços Web IFMA DAI Professor Mauro Lopes C. Silva

Prática da Disciplina de Sistemas Distribuídos Serviços Web IFMA DAI Professor Mauro Lopes C. Silva 1. O que são Serviços Web (Web Services)? Prática da Disciplina de Sistemas Distribuídos Serviços Web IFMA DAI Professor Mauro Lopes C. Silva A ideia central dos Web Services parte da antiga necessidade

Leia mais

SINS: Um ambiente para geração de aplicações baseadas em serviços

SINS: Um ambiente para geração de aplicações baseadas em serviços SINS: Um ambiente para geração de aplicações baseadas em serviços Sérgio Larentis Jr (Unisinos) Andrêsa Larentis (Unisinos) Jorge Barbosa (Unisinos) Sérgio Crespo C. S. Pinto (Unisinos) SBSI 2008 Roteiro

Leia mais

INTEGRAÇÃO DE APLICAÇÕES UTILIZANDO WEB SERVICE. Kellen Kristine Perazzoli 1, Manassés Ribeiro 2 RESUMO

INTEGRAÇÃO DE APLICAÇÕES UTILIZANDO WEB SERVICE. Kellen Kristine Perazzoli 1, Manassés Ribeiro 2 RESUMO INTEGRAÇÃO DE APLICAÇÕES UTILIZANDO WEB SERVICE Kellen Kristine Perazzoli, Manassés Ribeiro RESUMO O grande avanço tecnológico vivenciado nos últimos anos, os web services vem sendo utilizados trazendo

Leia mais

Sistemas Distribuídos na Web. Pedro Ferreira DI - FCUL

Sistemas Distribuídos na Web. Pedro Ferreira DI - FCUL Sistemas Distribuídos na Web Pedro Ferreira DI - FCUL Arquitetura da Web Criada por Tim Berners-Lee no CERN de Geneva Propósito: partilha de documentos Desde 1994 mantida pelo World Wide Web Consortium

Leia mais

soluções transversais SOLUÇÕES middleware

soluções transversais SOLUÇÕES middleware soluções transversais SOLUÇÕES middleware RESUMO DA SOLUÇÃO ITbank framework 4g performance orquestração interoperabilidade O Middleware SOA ITBank framework 4g implementa uma arquitetura SOA com orquestração

Leia mais

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO ESCOLA POLITÉCNICA DEPARTAMENTO DE ELETRÔNICA E DE COMPUTAÇÃO

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO ESCOLA POLITÉCNICA DEPARTAMENTO DE ELETRÔNICA E DE COMPUTAÇÃO UNIVERSIDADE FEDERAL DO RIO DE JANEIRO ESCOLA POLITÉCNICA DEPARTAMENTO DE ELETRÔNICA E DE COMPUTAÇÃO ESTUDO SOBRE INTEGRAÇÃO DE SISTEMAS COMPUTACIONAIS BASEADA EM ARQUITETURA ORIENTADA A SERVIÇOS Autor:

Leia mais

Web Services. Autor: Rômulo Rosa Furtado

Web Services. Autor: Rômulo Rosa Furtado Web Services Autor: Rômulo Rosa Furtado Sumário O que é um Web Service. Qual a finalidade de um Web Service. Como funciona o serviço. Motivação para o uso. Como construir um. Referências. Seção: O que

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos LICENCIATURA EM COMPUTAÇÃO Prof. Adriano Avelar Site: www.adrianoavelar.com Email: eam.avelar@gmail.com Mecanismos de Comunicação Protocolos de Aplicação Mecanismos de comunicação

Leia mais

Introdução Serviços Web WSDL SOAP UDDI Ferramentas. Serviços Web. (Web Services) Emerson Ribeiro de Mello

Introdução Serviços Web WSDL SOAP UDDI Ferramentas. Serviços Web. (Web Services) Emerson Ribeiro de Mello 1/39 Serviços Web (Web Services) Emerson Ribeiro de Mello Departamento de Automação e Sistemas Universidade Federal de Santa Catarina 22 de Maio de 2007 2/39 Arquitetura Orientada a Serviços Arquitetura

Leia mais

Sistemas Distribuídos Arquiteturas Middlewares

Sistemas Distribuídos Arquiteturas Middlewares Sistemas Distribuídos Arquiteturas s Arquitetura Arquitetura de um sistema é sua estrutura em termos dos componentes e seus relacionamentos Objetivo: garantir que a estrutura satisfará as demandas presentes

Leia mais

SOA-1: Fundamentos da Arquitetura Orientada a Serviços. Douglas Charcon System Engineer

SOA-1: Fundamentos da Arquitetura Orientada a Serviços. Douglas Charcon System Engineer SOA-1: Fundamentos da Arquitetura Orientada a Serviços Douglas Charcon System Engineer Agenda Direcionadores de Negócios Arquitetura Orientada a Serviços Enterprise Service Bus Enhanced SOA Resumo 2 Busca

Leia mais

Ferramentas unificadas de SOA alinham negócios e TI IDG Research aponta grandes ganhos potenciais a partir de uma solução integrada

Ferramentas unificadas de SOA alinham negócios e TI IDG Research aponta grandes ganhos potenciais a partir de uma solução integrada Insight completo sobre IDG/Oracle Relatório de pesquisa de SOA Ferramentas unificadas de SOA alinham negócios e TI IDG Research aponta grandes ganhos potenciais a partir de uma solução integrada Alinhamento

Leia mais

UNIVERSIDADE FEDERAL DO ESTADO DO RIO DE JANEIRO ESCOLA DE INFORMÁTICA APLICADA CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO

UNIVERSIDADE FEDERAL DO ESTADO DO RIO DE JANEIRO ESCOLA DE INFORMÁTICA APLICADA CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO UNIVERSIDADE FEDERAL DO ESTADO DO RIO DE JANEIRO ESCOLA DE INFORMÁTICA APLICADA CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO Uma Abordagem Prática para Desenvolvimento de Web Services com Contract-First

Leia mais

MADALENA PEREIRA DA SILVA SLA Sociedade Lageana de Educação DCET Departamento de Ciências Exatas e Tecnológica

MADALENA PEREIRA DA SILVA SLA Sociedade Lageana de Educação DCET Departamento de Ciências Exatas e Tecnológica MADALENA PEREIRA DA SILVA SLA Sociedade Lageana de Educação DCET Departamento de Ciências Exatas e Tecnológica Desenvolvimento de Web Services com SOAP. 1. Introdução. Com a tecnologia de desenvolvimento

Leia mais

PÓS-GRADUAÇÃO Lato Sensu. Gestão e Tecnologia da Informação

PÓS-GRADUAÇÃO Lato Sensu. Gestão e Tecnologia da Informação IETEC - INSTITUTO DE EDUCAÇÃO TECNOLÓGICA PÓS-GRADUAÇÃO Lato Sensu Gestão e Tecnologia da Informação BAM: Analisando Negócios e Serviços em Tempo Real Daniel Leôncio Domingos Fernando Silva Guimarães Resumo

Leia mais

Programação para a Internet. Prof. M.Sc. Sílvio Bacalá Jr sbacala@gmail.com www.facom.ufu.br/~bacala

Programação para a Internet. Prof. M.Sc. Sílvio Bacalá Jr sbacala@gmail.com www.facom.ufu.br/~bacala Programação para a Internet Prof. M.Sc. Sílvio Bacalá Jr sbacala@gmail.com www.facom.ufu.br/~bacala A plataforma WEB Baseada em HTTP (RFC 2068) Protocolo simples de transferência de arquivos Sem estado

Leia mais

Documento apresentado para discussão. II Encontro Nacional de Produtores e Usuários de Informações Sociais, Econômicas e Territoriais

Documento apresentado para discussão. II Encontro Nacional de Produtores e Usuários de Informações Sociais, Econômicas e Territoriais Documento apresentado para discussão II Encontro Nacional de Produtores e Usuários de Informações Sociais, Econômicas e Territoriais Rio de Janeiro, 21 a 25 de agosto de 2006 PID - Projeto de Interoperabilidade

Leia mais

Serviços Web: Arquitetura

Serviços Web: Arquitetura Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e Tecnologia do Maranhão Objetivos Nesta aula

Leia mais

Workshop BPM e SOA. Conceitos sobre BPMN, BPMS, BAM e BPMM

Workshop BPM e SOA. Conceitos sobre BPMN, BPMS, BAM e BPMM Workshop BPM e SOA Conceitos sobre BPMN, BPMS, BAM e BPMM Mudanças... >> Meus sistemas estão adequados aos meus processos? Gestor de Business Com meus processos de negócio desenhado, como faço para alinhar

Leia mais

Sistemas Empresariais Integrados

Sistemas Empresariais Integrados Sistemas Empresariais Integrados Introdução Basic MOM: in basic MOM it is the sender who specifies the identity of the receivers sender receiver message broker core : with message brokers, custom message

Leia mais

INFRAESTRUTURA DE TI E TECNOLOGIAS EMERGENTES

INFRAESTRUTURA DE TI E TECNOLOGIAS EMERGENTES Sistema de Informação e Tecnologia FEQ 0411 Prof Luciel Henrique de Oliveira luciel@uol.com.br Capítulo 5 INFRAESTRUTURA DE TI E TECNOLOGIAS EMERGENTES PRADO, Edmir P.V.; SOUZA, Cesar A. de. (org). Fundamentos

Leia mais

Linha de Produto para BPM

Linha de Produto para BPM Linha de Produto para BPM Prof. Dr. Marcelo Fantinato m.fantinato@usp.br Sistemas de Informação, EACH/USP Agenda Fundamentos LP para BPM Estabelecimento de Contratos Exemplo de Aplicação Trabalhos em Andamento/Próximos

Leia mais

Kassius Vargas Prestes

Kassius Vargas Prestes Kassius Vargas Prestes Agenda 1. Introdução Web Services 2. XML, SOAP 3. Apache Tomcat 4. Axis 5. Instalação Tomcat e Axis 6. Criação de um Web Service 7. Criação de um cliente Baixar http://www.inf.ufrgs.br/~kvprestes/webservices/

Leia mais

Gerenciamento de aplicações compostas: Preenchendo a lacuna de visibilidade da TI em aplicações compostas complexas Um artigo técnico da Oracle,

Gerenciamento de aplicações compostas: Preenchendo a lacuna de visibilidade da TI em aplicações compostas complexas Um artigo técnico da Oracle, Gerenciamento de aplicações compostas: Preenchendo a lacuna de visibilidade da TI em aplicações compostas complexas Um artigo técnico da Oracle, novembro de 2008. Gerenciamento de aplicações compostas:

Leia mais

Integre pela Internet com os Web Services OpenEdge

Integre pela Internet com os Web Services OpenEdge Integre pela Internet com os Web Services OpenEdge Luciano Oliveira Solution Consultant, Progress OpenEdge Foco da Sessão Implementando OpenEdge Web Services Entendendo Web Services Identificar quando

Leia mais

WS-BPEL Web Service Business Process Execution Language

WS-BPEL Web Service Business Process Execution Language DAS5316 WS-BPEL Web Service Business Process Execution Language Prof. Ricardo J. Rabelo (rabelo@das.ufsc.br) Responsável pela elaboração dos slides Alexandre Perin (perin@das.ufsc.br) Florianópolis (SC),

Leia mais

Inspeção da Ferramenta Oracle BPEL PM

Inspeção da Ferramenta Oracle BPEL PM UNIVERSIDADE FEDERAL DO ESTADO DO RIO DE JANEIRO CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA Relatórios Técnicos do Departamento de Informática Aplicada da UNIRIO n 0016/2009 Inspeção da Ferramenta Oracle BPEL

Leia mais

Web Services e SOAP. Alexandre Zua CaldeiraTecnologias de Middleware 2006/2007 20.10.2006. Faculdade de Ciências da Universidade de Lisboa

Web Services e SOAP. Alexandre Zua CaldeiraTecnologias de Middleware 2006/2007 20.10.2006. Faculdade de Ciências da Universidade de Lisboa Alexandre Zua Caldeira Tecnologias de Middleware 2006/2007 Faculdade de Ciências da Universidade de Lisboa 20.10.2006 1 Introdução Definições Limitações do Middleware Estudado Integração com Web Services

Leia mais

O desafio de uma visão mais ampla

O desafio de uma visão mais ampla com SAP NetWeaver BPM Descrição de Solução A competição acirrada tem levado as organizações a adotar novas disciplinas de gestão e empregar recursos tecnológicos avançados, a fim de atingir melhores índices

Leia mais

Curso de Aprendizado Industrial Desenvolvedor WEB

Curso de Aprendizado Industrial Desenvolvedor WEB Curso de Aprendizado Industrial Desenvolvedor WEB Disciplina: Programação Orientada a Objetos II Professor: Cheli dos S. Mendes da Costa Modelo Cliente- Servidor Modelo de Aplicação Cliente-servidor Os

Leia mais

CONSTRUÇÃO DE APLICAÇÕES DISTRIBUÍDAS UTILIZANDO SERVIÇOS WEB

CONSTRUÇÃO DE APLICAÇÕES DISTRIBUÍDAS UTILIZANDO SERVIÇOS WEB CONSTRUÇÃO DE APLICAÇÕES DISTRIBUÍDAS UTILIZANDO SERVIÇOS WEB Deusa Cesconeti e Jean Eduardo Glazar Departamento de Ciência da Computação Faculdade de Aracruz UNIARACRUZ {dcescone, jean}@fsjb.edu.br RESUMO

Leia mais

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE Aluno: Roberto Reinert Orientador: Everaldo A. Grahl Roteiro de apresentação Introdução Objetivos Fundamentação Teórica Workflow Processo

Leia mais

CORBA. Common Object Request Broker Architecture. Unicamp. Centro de Computação Rubens Queiroz de Almeida queiroz@unicamp.br

CORBA. Common Object Request Broker Architecture. Unicamp. Centro de Computação Rubens Queiroz de Almeida queiroz@unicamp.br CORBA Common Object Request Broker Architecture Unicamp Centro de Computação Rubens Queiroz de Almeida queiroz@unicamp.br Objetivos Apresentação Tecnologia CORBA Conceitos Básicos e Terminologia Considerações

Leia mais