| com exemplos em VB |
| Componente para deixar forms em Vb semelhantes às telas do winnamp |
| Componente para colocar sua aplicação VB no Systray |
| Componente para transformar sua aplicação VB em serviço |
| Ferramentas úteis para quem usa Olap Server |
 |
 |
||||||||
|
|
||||||||
|
||||||||
 |
 |
 |
 |
 |
 |
 |
||
 |
Por Dennes
Torres  dennes@bufaloinfo.com.brDennes Torres possui as certificações MCAD, MCSD,MCSE, MCDBA e MCT. Atualmente atua Como diretor da Búfalo Informática, líder do grupo de usuários DevASPNet no Rio de Janeiro e membro da liderança dos grupos getWindows e devSQL, também do Rio de Janeiro, podendo sempre ser encontrado na lista de discussão do grupo DevASPNet (devaspnet-subscribe@yahoogrupos.com.br) bem como nas reuniões do grupo. Mantém dois blogs em http://cidadaocarioca.blogspot.com e http://br.thespoke.net/blogs/dennes/default.aspx |
|
|
|
| WebServices, COM+ ou Remoting ? | |
|
|
|
Mas afinal, com 3 possíveis opções, qual utilizar ?
Bem, como primeiro passo, vamos descartar uma das opções. WebServices NÃO são opção para desenvolvimento em camadas.
Calma! Não se assuste, explicarei !
WebServices são meio de comunicação, protocolo de comunicação e não componentes para montagem de camadas.
Quando se fala de WebServices muitas vezes quem está começando imagina apenas os projetos de ASP.NET WebServices. Mas os webServices podem ser construidos de outras formas.
- O COM+ 1.5 (Windows XP e Server 2003) possui recursos para gerar webServices a partir dos componentes hospedados no COM+. O webService, neste caso, funciona como uma casca de comunicação com a camada de negócio, os componentes.
- Podemos usar componentes da arquitetura .NET Remoting através de HTTP, na forma de webServices
Assim sendo os webServices devem ser usados como o que eles são : uma camada de comunicação com a camada de negócios da empresa e não a própria camada de negócios da empresa.
E por que essa restrição ?
Porque os webServices fazem sua comunicação através de HTTP e XML. Em comparação com DCOM ou .NET Remoting o HTTP e XML são mais volumosos e lentos, eles apenas são excelentes para comunicações em grandes redes como a internet, passando por firewalls, mas dentro de uma rede interna o DCOM ou o .NET Remoting são melhores opções.
Assim sendo os webServices são uma excelente opção, sim, para desenvolver acesso remoto a uma camada de negócios. Mas desenvolvendo localmente a utilização de COM+ ou .NET Remoting pode ser bem mais eficiente.
Então agora temos 2 opções, COM+ e .NET Remoting. Temos ? Talvez com essas 2 opções você já esteja desejando optar pelo remoting... mas não é bem assim....
Devido ao fato do COM+ ser uma tecnologia pré-.NET muitos vêem o COM+ como legado, como algo do passado. Não é bem assim...
O COM+ continua sendo, ainda hoje na era do desenvolvimento .NET, O SERVIDOR de componentes da Microsoft.
O .NET Remoting permite o disparo de componentes remotamente, mas não possui muitos recursos que garantam o gerenciamento da escalabilidade de tais componentes no servidor. Até mesmo o processo container para componentes do .NET Remoting precisa ser produzido por nós.
Desta forma, só o COM+ fornece recursos adequados para o gerenciamento da escalabilidade, tal como Just-In-Time Activation e Shared Properties, além de muitos outros recursos avançados como Queued Components, COM+ Events, CRM, transações distribuidas, segurança, e muito mais.
Vendo por esse ponto de vista, podemos imaginar o COM+ como a melhor opção para o desenvolvimento em camadas, e na maioria das vezes realmente é.
Mas tem um porém. O COM+ utiliza, para comunicação remota, o DCOM, enquanto que o .NET Remoting tem a possibilidade de utilizar recursos de comunicação mais otimizados do que o DCOM.
Então, como ficamos ?
Então temos o COM+ para grandes aplicações onde for necessário grande escalabilidade, o .NET Remoting para aplicações menores onde a performance for um fator mais crítico que a escalabilidade e os webServices podem ser utilizados como intermediários, camada de comunicações entre aplicações externas e os componentes COM+ ou .NET Remoting
Veja abaixo os comentários já enviados :
| Nome : Alexandre Fernandes | E-Mail : alexandretarifa@gmail.com |
| Muito bom este artigo | |
| Nome : Windson Mateus | E-Mail : windmateus@gmail.com |
| Excelente artigo. | |
| Nome : Fabiano | E-Mail : fabianobb@ig.com.br |
| Excelente artigo, seria legal que tivesse um código de exemplo de cada modelo. | |
| Nome : Othon Gomes Lucas Neto | E-Mail : oneto@firjan.org.br |
| Muito bom, estava com algumas dúvidas de escalabilidade e ficou mais claro agora. Vocês poderiam falar um pouco mais do .Net Remoting |
|
| Nome : Fabio | E-Mail : penhabiazi@hotmail.com |
| O artigo é muito bom, mas estou comecando agora com delphi 2005, gostaria de saber como faço uma conexao entre o cliente e servidor igual ao Delphi 7 usando o componente socket. Eu passava o endereco IP e username do banco e password, apos a autenticacao, o servidor inicializava e liberava os acessos. Nao consegui visualizar isso no .net remoting, pois criei um servidor e uma aplicacao cliente, so que nao consigo passar os dados para autenticaca (IP, username, password). Teria algum componente proprio para isso ou tenho q passar atraves de alguma propriedade/evento etc... sem mais Obrigado Fabio Marcelo Biazi |
|
| Nome : Dennes | E-Mail : dennes@bufaloinfo.com.br |
| Sockets são conexões de rede em camada de transporte (vide modelo OSI). Passagem de logins e senhas não está ligado a sockets, são implementações particulares da aplicação. No .NET você tem acesso a sockets pelo namespace System.NET, mas vai cair na mesma questão do remoting : Sockets não são responsáveis por controle de login, sua aplicação ou o SO que fazem isso. Melhor seria utilizar remoting e implementar com ele o login. []'s Dennes |
|
| Nome : Byron Bernardes Jr. | E-Mail : byronjunior@casadamoeda.com.br |
| Caro Dennes, um excelente overview sobre Websevices, apesar se suscinta a explicação ficou clara, principalmente Escalibilidade vesus Performance. | |
| Nome : enevaldo | E-Mail : vadaer@yahoo.com.br |
| gostaria de exemplo de qualquer aplicativo utilizando conexao banco dados ADO utilizando componente COM+, conceito desenvolvimento em trÊs camadas utilizando transações. grato. enevaldo |
|
| Nome : Marcos André | E-Mail : marcolinodesign@ibest.com.br |
| Estou tentando desenvolver uma aplicação em delphi para acessar um webservice via xml....Já pesquisei horas e não encontro uma luz. Será que vc poderia me ajudar? | |
| Nome : Gordurinha | E-Mail : gordurinha131@terra.com.br |
| Excelente Artigo, eu só num entendi bulhufas.... Vlw Galera |
|
| Nome : Bruno Gallego | E-Mail : brunoonline@click21.com.br |
| Aproveitando o embalo, poderia citar também sobre Message Queue que é uma outra forma de trocar mensagens que poucos conhecem e muito importante, principalmente falando em disponibilidade. MSMQ - Message queue é o serviço de mensagens do windows e é 100% integrado com .NET. Permite enviar mensagens em XML , Binario ou ActiveX para outras maquinas, semelhante as tecnologias citadas pelo dennes. Ainda funciona com DTC ( Controle de Transação utilizado pelo COM+ ). Só não é tão interessante quando a msg precisa ser síncronizada, ou seja, precisa de um retorno/resultado. --- Bruno Gallego |
|
