.:: Computação & Concursos ::.

Sua referência em concursos públicos na área de computação.

Questões – TRE-MG

Cargo: Analista Judiciário – Especialidade Análise de Sistemas

40. Analise o conjunto de definições abaixo:
−  Um padrão desenvolvido para prover informações em forma de diretório de negócios e Web Services;
−  Uma especificação técnica para descrever, descobrir e integrar Web Services;
−  Um modo dinâmico para descobrir a localização de um serviço web;
−  Uma parte crítica da pilha de protocolos Web Services, habilitando os usuários dos serviços a publicarem e descobrirem esses serviços.

Esse conjunto de definições se refere ao protocolo Web Service denominado
(A) WSDL.
(B) SOAP.
(C) UDDI.
(D) HTML.
(E) HTTP.

Comentários: Questão relativa a um dos ‘componentes’ do padrão WebServices definido pela W3C. Vamos às definições de cada alternativa então:

WSDL – Web Service Description Language: É um documento XML usado para descrever o Web Service. ele é o responsável por descrever a localização de cada serviço e as operações( ou métodos ) que o Web Service em questão possui, juntamente com os parâmetros para cada operação e suas opção de retorno de dados. Segundo a WSCHOOLS, o WSDL ainda não é considerado um padrão da W3C.

SOAP – Simple Object Access Protocol: O SOAP é um protocolo bastante simples de comunicação que permite que diferentes aplicações possam interagir entre si trocando informações via documentos XML através do protocolo HTTP. Devido ao fato de ser definido como um documento XML, este protocolo se torna independente de plataforma e de linguegens de desenvolvimento, tornando seu uso bastante extenso entre praticamente qualquer aplicação que venha a acessar a internet.

UDDI – Universal Description, Discovery and Integration: O UDDI se caracteriza por ser um serviço de diretórios onde pode-se buscar informações a respeito de Web Services. Ele utiliza a WSDL para descrever as informações que ele possui a respeito de diversos Web Services . A comunicação entre aplicações e este servico de diretórios de Web Services se dá através do protocolo SOAP, o que torna acessivel para qualquer aplicação atraves de uma comunicação baseada em documentos XML.

HTML – Hyper Text Markup Language: O HTML é uma linguagem definida por diversas tags que informam aos navegadores web ‘como’ eles devem apresentar a informação contida naquele documento de hipertexto.

HTTP - Hyper Text Transfer Protocol: Protocolo de comunicação que efetua a interação entre um servidor web e um navegador web. É um protocolo de comunicação que está presente na Camada de Aplicação( Camada 7 do modelo OSI e Camada 4 do modelo TCP/IP ). Através deste protocolo, clientes podem efetuar requisições de informações a servidores web e estes podem responder a estas requisições.

Pode-se notar que as três primeiras alternativas tratam sobre caracteristicas de Web Services, enquanto as duas ultimas tratam sobre recursos utilizados na comunicação entre clientes e servidores na internet. Pelas definições apresentadas na questão, deve-se escolher a alternativa correspondente a um serviço onde é possivel se obter/descobrir informações a respeito de Web Services existentes, sendo este um serviço na forma de diretorios. Pelas alternativas, tem-se então a resposta certa como sendo a alternativa C ( UDDI ).

Bons Estudos!

junho 23, 2008 Posted by | Arquitetura de Sistemas de Computação, Questões de Provas, Redes de Computadores | Deixe um comentário

Questões: BNDES 2008

Cargo: Analista de Sistemas – Suporte

Questão
32. Marque a opção em que todas as ações aumentam o desempenho de um servidor HTTP Apache 2.x.
(A) Habilitar a compressão HTTP e transformar as páginas estáticas em componentes CGI.
(B) Habilitar o parâmetro hostnamelookups no Apache e configurar um servidor BIND na mesma sub-rede do servidor WEB.
(C) Alterar o protocolo de transporte para UDP e tornar obrigatório o envio de keepalives.
(D) Substituir os nomes DNS por endereços IP nas diretivas de controle de acesso Allow from e Deny from.
(E) Configurar arquivos do tipo .htaccess sempre que um novo diretório for criado.

Comentários: Essa é uma questão que é menos complicada do que parece. Mesmo que ela utilize termos desconhecidos para muitos, ( como HostNameLookUps, KeepAlinves ou até mesmo servidores BIND ) basta se concentrar no tema principal da questão: Performance. Mas ainda assim vejamos as alternativas uma a uma.

A – A compressão HTTP é um recurso que pode ser utilizado pelo apache e que realmente pode garantir performance. Ela consiste em o servidor compactar os dados que serão sendo enviados ao cliente e o navegador fica responsável pela descompactação( normalmente usando a compactação gzip ). Mesmo que isso gere um overhead no lado do cliente( que atualmente é quase desprezível devido ao poder de processamento dos computadores pessoais ), esse recurso consegue dimunuir o tráfego na rede otimizando assim o tempo de resposta total do servidor. O problema nesta alternativa está na segunda afirmação que diz para substituir paginas estáticas por componentes CGI( Common Gateway Interface ). Componentes CGI são scripts ou programas( isso mesmo, podem ser programas! ) que ficam em algum diretorio no servidor( normalmente no /cgi-bin) e que proveêm alguma funcionalidade disponibilizada na web pelo servidor( geração de conteúdo dinâmico ). Assim, esses componentes geram um overhead do lado do servidor para executar suas tarefas. Dessa forma, não faz nenhum sentido substituir páginas estáticas( textos, imagens, etc… ) que seriam diretamente transmitidas para o cliente por componentes CGI que gerariam um processamento desnecessario no servidor.

B – o HostNameLookups é um mecanismo de verificação do cliente através da resolução do nome em IP em um serviço de DNS e do reverso( como uma confirmação no cliente ). É uma ferramenta que auxilia em ataques de IP Spoofing e sua desativação pode ser considerada como uma pequena brecha de segurança. Mas como o caso aqui é performance, com certeza o HostNameLookups gerará um overhead no Apache. O servidor BIND( Berkeley Internet Name Domain ) é uma implementação de um serviço de DNS que contem uma aplicação servidora, uma biblioteca de resolução de nomes e um pacote de ferramentas relacionadas ao serviço. Pode-se pensar em uma pequena otimização no momento em que o Apache iniciar o processo de HostNameLookups quando adicionamos o BIND na mesma sub-rede. Mas de qualquer forma estariamos melhorando a performance do HostNameLookups e não do apache como um todo( ainda teria overhead gerado ).

C – Bem caro internauta, chegamos na alternativa mais polêmica da questão. É de conhecimento de todos que o protocolo da camada de transporte UDP consegue obter um melhor desempenho que o TCP. Caso pesquisemos no manual do Apache encontraremos em ( 4 ) a documentação a respeito do processo de keepalives e uma informação naquela página que afirma que com este recurso o Apache consegue obter um desempenho até 50% melhor. Explicando: quando um cliente faz uma requisição de uma pagina(supondo conter 4 arquivos: index.html, help.html, logo.jpg e styles.css) ao Apache, serão abertos 4 canais de comunicação(consecutivos, não simultâneos) para o envio de cada um dos arquivos. Somente para estabelecer o canal de comunicação cliente-servidor já existe a necessidade da troca dos pacotes SYN+SYN/ACK+ACK. Somente nesse processo podemos notar que teríamos uma repetição desnecessária desse estabelecimento de conexão. O keepAlives é o recurso que faz com que a primeira conexão seja mantida e todos os 4 arquivos da nossa pagina sejam encaminhados em sequência para o cliente. Essa persistência da conexão é conseguida através de um parâmetro do keepalives conhecido como simplesmente timeout. Assim a conexão é mantida com o cliente até que o timeout se esgote(configurado por padrão para 15 segundos). Com isso realmente é possível de conseguir otimizar a conexão.
ENTAO A ALTERNATIVA ESTÁ CERTA? Bem, não completamente. o KeepAlives possui uma desvantagem considerável. Justamente o seu recurso de timeout. O Apache suporta um número limitado de conexões keepalives simultâneas(consideremos por exemplo 100) configurado no parametro KeepAliveMaxRequests. Em site com grande numero de acessos simultâneos(consideremos 500) os 100 primeiros clientes que se conectarem acessarão o servidor. Os outros 400 teriam que esperar 15 segundos pra entrar na briga pela próxima conexão. Pode-se então discutir a eficiência do KeepAlives em casos específicos, mas fica apelativo garantir que este recurso proporciona um melhor desempenho sempre.
Uma segunda explicação bem mais simples também pode ser dada para eliminar esta alternativa. o KeepAlives é um recurso que provê a persistência da conexão por um limite de tempo. O protocolo UDP é um protocolo não-orientado a conexão. No próprio manual do apache ( 4 ) temos que o conceito de KeepAlives é de “… long-lived HTTP sessions which allow multiple requests to be send over the same TCP connection…”, ou seja, ele trabalha em cima do TCP e não do UDP! Algumas referências e trabalhos na internet ainda tratam a implementação de KeepAlives sobre o UDP, mas como estamos nos referindo ao Apache, Alternativa Incorreta!

D – As diretivas Allow From e Deny From afetam quais hosts terão acesso a uma área específica do servidor. Configurá-las com os nomes dos hosts acarreta em uma requisição dupla de DNS Lookup( independente do parâmetro HostNameLookups estar ativo ou não) a ser efetuada pelo Apache cada vez que um cliente tenta acessar aquela área do site. Substituir os nomes dos hosts que tem/não tem acesso à aquela área por seus IPs ou por uma faixa de IPs acaba com o processo de Lookup, otimizando assim o desempenho do servidor.

E – Totalmente errada esta alternativa. Analisemos. Os arquivos de configuração .htaccess são uma forma poderosa de extender os parâmetros de configuração do seu servidor sem ter que mexer nos arquivos de configuração principais. Através deles é possivel que cada diretório que o contenha possua suas próprias configurações. Mas deixar que o Apache analise cada diretório individualmente geraria um overhead monstruoso ao invés de manter as informações em um arquivo principal.

Portanto(após tamanha explicação e ainda assim muuuito superficial ;) ) vemos que a alternativa correta é a letra D. Como foi comentado no início da questão, não é preciso se apavorar com os termos desconhecidos(caso estes fossem pois já não são mais, correto? ) pois com um pouco de análise na alternativa correta pode-se perceber que o procedimento indicado iria acabar com a necessidade de uma consulta a um servidor de DNS durante o processo de resposta do Apache.

Links Interessantes

1) http://www.isc.org/index.pl?/sw/bind/index.php
2) http://www.serverwatch.com/tutorials/article.php/3436911
3) http://httpd.apache.org/docs/1.3/mod/mod_access.html
4) http://httpd.apache.org/docs/1.3/keepalive.html

Bons Estudos!

junho 3, 2008 Posted by | Arquitetura de Sistemas de Computação, Questões de Provas, Redes de Computadores | Deixe um comentário

   

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.