Para os leitores do Jornal de Arquitetura da Microsoft, a edição 17 já encontra-se acessível no The Architecture Journal Reader. No momento, disponível apenas em Inglês.
O assunto desta edição é a computação distribuída. Há uma série de artigos interessantes nesta edição, contemplando modelagem e padrões arquiteturais para sistemas distribuídos, entre outros.
System.Diagnostics.Debugger.Break();Após este código, os breakpoints normais também serão atingidos.//Criando um objeto task com duas propriedades "Name" e "Enabled" Task t = new Task { Name = "nome tarefa", Enabled = true }; //Salvando o objeto db4oBase = Db40Factory.OpenFile("task.db4o"); db4oBase.Store(t); db4oBase.Commit();
IObjectContainer db4Conn = Db4objects.Db4o.Db4oFactory.OpenFile("base.db4o"); try { //Criando uma nova instância para armazenar na base de dados TimeSheetInfo timeSheet = new TimeSheetInfo(); //Vinculando o tempo a tarefa 'teste' já existente timeSheet.Task = { Name = "teste", Enabled = true }; //Colocando as definições da tarefa timeSheet.Date = DateTime.Now.Date; timeSheet.ClockIn = DateTime.Now; timeSheet.NotWorkingTime = _blnNotWorkingTime; db4Conn.Store(timeSheet); db4Conn.Commit(); } catch (Exception ex) { db4Conn.Rollback(); throw; } finally { db4Conn.Close(); }
timeSheet.Task = (from TaskInfo t in db4Conn where t.TaskName == "teste" select t).Single<TaskInfo>();
A disputa dos runtimes para celulares está muito acirrada, tendo como grande líder o Java ME, que encontra-se em média em 8 de cada 10 dispositivos.
Contudo outras tecnologias também existem, a citar o Flash Lite, WebKit, Silverlight, Qt, Lua e Python. Cada uma com propósitos e características distintas, como pode ser visto na tabela abaixo.
A empresa Vision Mobile, que faz análise de mercado do segmento de mobilidade, publicou um artigo muito interessante em seu blog.
Em um tópico anterior, intitulado Programação Orientada a Aspectos, tratei das motivações e características da POA. Ainda citei ferramentas específicas para .NET, entre elas o PostSharp.
O PostSharp é uma ferramenta que, por sua natureza POA, promove o baixo acoplamento e a redução de linhas de código necessárias para um programa. Além disso, o PostSharp é uma ferramenta de código aberto.
A equipe de desenvolvimento do PostSharp mantém um blog muito interessante, que apresenta tópicos de interesse, como atualizações do PostSharp e soluções que se beneficiam do uso da ferramenta. Destas, gostaria de citar algumas de particular interesse:
A atividade de Log de aplicações, transversal ao desenvolvimento de sistemas, é muito beneficiada pelas ferramentas de POA, por sua característica de espalhamento de código.
O Log4PostSharp é um plug-in do PostSharp que utiliza o consagrado log4net como ferramenta de Log. Com isso, ela traz todos os benefícios do log4net através de mecanismos Orientados a Aspectos.
Com o uso do Log4PostSharp é possível registrar três tipos de mensagens:
Exemplos de código podem ser encontrados no site do Log4PostSharp.
O PostSharp4ViewState é um plug-in do PostSharp que permite controlar o uso da ViewState e do ControlState, de forma declarativa, para persistir informações de propriedades entre Postbacks de páginas e controles do ASP.NET
A Migração do Blog foi concluída, sem nenhum imprevisto.
Uma pequena mudança no título do Blog, saindo a referência ao '.NET'. Isso destaca nosso interesse de, daqui por diante, focar os temas de Arquiteturas de Sistemas e Mobilidade de forma mais abrangente.
Saudações,
Eduardo
Prezados, boa notícia.
Em muito breve, este Blog estará contando com a participação do Paulo Sérgio. Ele é Arquiteto de Sistemas da Mobiltec e possui bastante experiência na área de mobilidade, com destaque para Mobile Banking.
A participação do Paulo Sérgio implicará em algumas mudanças positivas: Alteração do título e link do Blog, que hoje tem uma característica pessoal, e sem dúvida acréscimo de qualidade ao conteúdo do Blog.
Fiquem atentos às novidades.
Saudações,
Eduardo Klein
A nova edição do Jornal de Arquitetura da Microsoft trata do tema Identidade e Acesso. Nela são abordados tópicos fundamentais como Identidades no contexto da Internet e Padrões para Arquiteturas Orientadas a Serviços, entre outros.
A versão em PDF pode ser baixada no site do Microsoft Architecture Journal. Outra boa opção de leitura é o Architecture Journal Reader.
No momento, a versão em português ainda não está disponível. Apenas em Inglês.
Em um post passado (05/07/2008 - Desenvolvimento J2ME para celulares), questionei a compatibilidade do BlackBerry com o J2ME MIDP.
Como pode ser visto neste artigo, a máquina virtual Java da RIM, a BlackBerry JVM, suporta a configuração CLDC e o perfil MIDP. Adicionalmente, incorpora uma série de APIs específicas do Blackberry, que permitem o desenvolvimento de aplicações mais sofisticadas e com visual similar ao das aplicações nativas do Blackberry.
Para a execução de MIDLets já desenvolvidos, é necessária a conversão dos mesmos para o formato do Blackberry (.COD), com o utilitário RAPC do SDK do Blackberry.
A OMA (Open Mobile Alliance) é um fórum organizado com o propósito de especificar e oferecer ao mercado soluções habilitadoras de mobilidade. A OMA foi formada em 2002 e conta com grandes empresas dos ramos de telefonia, redes e sistemas de informação.
Objetivos da OMA:
As atividades da OMA são organizadas em grupos (working groups). Estes são relacionados neste link.
Alguns grupos importantes da OMA:
| Grupo | Descrição |
| Arquitetura | Responsável pela definição geral de arquitetura da OMA e apoio aos demais grupos |
| Requisitos | Especifica e define requisitos de interoperabilidade e usabilidade entre os grupos de trabalho |
| Segurança | Especifica protocolos de comunicação entre dispositivos de mobilidade e servidores nas camadas de transporte e aplicação |
| Gerência de Dispositivos | Define protocolos e mecanismos de gerência do ciclo de vida de dispositivos e seus aplicativos |
| Sincronização de dados | Trabalha em especificações para sincronização de dados |
A OMA divulga sua Newsletter onde são apresentados tópicos de interesse, versões candidatas e aprovadas de seus trabalhos, novos membros da OMA, entre outros.
O Interop é um evento de tecnologia que acontece anualmente em Las Vegas, Nova York, Tóquio, São Paulo e Moscou. Este ano, o evento será realizado de 12 a 14 de agosto, no Transamérica Expo Center.
A Mobiltec encontra-se entre os expositores do evento de 2008, apresentando a solução M3.
Visite o site do evento e confira as atrações.
Log é o termo que refere-se ao registro de eventos de um sistema, tipicamente utilizado para dois fins:
No desenvolvimento de sistemas, encontramos ferramentas que auxiliam a atividade de Log. Entre os recursos que estas ferramentas agregam, podemos destacar:
São muitas as ferramentas de Log de aplicações existentes para o .NET Framework. Entre elas, destaco duas, de licenças open-source:
O .NET Compact Framework (.NET CF) nos oferece um ambiente de execução, um modelo de desenvolvimento e uma biblioteca de tipos para fácil implementação de aplicativos para dispositivos móveis, tipo Windows Mobile. No entanto, existem diferentes plataformas de dispositivos baseados no Windows Mobile. Cada uma, com suas peculiaridades, torna o desenvolvimento do aplicativo móvel, mesmo que baseado no .NET CF, diferente.
A tabela a seguir apresenta as plataformas suportadas pelo .NET CF (Fonte: MSDN - Devices and Platforms Supported by the .NET Compact Framework)
| Dispositivo | Plataforma |
| Pocket PC | Windows Mobile 2003 for Pocket PC, Windows Mobile 2003 for Pocket PC SE, Windows Mobile 5.0 software for Pocket PC, Windows Mobile 6.0 software for Pocket PC |
| Smartphone | Windows Mobile 5.0 software for Smartphone, Windows Mobile 6.0 software for Smartphone |
| Windows CE Embedded | Windows CE 4.2, Windows CE 5.0, Windows Embedded CE 6.0 |
O Pocket PC é um computador de mão (Handheld ou PDA - Personal Digital Assistant), focado em aplicações e dados. O Pocket PC costuma ter uma tela maior que um Smartphone, no formato 3x4 de resolução 240x320. Além disso, sua tela é sensível ao toque, sendo o dispositivo operado com as duas mãos.
Já o Smartphone é um dispositivo focado em voz, como os tradicionais celulares, mas que também combina funcionalidades de computadores e PDAs. Dentro das características de um celular, o Smartphone não possui tela sensível ao toque e pode ser operado com uma única mão, através de um teclado numérico, um botão tipo Joystick e as Softkeys.
No que se refere à biblioteca de tipos do .NET CF, a base é a mesma para as plataformas baseadas no Pocket PC e no Smartphone. A grande diferença fica por conta do desenvolvimento da UI, onde se percebe:
Neste último post, vamos cobrir alguns conceitos da Orientação a Objetos ainda em aberto.
Interface
Uma interface define um conjunto de comportamentos, e são implementadas por classes e componentes. Ao implementar uma interface, uma classe deve conter definições para todos os métodos definidos na mesma.
Uma interface permite a uma classe participar de uma funcionalidade, sem que outras classes saibam detalhes de sua funcionalidade. A única característica conhecida é que a classe 'suporta' a interface exigida.
Os diagramas a seguir apresentam exemplos de interfaces e suas notações.
Componente
É uma unidade funcional, que pode ser desenvolvida de forma independente e composta com outros componentes, de forma a criar sistemas. Um componente é tipicamente um agrupamento de classes com um propósito comum.
Diagrama de componentes de exemplo, com interfaces exigidas e interfaces expostas.
Padrões de Projeto
Padrões de projeto são conjuntos de soluções de modelagem e/ou implementação, que resolvem problemas conhecidos e consagrados do desenvolvimento de sistemas Orientados a Objetos.
Os padrões de projeto são benéficos ao desenvolvimento de sistemas OO em vários aspectos:
Muitas são as referências para padrões de projeto na Internet. Alguns links interessantes:
Conceitos da OO nos posts anteriores:
Você sentiu falta de algum conceito importante neste conjunto de posts sobre Orientação a Objetos? Algum conceito foi abordado de forma insuficiente? Por favor, permita-me tomar conhecimento de sua opinião. Deixe seu comentário.
Se ouve falar bastante sobre a Programação Orientada a Aspectos, e os benefícios que ela agrega à Orientação a Objetos.
Na idéia de se tentar entender estes benefícios, precisamos primeiro entender os efeitos colaterais que encontramos na Orientação a Objetos.
Estas características acabam comprometendo vários conceitos importantes da Orientação a Objetos, como a Coesão e o baixo acoplamento.
Alternativas para lidar com estes efeitos colaterais:
Separação de interesses (Separation of Concerns), segundo sua importância ou responsabilidade no sistema. Assim, o programador pode separar funcionalidades secundárias em módulos distintos do sistema.
Prós:
Fica por conta da motivação central da POA, a separação de interesses.
Contras:
A grande queixa da POA fica por conta da depuração de código, que é
mais complicada. Isto porque em tempo de codificação os códigos estão
separados por interesses, mas em tempo de execução estes elementos
estão juntos.
Para os interessados, existem diversos frameworks de POA, inclusive open-source, para uso com o .NET Framework. Algumas referências:
Este quarto post tem como objetivo discutir os conceitos associados ao mecanismo de herança da Orientação a Objetos. A herança é um dos recursos mais poderosos da OO quando falamos de "reuso" de código. Porém esta deve ser utilizada com muita cautela, pois muitas vezes é aplicada de forma desnecessária e leva muitas modelagens ao fracasso.
Herança
A herança é o mecanismo da OO que permite que compartilhemos atributos e métodos entre classes, quando detectamos similaridades entre estas. A herança modela relações como "Classe A é do tipo de Classe B" e "Classe A é como Classe B".
Neste primeiro exemplo vemos o uso de classes com características comuns, porém a herança não é aplicada.
Podemos ver claramente a duplicação de conceitos. Entre estas duplicações, temos as relações das classes semelhantes (Contas Corrente e Poupança) com as classes Pessoa e Transacao, além do atributo saldo, e sua respectiva propriedade.
É fácil percebermos que Conta Corrente e Conta Poupança são tipos de contas bancárias. Aplicando o mecanismo de reuso através da herança, podemos chegar ao seguinte modelo:
Perceba que os elementos duplicados não mais existem nesse modelo. As características comuns estão concentradas na classe abstrata Conta Bancaria. Uma vez que estes elementos comuns são agrupados em uma única classe, futuras adaptações ou correções do sistema ficarão mais fáceis (visto que estas não precisarão ser replicadas).
Supertipo: Refere-se à classe superior na relação de herança (no exemplo, a classe Conta Bancaria)
Subtipo: Refere-se à classe especializada na relação de herança (no exemplo, as classes Conta Corrente e Conta Poupança)
Sobreposição: A sobreposição refere-se à redefinição de métodos na hierarquia da herança, de forma que estes métodos implementam definições diferentes (mais especializadas) nos subtipos
Conceitos da OO nos posts anteriores:
Nos próximos posts, ainda serão tratados:
Neste terceiro post, iremos explorar os relacionamentos entre objetos e classes.
Associação
A associação é um relacionamento entre classes ou objetos. As associações são modeladas com base nas relações reais dos objetos e identificam quais objetos se comunicam entre si.
O diagrama a seguir apresenta uma associação entre duas classes.
Uma associação possui uma série de ítens de modelagem, entre eles:
0..1 - zero ou um (relação opcional) 1 - apenas um (relação obrigatória) 0..* - zero ou mais 1..* - um ou mais n - apenas n 0..n - zero a n 1..n - 1 a n
Agregação
A agregação é uma relação entre classes ou objetos, onde um é classificado como "parte" de outro. Ela representa uma relação onde um objeto é feito de outros objetos.
O diagrama a seguir apresenta uma relação de agregação.
Composição
É um tipo especial de agregação, mais forte, onde um objeto é totalmente responsável por suas partes. Além disso, uma "parte" pertence a apenas um objeto agregador.
Diagrama com exemplo de composição:
Conceitos da OO nos posts anteriores:
Nos próximos posts, ainda serão tratados:
Entre os grandes desafios do momento na Mobiltec estão alguns projetos específicos para desenvolvimento mobile. Entre os dispositivos móveis "alvo" dos projetos, temos os celulares convencionais e dispositivos Blackberry da RIM.
Uma pouco de pesquisa na internet nos leva a um ponto em comum: A Plataforma JavaME.
E junto, dois novos conceitos são introduzidos:
Para desenvolvimento JaveME, é necessário o J2ME Wireless Toolkit, combinado com uma IDE Java para desenvolvimento (como Eclipse ou Netbeans).
Após a pesquisa inicial, um pouco de ambientação... Montamos o Eclipse com seu plug-in para JavaME, o EclipseME. A equipe desenvolveu alguns exemplos de MIDLet (aplicativo JavaME).
Próxima visita, site do Blackberry Developer Program. Lá encontramos o BlackBerry JDE. Segundo o site:
"The BlackBerry® Java® Development Environment (BlackBerry JDE) is a fully integrated development environment and simulation tool for building Java Micro Edition (Java ME™) applications for Java ® based BlackBerry® smartphones. It is a Mobile Information Device Profile (MIDP) compliant Java ME environment for developers who wish to maintain seamless portability in their wireless applications."
Ambiente instalado, e a surpresa: Uma série de pacotes específicos do Blackberry (net.rim.*), que me levam a desconfiar que os ambientes são incompatíveis e que os MIDLets de exemplo construídos anteriormente não funcionarão no Blackberry. Ou estes pacotes seriam apenas um novo conjunto de recursos?
Onde fica o "JavaME compliant"?
[Ver post Compatibilidade da JVM do Blackberry com J2ME]
Outra preocupação fica na parte do "visual" dos aplicativos, que parece limitadíssimo. Tudo bem que estamos falando de "Limited Device Configuration", mas os componentes visuais já embutidos são extremamente simples.
E a aventura está apenas começando...
Segue mais um conjunto de conceitos da orientação a objetos. Embora o título do post cite a UML, esta segunda parte não apresenta diagramas da mesma. Isto pelo fato de que neste post são tratadas características mais conceituais da Orientação a Objetos.
Abstração
É a ação de pensarmos nas características essenciais de um objeto, sem nos preocuparmos como ele atinge estes objetivos. A abstração nos permite lidar mais facilmente com a complexidade de um sistema, pois em etapas iniciais da concepção do mesmo, ainda não dispomos de conhecimento suficiente para determinar os detalhes de cada objeto.
Dentro do conceito de abstração, definimos o que um objeto é capaz de fazer e o que a classe 'sabe'. Isso inclui atributos e métodos de interesse. O resto é postergado.
Coesão
A coesão refere-se à relação da implementação de uma classe ou método, com o seu propósito.
Classe e métodos altamente coesos são aqueles que implementam exatamente as suas responsabilidades. Quanto mais uma classe ou método implementa lógicas e controles que não são de sua responsabilidade, mais baixa é a sua coesão.
Caso não tomemos os devidos cuidados, a medida que um sistema é implementado a coesão das classes e métodos tente a diminuir, onde o ideal seria manter uma alta coesão.
Para lidarmos com este problema, é essencial um bom 'design' da estrutura do nosso sistema. Padrões de projeto são excelentes recursos para estruturarmos classes e métodos e eles nos ajudam a priorizar uma série de aspectos da OO, inclusive a alta coesão.
Acoplamento
O acoplamento está diretamente relacionado à dependência entre duas classes. O acoplamento é alto quando uma classe depende da implementação de outra (isto é, acessa os atributos da outra classe diretamente). Quando uma classe sabe interagir com outra sem conhecimento dos detalhes de implementação da segunda (apenas interagindo com esta através de métodos), então esta relação é de baixo acoplamento.
Encapsulamento
Refere-se a idéia de agrupar os conceitos de um determinado objeto dentro dele mesmo. Os métodos e atributos que conceitualmente pertencem a um objeto são compartimentados dentro da especificação da classe que o define.
O encapsulamento nos permite redefinir a implementação interna de uma classe, sem afetar outras classes e componentes do sistema, pois a utilização de um objeto não depende de sua implementação, mas sim de sua interface.
Mensagem
A mensagem é uma requisição de um objeto a outro, seja para obter uma informação ou para executar uma atividade. Uma mensagem é composta pelo nome de um método e lista de parâmetros.
Polimorfismo
É a habilidade de diferentes objetos responderem a uma mesma mensagem de forma distinta. Com o polimorfismo, é possível tratarmos instâncias de várias classes de uma forma comum. Assim, um objeto pode enviar uma mensagem a outro sem saber exatamente o seu tipo, e este segundo irá trabalhar corretamente.
Colaboração
É uma característica natural da OO, onde as classes trabalham em conjunto para realizar suas atividades
Conceitos da OO nos posts anteriores:
Nos próximos posts, ainda serão tratados:
Em uma série de posts, estarei cobrindo os principais conceitos da Orientação a Objetos. Além disso, irei apresentar estes conceitos através de pequenos diagramas da UML.
Classes e objetos
A classe é a abstração de um objeto. Ela define a estrutura de atributos e métodos dos objetos que são criados a partir dela.
O objeto, por sua vez, é o elemento que representa um conceito do mundo real. O objeto é capaz de realizar ações típicas do elemento que ele representa.
Instância: É um objeto de uma determinada classe. Ao processo de criação de um objeto, dá-se o nome de instanciação.
Classe concreta: Classe da qual podemos criar instâncias
Classe abstrata: Classe da qual não podemos criar instâncias
Atributos e métodos
Atributos são dados que determinam o estado de um objeto. Os métodos, por outro lado, são funções que determinam o comportamento do objeto.
Os métodos podem executar atividades que modifiquem o estado (atributos) do próprio objeto, ou que apenas computem um valor significativo retornado ao invocador dos mesmos.
Abaixo, diagrama de classes ilustrando métodos, atributos e relações. Na notação da UML, o primeiro quadro de uma classe exibe o nome da mesma. Os dois quadros opcionais abaixo deste exibem os atribudos e métodos da classe.
O próximo diagrama é um exemplo de diagrama de objetos. Cada objeto representando uma entidade real, instanciada no sistema. Atributos já podem se encontrar valorados.
Nos próximos posts, estarei apresentando outros conceitos da OO, como:
O jornal de arquitetura da Microsoft, The Architecture Journal, é uma publicação que traz a opinião de Arquitetos da comunidade de Arquitetos da Microsoft. Este jornal trata de assuntos relacionados à arquitetura de aplicações e gestão e infra-estrutua de TI.
Recentemente a Microsoft publicou um leitor para este jornal. O The Architecture Journal Reader é um aplicativo WPF, que apresenta como recursos a sincronização automática com novo conteúdo publicado, índice de leitura, resumos e mecanismo de pesquisa, entre outros.
A Mobiltec foi novamente premiada com o Melhor Produto Inovador no Espaço Inovação do CIAB Febraban 2008.
O produto apresentado no Congresso foi o Atendente Móvel, que utiliza tecnologia de mobilidade. Com isso os bancos poderão atender seus clientes de forma mais ágil e eficiente, dentro e fora das agências.
A solução é equipada com dispositivo PDA totalmente integrado, com funções de leitora de cartões magnéticos, leitora de código de barras, teclado numérico e impressora térmica.
Informações técnicas:
Middleware de Mobilidade:
A solução tem como alicerce o Middleware de Mobilidade M3, que agrega:
Referências:
Há alguns dias fui questionado sobre as atribuições de Arquitetos, Analistas e Engenheiros de sistemas. Este tipo de pergunta é muito freqüente na nossa área.
Embora não seja um consenso, é possível discriminar as atividades de cada um destes papéis.
Analista:
Tem como atribuições levantar e especificar, junto aos usuários, os requisitos funcionais do sistema.
Atividades relacionadas:
Engenheiro:
O engenheiro é o profissional responsável por definir e manter o projeto da infra-estrutura de rede e componentes físicos que darão suporte ao sistema.
Atividades relacionadas:
Arquiteto:
Tem como atribuições definir e manter a estrutura organizacional de um sistema. O arquiteto define classes, componentes e subsistemas e suas interações, relações e restrições. A visão do arquiteto é a mais abrangente, dentre os mebros da equipe do projeto.
Segundo o RUP, "o arquiteto de software estabelece a estrutura geral de cada visão de arquitetura: a decomposição da visão, o agrupamento dos elementos e as interfaces entre esses principais agrupamentos".
Arquiteto de Software - RUP 2003.06.00.06Atividades relacionadas:
Para quem busca uma classificação mais detalhada e abrangente do perfil de Arquiteto, sugiro a leitura deste link (em inglês):
O .NET Remoting é o mecanismo do .NET Framework que permite o desenvolvimento de aplicações distribuídas.
Na Mobiltec estamos desenvolvendo um sistema distribuído, onde passei pela necessidade de montar a Arquitetura da solução utilizando o Remoting. Neste sistema, os objetos estarão hospedados no IIS, onde a comunicação é efetuada através de HTTPChannel, e será utilizada serialização binária com BinaryFormatter.
A configuração do ambiente do Remoting é cercada de detalhes. A seguir reproduzo um passo a passo desta configuração, com trechos de código e configurações. Os códigos, escritos em C#, não são parte do sistema citado, apenas exemplos.
Definição dos objetos distribuídos
Os objetos distribuídos representam serviços que uma camada de componentes oferece para uma camada de apresentação do sistema. Para viabilizar a criação de Proxies, por parte do .NET Remoting, é necessário que a classe que representa o objeto distribuído faça herança do tipo MarshalByRefObject. Interfaces são aplicadas para que a camada 'consumidora' dos objetos remotos conheça os métodos oferecidos pelo objeto remoto. Segue um exemplo.
public class AccountBLL: MarshalByRefObject, IAccountBLL { Account IAccountBLL.GetAccount(string _accountName) { ... } }
Definição dos objetos 'transportados'
As classes que representam os objetos a serem transportados são serializadas/desserializadas para a comunicação. O atributo Serializable é utilizado para indicar que uma classe pode ser serializada.
[Serializable] public class Account { public string Name { get { ... } set { ... } } public <ListTransaction> Transactions { get { ... } set { ... } } }
Configuração do servidor IIS
A pasta virtual do IIS contém os binários da parte servidora do sistema em uma pasta bin e o respectivo Web.config da aplicação. No Web.config, configuramos as propriedades do .NET Remoting e os objetos que são expostos na rede. O exemplo a seguir utiliza a combinação do canal HTTP com o BinaryFormatter e exporta um objeto exemplo.
<configuration> <system.runtime.remoting> <application> <!-- Canal HTTP com formatação binária --> <channels> <channel ref='http'> <serverProviders> <formatter ref='binary'/> </serverProviders> </channel> </channels> <!-- Serviços expostos --> <service> <wellknown mode="SingleCall" type="BLL.AccountBLL, BLL" objectUri="Account.rem"/> </service> </application> </system.runtime.remoting> </configuration>
Configuração da aplicação cliente
A aplicação cliente, assim como o servidor, deve indicar o uso do HTTPChannel e BinaryFormatter.
<configuration> <system.runtime.remoting> <application> <!-- Canal HTTP com formatação binária --> <channels> <channel ref='http'> <clientProviders> <formatter ref='binary'/> </clientProviders> </channel> </channels> </application> </system.runtime.remoting> </configuration>
No início da aplicação, ou em algum outro momento conveniente, deve ser aplicada esta configuração explicitamente (Perceba que no servidor não foi necessário. O próprio ASP.NET se encarregou de aplicar as configurações do Web.config)
RemotingConfiguration.Configure("App.config", false);
Acesso aos objetos remotos
Já estamos prontos para fazer o acesso ao objeto remoto na aplicação cliente. A interface do componente remoto é utilizada para fins de montagem do Proxy do objeto e para acesso aos métodos disponíveis.
IAccountBLL accBLL = (IAccountBLL) Activator.GetObject(typeof(IAccountBLL), "http://localhost/SampleRemoting/Account.rem"); Account acc = accBLL.GetAccount("Nome");
O .NET Remoting viabilizou o acesso a um objeto remoto, como se fosse uma instância local. Então muito cuidado. É necessário cercar o acesso com tratamentos relacionados à disponibilidade do serviço remoto e também é preciso considerar os impactos de performance.
Programadores da linguagem C# percebem claramente que o VBNet traz flexibilidades à programação. O compilador C# é mais rígido com declarações de variáveis e conversões de tipos do que o compilador VBNet.
Para aqueles que gostam da maior rigidez do compilador, existem duas diretivas que ativam validações do compilador VBNet.
Option Explicit On:
Com esta diretiva declarada, todas as variáveis utilizadas devem ser declaradas com Dim ou ReDim. O código a seguir gera erro de compilação com Option Explicit On:
Dim thisVar As Integer thisVar = 10 thisInt = 10 ' erro de compilação
Option Strict On:
Com esta diretiva declarada, conversões implícitas de tipo, com perda de informação, são rejeitadas pelo compilador. O código a seguir gera erro de compilação com Option Strict On:
Dim thisVar As Integer thisVar = 1000 thisVar = 123456.789 ' erro de compilação
Esta opção proporciona uma tipagem mais forte, previne conversões com perdas não intencionais e desabilita a late binding, desta forma melhorando o desempenho do código.
Ativação das diretivas
São duas as formas de ativação:
Durante a fase de elaboração de um projeto baseado no RUP (Rational Unified Process), um artefato chave é o documento de arquitetura do sistema. Este artefato define a estrutura, a comunicação de componentes e endereça requisitos não-funcionais do sistema.
O documento de arquitetura tem como propósito comunicar a estrutura do sistema para as partes interessadas no mesmo, como patrocinadores, vendedores, técnicos, desenvolvedores, usuários e outros. Estes nitidamente com conhecimentos, interesses e foco totalmente distintos uns dos outros. Para isto tipicamente são utilizados diferentes níveis de abstração, onde visões distintas são criadas sobre os componentes da arquitetura e estes componentes são hierarquicamente decompostos para satisfazer diferentes níveis de interesse.
Tipicamente utilizo dois diagramas clássicos da UML para a descrição geral da arquitetura de um sistema:
Visão de componentes:
Aqui utilizo o diagrama de componentes para descrever os elementos significativos da arquitetura e as suas relações. Estes elementos podem ser componentes desenvolvidos no projeto, bibliotecas de terceiros, subsistemas e classes, entre outros.
Dentro da idéia de decomposição, são criados tantos diagramas quantos forem necessários para detalhar componentes complexos.
Visão de implantação:
Nesta visão o diagrama de implantação explora o cenário físico de alocação dos componentes em máquinas e como eles se comunicam através de redes, bancos de dados e arquivos.
Esta visão apresenta o potencial de escalabilidade do sistema, necessidades de hardware, entre outros.
Em interações com usuários e equipes de desenvolvimento, percebi que uma outra visão bastante esclarecedora e muito importante é a Visão de Desenvolvimento.Esta explora idéias fundamentais da organização do sistema, de particular interesse da equipe de desenvolvimento: A estrutura interna dos componentes do sistema, como os códigos-fonte e outros artefatos são manipulados no ambiente de desenvolvimento e como estes são mantidos em repositórios de controle de versão.
Creio que o sucesso do documento de arquitetura passa por conseguir levar aos diferentes tipos de indivíduos envolvidos os diversos aspectos da estrutura do sistema de forma clara e objetiva.
No momento, estou envolvido em um projeto de desenvolvimento de um sistema para um grande cliente do Rio de Janeiro. Meu papel no projeto é o de Arquiteto, embora também exerça outros papéis.
Ainda em fase de elaboração, um dos desafios é montar o ambiente de análise do sistema, ou seja, definir a ferramenta Case e o processo de análise. Há de se levar em consideração aspectos relacionados às etapas de Design e codificação, pois é interessante que uma única ferramenta seja utilizada em todo o projeto, a fim de otimizar a comunicação e a integração entre as etapas do ciclo de desenvolvimento.
O sistema em questão será desenvolvido em plataforma .NET, utilizando tecnologias como ASP.Net Web Forms, Ajax, .NET Remoting, ADO.Net e muito provavelmente o Windows Workflow Foundation.
Algumas características do sistema e do ambiente desenvolvimento:
Por forte recomendação do cliente, que utiliza esta plataforma de modelagem, a primeira opção a ser avaliada é a ferramenta Rational SW Modeler, da IBM. A ferramenta possui integração com repositório de fontes do tipo CVS (Concurrent Version System), que é o habilitador do cenário de compartilhamento dos modelos. A deficiência da ferramenta fica por conta de não oferecer engenharia de código para a linguagem VB.NET. No caso de utilização desta ferramenta, geração de código não existe e sincronização de modelos vira um processo manual. A impressão que fica é que o Rational SW Modeler é um gigante que faz muito pouco.
Outra ferramenta análisada foi o Enterprise Architect, da Sparx Systems. Esta, por sua vez, parece ser uma ferramenta muito mais focada na plataforma .NET. Oferece engenharia de código com VB.NET e integração com repositório de fontes do tipo CVS, VSS (Visual Source Safe) e o TFS (Team Foundation Server). No que se refere a UML, o Enterprise Architect parece muito superior ao SW Modeler. A única questão que não fica muito interessante é que o Enterprise Architect força um mesmo modelo de manipulação do repositório para todos os repositórios (no caso, o modelo de check-out com lock e check-in do VSS). Nisto o SW Modeler é mais flexível.
Embora a tendência a termos que utilizar o SW Modeler, por exigência do cliente, estamos com uma iniciativa forte para convencermos a equipe técnica do mesmo a aceitar a utilização do Enterprise Architect. Este segundo parece muito mais aderente ao cenário do projeto e ao futuro do sistema. Além de ter um custo muito inferior ao custo do primeiro.
Com as limitações de meu blog anterior, estou iniciando as atividades no Blogger.
Sou Eduardo Klein, 26 anos. Moro e trabalho em Porto Alegre/RS.
Trabalho com desenvolvimento de sistemas, principalmente sobre a plataforma .NET, na Mobiltec (http://www.mobiltec.com.br). A Mobiltec atua no desenvolvimento de sistemas próprios (produtos) e para terceiros (projetos externos), através de prestação de serviço.
No ciclo de vida dos sistemas desenvolvidos, seja os internos ou os externos, atuo principalmente na parte de Arquitetura destes e nas etapas de desenvolvimento, dentro da Fábrica de Software.
Maiores detalhes ao meu respeito podem ser vistos no meu site pessoal, em http://www.paginas.terra.com.br/informatica/epklein.
Saudações, Eduardo Klein
