Capítulo

1

e-Infraestruturas para Ciência e Engenharia Walter Abrahão Santos, LAC-INPE http://www.lac.inpe.br/~walter

Email: 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,

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, Mash-

ups, 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-ups1 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.

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

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

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.

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

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).

Figura 7. Modelo de Aplicações utilizando J2EE -

http://java.sun.com/j2ee/appmodel.html

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.

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

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.

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

(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).

Figura 11 – Padrões W3C para Web services, disponível em:

http://www.dpi.inpe.br/twsg/apresentacoes

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)

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).

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).

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.

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.

Figura 16 – Algumas categorias de composição de web services, adaptado de (https://blogs.oracle.com/StrawberryFieldsForever/entry/composição_de_serviços_parte_ii)

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;

• 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

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

O uso de semântica pode melhorar o reuso e a descoberta de software,

facilitando muito a composição de Web Services e permitindo que aplicações legadas

sejam incorporadas como parte da integração dos processos de negócio. Com o advento

de semântica à Web, é possível a composição automática de serviços mediante agentes

de software capazes de localizar, selecionar, utilizar, compor, e monitorar serviços Web

para atender as demandas de seus usuários. Basicamente, um Web Service Semântico

possui um conjunto de anotações semânticas em seu WSDL. Os Serviços Semânticos

envolvem os seguintes aspectos, detalhes em (MARTIN, 2007): (a) Web Semântica e

Serviços Web Semânticos; (b) Descrição de Serviços Semânticos (WSMO, OWL-S,

WSDL-S); (c) Busca Semântica e Recomendação de Serviços e (d) Composição

Dinâmica.

7.2 Ontologias

Basicamente, uma ontologia geralmente descreve: (a) Indivíduos: objetos

básicos ou de nível primários; (b) Classes: conjuntos, coleções ou tipos de objetos; (c)

Atributos: propriedades, características, aspectos ou parâmetros que objetos possuem ou

compartilham e (d) Relações: como objetos podem estar relacionados entre si. Na

Figura 18 mostra um exemplo prático de uma ontologia de “craques” do futebol.

Figura 18 – Ontologia de “craques” de Futebol com meta anotação (FONTES, 2011)

Vimos que um aspecto chave para se obter Serviços Semânticos é dotar web

services com anotações semânticas, neste ponto entra a importância do uso de

ontologias. Na Ciência da Computação, uma ontologia é um modelo de dados que

representa conhecimento de um determinado domínio, seus objetos e suas relações o

que a orna útil para inferência (GRUBER, 95). Por isso ontologias são empregadas em

Inteligência Artificial, Web Semântica e Engenharia de Software como o conjunto de

entidades com suas relações, restrições, axiomas e vocabulário.

Atualmente a OWL-S é recomendada pelo W3C como a linguagem padrão de

ontologia para Web (OWL-S, 2012). Como mencionado anteriormente para Serviços

Semânticos, o uso de ontologias é útil para: (a) troca de informações entre aplicações

em domínios correlatos; (b) descoberta semântica de serviços Web e (c) composição de

serviços Web.

7.3 Clouds e Grids

Algumas aplicações, chamadas I-O-bound e CPU-bound, exigem uma alta

capacidade de processamento e armazenamento, tanto para realização de cálculos

teóricos e simulações, quanto para a análise e interpretação de seus dados. Como

resultado destas demandas dois novos paradigmas tecnológicos complementares

surgiram, a computação em Grade (Grid) e na Nuvem (Cloud) possibilitando

processamento paralelo em diversas plataformas e com uma vasta área de memória

distribuída. Adicionalmente, usando recursos distribuídos em rede, por isso o termo

nuvem, uma grande massa de dados pode ser facilmente acessível e compartilhada de

qualquer lugar e com armazenagem segura.

Soluções arquiteturais baseadas em grades permitem a gerência de recursos

distribuídos em extranets e criam ambientes colaborativos também conhecidos como

organizações virtuais, do inglês, Virtual Organisations, totalmente transparente a seus

usuários (STANOEVSKA-SLABEVA, 2010), vide Figura 19 para uma arquitetura

genérica. Uma convergência dos paradigmas SOA com grades oferece diversas

oportunidades. A idéia em computação em grade é de que recursos de computação

estejam disponível tal como o fornecimento de energia elétrica, ou seja, possam ser

fornecidos por terceiros. Sobretudo utilizando-se de ciclos de CPU e recursos

computacionais ociosos das máquinas conectadas em diversos domínios e distribuídas

geograficamente expandindo os conceitos de clusters.

Figura 19 – Convergência Grids e SOA (STANOEVSKA-SLABEVA, 2010)

A Computação em Nuvem, ou Cloud Computing, necessita basicamente de três

elementos: (a) clientes magros (thin clients, em inglês); (b) Computação em Grade e (c)

Computação Utilitária - sistema de cobrança por consumo. A computação em grade

oferece recursos de data centers a usuários liberando-os de possuir uma infraestrutura

computacional necessária. Além disso, a grade computacional conecta diferentes

computadores numa grande estrutura que utiliza recursos ociosos. O sistema de

cobrança é semelhante ao de uma conta de telefone, gás ou luz onde se paga pelo

consumo de recursos.

A idéia da Computação em Nuvem é bastante atrativa, entretanto seu uso

pressupõe uma Internet de boa velocidade, consistente, segura e estável. A

interoperabilidade entre diferentes nuvens pode ser vista como um problema, já que

ainda não existem padrões claramente definidos. Há quatro tipos de nuvem serviços,

como mostra a Figura 20 (LEAVIT, 2011): (a) Serviços - alguns produtos oferecem

serviços baseados na Internet diretamente a usuários tais como: armazenagem,

middleware, suporte a colaboração e banco de dados; (b) IaaS (Infrastructure-as-a-

service) – “Infraestrutura-como-um-serviço”, produtos fornecem uma infraestrutura

computacional completa via Internet; (c) PaaS (Platform-as-a-service) – “Plataforma-

como-um-serviço”, produtos oferecem um ambiente de desenvolvimento de aplicações,

total ou parcial, aos usuários podem ter acesso e utilizar online, mesmo em colaboração

com os outros e (d) SaaS (Software-as-a-service) “Software-como-um-serviço”,

produtos fornecem uma aplicação completa, incluindo soluções complexas como CRM

ou ERP via Internet.

Figura 20 – Grandes distribuidores de serviços em nuvem (LEAVIT, 2011)

8 Estudo de casos em e-Science e e-Engineering Há atualmente diversas aplicações que utilizam e-infraestruturas, mas

basicamente nos ateremos àquelas aplicadas à e-Science e e-Engineering.

8.1 e-Science no Observatório Virtual

A aplicação escolhida para e-Science é um observatório virtual (VO) que

consiste de um conjunto de ferramentas computacionais e arquivos que interopera e

utiliza a Internet um ambiente de e-Science na área de Astronomia, para maior clareza

uma arquitetura genérica de um VO é mostrada na Figura 21 (MANN, 2004). Tal como

um observatório real compreende telescópios, cada qual com sua coleção única de

instrumentos astronômicos, um VO é uma coleção de centros ou nós com seu respectivo

conjunto único de dados, software e capacidades de processamento (CLAUS &

SANTOS, 2009).

Figura 21 – Arquitetura genérica de um observatório virtual (MANN, 2004)

Para a arquitetura mostrada na Figura 21, a maior parte do trabalho atualmente

tem se concentrado na interoperabilidade de recursos de dados e nos serviços de

diretório (Registry). O primeiro nível refere-se à parte mais prioritária de conexões com

dados mesmo com o risco de apenas se concentrar na integração e descoberta de dados.

É fato que um VO fornecerá a astrônomos uma vasta quantidade de dados federados nos

próximos anos, mas o foco maior é com a real utilização desta massa de dados.

Portanto a ênfase também no uso de dados de VO, representado com o trecho em cor

cinza na Figura X2, que contém serviços úteis como mineração de dados, imagens, etc.

Por conseqüência, este trabalho também é importante para o escopo da e-Science no seu

sentido mais geral, uma vez que a astronomia é apenas uma das disciplinas que

enfrentam a mesma avalanche de dados (MANN, 2004).

No INPE especificamente, houve o desenvolvimento de um protótipo para o

SoarVO (Southern Astrophysical Research Telescope Virtual Observatory) cujo projeto

disponibilizará os dados dos instrumentos do telescópio SOAR, localizado no Chile, e

consumidos por pesquisadores dos Estados Unidos, Chile e Brasil (Laboratório

Nacional de Astrofísica – LNA). Em (CLAUS & SANTOS, 2009), são descritos as

principais características do projeto aqui transcritas:

• “Uso de protocolos do Observatório Virtual (VO), entre eles os que definem a interoperabilidade entre outros clientes e servidores (...).

• Possibilidade de exportação dos resultados como VOTables para interoperabilidade com outros clientes e servidores. Os resultados de busca também serão fornecidos em HTML e CSV.

• Modelo de banco de dados simplificado: como ainda não existem definições sobre volume total de dados, nem sobre arquiteturas para suportar este volume; e considerando a possibilidade da criação de espelhos para o observatório virtual, foi adotado e modelado um banco de dados que pode ser recriado com os dados existentes no servidor sem restrições ao volume de dados.

• Com esta abordagem será possível ter espelhos com subconjuntos de dados em qualquer volume; além de ser mais simples a replicação dos bancos em si.”

8.2 e-Engineering no Projeto Conceitual de Satélites usando um Barramento Corporativo de Serviços

A fase conceitual de projetos de satélite é uma fase chave que mapeia as

necessidades dos clientes em funções do produto e é onde a arquitetura funcional (e às

vezes a arquitetura física) é decidida. Quando mal executada, a partir da fase conceitual,

vários problemas podem surgir.

A complexidade e demanda de sistemas espaciais é cada vez maior e tornam os

aspectos técnicos relacionados ao projeto conceitual mais importantes e difíceis. Além

disso, devido à pressão sobre os prazos e custos, muitos projetos espaciais demandam

sua distribuição de atividades durante sua consecução. Isto faz com que o seu

desenvolvimento tenha uma divisão entre vários parceiros de projeto que, muitas vezes,

estão separados temporal e geograficamente. Este cenário distribuído dificulta a troca de

informações e aumenta os riscos de concepção.

Para lidar com alguns dos aspectos de projeto distribuído de sistemas espaciais,

este estudo de caso em e-Engineering propõe um ambiente colaborativo de apoio à

engenharia de sistemas espaciais, chamado SpaceESB (SOUZA & DOS SANTOS,

2011). Sua arquitetura conceitual é ilustrada na Figura 22 onde se mostra como alguns

processos da fase conceitual de uma missão espacial podem ser disponibilizados com

base no reuso e integração da informação. Desta forma pode-se tratar melhor a natureza

interdisciplinar do domínio, através do paradigma da Arquitetura Orientada a Serviços e

do emprego de um Barramento Corporativo de Serviços (ESB) onde aplicações tornam-

se distribuídas e a sua reutilização promovida.

Figura 22 – Arquitetura Conceitual do SpaceESB (SOUZA, 2011)

Para fins de demonstração do funcionamento do ambiente distribuído, foi

integrado ao SatBudgets o SpaceESB, de acordo com a Figura 22. O SatBudgets (DOS

SANTOS & LEONOR & STEPHANY, 2009) é uma ferramenta que auxilia na fase

conceitual de um projeto de satélite gerando automaticamente, a partir da modelagem

SysML do satélite em consideração, balanços mecânico e elétrico para mostrar a

viabilidade de construção do sistema ou a necessidade de alterações no projeto do

satélite. Toda troca de dados entre o SatBudgets e o SpaceESB é realizada através de

arquivos XML envelopados pelo protocolo SOAP onde eram invocamos apenas três

serviços remotos necessários nas atividades de projeto conceitual de satélites.

Neste estudo de caso é feita a exploração do espaço de projeto (Design Space

Exploration - DSE) que é um aspecto central no projeto de sistemas. A DSE ajuda os

engenheiros de projeto a escolher, entre as diversas combinações possíveis alternativas,

qual é a solução mais indicada para um determinado projeto (GANESAN;

PREVOSTINI, 2006). Neste trabalho, o espaço explorado de arquiteturas foi

propositalmente restrito a dois pontos por não ser o escopo do estudo e seus resultados

sumarizados na Figura X5.

Figura 23 – Exploração do espaço de projetos de satélites (SOUZA, 2011)

Para isso foram criadas duas diferentes arquiteturas, que serão chamadas de:

Arquitetura A (mais magra – Kg, menos gulosa – potência e menos confiável – sem

redundância) e Arquitetura B (mais gorda – Kg, mais gulosa – potência e mais confiável

– com redundância). Essas arquiteturas foram modeladas usando SysML e foram usadas

como modelos de entrada para a ferramenta SatBudgets. Assim, a partir das saídas da

ferramenta SatBudgets as arquiteturas criadas foram avaliadas nos seguintes balanços:

mecânico, elétrico, de número de termistores, número de comandos diretos e área do

painel solar. Esses compõem o repertório de balanços disponíveis atualmente.

9 Comentários Finais Este trabalho apresentou brevemente alguns dos diversos tópicos que envolvem

a montagem de uma e-infraestrutura baseada em SOA. A computação orientada a

serviço aborda uma vasta e complexa redes de conceitos e engloba tecnologias que

devem ser integradas articuladamente. Pesquisa e desenvolvimento nesta área se foca

em temas relacionados a fundação, desenvolvimento, composição, gerência e

monitoração de serviços. Adicionalmente pode-se ligar requisitos entre diversas

atividades de e-Science e e-Enginnering, descobrir relações a diversas esferas de

trabalho nestas áreas e correlacionar trabalhos atuais com futuros projetos levando a

soluções que melhor interoperam entre seus diversos sistemas.

Através do emprego de Web Semântica e Ontologias, o desejo que

computadores e pessoas possam trabalhar harmoniosamente pode ficar mais próximo

com uma Web mais estruturada permitindo serviços semânticos. Adicionalmente

aplicações I-O-bound e/ou CPU-bound, exigem a computação em Grade (Grid) e na

Nuvem (Cloud) como novos paradigmas tecnológicos.

Foram abordados dois estudos de caso: (a) um Observatório Virtual em e-

Science e (b) Um Ambiente Colaborativo para Apoio ao Projeto Conceitual de Satélites

usando um Barramento Corporativo de Serviços (SpaceESB) focado em e-Engineering.

Neste último caso, para demonstrar a facilidade de reuso de sistemas legados em uma

Arquitetura Orientada a Serviços, foi realizada a integração da ferramenta SatBudgets

ao SpaceESB. Através do consumo de serviços disponíveis no SpaceESB, a ferramenta

SatBudgtes teve quantidade de balanços disponíveis aumentada. No caso do

Observatório Virtual não basta apenas uma infraestrutura que conecte as diferentes

bases sem um respectivo conjunto de funcionalidades que aproveitem a riqueza dos

dados em informação e conhecimento útil.

Finalmente, espera-se a difusão deste conhecimento prévio de e-infraestruturas

de ciência e engenharia contribua que a computação se estabeleça o terceiro tipo de

ciência, ao lado de teoria e experimentação para exploração útil das grandes coleções de

dados crescentemente disponíveis.

Referências Bibliográficas

BASTOS, A.B., Estudo de BPMN na aplicação de e-Engineering, Estudo Dirigido em SOA, INPE Pós-Grad. CSE, 2011.

CLAUS, R. L., SANTOS, R. D. C., Desenvolvimento de Aplicações e Serviços para Observatórios Virtuais, Relatório Final PIBIC/CNPq/INPE, disponível em http://mtc-m18.sid.inpe.br/rep/sid.inpe.br/mtc-m18@80/2009/08.17.19.40?languagebutton=pt-BR&searchsite=bibdigital.sid.inpe.br:80, 2009.

COSTA, G. C. B. ; ARAÚJO, M. A. P. - Computação em Nuvem - Engenharia de Software Magazine, n. 33, pp. 14-25, 2011.

CSBC, IV e-Science Workshop - CSBC´2010 – Acesso em Jan 2012, http://www.dimap.ufrn.br/csbc2011/eventos/escience.php, 2012.

DOS SANTOS, W.A., LEONOR, B.B.F; STEPHANY, S. A Knowledge-Based and Model-Driven Requirements Engineering Approach to Conceptual Satellite Design. In: International Conference on Conceptual Design Modeling, 28th, Berlin. Proceedings... Heidelberg: Springer Verlag, v. 5829, p. 487-500, 2009.

ERL, T. Service Oriented Architecture: A Field Guide to Integrating XML and Web Services, The Prentice Hall, 2004.

FONTES, C.A., Explorando Inferência em um Sistema de Anotação Semântica, Dissertação de Mestrado, Instituto Militar de Engenharia – IME, 2011.

FOWLER, M. e Kobryn, C., UML Essencial, 3ª Edição, Bookman, 2005.

GANESAN, S.; PREVOSTINI, M. Bridging the Gap Between SysML and Design Space Exploration. In: FORUM ON SPECIFICATION AND DESIGN LANGUAGES. FDL 2006., 2006, Darmstadt, Germany. Proceedings... Darmstadt: Technische Universität Darmstadt, p. 389-395. ISBN: 9783000197109, 2006.

GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, USA: Addison-Wesley, 1994.

GOTTSCHALK, K.; GRAHAM, S.; KREGER, H.; SNEL, J. Introduction to Web services architecture. IBM Systems Journal, v.41, n.2, p. 170-177. 2002.

GRUBER, T., Towards Principles for the Design of Ontologies Used for Knowledge Sharing. International Journal of Human and Computer Studies, 43(5/6), pp. 907-928, 1995.

HILLSIDE, The Hillside Group - Acesso em Jan2012, http://hillside.net/, 2012.

HOLLEY, K.; ARSANJANI, A. 100 SOA questions asked and answered. United States of America: Prentice Hall, 304 p. ISBN 9780137080205, 2010.

J2EE, Java Sun, Core J2EE Patterns, Acesso em Jan 2012, http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html, 2012.

JOSUTTIS, N. M. SOA in Practice: The Art of Distributed System Design. United States of America: O’Reilly, 352 p. ISBN 9780596529550, 2007.

LAZZERI, J. C. SOA - Modelando Serviços com fluxos em BPMN. 2010. Disponível em: < http://www.artigonal.com/ti-artigos/soa-modelando-servicos-com-fluxos-em-bpmn-3745520.html> . Acesso em: Agosto de 2011.

LEAVITT, N. - Is Cloud Computing Really Ready for Prime Time?, IEEE Computer Society Magazine, Jan. 2009, pp. 15-20.

MANN, B., WILLIANS, R., What is the Virtual Observatory? Workshop on Service Composition for Data Exploration in the Virtual Observatory, July 2004.

MARTIN, D. et al., Bringing Semantics to Web Services with OWL-S, World Wide Web (2007) 10:243–277, DOI 10.1007/s11280-007-0033-x, 2007.

MORAES, M. C. – UML Introdução, Notas de aulas, Acesso em Jan 2012, http://200.17.137.109:8081/novobsi/Members/cecamoraes, 2012.

MOREIRA, J. J. M. wsQL – uma arquitectura de software baseada em Web services. 208 p. Dissertação (Mestrado em Tecnologia Multimídia) - Faculdade de

Engenharia da Universidade do Porto, Disponível em: <http://repositorio- aberto.up.pt/bitstream/10216/11646/2/Text o integral.pdf>. Acesso em: jul. 2011, Porto, Portugal, 2005.

MORO, T. D., DORNELES, C. F., REBONATTO, M. T. Web services WS-* versus Web Services REST. Acesso em: Novembro de 2010, disponível em: <http://www.upf.br/computacao/images/stories/TCs/arquivos_20092/Tharcis_Dal_Moro.pdf>. 2009.

OASIS STD. Reference model for service oriented architecture 1.0. Acesso em: ago.2011, Disponível em: http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf, 2006.

OPEN GROUP. SOA reference architecture - Draft Technical Standard. Acesso em: jul. 2011. Disponível em: http://www.opengroup.org/projects/soa-ref-arch/uploads/40/19713/soa-ra-public-050609.pdf April 2009.

OWL-S, Web Ontology Language for Web Services, Acesso em Jan. 2012, http://www.daml.org/services.

PRESSMAN, R. S. Software Engineering. A Practitioner’s Approach. 6th Edition, Mcgraw-Hill, 2005.

RATIONAL, Rational Software Corp, Modeling Language Guide – Rational Rose Realtime, version 2003.06.00, Product Documentation, 2003.

SILVA, L. M.; BRAGA, R.; CAMPOS, F. - Um Framework para Composição Semântica de Workflows Científicos, VETOR - Revista de Ciências Exatas e Engenharias, Vol. 19, No 1, 2009.

SOMMERVILLE, I. Engenharia de Software. 8 ed., Brasil: Addison-Wesley, p. 568. ISBN 9788588639287, 2007.

SOUZA, A.C.C., SpaceESB: Um Ambiente Colaborativo para Apoio ao Projeto Conceitual de Satélites usando um Barramento Corporativo de Serviços, Dissertação de Mestrado em Engenharia e Tecnologia Espacial/ Engenharia e Gerenciamento de Sistemas Espaciais, Instituto Nacional de Pesquisas Espaciais (INPE), 2011.

SOUZA, A.C.C., DOS SANTOS, W.A., Automating Services for Spacecraft Conceptual Design via an Enterprise Service Bus, Proceedings of the ISPE Concurrent Engineering - CE2011, Massachusetts Institute of Technology – MIT, USA, Jul. 2011.

STANOEVSKA-SLABEVA, WOZNIAK, T. and RISTOL, S. eds. - Grid and Cloud Computing A Business Perspective on Technology and Applications, Springer Verlag, 2010.

W3C, Web Services Architecture. W3C Working Draft 14 November 2002. Relatório Técnico. Acesso em: jul. 2011.Disponível em: http://www.w3.org/TR/2002/WD-ws-arch-20021114/, 2002.

WU Q.; ZHOU C., JING T. Research on SOA based framework of collaborative design system for complicated product. In: INTERNATIONAL CONFERENCE ON COMPUTER SCIENCE AND SOFTWARE ENGINEERING, 1., 2008. Wuhan, China. Proceedings... Wuhan, 2008.