Questionrio

1. Fale sobre arquitetura N camadas?

Na arquitetura com n camadas para sistemas distribudos, aparecem s figuras do Cliente e Servidor. CLIENTE qualquer equipamento (ou processo) que depende de outro para executar seu trabalho. SERVIDOR este outro equipamento (ou processo) que atende ao cliente. necessria a existncia de meios de conexo entre as duas partes (meios pblicos, privados ou mistos). Qualquer equipamento (ou processo) pode atuar como cliente ou servidor, dependendo do momento, devido troca de informaes. CLIENTES solicitam servios e SERVIDORES fornecem servios. Dominantes at dcada de 80. Onde o problema bsico era interface no amigvel.

2. Fale sobre arquitetura centralizada.

3. Vantagens da arquitetura N camadas.

Sistemas em camadas surgiram para: -Melhor aproveitar os PCs da empresa -Oferecer sistemas com interfaces grficas amigveis -Integrar o desktop e os dados corporativos Em outras palavras, permitiram aumentar a escalabilidade de uso de Sistemas de Informao.

4. Fale sobre arquitetura Cliente/Servidor?

Os primeiros sistemas cliente-servidor eram de duas camadas o Camada cliente trata da lgica de negcio e da UI o Camada servidora trata dos dados (usando um SGBD)

Normalmente desenvolvido em um ambiente de desenvolvimento, como o Visual Basic, Delphi ou Power Builder, instalado em cada Cliente. Este programa acessa dados em um servidor de Banco de dados. Sendo a aplicao Cliente, um programa para Windows (na grande maioria dos

casos), esta deve ser instalada em cada um dos computadores da rede que far uso da aplicao. o processo de instalao normal, para qualquer aplicao Windows.
5. Quais as funes no modelo de duas camadas para aplicao Cliente?

- Apresentao: O Cdigo que gera a Interface visvel do programa, que utilizada pelo usurio para acessar a aplicao, faz parte da aplicao Cliente. Caso sejam necessrias alteraes na interface do programa, fazse necessria a gerao de uma nova verso do programa, e todos os computadores que possuem a verso anterior, devem receber a nova verso, para que o usurio possa ter acesso s alteraes da interface. Este um dos problemas da configurao duas camadas. O gerenciamento desta tarefa, algo extremamente complexo e de custo elevado. - Lgica do Negcio: Aqui esto as regras que definem a maneira como os dados sero acessados e processados. Fazem parte das Regras do Negcio, desde funes simples de validao da entrada de dados, como o clculo do digito verificador de um CPF, at funes mais complexas. Cada vez que uma determinada regra muda, ou quando regras forem acrescentadas ou retiradas necessria a gerao de um novo programa. Mais problemas com o modelo de duas camadas: Qualquer alterao nas regras do negcio suficiente para gerar a necessidade de atualizar a aplicao, em centenas ou milhares de computadores. -A outra camada, vem a ser o Banco de dados, o qual fica armazenado em Servidor da rede, um tpico exemplo de uma aplicao em duas camadas. So diferentes aplicativos, instalam diferentes verses da mesma DLL e um conflito gerado. o caso tpico onde a instalao de um programa, faz com que um ou mais programas, instalados anteriormente, deixem de funcionar. A idia bsica do modelo de trs camadas "retirar" as Regras do Negcio do cliente e centraliz-las em um determinado ponto, o qual chamado de Servidor de Aplicaes. O acesso ao Banco de dados feito atravs das regras contidas no Servidor de Aplicaes. Ao centralizar as Regras do Negcio em um nico ponto, fica muito mais fcil a atualizao destas regras. Esquema modelo trs camadas. Todo o acesso do cliente ao Banco de dados feito de acordo com as regras contidas no Servidor de aplicaes. O cliente no tem acesso direto ao Banco de dados, sem antes passar pelo servidor de aplicaes. Com isso as trs camadas so as seguintes:

6. Explique DLL Hell?

7. Modelo trs camadas.

-Apresentao: Continua no programa instalado no cliente. Alteraes na Interface do programa geram a necessidade de atualizar a aplicao em todos os computadores, onde esta est sendo utilizada. -Lgica: So as regras do negcio, as quais determinam de que maneira os dados sero utilizados. Esta camada foi deslocada para o Servidor de aplicaes. Vejam que ao centralizar as regras do negcio em um Servidor de aplicaes, estamos facilitando a tarefa de manter a aplicao atualizada. -Dados: Nesta camada temos o servidor de Banco de dados, no qual reside toda a informao necessria para o funcionamento da aplicao.
8. Problemas no servidor trs camadas?

A arquitetura em trs camadas original sofre de problemas: -A instalao inicial dos programas no desktop cara -O problema de manuteno ainda persiste quando h mudanas camada de apresentao -No se pode instalar software facilmente num desktop que no est sob seu controle administrativo

9. Conceito do Browser.

-Conceito de Intranet -A camada de aplicao se quebra em duas: Web e Aplicao -Evitamos instalar qualquer software no desktop e, portanto, problemas de manuteno -Evitar instalao em computadores de clientes, parceiros, fornecedores, etc. s vezes, continua-se a chamar isso de trs camadas porque as camadas Web e Aplicao podem rodar na mesma mquina para pequenos volumes. -Cliente: o Cliente o Navegador utilizado pelo usurio, quer seja a Internet Explorer quer seja o Netscape Navigator, ou outro Navegador qualquer. -Apresentao: Passa para o Servidor Web. A interface pode ser composta de pginas HTML, ASP, ou qualquer outra tecnologia capaz de gerar contedo para o Navegador. Com isso alteraes na interface da aplicao, so feitas diretamente no servidor Web, sendo que estas alteraes estaro, automaticamente, disponveis para todos os Clientes. -Lgica: So as regras do negcio, as quais determinam de que maneira os dados sero utilizados. -Dados: Nesta camada temos o servidor de Banco de dados, no qual reside toda a informao necessria para o funcionamento da aplicao.

10. Explique o conceito quatro camadas (web).

11. Explique Arquitetura distribuda em n camadas.

Os problemas remanescentes: -No h suporte a Thin Clients (PDA, celulares, smart cards, quiosques,...), pois se precisa usar um browser (pesado) no cliente -Fazer aplicaes distribudas multicamadas difcil A maioria das empresas no quer contratar especialistas altamente qualificados para programar sistemas distribudos, pois isto elevaria muito o custo do projeto! A soluo introduzir middleware num servidor de aplicao que oferea esses servios automaticamente.
12. Vantagens e Desvantagens da Arquitetura Cliente Servidor com n camadas.

Vantagens -A arquitetura cliente/servidor oferece uma maior estruturao no processamento distribudo, baseada no conceito de servios -Permite um compartilhamento de recursos mais eficiente -Um servidor pode atender diversos clientes -Oferece transparncia de localizao -O processamento percebido pelo cliente como se fosse algo local, independente de onde est realmente acontecendo -Permite comunicao entre processos atravs de troca de mensagens, o que torna a arquitetura fracamente acoplada -As mensagens se restringem apenas a solicitao e resposta -Oferece encapsulamento de servios -O cliente toma conhecimento apenas da interface para solicitar algo e sua resposta, desconhecendo a implementao no servidor Desvantagens -Maior complexidade -Devido ao uso de mensagens mais simples (somente solicitao e resposta), preciso que exista toda uma estrutura complicada por trs que permita um funcionamento transparente -Dependncia de comunicao -Por ser uma soluo baseada em troca de mensagens, a arquitetura cliente/servidor totalmente dependente da existncia de conexo entre as partes envolvidas -Custos mais altos que em solues centralizadas -Software, pessoal especializado, treinamento. Imagine o que ocorre se quisermos que um programa (e no um humano) acesse uma aplicao remota distribuda. Alm do mais, queremos cruzar domnios administrativos. Deve-se ter uma forma de expor a funcionalidade de um programa para outro programa. Atualmente, a tecnologia empregada "Web Services.

13. Arquitetura SOA.

14. Caractersticas da Arquitetura SOA.

-Noo de "service": exposio de business logic para acesso em ambiente distribudo: promove integrao mais fcil. -Acesso a sistema por outros sistemas, no s por usurios -Platform-agnostic (pode misturar Java com .NET, ...) -Composio de servios para criar servios "maiores" usando outros servios -Servios podem ser descobertos -Comunicao freqentemente assncrona (devido ao cruzamento de domnios administrativos o que faz com que eu no saiba se o outro lado est "no ar")
15. O que Socket?

Um soquete definido como uma extremidade de um canal de comunicao. Um par de processos (ou threads) se comunica em uma rede utilizando um par de soquetes - um para cada processo. Um soquete formado por um endereo IP concatenado com um nmero de porta. Em geral os soquetes utilizam uma arquitetura cliente-servidor. O servidor espera por pedidos de clientes ouvindo uma porta especfica. Assim que um pedido recebido, o servidor aceita uma conexo do soquete cliente para completar a conexo.

16. Como funciona uma conexo via socket?

Um cliente faz a requisio de conexo em um host X, atravs de um endereo IP do host + a porta 80 (no caso web) e recebe a porta a qual a comunicao se estabelecer, sendo esta porta acima de 1024. No caso de outra solicitao de outro host, a porta dever ser acima de 1024 e diferente da porta j utilizada. Geralmente os pedidos de requisio so atendidos por threads diferentes, agilizando a resposta. A linguagem Java fornece trs tipos diferentes de soquetes. Os soquetes orientados a conexo (TCP) so implementados com a classe Socket. Os soquetes sem conexo (UDP) utilizam a classe DatagramSocket. Um terceiro tipo a classe MulticastSocket, que uma subclasse da classe DatagramSocket. Um soquete de difuso seletiva (multicast) permite que um dado seja enviado para mltiplos destinatrios simultaneamente. Por se tratar de uma comunicao de baixo nvel entre processo e threads distribudos e fluxo no-estruturados de bytes entre os threads que esto em comunicao, deixam por conta da aplicao Cliente ou Servidor a responsabilidade de impor uma estrutura aos dados. Ex. RPC e RMI. O modelo RPC baseado na necessidade de se executar um componente de uma aplicao em qualquer lugar da rede. Possui nvel mais alto de

17. Socket Java?

18. Problemas da comunicao Socket?

19. O que modelo RPC?

programao e transparente ao usurio. Os procedimentos podem estar em mquinas diferentes. O RPC separa a aplicao de seu cdigo de comunicao e rede.
20. O que Stubs?

Procedimentos que contm o cdigo de chamadas a rede. Cabe aos stubs a passagem de parmetros entre procedimentos. Com eles o RPC protege os programas de aplicao (cliente e servidor) de preocupaes com detalhes da rede. No altera a interface dos procedimentos, facilitando a flexibilidade.

21. Implicaes do protocolo de transporte RPC.

Utilizando TCP: sem problemas. Utilizando UDP: a aplicao deve programar servios como: time-out; retransmisso e tratamento de duplicao de mensagens. Chamadas de Procedimentos que no bloqueiam ou no recebem respostas. A chamada enviada para o servidor e o controle retornado imediatamente para o cliente (no h bloqueio do cliente). Exemplo: print. Como o RPC utiliza grande parte do cdigo fonte em todas suas conexes o programa da Sun RPCGen, gera automaticamente este cdigo, evitando que o usurio reescreva o mesmo cdigo. O RPC programa trs nveis: Alto, mdio e baixo nvel. Alto: Transparente ao usurio, a chamada pode ser feita como qualquer outro procedimento. Mdio: prprio RPC, onde o usurio faz uma chamada remota sem precisar conhecer os detalhes de implementao. Baixo Nvel: mais flexvel, pois permite ao programador controlar certos detalhes de implementao das chamadas sendo, portanto mais eficiente quando usada por programadores experientes. Uma das abordagens da tecnologia Java para prover as funcionalidades de uma plataforma de objetos distribudos. Permite que um thread invoque um mtodo em um objeto remoto, da mesma forma que invocaria em objeto local. Esse stub no cliente responsvel por criar um pacote que consiste no nome do mtodo a ser invocado no servidor e nos parmetros desse mtodo, um processo conhecido como marshalling dos parmetros. O

22. RPC Assncrona?

23. RPCGen?

24. Camadas do RPC?

25. RMI?

26. Processo de Marshalling e Unmarshalling?

stub envia ento esse pacote (agregao) para o servidor, onde ele recebido pelo skeleton do objeto remoto. O skeleton responsvel por efetuar a operao unmarshalling (extrao) dos parmetros e por invocar o mtodo desejado no servidor. O skeleton agrega o valor de retorno (ou exceo, se houver) em um pacote e retorna-o ao cliente. O stub efetua a extrao do valor de retorno e o passa para o cliente.
27. Camadas da arquitetura RMI

. Stub/skeleton: oferece as interfaces que os objetos da aplicao usam para interagir entre si; . Referncia remota: o middleware entre a camada de stub/skeleton e o protocolo de transporte. nesta camada que so criadas e gerenciadas as referncias remotas aos objetos; . Protocolo de transporte: oferece o protocolo de dados binrios que envia as solicitaes aos objetos remotos pela rede. A implementao do servio se d atravs da definio de uma classe que programa a interface especificada. No entanto, alm de programar a interface especificada, preciso incluir as funcionalidades para que um objeto dessa classe possa ser acessado remotamente como um servidor.

28. Implementando o servio remoto em RMI

29. Objetos clientes e servidores em RMI Interface remota Servio Remoto Servidor RMI Cliente RMI Stubs e Skeletons (para comunicao). 30. Diferenas entre RMI e RPC - Em primeiro lugar, as RPCs tradicionalmente suportam apenas programao procedural, na qual somente procedimentos ou funes remotas podem ser chamados. A RMI baseia-se em objetos: suporta a invocao de mtodos em objetos remotos. -Em segundo lugar, os parmetros dos procedimentos remotos na RPC so estruturas de dados comuns; com a RMI possvel passar objetos como parmetros para os mtodos remotos. Permitindo que um programa Java invoque mtodos em objetos remotos, a RMI torna possvel aos usurios desenvolver aplicaes Java que sejam distribudas por toda rede. 31. O que CORBA? CORBA significa Common Object Request Broker Architecture, e define uma especificao que permite aos objetos de sistemas distribudos comunicarem entre si de forma transparente, no importando onde eles estejam, em que plataforma ou sistema operacional estejam rodando, em que linguagem de programao eles foram implementados e at mesmo qual protocolo de comunicao eles utilizam. O CORBA uma especificao das interfaces do ORB,

ou melhor, um modelo concreto para a especificao abstrata dada no documento que define a arquitetura OMA. 32. Componentes da Arquitetura OMA (Object Management Arquitecture) Ncleo CORBA e ORB - manipulam requisies entre objetos; Servios CORBA - definem servios no nvel de sistema que ajudam a gerenciar e manter objetos; Facilidades CORBA - definem facilidades e interfaces no nvel de aplicao - manipulao de dados e armazenamento; Objetos de Aplicao - so os objetos propriamente ditos no nvel visvel de aplicao. 33. O que ORB? O ORB a estrutura mais importante da arquitetura CORBA. Dele a funo de intermediar todas as transferncias entre cliente e servidor, e fazer com que a transao seja transparente para cada uma das partes durante todo o processo. O ORB responsvel pela localizao do objeto ao qual se destina a requisio, assim como, o envio dos parmetros da requisio no formato aceito por este objeto. Tambm funo do ORB, o retorno de parmetros de sada da requisio para o cliente, se assim houver. 34. Servio de registro de objeto. Um recurso importante desses sistemas um servio de registro de objeto, com o qual o objeto se registra. As aplicaes que desejarem utilizar um objeto distribudo devero obter uma referncia ao objeto atravs desse servio. O rmiregistry atua como um servio de registro para RMI. Em um sistema CORBA, o ORB no servidor responsvel por fornecer o servio de registro. 35. COM/DCOM Tecnologia Microsoft semelhante a um ORB menos sofisticado, no aberto, no multiplataforma, inferior no suporte a POO, e pior em desempenho e flexibilidade. 36. O que Middleware? Middleware um software capaz de interpretar os aplicativos e traduzi-los na linguagem do sistema operacional em que ele reside. Exemplos como, CORBA, DCOM e RMI, onde o processamento passou a ser repassado para vrios servidores. 37. Web Service uma aplicao que aceita solicitaes de outros sistemas atravs da Internet. Web Services se tornou uma tecnologia ideal para comunicao entre sistemas: a comunicao entre os servios padronizada, possibilitando a independncia de plataforma e de linguagem de programao. Por exemplo, um sistema desenvolvido em Java e rodando em um servidor Linux pode acessar, com transparncia, um servio feito em .Net rodando em um servidor Microsoft. A base dos web services a troca de mensagens em XML atravs de protocolos web padro como o HTTP. 38. Benefcios do Web Service

No requer configuraes especiais nos firewalls, pois utiliza protocolo HTTP. Re-uso dos componentes pertencentes aos sistemas integrados, podendo participar de mltiplos sistemas.

39. Arquitetura de Web Service Provedor de servios: entidade que cria o Web Service. Ele disponibiliza o servio para que algum possa utiliz-lo; Consumidor de servios: qualquer um que utilize um Web Service criado por um provedor de servios chamado de consumidor de servios; Registro dos servios: Um registro de servios a localizao central onde o provedor de servios pode relacionar seus Web Services, e no qual um consumidor de servios pode pesquis-los. O registro dos servios contm informaes como detalhes de uma empresa, quais os servios que ela fornece e a descrio tcnica de cada um deles. Portanto, o provedor de servios define a descrio do servio para o Web Service e publica esta para o consumidor de servios no registro de servios. O consumidor de servios utiliza a descrio do servio publicada para se ligar ao provedor de servios e invocar ou interagir com a implementao do Web Service. 40. Quais so as camadas de comunicao entre aplicaes Web Services? XML (Extensible Markup Language) SOAP (Simple Object Access Protocol) WSDL (Web Services Definition Language) UDDI (Universal Discovery Description Integration) 41. Fale sobre XML. O XML (Extensible Markup Language) um formato de texto muito simples e flexvel derivado do SGML e originalmente projetado para encontrar chaves em documentos eletrnicos em larga escala. XML uma linguagem de marcao de dados (meta-markup language) que fornece um formato para descrever dados estruturados. Isso facilita declaraes mais precisas do contedo e resultados mais significativos de busca atravs de mltiplas plataformas. O XML tambm permitiu o surgimento de uma nova gerao de aplicaes de manipulao e visualizao de dados via Internet. O XML permite a definio de uma infinidade de tags que podem ser usados para criar dados estruturados. Uma caracterstica importante que uma vez tendo sido recebido o dado em XML pelo cliente, tal dado pode ser manipulado, editado e visualizado sem a necessidade de acionar de novo o servidor. Dessa forma, os dados em XML podem ser distribudos atravs da rede para os clientes que desejarem. 42. Fale sobre Protocolo de Transporte Padro SOAP. O SOAP definia um mecanismo para transmisso de procedimentos remotos XML sobre HTML. um dos principais elementos dos Web Services, apesar de no ser necessrio o conhecimento do seu funcionamento para se criar e consumir um Web Service. Porm, o entendimento geral do protocolo

til para se lidar com eventuais situaes de erros e problemas com a interoperabilidade entre plataformas no uso de Web Services. O protocolo se encontra dividido basicamente em duas partes principais: uma, da especificao, define um framework de mensagens. Protocolos de rede variados, como HTTP, SMTP, FTP, RMI/IIOP ou um protocolo de mensagem proprietrio servem como carregadores das mensagens SOAP. A segunda define trs componentes opcionais: um conjunto de regras de codificao para expressar instncias dos tipos de dados definidos pela aplicao, uma conveno para representar RPCs e respostas e um conjunto de regras para usar SOAP com HTTP. Em outras palavras, SOAP possibilita dois processos (possivelmente em duas mquinas diferentes) comunicarem entre si, desconsiderando o hardware e a plataforma que eles esto rodando. Suas funcionalidades so: Interoperabilidade entre sistemas utilizando linguagens e protocolos padronizados largamente difundidos, como XML e HTTP. Permite a comunicao entre sistemas protegidos por firewalls, sem precisar abrir portas adicionais e possivelmente no seguras. Ele utiliza (na maioria dos servidores) a porta 80. SOAP descreve completamente cada elemento na mensagem, facilitando o entendimento e a proteo contra erros. E, algumas funcionalidades que o SOAP no capaz de executar: Coleta de lixo distribuda. Objetos por Referncia (pois necessria a coleta de lixo distribuda). 43. Vantagens e Desvantagens SOAP. Um dos grandes benefcios do SOAP que ele aberto e foi adotado pela maioria das grandes empresas de hardware e software. SOAP nos d alguns benefcios: XML pode ser facilmente lido por usurios, portanto, mais fcil de entender e eliminar erros. XML parsers (analistas) e tecnologias correlatas so mundialmente disponveis. XML um padro aberto. XML inclui vrias tecnologias que podem fortalecer o SOAP. Simplificao da especificao, diferente de outros protocolos usados nas tecnologias COM, DCOM e CORBA. Principais vantagens Pode atravessar firewalls com facilidade. Os dados do SOAP so estruturados usando XML. Portanto, as mensagens podem ser compreendidas por quase todas as plataformas de hardware, sistemas operacionais e linguagens de programao. Pode ser usado, potencialmente, em combinao com vrios protocolos de transporte de dados, como HTTP, SMTP e FTP. O SOAP mapeia satisfatoriamente para o padro de solicitao / resposta HTTP. Pode ser usado tanto de forma annima como com autenticao (nome/senha). Principais desvantagens: Falta de interoperabilidade entre ferramentas de desenvolvimento do SOAP.

Mecanismos de Segurana Imaturos. O SOAP no define mecanismo para criptografia do contedo de uma mensagem SOAP. No existe bsico de garantia quanto entrega da mensagem. Quando uma mensagem estiver sendo transferida, se o sistema falhar, ele no saber como reenviar a mensagem. Um cliente SOAP no pode enviar uma solicitao a vrios servidores. O fato das aplicaes permitirem que o SOAP seja usado com o HTTP permite transpor barreiras como firewalls com facilidade, permitindo que os softwares que aceitem SOAP estejam disponveis internamente e externamente na rede. Resumindo, SOAP um protocolo leve, o que faz ele ter poucos recursos e de fcil entendimento. Mas, por outro lado, nos faz ter uma preocupao maior com relao a segurana e transporte das mensagens. 44. Fale Sobre WSDL. Web Service Definition Language define um sistema para a descrio de servios. Atravs dela, descrevemos os servios externos, ou interfaces que so oferecidos por uma determinada aplicao, independente de sua plataforma ou linguagem de programao. O seu principal objetivo descrever as interfaces apresentadas e apontar a localizao dos seus servios, disponveis em um local previsvel e bem conhecido, na rede, o qual permite que o cliente acesse de maneira confivel. Por ser um documento XML, sua leitura se torna fcil e acessvel. 45. Componentes WSDL. Atravs dos componentes, possvel uma maior flexibilidade dos WSDL, estes podem ser reutilizados para definir diferentes servios. Os componentes so: Tipos de dados: Denominados de tipos <types>. Parmetros de entrada e sada de um servio: Denominados de mensagem <message>. O relacionamento entre parmetros de entrada e sada: Assinatura do mtodo, denominada de operaes <operation>. Agrupamento lgico de operaes: Denominado de tipo de porta <portType>. O protocolo a ser usado para acessar os mtodos de um objeto: Denominado de vnculo, define o protocolo a ser usado para acessar os mtodos de um objeto (SOAP, HTTP ou MIME). Endereo do servio: Alm dos componentes acima, define um servio. 46. O que Namespaces? Os namespaces so espaos para nomes, definidos no interior dos documentos XML. Um documento WSDL um XML, que utiliza os namespaces para maximizar a taxa de reutilizao dos componentes de um documento WSDL, utilizando-se de atributos para fazer referncia a outros elementos, seja dentro ou fora do documento. 47. Alguns Elementos.

Elemento <definitions> - o elemento raiz de qualquer documento WSDL. Ele contm atributos que servem para definir os namespaces utilizados no documento WSDL. Elemento <types> - O elemento types contm os tipos de dados que esto presentes na mensagem. Elemento <message> - O elemento message define os dados a serem transmitidos. Elemento <import> - O elemento import funciona como separao entre as vrias partes de uma definio WSDL. Elementos <operation> e <portType> - Os elementos portType possuem um conjunto de operaes (<operation>), as quais possuem um atributo name e um atributo opcional para especificar a ordem dos parmetros usados nas operaes. Existem quatro diferentes tipos de mensagens de operaes, segundo: Operao unidirecional: Define uma mensagem enviada de um cliente para um servio, sem resposta. Solicitao-Resposta: O mais utilizado. O cliente envia uma solicitao a um servio, e recebe como resultado uma mensagem de resposta com o resultado dessa solicitao. Pode ser vista como um RPC (remote procedure call). Pedido-Resposta: No utilizada freqentemente. Define uma mensagem enviada do servio para o cliente, resultando em uma mensagem enviada do cliente de volta para o servio. Notificao: quando o servio envia uma mensagem para o cliente. Como pode ver, o portType corresponde apenas a um agrupamento de operaes, onde voc pode agrup-las em um ou vrios elementos <portType>. Caso voc utilize uma ferramenta para se criar a WSDL, como por exemplo o Axis em Java ou o nuSOAP no PHP, estas ferramentas podero tomar esta deciso. Elemento <binding> - O elemento binding mapeia os elementos operation em um elemento portType, para um protocolo especifico. Elementos <service> e <port> Os elementos service e port definem a localizao real do servio, tendo em vista que o mesmo pode conter varias portas e cada uma delas especifica para um tipo de ligao, descrita no elemento binding. 48. Fale Sobre UDDI. O Universal Description, Discovery, and Integration (UDDI) uma especificao tcnica que tem como objetivo descrever, descobrir e integrar Web Services. um elemento central do grupo de padres que compe a pilha de componentes dos servios web. No momento que construmos um Web Services, necessitamos que os servios sejam acessados em algum lugar da Internet por um cliente. Uma das maneiras fazer com que a aplicao cliente conhea a URI do servio. Tem como objetivo ser um mediador do servio, permitindo que os clientes requisitantes encontrem um fornecedor do servio apropriado. Resumidamente, o UDDI uma interface web, que define servios que possibilitam a descrio e descoberta de negcios, organizaes e outros provedores de servio, disponibilizando o acesso e o gerenciamento destes servios.

49. Estrutura de uma publicao UDDI. O XSD (XML Schema) foi escolhido por causa do seu suporte a um rico conjunto de tipos de dados e a sua habilidade de facilmente descrever e validar informaes baseadas nos modelos representados nos schemas. O UDDI XSDS define alguns tipos centrais de centro de informao que prov os tipos de informao que os usurios e aplicaes precisariam conhecer por usar um servio de Rede particular. Junto, estes formam um modelo bsico de informao e um framework para interao de registros UDDI Concluindo, tipicamente fornecedores de servios de UDDI operam um servio conhecido como UDDI Business Registry (UBR), o qual representa um diretrio pblico de servios disponveis, e pode ser acessado para publicar e solicitar informaes sobre um Web Service. 50. Explique SOA. Uma arquitetura orientada a servios no tecnologia por si, um conjunto de princpios e metodologias para desenhar e desenvolver servios de software que possam ser distribudos e geridos atravs da rede da organizao. A reutilizao destes componentes de cdigo e/ou estruturas de dados possvel pois estes so agrupados em unidades auto-contidas e desacopladas. O SOA uma arquitetura de software construda com base numa coleo de servios que interoperam por intermdio de interfaces bem definidas, semelhantes a implementaes DCOM, ORB (CORBA). Numa SOA, uma aplicao no mais que um conjunto harmonioso de interaes entre servios. As arquiteturas orientada a servios evoluem a abordagem seguida pelo DCOM e CORBA por utilizar servios que possam ser descobertos tanto em tempo de desenho ou de execuo por outros servios, no s pelo seu identificador unvoco mas tambm pela identidade da interface que o expe e tipo de servio. 51. Soluo SOA para nveis de arquitetura. Complexidade: A substituio dos sistemas legados constitui hoje um custo elevado, no disponvel a grande parte dos oramentos para os SI disponveis pelas organizaes. Programao redundante e no reutilizvel: Nas organizaes, muitos sistemas/ programas que implementam a mesma funcionalidade foram desenhados e implementados ao longo do tempo de forma isolada, mesmo que partilhando a mesma estrutura de dados. Inferno da multiplicidade de interfaces entre aplicaes: Em muitos sistemas, a criao de interfaces entre aplicaes de negcio igual ao nmero de aplicaes origem vezes o nmero de aplicaes de destino. 52. Benefcios de SOA.
Possuir uma de arquitetura integrar centrada aplicaes nos de processos: ambientes As ou aplicaes so desenvolvidas para satisfazer os processos. Facilidade plataformas heterogneas existentes nas empresas: atravs da utilizao de protocolos padro, tal como os Web Services.

Reduo dos custos de desenvolvimento e integrao: atravs da reutilizao de cdigo e funcionalidades Valorizao dos ativos: pela obteno de valor acrescentado dos sistemas existentes. Potenciar a comunicao e integrao dos sistemas com clientes e parceiros: sem ter que recorrer a configuraes especficas nas firewalls. Escalabilidade de servios: possvel acrescentar servios dinamicamente. Optimiza a comunicao entre os tcnicos e os utilizadores de negcio: Os tcnicos so obrigados a comunicar em termos de fluxos de processos, enquadrados numa arquitetura de negcio. Otimiza o Time-to-market: a partilha de servios em tempo-real aumenta a eficincia dos processos e qualidade da informao disponvel para suportar a gesto e deciso, com impacto directo no aumento da produtividade. Personalizao e filtragem dinmica: Capacidade de barrar ou devolver os dados precisos s aplicaes ou utilizadores especficos, utilizando o mesmo servio. Melhoria no ROI (Retorno do Investimento) dos projetos: como resultado da mais fcil integrao e maior agilidade dos sistemas em adequarem-se dinmica do negcio.

Desafios SOA. Segurana: A interoperabilidade entre sistemas faz com que estes estejam mais expostos a vulnerabilidades e ameaas externas. Disponibilidade da informao em Tempo Real: As arquiteturas fracamente acopladas, adequam-se muito bem a sistemas que no necessitam de respostas em tempo-real. Competncias e experincia na implementao SOA: Apesar do crescente envolvimento das principais organizaes da rea de engenharia de software, do esforo de definio de padres para a implementao da SOA, o que um fato que existe ainda uma imaturidade elevada. Custo: A construo de uma SOA implica um investimento inicial nada desprezvel. 53. Fases no desenvolvimento de sistemas baseados na arquitetura SOA. As arquiteturas SOA so compostas por uma composio de servios de negcio alinhados. Para criar uma arquitetura SOA temos de identificar, especificar e desenhar servios. Temos tambm de especificar, tanto do ponto de vista do fornecedor de servios como do ponto de vista do consumidor de servios