Interoperabilidade ou Migração?

A primeira grande decisão é se se deve optar por aproveitar a base existente, aproveitando os mecanismos de interoperabilidade existentes, ou migrar as aplicações ou parte delas, de modo a evitar mistura de tecnologias.

Por princípio, devido a questões de simplicidade e performance, o código .Net deve interagir o mínimo possível com COM. Quando são criadas novas aplicações, seguir este princípio não é complicado. No entanto, o facto é que a maior parte dos desenvolvimentos são feitos sobre aplicações já existentes, pelo que nestes casos é necessário decidir entre a interoperabilidade e a migração.

A interoperabilidade é um mecanismo que funciona bastante bem para casos simples, mas que se pode complicar quando os componentes COM não são triviais. Por outro lado, existem questões de performance que se agudizam quando componentes .Net comunicam com componentes COM que usam o modelo Single-Threaded Apartment, como é o caso dos componentes criados em VB6. Finalmente, a interoperabilidade também ajuda a evitar a duplicação de funcionalidades entre as duas tecnologias.

A migração de componentes é uma decisão importante, dado implicar a reescrita de código. Esta pode ser a melhor solução quando o peso da interoperabilidade, seja devido à complexidade seja devido à performance, é grande. A migração também tem a vantagem de permitir que o código seja renovado, aproveitando todas as vantagens da nova plataforma.

Interoperabilidade

Quando a via é a da interoperabilidade, existem diversas questões a tomar em atenção e diversas alternativas a analisar. Nesta secção descrevem-se aquelas que considero mais relevantes.

A invocação de componentes COM STA é pesada, dado que implica a utilização de proxies/stubs e a interacção entre diversas threads. Todos os componentes VB6 são STA.

Decorre do ponto anterior que as interfaces devem ser pouco conversadoras (“chatty”), ou seja, para concretizar um serviço, as invocações de métodos devem ser reduzidas a um mínimo, para minimizar o peso da mudança de contexto.

Os inputs e outputs dos métodos devem ser de tipos tão simples quanto possíveis. Idealmente os tipos devem ser blittable. Os seguintes tipos têm estas características:

• System.Byte
• System.SByte
• System.Int16
• System.UInt16
• System.Int32
• System.UInt32
• System.Int64
• System.IntPtr
• System.UIntPtr
• Arrays uni-dimensionais de tipos blittable.

O MSXML não é suportado em aplicações .Net, pelo que não podem existir inputs nem outputs de classes do MSXML, como o DOMDocument, em métodos que devem ser interoperáveis.

O mecanismo de interoperabilidade faz-se através de wrappers, os RCW (runtime callable wrappers) e os CCW (COM callable wrapper).

No caso dos RCW, regularmente os mais importantes dado que são os usados pelos componentes .Net para invocar componentes COM, a gestão de memória faz-se por garbage collection, logo é não-determinista. Esta característica pode ser problemática, dado que a gestão dos componentes COM faz-se por contagem de referências, e por conseguinte é determinista. Esta diferença é extremamente importante quando os componentes COM mantêm recursos dispendiosos que devem ser libertados logo que possível. O caso clássico é quanto o nosso objecto COM mantém uma ligação aberta à BD, que apenas é fechada quando aquele é destruído. Este objecto, se utilizado por objectos .Net tem um tempo de vida indefinido, devido ao garbage collection, o que pode significar a existência de uma ligação pendurada por cada instância do referido objecto COM. Nestes casos o melhor é criar um wrapper que implemente o padrão Disposable, descrito em http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconFinalizeDispose.asp.

A utilização de ADO e ADO.Net deve ser evitada em métodos interoperáveis, por questões de performance, relacionadas com o marshaling e a mudança de contextos.

As páginas ASP e ASP.Net podem coexistir num mesmo site sem problemas, dado que são processadas por ISAPIs diferentes. Existem apenas algumas questões quando se pretende partilhar dados entre as duas tecnologias.

Tanto o objecto Session como o Application do ASP não podem ser usados em ASP.Net, pelo que não podem ser usados para partilhar estado, seja de sessão seja de aplicação. Existem diversas alternativas à utilização destes objectos, como a partilha de estado por URL ou campos escondidos nos formulários para o caso do objecto Session, por exemplo.

Se uma página ASP.Net utilizar objectos COM STA, deve ser aplicado o atributo aspcompat à página, tanto por questões de performance como no caso do objecto COM necessitar de aceder aos objectos de contexto ASP. Este atributo deve ser aplicado a todas as páginas que se encontrem nestas condições, mas a mais nenhumas.

Por vezes pode fazer sentido utilizar os Web Services para criar uma fachada (façade) para uma aplicação COM, utilizando adapters. A utilização do Scriptor por componentes .Net pode utilizar esta solução.

Migração

Nos casos em que se opta pela migração, é necessário tomar algumas decisões quanto ao processo de migração. A migração deve ser horizontal ou vertical? A aplicação deve ser migrada à medida que são adicionadas novas funcionalidades?

A decisão de migrar componentes COM para .Net deve ser tomada após uma avaliação cuidada das vantagens desta decisão, pois representa um conjunto de tarefas potencialmente complexas, demoradas e com alguns riscos. Normalmente, a migração compensa quando, do ponto de vista do negócio, se chegou à conclusão que a remodelação da aplicação, ou de algum seu componente, é necessário.

Regra geral, quando se opta pela migração, deve-se optar pelas áreas da aplicação mais independentes e/ou mais simples.

Ao processo de migração de uma aplicação por camadas, dá-se o nome de migração horizontal. Este tipo de migração é conveniente quando a aplicação em causa não é demasiado complexa, sendo relativamente simples a substituição de uma camada inteira, por exemplo quando a camada de apresentação é constituída por poucas ASPs.

Quando se opta por uma migração horizontal, a camada mais óbvia para migrar primeiro é a de apresentação, pois o ASP.Net apresenta muitas vantagens, bastante evidentes, em relação às ASPs:

• Potentes capacidades de data-binding.
• Mecanismos simples e flexíveis de configuração.
• Gestão de sessões mais eficaz.
• Poderoso mecanismo nativo de caching.
• Melhor performance.
• O modelo de criação de páginas ASP.Net é muito mais produtivo e moderno.
• Server-side controls…

À migração que se faz por funcionalidades, ou por use cases, dá-se o nome de migração vertical. Neste caso, após análise da aplicação, decide-se quais as áreas que serão migradas, efectuando-se a operação verticalmente, através de todas as camadas.

Esta é uma boa solução quando:

• As áreas/funcionalidades da aplicação se encontram isoladas entre si, partilhando pouco código e dados.
• Se pretende refazer a aplicação. Neste caso a migração por áreas é uma boa base de testes para a reconstrução gradual da aplicação.
• Se pretende adicionar novas funcionalidades. Sempre que se criar novo código, a utilização de .Net deve ser ponderada seriamente.

Quando são identificados componentes COM a migrar para .Net, é altamente recomendada a utilização do Code Advisor, um add-in para o VB6 que faz recomendações para a criação de código VB que possa ser convertido com o mínimo de problemas possíveis para .Net.

O add-in está disponível em http://msdn.microsoft.com/vbasic/downloads/codeadvisor/default.aspx.

O Visual Studio.Net possui um wizard de migração de código VB6 para VB.Net. Este wizard é eficaz quando o código VB não utiliza muitos componentes externos, como ADO e MSXML. Todo o código que use objectos deste último componente necessita de ser convertido manualmente para classes do System.Xml namespace.

Referências

Microsoft .NET/COM Migration and Interoperability - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/cominterop.asp

Web Service Façade for Legacy Applications -

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/wsfacadelegacyapp.asp

Recursos sobre Interoperabilidade – http://msdn.microsoft.com/netframework/programming/interop/

Sam Gentile, que publica muita informação sobre este tópico – http://samgentile.com/blog/

Preparing Your Visual Basic 6.0 Applications for the Upgrade to Visual Basic .NET - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvb600/html/vb6tovbdotnet.asp