Motivao

Arquitetura deSoftware paraAplicaesDistribudasMarco Tlio de Oliveira ValenteMiddlewareMarco Tlio de Oliveira ValenteMiddleware3Desenvolver uma aplicao distribuda mais difcil do que desenvolver uma aplicao centralizadaProblemas tpicos: comunicao, heterogeneidade, falhas,concorrncia, segurana, escalabilidade etc

Middleware: infra-estrutura de software que fica entre o sistema operacional e uma aplicao distribudaObjetivo: tornar mais simples e produtivo o desenvolvimento de umaaplicao distribuda

Idia: oferecer abstraes/recursos de mais alto nvel que tornem transparente ao programador detalhes de programao em redesFazer com que programao distribuda seja o mais semelhante aprogramao centralizada

Wolfgang Emmerich. Software engineering and middleware: a roadmap. ICSE 2000: 117-129.Middleware3Middleware e linguagens de programao:LP: escondem o hardware (registradores, instrues de mquina,modos de endereamento, perifricos etc)Middleware: escondem a rede (endereos IP, portas, sockets, formato de mensagens, conexes, falhas etc)Veja que hoje a rede o computador

Classificao de sistemas de middleware:De acordo com o nvel de abstrao providoDe acordo com o tipo de abstrao providaDe acordo com o domnio de aplicao ou tecnologia de redeMiddleware: Nveis de Abstrao3Sistemas de middleware que fornecem uma infra-estrutura para execuo de aplicaes (host infrastructure middleware)Abstraem e unificam em uma API particularidades de um hardware ou sistema operacionalFornecem primitivas para criao de threads, sincronizao, comunicao via TCP ou UDP etcExemplos: Sun JVM, .NET CLR

Sistemas de middleware que fornecem uma infra-estrutura de comunicao (communication ou distribution middleware)Exemplos: Java RMI, CORBA, DCOM, SOAP, .NET Remoting Framework, JavaSpaces, Servios Web etcUso mais comum do termo middlewareMiddleware: Nveis de Abstrao38Sistemas de middleware que fornecem outros servios, alm de comunicao (common based middleware)Servios: persistncia, transaes, nomes, autenticao etcExemplos: EJB, CCM (Corba Component Model)Conhecidos como middleware baseados em componentes

Requisitos funcionais: o que o sistema faz (ou seja, as funcionalidades do sistema)Requisitos no-funcionais: como o sistema funciona (atributos de qualidade)Exemplos: distribuio, persistncia, desempenho, segurana,concorrncia, confiabilidade, tolerncia a falhasMiddleware: Abstraes de38ComunicaoClassificao baseada nas primitivas de comunicao entrecomponentes fornecidas pela plataforma de middlewareExemplos:Chamada remota de procedimentos (Sun RPC, DCE RPC etc)Chamada remota de mtodos (Java RMI, CORBA, DCOM etc)Mensagens/eventos (JMS, IBM MQSeries etc)Espaos de tuplas (TSpaces, Java Spaces etc)Transaes (CICS, MTS, JTS, Encina, Tuxedo etc)Middleware: Domnios de Aplicao38Middleware para domnios de aplicao especficos (domain specific middleware):Exemplos: telemedicina, ensino a distncia, comrcio eletrnico, jogos digitais, multimdia, vdeo sob demanda etcNestes casos, o middleware um framework (esqueleto de uma aplicao que vai ser terminada pelo usurio do middleware)

Middleware para tecnologias e ambientes de rede especficos:Exemplos: computao mvel, grades computacionais (grids), sistemas embutidos, TV Digital etcPrximos Captulos38RPC

Middleware Orientado por Objetos: Viso GeralJava RMICORBA

Middleware Orientado por Objetos: Recursos AvanadosChamadas assncronasReflexo computacional

Web Services, Estilos Arquiteturais e RESTArquiteturas orientadas a serviosRPC38Birrell, A.D. & Nelson, B.J. "Implementing Remote Procedure Calls."ACM Transactions on Computer Systems 2, 1 (Feb. 1984): 39-59.The primary purpose of our RPC project was to make distributed computation easy. Previously, it was observed within our research community that the construction of communicating programs was a difficult task, undertaken only by members of a select group of communication experts. Even researchers with substantial systems experience found it difficult to acquire the specialized expertise required to build distributed systems with existing tools. This seemed undesirable ....The existing communication mechanisms appeared to be a major factor constraining further development of distributed computing. Our hope is that by providing communication with almost as much ease as local procedure calls, people will be encouraged to build and experiment with distributed applications.RPC: Idia BsicaCliente

r= soma(x,y)Servidor

float soma(x,y) { return x+y;}38RPC: Marshalling e Unmarshalling38Quando cliente A chama procedimentos de um servidor B:Pode ser necessrio passar como parmetro (e receber comoresultado) estruturas mais complexas (objetos, vetores etc)Cliente A:Deve converter os parmetros para um formato que possa ser transmitido por um protocolo de transporte (TCP, por exemplo)Este processo chamado de marshallingServidor B:Deve converter mensagem recebida em uma estrutura de dadosEste processo chamado de unmarhallingProcesso de marshalling/unmarshalling tedioso e sujeito a errosPortanto, deve ser automatizado pela plataforma de middlewareRPC: Stubs38Funcionamento interno baseado em mdulos chamados de stubsStubs: encapsulam detalhes de comunicao no cliente e servidorAutomatizam processo de marshalling e unmarshallingAutomatizam comunicao com o processo remoto (interagindo com o protocolo de transporte)Marshalling/unmarshalling realizado por stubs chamado de estticoRPC: Arquitetura Internar= soma(x,y)float soma(x,y) {}(1)38(2)float soma(x,y) {return x+y;}(3)(4)(5)(6)ClienteStubClienteStub ServidorServidorQuesto fundamental: Quem gera os stubs?Evidentemente, gerao manual no faz sentidoRPC: Arquitetura InternaStubs so gerados automaticamente, por um compilador de stubsEntrada deste compilador: assinatura dos procedimentos remotos,em uma linguagem chamada XDR (External Data Representation)Genericamente, conhecida como linguagem para definio de interfacesSada deste compilador: cdigo fonte dos stubsrpcgenarquivo XDRclient_stub.c38server_stub.cSistemas de Middleware Orientados38por ObjetosExtenso de RPC para o paradigma orientado por objetosIdia bsica: objetos clientes podem chamar mtodos de objetos remotos com transparncia de acesso (isto , com a mesma sintaxe de chamadas locais)Principal abstrao: chamada remota de mtodos (RMI)Objetos remotos so manipulados usando-se referncias de redeSistemas: CORBA, Java RMI, DCOM, .NET Remoting etcServidor (de aplicao): instancia objeto remoto e o registra no servidor de nomes (registrar= dar um nome para o objeto)Servidor de nomes: tabela (nome, referncia de rede)Cliente: consulta servidor de nomes (fornecendo o nome do objeto), obtm uma referncia de rede para o objeto remoto), usa essa referncia para realizar chamadas remotasJava RMIMiddleware para programao distribuda em JavaImplementado como um pacote da linguagemAnn Wollrath, Roger Riggs, Jim Waldo. A Distributed Object Modelfor the Java System. COOTS 199638Java RMI: Exemplo de Aplicao38Codificar um servidor com um objeto da seguinte classe:

class ContaImpl .... { ......float obterSaldo ();........}

Codificar um cliente que chame remotamente o mtodoobterSaldo() deste objetoJava RMI: Exemplo de Aplicao38Passo 1: Definio da interface remota (assinatura dos mtodos que sero invocados remotamente)

// arquivo Conta.javaimport importjava.rmi.Remote; java.rmi.RemoteException;public interface Conta extends Remote {...... float obterSaldo () throws RemoteException;......}Java RMI: Exemplo de Aplicao38Passo 2: Implementao da Interface Remota (servidor)// arquivo ContaImpl.java import java.rmi.*;import java.rmi.server.*;class ContaImpl extends UnicastRemoteObject implements Conta { private int numero;private float saldo= 0.0;public ContaImpl (int n) throws RemoteException { numero= n;}public float obterSaldo() throws RemoteException { return saldo;}public static void main (String[] args) {......Conta c= new ContaImpl (804);Naming.rebind (Conta804, c);// registra este objeto}}Java RMI: Exemplo de Aplicao38Passo 3: Implementao do Cliente

// arquivo ClienteImpl.javaimport importjava.rmi.*; java.rmi.server.*;public class ClienteImpl {public static void main (String[] args) {......Conta c= (Conta) Naming.lookup ( // + args[0]+/Conta804); float s= c.obterSaldo(); // chamada remota// mesma sintaxe chamada local......}Java RMI: Exemplo de Aplicao38Passo 4: CompilaoCompilao do servidor e do cliente (javac)Gerao de stubs:rmic ContaImplrmic gera os seguintes arquivos:ComtaImpl_Stub.class: stub do clienteContaImpl_Skel.class: skeleton(apenas RMI < JDK 1.4)Passo 5: ExecuoExecuo do Servidor:// registry (permanece em execuo)// servidor (outro processo)rmiregistryjava ContaImplExecuo do Cliente:java clienteImpl server01.dcc.ufmg.brJava RMI: Passagem de Parmetros38Objetos serializveis so passador por valor:Classe do objeto deve implementar a interface SerializablePassa-se uma cpia do objeto (atributos + mtodos)Objetos remotos so passadas por referncia:Passa-se a referncia (e no o objeto), a qual pode ser utilizada para realizar um callback no clienteCallback: servidor chama mtodo do clienteUsado, por exemplo, quando o servidor deseja notificar o cliente sobre a ocorrncia de algum eventoExemplo de Callbackvoid g (){..... }ABCliente

objeto remotoServidor

objeto remoto

void f (A a) {a.g(); // callback}as s.f(a);38Java RMI - ChatAplicao de chatusando Java RMI, com a seguinte interface:38Sistema de Chat em Java RMIvoid conecta(C c) { adiciona c em conectados } void envia (String s){ for (int i= 0; i < conectados.size; i++)conectados[i].display(s); // callback}conectadoss.envia(Bom dia!);display (s)cs.conecta(c);......remotoremotodisplay (s)cs.conecta(c);remotodisplay (s)cs.conecta(c);remoto38CORBA38CORBA: Common Object Request Broker ArchitecturePadro para desenvolvimento de aplicaes distribudas parasistemas heterogneos usando orientao por objetosOMG: Object Management Group (http://www.omg.org)Consrcio de empresas responsvel pela proposio emanuteno do padro CORBACriado em 1989, possui atualmente diversas empresasOMA: Object Management ArchitectureArquitetura para construo de aplicaes distribudasPrimeira especificao importante da OMGObjetivo da OMG: propor uma arquitetura e, em seguida, propor padres para os componentes da mesmaCORBA38Steve Vinoski, CORBA: Integrating Diverse Applications Within Distributed Heterogeneous Environments, IEEE Communications Magazine, vol. 14, no. 2, February 1997.Steve Vinoski: New Features for CORBA 3.0. Commun. ACM 41(10): 44-52 (1998)IIOP: Internet Inter-ORB ProtocolProtocolo, baseado em TCP/IP, para troca de mensagens entre ORBs de diferentes fabricantesObjetivo: interoperabilidadeORB IONAIIOP38ORB JavaIDL: Interface Definition Language38Linguagem para definir a interface de um objeto remotoEspecifica a assinatura das operaes que sero implementadaspor um objeto remotoLinguagem declarativa (sem cdigo)Tipos pr-definidos: long, short, float, double, char, boolean, enumTipos estruturados: struct, union, string, sequenceTratamento de exceesModos de passagem de parmetros: in, out e in outHerana mltipla de interfacesIdia: especificar interface em uma linguagem neutraIDL: Interface Definition Language38Exemplo:typedef sequenceextrato;struct Data {short dia, mes,ano;};

interface conta {float obterSaldo ();extrato obterExtrato (in Data inicio, in Data fim);.......};IDL: Interface Definition Language38Compiladores de IDL geram automaticamente:stub (clientes)skeleton (servidor)Independncia de linguagem:Compiladores IDL implementam gerao de cdigo para C, C++, Smalltalk, Ada, COBOL, Java etcCORBA especifica como deve ser o mapeamento (binding) de IDL para cada uma das linguagem acimaDesenvolvimento de Aplicaes emCORBA: Viso GeralFonte IDLCompilador IDL-JavaCompilador IDL-C++stub.javacliente.javaservidor.cppskel.cppClienteServidor ORB ARun-timeORB BRun-timeIIOPCliente38ServidorCORBA: Vantagens e Desvantagens38Vantagens:Padro (independncia de LP, SO, fornecedor)Middleware bastante completo (diversos servios)Desvantagens:Padro imposto por um grande comit: solues extensas, duplicadas, sobrecarregadas, para atender a todos os gostos etcVide linguagens propostas por comits (ADA, PL/I etc)Ditado: Um camelo um cavalo projetado por um comitThe only way to reach agreement during the submission process for a CORBA specification is to take the grand union of the feature sets of all the pre-existing proprietary implementations (ICE home page)Soluo fechada, monoltica, inflexvel, com poucos pontos deconfigurao, customizao, personalizao etcCaixa-preta, one size fits allTransparncia38Idia: distribuio deve ser transparente aos programadoresPrincipais tipos de transparncia (segundo ISO RM-ODP):Transparncia de acesso: a maneira por meio da qual um componente A acessa servios de um componente B independe do fato de B ser local ou remotoTransparncia de localizao: para que um componente A acesse servios de um componente B, ele no precisa conhecer o endereo fsico de B (mas apenas seu nome lgico)Transparncia de migrao: componente B pode migrar de uma mquina para outra sem impactar componente ATransparncia de replicao: componente A pode acessar o componente B ou uma de suas rplicasTransparncia fundamental para aumentar o nvel de abstrao, bem como para prover escalabilidade (no caso de migrao e replicao)Transparncia em CORBA e RMI38Transparncia de acesso: mtodos remotos so chamados com a mesma sintaxe de mtodos locaisJava RMI: SimCORBA: Sim

Transparncia de localizao: para efetuar uma chamada remota, clientes no precisam conhecer o nome da mquina onde localiza- se o objeto servidorJava RMI: no, pois mtodo lookup tem como parmetro o nome da mquina do objeto servidorCORBA: sim, pois clientes precisam conhecer a localizao de uma nica mquina (o servidor de nomes da rede)Crticas a Transparncia38Jim Waldo, Geoff Wyant, Ann Wollrath, Samuel C. Kendall: A Note on Distributed Computing. Mobile Object Systems 1996: 49-64There is an overall vision of distributed object-oriented computing in which, from the programmers point of view, there is no essential distinction between objects that share an address space and objects that are on two machines with different architectures located on different continents.It is the thesis of this note that this unified view of objects is mistaken. There are fundamental differences between tthe interactions of distributed objects and the interactions of non- distributed objects. Further, work in distributed object-oriented systems that is based on a model that ignores or denies these differences is doomed to failure, and could easily lead to an industry-wide rejection of the notion of distributed object-based systems.Computao Local x Remota38Latncia:Ignoring the difference between the performance of local and remote invocations can lead to designs whose implementations are virtually assured of having performance problems because the design requires a large amount of communication between components that are in different address spaces and on different machines.Acesso a Memria:A more fundamental difference between local and remote computing concerns the access to memory in the two cases specifically in the use of pointers. Simply put, pointers in a local address space are not valid in another (remote) address space. The system can paper over this difference ... Two choices exist: either all memory access must be controlled by the underlying system, or the programmer must be aware of the different types of accesslocal and remote.Computao Local x Remota38Falhas:Being robust in the face of partial failure requires some expression at the interface level. Merely improving the implementation of one component is not sufficient. The interfaces that connect the components must be able to state whenever possible the cause of failureConcorrncia:Distributed objects by their nature must handle concurrentmethod invocationsReflexo ComputacionalMarco Tlio de Oliveira ValenteReflexo Computacional41Capacidade de um sistema se auto-inspecionar e auto-manipularUm sistema reflexivo possui dois nveis:Nvel bsico: contm objetos do domnio da aplicaoMeta-nvel: contm objetos que permitem acessar propriedades e manipular objetos do nvel bsicoObjeto do meta-nvel so chamados de meta-objetosProtocolo de meta-objetos: protocolo de interao com meta-objetosReificao: ao de transformar em meta-objetos informaes do nvel baseReflexo envolve duas atividades:Inspeo: quando meta-nvel inspeciona informaes do nvelbsicoInterseo: quando meta-nvel interfere no comportamento ou na estrutura do nvel bsicoReflexo Computacional41A atividade de intercesso pode ser:EstruturalComportamentalReflexo estrutural: permite alterar estruturas de dados do programa (criar classes, criar objetos, adicionar mtodos em classes, adicionar campos em classes etc)Reflexo comportamental: permite interferir na execuo do programa, interceptando alguns eventos (chamadas de mtodos, criao de objetos etc)Reflexo desde o incio foi usada para implementar diversos requisitos no funcionais tpicos de sistemas distribudos:Transaes, segurana, tolerncia a falhas, balanceamento de carga, logging, persistncia etcVantagem: separao de interesses43Reflexo em JavaTudo comea com um meta-objeto do tipo ClassExemplo: Class c= Class.forName(java.util.Stack);Pode-se usar mtodos do tipo Class para inspeo de informaes:Obter a super-classe do tipo baseObter interfaces que so implementadas pelo tipo baseObter informaes sobre os construtores do tipo baseObter informaes sobre os mtodos do tipo base (modificadores, tipo de retorno, tipo dos parmetros)Pode-se ainda interceder no nvel bsico do programa para:Criar objetos de tipos cujos nomes somente sero conhecidos em tempo de execuoObter/definir valores de atributos cujos nomes somente sero conhecidos em tempo de execuoInvocar mtodos cujos nomes somente sero conhecidos emtempo de execuoReflexo em Java44Programa que lista informaes sobre uma interface cujo nome informado pelo usurio:Console.readString(s);// le nome da interface do tecladoClass c= Method[] for (int StringClass.forName(s); theMethods= c.getMethods();i = 0; i < theMethods.length; i++) { methodString= theMethods[i].getName();System.out.println("Name: " + methodString);String returnString= theMethods[i].getReturnType().getName(); System.out.println(" Return Type: " + returnString);Class[] parameterTypes= theMethods[i].getParameterTypes(); System.out.print(" Parameter Types:");for (int k= 0; k < parameterTypes.length; k ++) { String parameterString= parameterTypes[k].getName();System.out.print(" " + parameterString);}System.out.println();}Reflexo em Java44Permite inspeo do nvel basePermite forma limitada de reflexo estrutural:Pode-se criar objetos e chamar mtodos de forma reflexivaNo se pode adicionar atributos/mtodos em classes, mudar o nome de um mtodo, mudar modificadores etcPermite forma limitada de reflexo comportamental:Interceptao de chamadas de mtodos via classes proxydinmicasSolues mais poderosas:Sistemas como Javassist (reflexo estrutural) e Kava (reflexo comportamental).Programao orientada por aspectosEm linhas gerais,AOP= reflexo sem reificaoClasses Proxy Dinmicas44Recurso de reflexo de Java para criao dinmica de proxiesProxy: padro de projeto comum em aplicaes distribudasProxy: objeto que implementa a mesma interface de um objeto baseAge como um intermedirio entre objeto base e seus clientesNormalmente, possuem uma referncia para objeto base e interceptam todas as chamadas destinadas ao mesmoExemplo: stubs so exemplos de proxyEm Java, classes proxy dinmicas tm duas propriedades:Seu cdigo criado em tempo de execuoImplementam interfaces definidas em tempo de criaoInstncias de classes proxy dinmicas tm ainda um objeto manipulador de invocao (invocation handler), o qual definido pelo cliente que solicitou a criao das mesmas.Classes Proxy Dinmicas44Toda a invocao de mtodo sobre uma instncia de uma classe proxy dinmica enviada automaticamente para o mtodo invoke do manipulador desta instncia, passando os seguintes parmetros:a instncia da classe proxy sobre a qual a invocao foi realizada;um objeto da classe java.lang.reflect.Method, o qual reifica o mtodo que est sendo chamado;um vetor do tipo Object que contm os argumentos destemtodo.Classes Proxy Dinmicas Service

serviceDynamicProxyClassserviceServiceImplservice InvocationHandlerinvoke(Object, Method, Object[])ClientInvocationHandlerIm plimplementsinvoke(Object, Method, Object[])implementsreferences44referencesreferencesExemplo de Classe Proxy49} // class DebugHandlerclass DebugHandler implements java.lang.reflect.InvocationHandler { private Object base;private DebugHandler(Object base) { this.base = base;}public Object invoke(Object proxy, Method m, Object[] args) throws Throwable {Object result; try {System.out.println("before method " + m.getName());// forward to base objectresult = m.invoke(base, args);} catch (...) {...} finally {System.out.println("after method " + m.getName());}return result;}Exemplo de Classe Proxy50Exemplo de Uso:... }public interface Foo {Object bar(Object obj) throws BazException;}public class FooImpl implements Foo {Object bar(Object obj) throws BazException {}.....Foo base= new FooImpl();DebugHandler handler= new DebugHandler(base); Class c= base.getClass();Foo proxy= Proxy.newProxyInstance(c.getClassLoader(), c.getInterfaces(), handler);.....proxy.bar(....);Outros Recursos de SistemasdeMiddlewareMarco Tlio de Oliveira ValenteSincronizao de Requisies57Normalmente, chamadas remotas so sncronasCliente fica bloqueado, esperando resultado da chamada remota

No entanto, dependendo da durao de uma chamada remota, pode no ser interessante que o cliente fique bloqueado

Chamadas oneway:Controle retorna ao cliente quando middleware recebe requisioDespacho/execuo da chamada e execuo do cliente ocorrem de forma assncronaSomente podem ser aplicadas a mtodos com retorno voidNo ativam uma exceo em caso de falha na execuo da chamada remota; recomendadas quando o cliente no necessita do resultado da chamada remotaChamadas Assncronas57Primeira soluo: baseada em polling (tambm chamada de deferred synchronous)Quando cliente realiza uma chamada assncrona, a mesma retorna um objeto de um tipo Future (ou Promises ou outro nome similar)Future x= s.f(....);Cliente ento prossegue sua execuoMiddleware despacha a chamada de forma assncrona (em uma thread independente). Quando o resultado chega, o mesmo associado ao objeto do tipo Future.Em um determinado momento, o cliente pode precisar do resultado da chamada remota.Para isso, basta realizar um polling no Future:Object o= x.getResult();Chamadas Assncronas57Segunda soluo: usando callbackChamadas remotas possuem sempre um primeiro parmetro que um objeto sobre o qual ser realizado o callbackQuando resultado estiver disponvel, chama-se mtodo deste objetoInterface provida pelo sistema:interface Listener { void setResult (Object x); }Interface criada pelo programador e implementada pelo obj. remoto:interface A { String f (int x); }Interface gerada pelo sistemainterface A_Async extends A {void async_f(Listener x, int y);}Chamada Assncrona:Async_A a= Naming.lookup(....); Listener x= new MyListener(); a.async_f(x, 10);Trader: Servio de Negociao57Servio de nome mais avanado existente em CORBAServios de nomes tradicionais funcionam como as pginasbrancas de uma lista telefnicaRequerem que clientes conheam previamente os nomes dos objetos remotos que acessam (ou pelo menos do primeiro objeto remoto acessado)Este fato pode ser uma limitao importante, principalmente emambientes mais dinmicosTrader: objeto remoto pesquisado com base em suas propriedades, caractersticas, qualidade de servio etcSemelhante s pginas amarelas de uma lista telefnicaRequer o uso de uma Trader Constraint Language para consultasExemplo: (page_min > 5) and ((page_type=A4) or color)CORBA TraderObjetivo: maior independncia entre clientes e servidoresClientes no precisam conhecer nomes de objetos remotosNo entanto, clientes ainda precisam conhecer:o nome da interface dos objetos remotosos nomes das propriedades dos objetos remotosReflexo pode ajudar a obter estas informaes, mas cdigo reflexivo extenso, sujeito a erros etc57Coleta de Lixo Distribuda57Suponha as seguintes interfaces remotas: interface Srv extends Remote { Msg getMsg(); } interface Msg extends Remote { ... }Suponha um servidor com um objeto remoto que implementa Srv:Msg getMsg() { return new MsgImpl(); }Suponha ainda uma classe remota MsgImpl, que implementa MsgCdigo do cliente:void foo() {Srv s= "referncia para objeto remoto que implementa Srv"Msg msg;for (int i= 0; i

Ferramentas para Programao com BPEL84Outros Paradigmas paraComputao Distribuda (diferentes Cliente/Servidor)Marco Tlio de Oliveira ValenteEspaos de Tuplas e LindaMarco Tlio de Oliveira ValenteEspaos de Tuplas e Linda87Linda: modelo de coordenao baseado na idia de espao de tuplas (David Gelernter, 1985)Diversas implementaes: TSpaces (IBM), JavaSpaces, LightTS etcModelo de coordenao: comunicao e sincronizao de processos distribudosEspao de tuplasMemria compartilhada, persistente, associativa e globalProcessos distribudos podem inserir, ler e retirar tuplas destamemriaTupla: sequncia ordenada de valoresExemplos de tuplas:( "Joo", "Rua Cinco", 125 )( "Joo","pisd" )( "Maria", "pisd" )("A", 1,1, 15)("A", 1,2, 7)("A", 2,1, 10)("A", 2,2, 22)Operaes sobre Espao de Tuplas87Trs operaes bsicasout t: deposita uma tupla t no espaoin p: retira uma tupla do espao que "case" com o padro p; seno existir, fica bloqueado at que existard p: l (sem retirar) uma tupla do espao que que "case" como padro p;se no existir, fica bloqueado at que existaNo caso de in e rd, se existir mais de uma tupla que case com opadro, uma delas no-deterministicamente escolhidaOperaes so atmicas e podem ser chamadas remotamenteExistem ainda operaes do tipo "probe":inp p: retira uma tupla do espao que "case" com o padro p eretorna true; se no existir, retorna FALSErdp p: l (sem retirar) uma tupla do espao que que "case" com o padro p e retorna true; se no existir, retorna falseCasamento de Padres87Se x um varivel do tipo t, ?x casa com qualquer valor do tipo tExemplo 1:int i;out(1, 2, "xyz")rd(?i, 2, "xyz) bem sucedido (i= 1)Exemplo 2:Exemplo 3:int i, out(1, rd(?i,j; string s; 2, "xyz")?j, ?s) bem sucedido (i= 1, j=2, s= xyz)int i,j;out(1,2, "xyz")rd(?i,?j, "xyz) bem sucedido (i= 1e j= 2)90Casamento de PadresExemplo 6:int i, j;out(1, 2, "xyz")rd (?i, ?j, "abc) no bem sucedidoExemplo 7:out("string", 10.1, 21, "another string") real f; int i;bem sucedido (f=10.1 e i=21) bem sucedido (f=10.1 e i=21)rd("string",in("string",rd("string",?f, ?i, "another?f, ?i, "another?f, ?i, "anotherstring") string") string")permance suspensoExemplo 4:int i, j=2; string s; out(1, 2, "xyz")rd(?i, j, ?s) bem sucedido (i=1,s= xyz)Exemplo 5:int i, j=3; string s; out(1, 2, "xyz")rd(?i, j, ?s) no bem sucedido(epermanece suspenso)Espao de Tuplas91Espao de Tuplas uma memria:Compartilhada: por diversos processos distribudosPersistenteGlobal: um espao uitlizado por diversos processosAssociativa: valores armazenados na memria (tuplas) so recuperados (operaes in e rd) usando-se padres (e no por meio de endereos, como ocorre em uma memria tradicional).Linda foi originalmente proposto para implementao de sistemasparalelosPeriodicamente, interesse por Linda renovadoRazo: modelo de programao assncrono e desacoplado deLinda interessante em redes abertas, reconfigurveis etcJantar dos Filsofos91{ // crian processosprocess phil(i: 0 to n-1) int i;while(true) {think();in("fork", i);in("fork", (i+1)%n); eat();out("fork", i);out("fork", (i+1)%n);}}process main() { int i;for (i=0, i