Capítulo 3: Chamadas de Procedimentos Remotos

Transcrição

1 Chamada de Procedimentos Remotos RPC - Remote Procedure Call Capítulo 3: Chamadas de Procedimentos Remotos Modelo de programação da comunicação num sistema cliente-servidor Obvia as limitações referidas Objectivo: Estruturar a programação distribuída com base na chamada pelos clientes de procedimentos que se executam remotamente no servidor 1 2 Chamada de um Procedimento Remoto RPC: Fluxo de execução Execução de um procedimento noutro processo O chamador (cliente) envia uma mensagem com um pedido O chamado (servidor) devolve uma mensagem com a resposta O programador chama um procedimento local normal O envio e recepção de mensagens são escondidos Bloqueia-se Cliente bloqueado CLIENTE Chamada ao procedimento remoto: envio dos parâmetros SERVIDOR Execução do procedimento pedido cliente r = serverfunc ( p1, p2 ); servidor r_type serverfunc ( p_type p1, p_type p2 ) Retoma a execução Retorno do procedimento remoto: devolução dos resultados 3 4

2 RPC: Benefícios Adequa-se ao fluxo de execução das aplicações Chamada síncrona de funções Simplifica tarefas fastidiosas e delicadas Construção e análise de mensagens Heterogeneidade de representações de dados Esconde diversos detalhes do transporte Endereçamento do servidor Envio e recepção de mensagens Tratamento de erros Simplifica a divulgação de serviços (servidores) A interface dos serviços é fácil de documentar e apresentar A interface é independente dos protocolos de transporte Positivo RPC: comparação com Mensagens A interface do serviço encontra-se claramente especificada e não é apenas um conjunto de mensagens Mecanismo de estabelecimento da ligação entre o cliente e o servidor é automatizado através do serviço de nomes e rotinas do run-time de suporte ao RPC As funções do cliente e do servidor são consistentes, o sistema garante que são correctamente emparelhadas O modelo de invocação de uma função e respectiva sincronização simplificam a programação Os dados são automaticamente codificados e descodificados resolvendo o problema da heterogeneidade As excepções adaptam-se bem ao tratamento de erros nas invocações remotas Negativo Só são bem suportadas as interacções 1-para-1 (ou seja não suporta difusão) Existem mais níveis de software que implicam maior overhead na execução 5 6 RPC: Rotinas de adaptação (stubs) (também chamados ties do lado do servidor) Arquitectura do sistema de RPC: Blocos funcionais das aplicações Cliente Servidor Conversão de parâmetros Recepção e análise de Criação e envio de mensagens mensagens (pedidos) (pedidos) Conversão de parâmetros Recepção e análise de mensagens Conversão de resultados (respostas) Criação e envio de mensagens Conversão de resultados (respostas) cliente serverfunc ( ); clientstub ( ) serverstub ( ) servidor serverfunc ( ) Código do cliente stubs Run-Time Library Threads transporte Protocolo de apresentação Protocolo de sessão Protocolo de transporte Código do servidor stubs (ou ties) Run-Time Library transporte Threads 7 8

3 Arquitectura Exemplo de RPC: SUN RPC As Rotinas de Adaptação Stubs Efectuam as conversões de envio e recepção dos parâmetros da Chamada Remota Cada rotina tem os seus parâmetros específicos pelo que cada uma tem um stub Do lado do servidor existe um stub ou tie que executa as mesmas conversões pela ordem inversa Função de despacho do servidor Espera por mensagens de clientes num porto de transporte Envia mensagens recebidas para o stub respectivo Recebe mensagens dos stubs e envia-os para os clientes O Sistema de Suporte Run-time system Executa as operações genéricas do RPC, por exemplo: Abrir a ligação com o servidor, efectuar o envio e recepção das mensagens, fechar ligação Como são operações genéricas existe apenas um RTS por cliente e um por servidor Sistema de RPC desenvolvido pela SUN cerca de 1985 Destinado inicialmente a suportar o sistema de ficheiros distribuído NFS Especificação de domínio público Implementação simples e muito divulgada em grande número de plataformas (Unix, MS-DOS, ) 9 10 Objectivos SUN RPC Máquina A Kernel Aplicação cliente funcx(args); pedido RPC stubs resposta Socket TCP ou UDP Máquina B Kernel Aplicação servidora funcx(args); RPC stubs + dispatcher pedido resposta Socket TCP ou UDP Linguagem de IDL semelhante a C, suportada pelo compilador rpcgen Apenas um parâmetro de entrada e um parâmetro de saída Vários valores são transferidos em estruturas Construção que permite transmitir condicionalmente informação Todos os parâmetros são passados por referência para os stubs rpcgen gera automaticamente o programa principal do servidor Biblioteca de RPC inicialmente usava sockets, actualmente usa TLI connect 11 12

4 Sun RPC: Exemplo de IDL program BINOP version BINOP_VERS long BINOP_ADD ( struct input_args ) = 5; = 1; = ; struct input_args long a; long b; ; Identificação (nomes) Interface (n programa, n versão) (300030, 1) Função (Interface, n função) (300030, 1, 5) Máquina A Cliente Sun RPC: Serviço de Nomes e encaminhamento de RPCs cliente stub call ( binding handle n interface, n função, parâmetros) porto de transporte transporte rpcbind procura (n interface, transporte) pedido XID (op. id) RPC version n interface n função autenticador parâmetros resposta XID RPC error resultados porto 111 stub Máquina B registo (n interface, porto de transporte) despacho da interface servidor Servidor operação Diagrama de ficheiros rpcgen: definição e compilação da interface calc.x Service Interface Makefile rpcgen Sample Makefile calc_clnt.c calc.h Definições #include Tipos Protótipos Client stubs calc_xdr.c XDR marshaling calc_srv.c Server stubs & dispatcher Client source files Server source files 17 calc.x enum calc_error CALC_OK = 0, /* No error */ CALC_ZERO_DIV = 1 /* Division by zero */ ; struct calc_args double v1; double v2; ; struct calc_result calc_error error; double value; ; program CALC_PROG version CALC_VERS calc_result SUM(calc_args) = 1; calc_result SUB(calc_args) = 2; calc_result MUL(calc_args) = 3; calc_result DIV(calc_args) = 4; = 1; = ; calc_clnt.c calc_svc.c calc_xdr.c rpcgen -C rpcgen -Sc rpcgen -Ss rpcgen -Sm Sample client Sample server Sample Makefile 18

5 Diagrama de ficheiros (cont.) Funções de conversão via XDR calc.x calc_result sum(calc_args)... VERSION=1 rpcgen -C calc_clnt.c calc_result sum_1(calc_args,...)... calc.h typedef... calc_result; calc_xdr.c typedef... calc_args; calc_result xdr_calc_result() sum_1(calc_args,...);... calc_result xdr_calc_args() sum_1_svc(calc_args,...);... calc_srv.c main(...)... svc_run(); calc_prog_1(...)... main(...)... calc_result sum_1_svc(calc_args,...) calc.x enum calc_error CALC_OK = 0, /* No error */ CALC_ZERO_DIV = 1 /* Div. by zero */ ; struct calc_args double v1; double v2; ; struct calc_result calc_error error; double value; ; rpcgen -C program CALC_PROG version CALC_VERS calc_result SUM(calc_args) = 1; calc_result SUB(calc_args) = 2; calc_result MUL(calc_args) = 3; calc_result DIV(calc_args) = 4; = 1; = ; Funções de conversão calc_xdr.c para cada tipo definido no IDL #include "calc.h bool_t xdr_calc_error(xdr *xdrs, calc_error *objp) if (!xdr_enum(xdrs, (enum_t *)objp)) return (FALSE); return (TRUE); bool_t xdr_calc_args(xdr *xdrs, calc_args *objp)... bool_t xdr_calc_result(xdr *xdrs, calc_result *objp) if (!xdr_calc_error(xdrs, &objp->error)) return (FALSE); if (!xdr_double(xdrs, &objp->value)) return (FALSE); return (TRUE); Chamadas a funções de conversão de tipos base (oferecidas na biblioteca run-time do SUN RPC) 20 calc.x Funções do cliente (stubs) enum calc_error CALC_OK = 0, /* No error */ CALC_ZERO_DIV = 1 /* Division by zero */ ; struct calc_args double v1; double v2; ; struct calc_result calc_error error; double value; ; rpcgen -C program CALC_PROG version CALC_VERS calc_result SUM(calc_args) = 1; calc_result SUB(calc_args) = 2; calc_result MUL(calc_args) = 3; calc_result DIV(calc_args) = 4; = 1; = ; Função genérica de chamada de procedimento remoto (da biblioteca de run-time) #include "calc.h calc_clnt.c static struct timeval TIMEOUT = 25, 0 ; calc_result * sum_1(calc_args *argp, CLIENT *clnt) static calc_result clnt_res; if (clnt_call(clnt, SUM, xdr_calc_args, argp, xdr_calc_result, &clnt_res, TIMEOUT)!= RPC_SUCCESS) return (NULL); return (&clnt_res); calc_result * sub_1(calc_args *argp, CLIENT *clnt)... calc_result * mul_1(calc_args *argp, CLIENT *clnt)... calc_result * div_1(calc_args *argp, CLIENT *clnt) #include <stdio.h> #include <rpc/rpc.h> #include "banco.h" static void bancoprog_1(); main() register SVCXPRT *transp; Exemplo: Ficheiro banco_svc.c Gerado pelo rpcgen (void) pmap_unset(bancoprog, BANCOVERS); transp = svcudp_create(rpc_anysock); if (transp == NULL) fprintf(stderr, "cannot create udp service."); Função de despacho exit(1); if (!svc_register(transp, BANCOPROG, BANCOVERS, bancoprog_1, IPPROTO_UDP)) fprintf(stderr, "unable to register (BANCOPROG, BANCOVERS, udp)."); exit(1); transp = svctcp_create(rpc_anysock, 0, 0); if (transp == NULL) fprintf(stderr, "cannot create tcp service."); exit(1); if (!svc_register(transp, BANCOPROG, BANCOVERS, bancoprog_1, IPPROTO_TCP)) fprintf(stderr, "unable to register (BANCOPROG, BANCOVERS, tcp)."); exit(1); svc_run(); fprintf(stderr, "svc_run returned"); exit(1); /* NOTREACHED */ Cria porto UDP Associa nome da interface e função de despacho ao porto Faz o mesmo para porto TCP Lança ciclo de espera de pedidos Quando chegar algum pedido, svc_run() chama a função de despacho 22

6 Função de despacho Exemplo: Ficheiro banco_svc.c Gerado pelo rpcgen static void bancoprog_1(rqstp, transp) struct svc_req *rqstp; register SVCXPRT *transp; union criarin criar_1_arg; int saldo_1_arg; contaevalor depositar_1_arg; contaevalor levantar_1_arg; transferirin transferir_1_arg; pedirextratoin pedirextrato_1_arg; argument; char *result; bool_t (*xdr_argument)(), (*xdr_result)(); char *(*local)(); switch (rqstp->rq_proc) case NULLPROC: (void) svc_sendreply(transp, xdr_void, (char *)NULL); return; case CRIAR: xdr_argument = xdr_criarin; xdr_result = xdr_criarret; local = (char *(*)()) criar_1; break; case SALDO: xdr_argument = xdr_int; xdr_result = xdr_saldoret; local = (char *(*)()) saldo_1; break; case PEDIREXTRATO: xdr_argument = xdr_pedirextratoin; xdr_result = xdr_pedirextratoret; local = (char *(*)()) pedirextrato_1; break; Função genérica para obter argumentos (da biblioteca de run-time) default: svcerr_noproc(transp); return; bzero((char *)&argument, sizeof(argument)); if (!svc_getargs(transp, xdr_argument, &argument)) svcerr_decode(transp); return; result = (*local)(&argument, rqstp); if (result!= NULL &&!svc_sendreply(transp, xdr_result, result)) svcerr_systemerr(transp); if (!svc_freeargs(transp, xdr_argument, &argument)) fprintf(stderr, "unable to free arguments"); exit(1); return; Função genérica para enviar resposta (da biblioteca de run-time) 23 A Visão da Programação do RPC LINGUAGEM DE DESCRIÇÃO DE INTERFACES - IDL 24 RPC IDL: Características RPC IDL: Código gerado pelo compilador Linguagem própria Linguagem declarativa (não tem a parte operacional das linguagens de programação) permite definir Tipos de dados Protótipos de funções Fluxo de valores (IN, OUT, INOUT) Interfaces Conjuntos de funções Stubs Para o cliente Traduzem e empacotam parâmetros numa mensagem Enviam a mensagem para o servidor, esperam uma resposta Desempacotam a mensagem e traduzem a resposta Para o servidor Desempacotam a mensagem e traduzem os parâmetros Invocam a função desejada e esperam pelo seu retorno Traduzem e empacotam a resposta numa mensagem Função de despacho do servidor Espera por mensagens de clientes num porto de transporte Envia mensagens recebidas para o stub respectivo Recebe mensagens dos stubs e envia-os para os clientes 25 26

7 IDL: Pode ser um.h? RPC IDL: Limitações usuais Quais os parâmetros de entrada/saída da seguinte função? int transfere(int origem, int destino, int valor, int *saldo, char *descr); Ambiguidades acerca dos dados a transmitir: Endereçamento puro de memória (void *) Flexibilidade no uso de ponteiros para manipular vectores Passagem de vectores (normalmente por ponteiro) Strings manipuladas com char * Passagem de variáveis por referência (&var) Semânticas ambíguas Valores booleanos do C (0 False;!= 0 True) Problemas complexos (durante a execução) Transmissão de estruturas dinâmicas com ciclos Integridade referencial dos dados enviados RPC IDL: Soluções para alguns dos problemas Exemplo: IDL Sun RPC Ficheiro banco.x Novos tipos de dados próprios do IDL Sun RPC define 3 novos string: para definir cadeias de caracteres bool: valor booleano, apenas dois valores opaque: bit-arrays, sem tradução Agregados próprios do IDL Uniões (unions) com descriminantes Vectores conformes (DCE/Microsoft) Vectores variáveis (Sun, DCE/Microsoft) program BANCOPROG version BANCOVERS criarret CRIAR(criarIn) = 1; saldoret SALDO(int) = 2; resultado DEPOSITAR(contaEvalor) = 3; resultado LEVANTAR(contaEvalor) = 4; resultado TRANSFERIR(transferirIn) = 5; pedirextratoret PEDIREXTRATO(pedirExtratoIn) = 6; = 1; = 0x ; 30 31

8 Exemplo: Interface em IDL RPC Microsoft [ uuid(00918a0c-4d50-1c17-9bb3-92c1040b0000), version(1.0) ] interface banco typedef enum SUCESSO, ERRO, ERRO_NA_CRIACAO, CONTA_INEXISTENTE, FUNDOS_INSUFICIENTES resultado; typedef enum CRIACAO, SALDO, DEPOSITO, LEVANTAMENTO, TRANSFERENCIA, EXTRATO tipooperacao; typedef struct long dia; long mes; long ano; tipodata; resultado criar([in] handle_t h, [in] long valor, [in, string] char nome[], [in, string] char morada[], [out] long *numero); resultado saldo([in] handle_t h, [in] long nconta, [out] long *valor); resultado depositar([in] handle_t h, [in] long nconta, [in] long valor); resultado levantar([in] handle_t h, [in] long nconta, [in] long valor); resultado transferir([in] handle_t h, [in] long ncontaorigem, [in] long ncontadest, [in] long valor); resultado pedirextrato([in] handle_t h, [in] long nconta, [in] long mes, [in] long ano, [in, out, ptr] dadosoperacao dados[50], [out] long *nelemento); typedef struct tipodata data; tipooperacao operacao; long movimento; long saldo; dadosoperacao; 2009 José Alves Marques 32 Protocolos e Serviços necessário para suportar o RPC HETEROGENEIDADE 33 Heterogeneidade Nos sistemas distribuídos a heterogeneidade é a regra Os formatos de dados são diferentes Nos processadores (ex.: little endian, big endian, apontadores, vírgula flutuante) Nas estruturas de dados geradas pelos compiladores Nos sistemas de armazenamento (ex: strings ASCII vs Unicode) Nos sistemas de codificação Marshalling As redes transmitem bytes entre as máquinas Necessário serializar objectos em memória para sequência de bytes Des-serializar sequência de bytes para objectos na máquina destino Máquinas representam tipos de formas diferentes É necessário traduzir entre representação de tipos do emissor e representação de tipos do receptor Marshalling: serializar + traduzir Unmarshalling: operação inversa 34

9 Resolução da Heterogeneidade na Comunicação Protocolos de Apresentação no RPC Modelo OSI camada de Apresentação Protocolo ASN.1 Sistemas de RPC aproveitam descrição formal da interface heterogeneidade resolvida através de técnicas de compilação. A partir destes sistemas a heterogeneidade na comunicação ficou resolvida no ambiente de execução. Decisões a efectuar Estrutura dos mensagens Implícita as mensagens apenas contêm os dados a transmitir Explicita Auto-descritiva (marcada, tagged) Políticas de conversão dos dados Canónica Uma única representação para que todos convertem J N formatos N funções J Não há comportamentos variáveis L É preciso converter mesmo quando é inútil O-receptor-converte (Receiver-makes-it-right) J Poupa conversões inúteis L N formatos N x N funções Protocolos de Apresentação Conversã o XDR (external Data Representation) Sun RPC Canónica NDR (Network Data Representation) DCE RPC Microsoft RPC ASN.1 (Abstract Syntax Notation) CDR (Common Data Representation) Java Object Serialization OSI CORBA Java RMI W3C Canónica O-receptorconverte O-receptorconverte Canónica XML (Extensible Markup Language) Canónica Caso de estudo: extensible Markup Language - XML Estrutura das msgs. Implícita Binária Comprimentos de vectores variáveis Alinhamento a 32 bits (excepto vectores de caracteres) Implícita Binária Marcas arquitecturais (architecture tags) Explícita Tagged Binária Encoding Rules: Basic Distinguished Canonical Packed Implícita Binária Explícita Binária Explicita Tagged Textual Tipos de Documentos DTD XML schema 38 Resolver a heterogeneidade na comunicação e nos dados de forma universal

10 XML extensible Markup Language Formato canónico Estrutura explícita Textual O XML deriva de uma linguagem muito mais antiga para definição do formato de impressão de documentos o SGML. O SGML já tinha sido a tecnologia de base no desenvolvimento do HTML. Essencialmente o XML permite através de etiquetas (tags) associar a descrição do formato aos dados de um documento. Toda a descrição é textual o que resolve muito dos problemas de portabilidade. O XML é uma proposta do W3C e é percepcionado como o substituto dos formatos anteriores de representação de dados como o EDI Importância do XML Exemplo de uma estrutura de dados em XML O XML trabalha sobre documentos Os documentos podem ser usados para múltiplos fins: Representar/apresentar a informação num forma visível: em papel ou transformada para html Comunicação de dados entre plataformas heterogéneas Para armazenamento da informação em ficheiros ou em bases de dados <person id=" "> <name>smith</name> <place>london</place> <year>1934</year> <!-- a comment --> </person > 42

11 Sintaxe XML Benefícios do XML Regras de construção simples mas rígidas: Existe um elemento raiz único Todos os elementos têm que fechar Fecham pela ordem inversa em que abrem Os nomes são case-sensitive Um documento que respeita as regras diz-se bem formado (well formed) Adicionalmente, pode-se definir uma gramática para validar documentos XML Que sequências de elementos são válidas Que tipo de dados contém o elemento Tecnologia não proprietária Independente das plataformas o formato é texto Compatível com o HTTP O XML tem uma sintaxe mais restritiva que o HTML, mas pode ser usado como o HTML pelo que passa pelas firewalls Internacional Formato texto que usa UTF-8 ou UTF-16 para representar os caracteres Extensível Novas tags podem ser adicionadas por necessidade de extensão. Para evitar duplicações existem namespaces a que um documento pode ser associado. Benefícios do XML(II) A interpretação das mensagens depende de tags e não da posição do campo na mensagem Permite a transformação automática dos dados As transformações são especificadas usando XML Stylesheet Language Transformatiom (XSLT) Auto definida A estrutura de um documento XML tem uma meta-descrição com base Document Type Definition (DTD) ou actualmente com XML schema Ferramentas genéricas Ferramentas Open Source em Java e ferramentas já existentes para SGML. Tecnologia XML Namespaces Permite a unicidade de nomes e resolver colisões. Os Espaços de nomes são normalmente associados a um domínio de aplicação Um nome torna-se único por associação a um URI Xpath Define um mecanismo de acesso a elementos dentro de um documento XML Xlink Mecanismo para indexar outros documentos semelhantes aos hiperlinks do HTML mas mais robusto XSL XML style sheet- documentos XML que definem transformações de documentos em XML DOM - Document Object Model O DOM define os métodos para aceder a um documento XML. Pressupõe que o documento é carregado em memória e que através de uma API se acede aos diferentes elementos SAX - Simple API for XML O SAX é um parser que invoca funções à medida que encontra elementos no documento

12 Exemplo simples mensagem Com definição de namespace Exemplo com múltiplos namespaces <person pers:id=" " xmlns:pers = " <pers:name> Smith </pers:name> <pers:place> London </pers:place > <pers:year> 1934 </pers:year> </person> <?xml version="1.0"?> <bk:book xmlns:bk='urn:loc.gov:books' xmlns:isbn='urn:isbn: '> 6'> <bk:title>cheaper by the Dozen</bk:title> <isbn:number> </isbn:number> </bk:book> extensible Stylesheet Language (XSL) Esquema do Documento Permite: Transformar XML em HTML Transformar XML noutro XML Filtrar e ordenar dados XML Apresentar o mesmo documento de formas diferentes dependendo do dispositivo de destino (ecrã, impressão, telefone móvel, etc.) A especificação de documentos era inicialmente efectuada em DTD Document Type Definition Em 2001 foi proposto o XML Schema Estende as capacidades do DTD mas cuja principal vantagem é ter uma sintaxe XML que o DTD não tinha Um parser usando um DTD ou XML Schema pode verificar se o documento está sintacticamente correcto e se está conforme com um determinado tipo A meta-descrição pode ser incluída no documento, mas a utilização mais interessante é poder aceder-lhe através de um URI partilhando-o entre aplicações

13 XML Schema XML schema para a estrutura de dados Person Define Elementos obrigatórios e proibidos Estrutura hierárquica dos elementos Atributos necessários ou opcionais dos elementos e gama de valores permitidos Referências de parte de um documento a outros elementos do documento <xsd:schema xmlns:xsd = URL of XML schema definitions > <xsd:element name= "person" type ="persontype" /> <xsd:complextype name="persontype"> <xsd:sequence> <xsd:element name = "name" type="xsd:string"/> <xsd:element name = "place" type="xsd:string"/> <xsd:element name = "year" type="xsd:positiveinteger"/> </xsd:sequence> <xsd:attribute name= "id" type = "xsd:positiveinteger"/> </xsd:complextype> </xsd:schema> Exemplo de XML Schemas mais elaborado </xml version= 1.0 encoding= UTF-8?> <xsd:schema xmlns:xsd= targetnamespace= xmlns= > <xsd:element name= employeelist > <xsd:complextype> <xsd:sequence> <xsd:element ref= employee minoccurs= 1 maxoccurs= unbounded /> <xsd:seuqence> </xsd:complextype> </xsd:element> <xsd:element name= employee <xsd:complextype> <xsd:sequence> <xsd:element ref= employee_id minoccurs= 1 maxoccurs= 1 /> <xsd:element ref= name minoccurs= 1 maxoccurs= 1 /> <xsd:element ref= extn minoccurs= 1 maxoccurs= 1 /> <xsd:element ref= dept minoccurs= 1 maxoccurs= 1 /> <xsd:element ref= minoccurs= 1 maxoccurs= 1 /> </xsd:sequence> <xsd:attributegroup ref= employeeattribute /> </xsd:comlextype> </xsd:element> <xsd:element name= name <xsd:complextype> <xsd:sequence> <xsd:element ref= first_name minoccurs= 1 maxoccurs= 1 /> <xsd:element ref= last_name minoccurs= 1 maxoccurs= 1 /> <xsd:sequence> </xsd:complextype> </xsd:element> 2009 José Alves Marques Namespace declaration <!ELEMENT employeelist (employee*)> <!ELEMENT employee (employee_id, name, extn, dept, )> <!ELEMENT name (first_name, last_name)> <xsd:element name= employee_id > <xsd:simpletype> <xsd:restriction base= xsd:int > <xsd:minlnclusive value= 1 /> <xsd:maxlnclusive value= /> <xsd:restriction> </xsd:simpletype> </xsd:element> <xsd:element name= first_name type= xsd:string /> <xsd:element name= last_name type= xsd:string /> <xsd:element name= type= xsd:string /> <xsd:element name= dept > <xsd:simpletype> <xsd:restriction base= xsd:string> <xsd:pattern value= [0-9]3-[0-9]3-[0-9]4 /> </xsd:restriction> </xsd:simpletype> </xsd:element> <xsd:element name= extn > <xsd:simpletype> <xsd:restrition base= xsd:string > <xsd:pattern value= [0-9]5 /> </xsd:restrition> </xsd:simpletype> </xsd:element> <xsd:attributegroup name0 employeeattribute > <xsd:attribute name= type use= required > <xsd:simpletype> <xsd:restriction base= xsd:string > <xsd:enumerator value= contract /> employee:_id must be an integer between 1 and 100,000. <!ELEMENT first_name (PCDATA)> <!ELEMENT (PCDATA) Department must be specified in the form: Extension must be specified in the form (String consisting of five digits). <!ATTLIST employee type (permicontract) #REQUIRED>

14 Tecnologia XML SAX Simple API for XML Processamento em série Baseado no tratamento de eventos 61 Quando usar DOM - Document Object Model Quando pretendemos processar informação em série (data stream). A informação a processar não precisa de manter estado. Importação/exportação de dados Manipulação de árvore em memória