e-infraestruturas para Ciência e Engenharia Walter Abrahão Santos, LAC-INPE walter.abrahao@lac.inpe.

Transcrição

1 Capítulo 1 e-infraestruturas para Ciência e Engenharia Walter Abrahão Santos, LAC-INPE walter.abrahao@lac.inpe.br 1 Introdução A grande motivação deste trabalho foi o crescente número de projetos empregando recursos de aplicações eletrônicas, necessidade de tentar difundir conhecimento já pré-existente em torno desta temática e a rápida convergência de tecnologias. No INPE, vários projetos empregando e-infraestruturas estão em andamento focados nas áreas técnico-científicas do instituto como veremos ao longo deste trabalho. No Brasil, dentro do Congresso da Sociedade Brasileira de Computação, anualmente é realizado o evento e-science Workshop o qual em sua 4ª edição motiva a participação de interessados usando a seguinte exposição (CSBC, 2010): Nas últimas décadas, tem havido uma revolução no modo como ciência e engenharia têm sido conduzidas. Nesta revolução, a Computação tem se estabelecido como um terceiro tipo de ciência, ao lado de teoria e experimentação. A ciência de apoio computacional à experimentação cientifica tem sido chamada de e-ciência (do inglês e-science). Neste novo modo de fazer ciência, pesquisadores precisam explorar grandes coleções de dados, além de utilizar, através de uma rede de alto desempenho, recursos computacionais em larga escala que estão geograficamente distribuídos. Além disso, tais pesquisadores também necessitam de alto desempenho em tarefas de visualização de seus resultados experimentais. Como conseqüência destas novas demandas, novos problemas relacionados à modelagem e gerenciamento de dados científicos, software e de todo o conhecimento envolvido neste cenário precisam ser resolvidos. Para resolver essa nova geração de problemas científicos, equipes de pesquisadores multidisciplinares e distribuídas precisam colaborar para progredir nestes novos Grandes Desafios. Recentes avanços em pesquisa em Computação incluindo ontologias, inteligência artificial, modelagem de workflows científicos,

2 serviços web semânticos, gerenciamento de componentes de software, computação em grade (grid), modelagem de recursos, proveniência de dados e processos, curadoria de dados, entre outros podem ajudar nestes Grandes Desafios. Vários projetos nacionais e internacionais ao redor do mundo têm sido iniciados para realizar pesquisas que transformarão o objetivo de e-science e computação em grande em uma realidade. Apesar da limitação de espaço e tempo, este texto tenta abranger uma variedade enorme de tópicos relevantes, ainda que superficialmente, e está organizado nas seguintes sessões: (1) apresenta introdução e as tendências emergentes em Engenharia de Software; (2) fundamentos de Orientação a Objetos, UML e Padrões como blocos construtivos para e-infraestruturas; (3) uma breve introdução a Arquitetura Orientada a Serviços (SOA) e Web Services (WS); (4) os principais padrões, protocolos, especificações e semântica para WS são apresentados bem como em (5) as principais tecnologias WS: XML, WSDL, SOAP e UDDI; (6) a composição de serviços, Mashups, adoção nas empresas e tendências de Mercado; (7) aborda brevemente com Web Semântica, Ontologias, Clouds e Grids e finalmente (8) ilustra dois estudos de caso, um observatório virtual para aplicações de e-science e um ambiente colaborativo para Engenharia de Sistemas de satélites usando um Barramento Corporativo de Serviços (SpaceESB) focado em e-engineering. Comentários finais e referências completam o trabalho que se espera auxiliar para melhor entendimento da área. 1.1 Tendências Emergentes em Engenharia de Software A área de Engenharia de Software constantemente se adéqua aos novos desafios impostos na construção eficiente de sistemas. Pressman menciona que sistemas software intensivos tornaram-se hoje parte central de praticamente qualquer tecnologia moderna uma vez que (PRESSMAN, 2005) : (a) Software contido em virtualmente qualquer produto ou serviço irá continuar a crescer e em alguns casos dramaticamente; (b) Software deve ser comprovadamente seguro, íntegro e confiável; (c) Requisitos irão surgir à medida em que sistemas evoluem; (d) Interoperabilidade e conectividade irão ser tornar dominantes à medida que mash-ups 1 tornam-se padrões em desenvolvimento e (e) Um mundo inteligente requer software mais elaborado e confiável. Neste contexto, Pressman também apresenta tendências na engenharia destes novos sistemas de software dividindo-as em soft e hard em sua dificuldade. As 1 Mash-ups são páginas Web ou aplicações que usam e combinam dados, apresentação e funcionalidades de duas ou mais fontes para gerar novos serviços.

3 tendências soft se concentram em (a) características gerais dos novos sistemas que construímos e testamos, por exemplo: requisitos emergentes e autonomia de ação e (b) características sócio-antropológicas da nova geração de pessoas trabalham na engenharia de software. As tendências hard são: (a) os aspectos técnicos da próxima geração de sistemas software-intesivos e (b) as direções técnicas que processos, métodos e ferramentas de engenharia de software irão tomar. Este mini-curso estará focado em atender as tendências hard no tocante aos aspectos técnicos na infraestrutura de construção de sistemas para e-science e mais especificamente e-engineering. Para tanto discutiremos, em linha geral, como estes sistemas requerem uma abordagem de Orientação a Objetos que emprega UML e Padrões de projetos para aumentar produtividade e eficiência em reuso na seção 2. A adoção de uma arquitetura orientada a serviços (SOA) e serviços web lida com a complexidade de construção como mostrado na seção 3. Os padrões, protocolos e especificações e a semântica para Web Services na seção 4 são elucidados. Na seção 5, as principais tecnologias de Web Services, como XML, WSDL, SOAP e UDDI são apresentadas. Na seção 6 mostra como estas aplicações são construídas pela composição de serviços, mash-ups bem como está sua adoção nas empresas e quais as tendências de mercado. Na seção 7 mostra como a Web Semântica e Ontologias auxiliam na geração destes sistemas e como podem se materializar em formas como computação em Nuvem (Cloud) e em Grade (Grid). Finalmente, na seção 8 são apresentados alguns estudos de casos em e-science e e-engineering com subseqüente fechamento em comentários finais e referências bibliográficas. 2 Fundamentos de Orientação a Objetos, UML e Padrões Um dos maiores desafios na construção de sistemas software-intensivo é lidar com aspectos de complexidade e tamanho. Neste contexto esta seção apresenta algumas direções visando aumentar produtividade e eficiência em reuso mediante a metodologia de Orientação a Objetos, modelagem e documentação que emprega UML e emprego de padrões de projetos. 2.1 Orientação a Objetos (OO) Orientação a Objetos (OO) é um paradigma de construção de software, ou seja, uma maneira de abordar o problema de escrita de software através da abstração de sua

4 realidade no que chamamos de objetos, os quais possuem um nome, atributos e métodos ou operações. Como mostrado na Figura 1, um programa OO seria, portanto é um conjunto de objetos que trocam mensagens entre si invocando no final seus métodos e alterando seus atributos. Os objetos são próprios do domínio do problema. Figura 1 Abstração de um programa orientado a objetos em execução Objetos são na realidade instâncias do que chamamos de classes. Um software de bordo para controle de satélites pode ter classes específicas para sensores, atuadores, interfaces, controladores, etc. Estes quando instanciados tornam-se objetos, por exemplo, sensor solar SS1, magnetotorqueador MT2, etc. Conforme a Figura 02, classes podem se relacionar entre si e uma das principais são relações Generalização/Especialização. Para um maior aprofundamento vide (PRESSMAN, 2005) e (FOWLER, 2005). Figura 2 Generalização/Especialização entre classes e instanciação de objetos

5 2.2 UML Linguagem de Modelagem Unificada Para facilitar a construção de sistemas utilizamos modelos que são uma simplificação da realidade. A UML (Unified Modeling Language) é hoje o padrão de facto para modelagem de sistemas após ter sido consolidada por grandes especialistas na área (PRESSMAN, 2005) (FOWLER, 2005). A UML é uma linguagem visual de modelagem empregada em qualquer processo de desenvolvimento. Ela consiste de um conjunto de diagramas, vide Figura 03, focados em aspectos de caráter estrutural ou comportamental e construídos utilizando blocos fundamentais da UML como mostrado na Figura 04, por exemplo, para sistemas para Tempo Real (RATIONAL, 2003). Figura 3. Diagramas da UML (MORAES, 2012) Figura 4. Blocos fundamentais de construção UML para aplicações de Tempo Real (RATIONAL, 2003) 2.3 Padrões Com a introdução de OO e crescimento em tamanho de sistemas, questões de recorrência em projetos foram surgindo o que motivou o emprego da idéia de padrões, que fundamentalmente oferecem exemplos de projetos. Padrões descrevem maneiras comuns de se fazer coisas e são coletadas por profissionais que encontram temas recorrentes em sistemas (FOWLER, 2005). A fase de projeto em que são usados, e.g.

6 Análise, Projeto, etc., define a classe de padrões. Há um repositório na web, mantido pelo The Hillside Group (HILLSIDE, 2012), que congrega diversos padrões nos mais diversos domínios promovendo o uso de padrões e linguagens de padrões para registrar, analisar e melhorar software e seu desenvolvimento. Para nosso trabalho dois grupos de padrões são particularmente importantes: padrões GOF (Gang of Four) e padrões Java 2EE (Enterprise Edition). Os padrões GOF, em número de 23 padrões, denominação devida aos seus quatro autores (GAMMA, 1994) e, como esquematizado na Figura 5, se dividem em três grandes grupos pelo propósito: Criação, Estrutura e Comportamento. Figura 5. Os 23 padrões GOF (Gang of Four) (GAMMA, 1994) Diversas aplicações que e-infraestruturas possuem uma grande quantidade de características comuns que podem ser otimizadas mediante o emprego de padrões. A Java 2 Platform, Enterprise Edition (J2EE ) contém padrões que são mais recentes que os padrões GOF e advém do uso difundido de Java como linguagem de construção de algumas aplicações (J2EE, 2012). Os relacionamentos entre os diversos padrões J2EE são mostrados na Figura 6 onde são divididos por camadas. Atualmente, um grande número de desenvolvedores deseja escrever aplicações com transações distribuídas para suas instituições e assim incrementar a velocidade, segurança e confiabilidade da tecnologia no lado do servidor de aplicações. Para aqueles já nesta área, é notória a rápida demanda para que aplicações institucionais sejam projetadas, construídas e produzidas com menor custo, maior velocidade, e poucos recursos. Visando reduzir custos e aumentar rapidez no projeto e

7 desenvolvimento, o J2EE provê uma solução baseada em componentes para projeto, desenvolvimento, montagem e implantação de aplicações empresariais. Figura 6. Os relacionamentos entre os diversos padrões J2EE (J2EE, 2012) A plataforma J2EE, conforme a Figura 7 oferece um modelo de aplicação distribuída multicamadas e com componentes reutilizáveis, um modelo unificado de segurança lógica, um controle flexível de transações e suporte a web services através de padrões e protocolos abertos baseados em uma linguagem extensível de marcação, o XML (Extensible Markup Language).

8 Figura 7. Modelo de Aplicações utilizando J2EE - Resumidamente, para se desenvolver aplicações Java para a web e distribuídas com maior facilidade e robustez, serão empregados vários especificações J2EE, como JSP, Servlets, Web Services, EJB, etc. Particularmente, EJBs são componentes Java distribuídos, que são executados em um servidor de aplicações, JBOSS ou GlassFish por exemplo. A aplicação cliente pode se conectar remotamente a um desses servidores de aplicações, instanciar um EJB e utilizá-lo como o mesmo fosse uma classe local. Todas as funcionalidades relativas a transações, segurança, persistência de dados, etc. são responsabilidade do servidor de aplicações poupando tempo do programador desses detalhes. Entretanto a curva de aprendizado para EJBs requer grande empenho (J2EE, 2012). 3 Introdução à Arquitetura Orientada a Serviços (SOA) e WS Ao longo de muitos anos, as empresas investem cada vez mais no desenvolvimento de soluções de TI. Essas soluções têm plataformas, linguagens de programação, paradigmas de programação e até middleware diferentes, fazendo com que haja uma grande redundância de funcionalidades e alto acoplamento entre as soluções.

9 Devido a esse crescimento desordenado, essas empresas possuem inúmeras aplicações legadas que não podem ser descartadas e necessitam ser integradas às novas soluções. Ao contrário do que muitos pensam a Arquitetura Orientada a Serviços não foi inventada. SOA é uma evolução natural da arquitetura de sistemas tradicional em resposta às demandas de um mercado que exibe, a cada dia, mais agilidade e qualidade (ERL, 2004). O modelo arquitetônico SOA acomoda inúmeras visões e consolida qualidades oriundas da arquitetura dos objetos distribuídos e componentes, como: distribuição, reutilização, contratos, estilo modular, baixo acoplamento e conectividade (LAZZERI, 2010). Segundo a OASIS, 2006, SOA é um paradigma para organizar e utilizar competências distribuídas que podem estar sob controle de diferentes domínios proprietários, é um meio para organizar as soluções que promovem o reuso, crescimento e interoperabilidade. O uso de SOA muda a maneira como as soluções são desenvolvidas e implementadas, a exposição das funcionalidades do negócio como serviços possibilita às empresas respostas mais rápidas às mudanças do mercado. SOA permite também que os sistemas já existentes sejam combinados com novos esforços de desenvolvimento (aplicativos compostos). Daí a motivação em empregá-la como base para alguns processos de engenharia de sistemas. Freqüentemente, na Arquitetura Orientada a Serviços, os serviços são organizados através de um barramento de serviços que disponibiliza interfaces, ou contratos, acessíveis através de web services ou outra forma de comunicação entre aplicações. A arquitetura SOA, mostrada genericamente na Figura 8, é baseada nos princípios da computação distribuída e utiliza o paradigma request / reply para estabelecer a comunicação entre os sistemas clientes e os sistemas que implementam os serviços (WU et al., 2008). Neste cenário, o provedor de serviços publica e registra um serviço em um repositório. O consumidor de serviços utiliza o registro para obter o contrato do serviço, que contém informações sobre as operações disponíveis e os parâmetros que o serviço

10 necessita para se comunicar. Através desse contrato o consumidor inicia as requisições ao serviço. Figura 8 - Esquema básico do ambiente SOA (W3C, 2002). A Engenharia de Software, no decorrer dos anos, evoluiu da programação estruturada para a orientada a objetos, para a baseada em componentes, e por fim para a orientada a serviços. Cada uma das evoluções se baseia na abstração anterior e SOA abrange as melhores práticas da orientação a objetos e componentes. A Figura 9 ilustra os diferentes níveis de abstração: de objetos a serviços (HOLLEY; ARSANJANI, 2010). Figura 9 - Níveis de abstração até SOA (HOLLEY; ARSANJANI, 2010) Conforme mostra a Figura 10, SOA tem como base os seguintes aspectos: interface com consumidor, processos de negócio, serviços, componentes de serviço, sistemas operacionais e integração. Adicionalmente, os aspectos de SOA são representados em camadas lógicas que podem ser usadas como diretrizes para o projeto de soluções orientadas a serviços.

11 Figura 10 - Camadas lógicas da Arquitetura SOA, (Open Group, 2009). A partir da Figura 10, fica claro que SOA evoluiu a partir das camadas de provedores de serviços, focadas na construção de objetos e componentes usando as abordagens orientada a objetos e a componentes, para a integração com as camadas de consumidores de serviços, focadas na construção e orquestração de serviços para implementar os processos de negócios usando a abordagem orientada a serviços. O modelo de camadas apresentado é apenas uma referência para Arquitetura Orientada a Serviços que permite entendimento das entidades significativas e os relacionamentos entre elas em um ambiente orientado a serviço. 3.1 Web Services SOA e web services muitas vezes são tratados como sinônimos, mas não são a mesma coisa (JOSUTTIS, 2007). Em SOA as atividades do negócio são expostas como serviços. O web service é uma das possíveis maneiras de se colocar em prática as características de SOA (MORO et al., 2009). A implementação da Arquitetura Orientada a Serviços tem sido realizada através de web services, pois essa tecnologia tem se consolidado como uma das mais adequadas para a integração de sistemas heterogêneos (MOREIRA, 2005). Outros exemplos de arquiteturas que podem ser usadas para a implementação de SOA são (SOMMERVILLE, 2007): CORBA (Common Object Request Broker Architecture), que define uma arquitetura de objetos para a computação distribuída, DCOM

12 (Distributed Component Object Model), promovido pela Microsoft e JavaRMI (Java Remote Method Invocation). Um serviço em SOA deve ter os seguintes atributos (HOLLEY; ARSANJANI, 2010): (a) Sem estado (Stateless): os web services não dependem do contexto ou do estado de outros serviços. Um serviço stateless não guarda o estado e trata cada requisição como uma transação nova e independente, sem relação com requisições anteriores ou futuras; (b) Detectável: um web service deve ser descoberto por potenciais consumidores do serviço. Serviços são publicados em um repositório pelos provedores de serviços, assim aqueles podem ser detectados e invocados; (c) Autodescrição: um web service deve ter um contrato ou interface bem definido, descrevendo as informações que um consumidor de serviços necessita para descobrir e conectar-se ao serviço; (d) Combinável: um web service pode compor e/ou ser composto por outros serviços para criar novas soluções; (e) Baixo acoplamento: é a capacidade de um serviço ser independente de outros serviços para realizar uma tarefa; (f) Regido por políticas: Serviços são construídos por contrato. Relações entre os serviços são regidas por políticas e acordos de nível de serviço (SLA - Service Level Agreement), promovendo a consistência do processo e reduzindo a complexidade; (g) Localização, linguagem e protocolos independentes: serviços são projetados para serem transparentes, sendo acessíveis por qualquer usuário, em qualquer plataforma, de qualquer lugar. 4 Padrões, protocolos, especificações e semântica para WS Utilizando padrões, protocolos, especificações e semântica para WS é possível materializar os atributos anteriormente mencionados para SOA. Segundo o W3C, 2004, web services são usados na integração de sistemas e na comunicação entre diferentes aplicações. A Figura 11 mostra alguns padrões W3C para WS onde é possível utilizálos para integrar aplicações escritas em diferentes linguagens e executando em diferentes plataformas através de mensagens baseadas em XML (extensible Markup Language).

13 Figura 11 Padrões W3C para Web services, disponível em: As trocas de informações realizadas com web services utilizam um canal de comunicação, geralmente, o protocolo HTTP (Hypertext Transfer Protocol). Na Figura 12, mostra-se a pilha de protocolos que apóiam a utilização de WS. Existem alguns tipos de arquiteturas para o desenvolvimento de web services, entretanto o RPC, WS-* (WSDL/SOAP) e REST os mais conhecidos e usados hoje em dia. A arquitetura WS-* é a mais utilizada hoje em dia e é composta por mais de 20 especificações, donde SOAP, WSDL e UDDI são as especificações base deste conjunto e descritas a seguir (MORO et al., 2009). Figura 12 Pilha de protocolos na utilização de WS (BASTOS, 2011)

14 Alguns dos principais padrões para WS são: (a) Camada de Transporte (protocolos de transporte); (b) Camada de Mensagem (XML, SOAP); (c) Camada de Descrição (Descrição de Serviços: WSDL, XSD); (d) Camada de Descoberta (Registro de Serviço: UDDI) e (e) Camada de Processo (BPEL). Há alguns padrões para Web Services que definem frameworks para Coordenação de Serviços, dentre eles é destacado o WS-Transactions que é uma família de especificações da OASIS compreendendo: (a) WS-BusinessActivity (WS- BA); (b) WS-AtomicTransaction (WS-AT) e (c) WS-Coordination (WS-C): framework genérico que suporta WS-AT e WS-BA. 5 Principais tecnologias WS: XML, WSDL, SOAP e UDDI. As principais tecnologias envolvidas em WS são mostradas na Figura 13, tais como o consumidor de serviço, o provedor serviço e seu relacionamento. O consumidor de serviços invoca ou usa um serviço mediante a descrição do serviço em WSDL (Web Service Definition Language) para obter as informações necessárias para consumir o serviço. Um broker é usado para encontrar um serviço publicado em UDDI (Universal Description Discovery & Integration). Provedores de serviços utilizam UDDI para publicar os serviços que eles oferecem. Consumidores de serviços usam UDDI para descobrir serviços que lhes interessam e obter os dados necessários para utilizar esses serviços. Figura 13 Web services, protocolos e mensagens, (GOTTSCHALK, al., 2002).

15 5.1 XML O XML (extensible Markup Language )é uma linguagem capaz de descrever diversos tipos de dados. O XML, cujo trecho exemplo é mostrado na Figura 14, é uma recomendação para gerar linguagens de marcação para necessidades especiais e tem como propósito principal é a facilidade de compartilhamento de informações através da internet com capacidade de descrever diversos tipos de dados. Figura 14 Trecho do arquivo WSDL de WS com XML (SOUZA, 2011) Por criar uma infraestrutura única para diversas linguagens e ser uma tecnologia simples, ferramentas que lidam com XML permitem que programadores dediquem seus esforços às tarefas importantes quando trabalha com os dados, pois realizam a validação destes percorrendo as estruturas. 5.2 SOAP O SOAP (Simple Object Access Protocol) é um protocolo padrão para troca de mensagens. Como SOAP adota um formato XML, o qual é baseado em texto, SOAP é interpretado pela maioria de ambientes novos, e já existentes, e pode ser transportado sobre vários protocolos. Na maioria das vezes SOAP é transportado sobre o protocolo HTTP, mas também já existem implementações que enviam SOAP usando JMS (Java Message Service).

16 Em web services uma requisição feita por um consumidor de serviços é formatada em uma mensagem XML, a qual é encapsulada utilizado o protocolo SOAP para ser transportado sobre HTTP. No provedor de serviços, essa mensagem é desempacotada, os dados são lidos e processados e o resultado é novamente encapsulado por SOAP e enviado pelo protocolo HTTP ao solicitante. 5.3 UDDI O UDDI é um diretório de serviços que permite a descrição e descoberta de: (1) empresas, organizações e outros provedores de serviços, (2) web services disponíveis, e (3) as interfaces que podem ser utilizadas para acessar esses serviços. Com base em um conjunto comum de padrões da indústria, incluindo HTTP, XML, e SOAP, o UDDI fornece uma infraestrutura fundamental para um ambiente baseado em web services (OASIS, 2004). 5.4 WSDL WSDL é uma linguagem de definição de interface baseada em XML que permite descrever os contratos dos serviços. Esse contrato é um documento que contém a descrição do serviço, suas operações e a forma como acessá-lo. Os documentos WSDL são constituídos por palavras-chave como (W3C, 2001): (a) PortType: descreve as operações existentes no web service e seus dados de entrada e saída; (b) Binding: provê informações de como interagir com o web service especificando o protocolo a ser usado, como por exemplo, SOAP/HTTP e (c) Port: descreve o endereço através do qual o web service poderá ser invocado, geralmente representado por uma URL. Através do WSDL, aplicações desenvolvidas em qualquer linguagem e plataforma conseguem acessar um web service e suas operações. Por exemplo, a partir de WSDL de um web service em Java, executando em um ambiente WebSphere, e oferecendo invocação por meio de HTTP, um desenvolvedor.net pode importar o WSDL e gerar um aplicativo que faça solicitações ao serviço.

17 6 Composição de serviços, Mash-ups, Adoção nas empresas e tendências de Mercado O plano de composição de serviços abrange papéis e funcionalidades para agregar vários serviços em um único serviço composto, vide Figura 15, que pode ser usado como serviço básico em composições de serviços adicionais ou oferecido como aplicações completas e soluções para clientes do serviço. Figura 15 Papéis e funcionalidades na composição de serviço Uma das principais características de um serviço, desejável desde o momento da especificação, é a sua capacidade de se compor com outros Serviços para a elaboração de um novo de mais alto nível de abstração. Conforme esquematizado na Figura 16, Web services podem ser encadeados de diversas maneiras no que se denomina de composição de serviços o qual pode envolve basicamente os seguintes conceitos: (a) Orquestração; (b) Coreografia; (c) Modelagem de processos e (d) Mash-ups.

18 Figura 16 Algumas categorias de composição de web services, adaptado de ( A composição de processos de negócio através de Web Services via Orquestração e Coreografia são dois termos comumente utilizados, mas muitas vezes usados como equivalentes gerando confusão. A diferença básica entre ambos é que enquanto na Orquestração há um controlador central responsável pela invocação dos Serviços, na Coreografia, não existe um controlador. A explicação comparativa sobre cada um destes termos segue: Processo Mestre: coordena a composição de processos e controla sua execução dentro de uma orquestração; Processo Participante: participa de uma composição de processos; Orquestração: composição de Web Services oriundos de processos de negócio onde existe a figura de um processo central (processo mestre) que controla e coordena os demais processos. Somente o processo mestre detém a inteligência sobre o processo completo, e a execução é então centralizada. Devido a essa centralização, orquestrações ocorrem normalmente dentro de uma mesma corporação, uma vez que dentro dessa corporação é simples decidir qual processo será o processo-mestre. Nele cada processo participante não tem conhecimento de que faz parte de uma composição de processos, exceto o processo mestre;

19 Coreografia: composição de Web Services onde não existe um processo mestre. Nela cada processo envolvido tem o conhecimento de participar de uma composição de processos e que necessita interagir com outros processos ordenadamente por isso coreografia - para que a composição resultante tenha sucesso. Assim, cada processo participante sabe exatamente quando atuar, com quais outros processos participantes interagir, quais operações deve executar, quais mensagens deve trocar e até mesmo o momento adequado de troca de mensagens. A coreografia é o resultado do conhecimento e comportamento coletivo espalhado pelo sistema. Devido à descentralização, coreografia de processos costuma ser utilizada entre processos ou Web Services de corporações distintas. Modelagem de processos - termo utilizado para os trabalhos relativos ao Mapeamento - levantamento e diagramação do processo como ele é executado e seu possível Redesenho, otimização do processo. Mash-ups é um site personalizado ou uma aplicação web que emprega conteúdo de mais de uma fonte para gerar um novo serviço completo. O código de terceiros é tipicamente executado em mash-ups através de uma interface pública ou uma API. Outras codificações de conteúdo podem ser Web feeds (exemplo: RSS ou Atom), Javascript e widgets (mini aplicações web, disponíveis para serem incorporadas a outros sites). Semelhante a revolução de publicação online obtida via blogs, os mash-ups, feitos sob encomenda muitas vezes, estão revolucionando o desenvolvimento web pela simplicidade de projeto possibilitando a qualquer um combinar dados de diversas fontes. Arquiteturalmente, um mash-up é dividido em três camadas: (a) Apresentação / Interação com Usuários; (b) Web Services: fornece funcionalidades como vimos e (c) Dados: gerenciamento de dados como transmissão, armazenagem e recepção. 7 Introdução a Web Semântica, Ontologias, Clouds e Grids Devido ao crescimento da Web tanto em tamanho, como em diversidade, automação passa a ser necessária nos aspectos relacionados aos serviços Web, tipicamente, sua descoberta, execução, seleção e composição automáticas. O emprego de tecnologias da Web Semântica como serviços Web semânticos e ontologias, pode facilitar no processo de automatização [SILVA, 2009]. Além disso, plataformas ofertadas como serviço permitem que o usuário faça uso de toda uma plataforma de

20 desenvolvimento de aplicações voltadas para outros paradigmas da computação como a Computação em Nuvem (Clouds) e em Grade (Grid) (OASIS, 2004). 7.1 Web Semântica Diversas aplicações de pesquisa em e-science ou execuções em e-engineering demandam um fluxo de trabalho que, em geral, é muito extenso, composto por muitas computações, e voltado para representar um processo, geralmente de natureza colaborativa. Devido à sua extensão, um fluxo de trabalho acaba se tornando de difícil definição e exigindo ferramentas que fazem uso da semântica para facilitar sua composição. Conforme mostrado na Figura 17, a web semântica ganha espaço hoje porque, apesar do fácil acesso, intercâmbio e a recuperação de informações, a web tradicional foi estruturada com descentralização e ligeiramente anárquica apresentando um crescimento exponencial e caótico. Adicionalmente, as tecnologias e linguagens atualmente utilizadas para web se focam em exibição e apresentação dos dados com pobre conteúdo de informações e dificuldade de manuseio por máquinas e seres humanos. Diferentemente a web semântica emprega algumas tecnologias para tal, a saber: (a) RDF (Resource Description Framework) e RDFa - (RDF in attributes) linguagens para a publicação de dados com significado; (b) SPARQL (SPARQL Protocol and RDF Query Language) - linguagem para a consulta de dados e (c) OWL - (Web Ontology Language) para a definição de vocabulários. Figura 17 Web tradicional vs. Web Semântica vs. Serviços Web Semânticos