BRM é um mecanismo de processamento que permite que business experts declarem e gerenciem regras de negócio sem ter de programá-las numa linguagem imperativa. Essencialmente, este ambiente encapsula e desacopla as regras das aplicações que as utilizam, provendo um conveniente grau de flexibilidade.

Isolar as regras de negócio das aplicações, permite que business experts e os autores das regras façam atualizações de forma dinâmica sem quaisquer alterações nas demais aplicações ou processos.

Particularmente, acredito ser um recurso bastante útil para regras que representam fórmulas, cálculos e classificações, por exemplo. Nada mais que isso, creio. Recentemente, identifiquei algumas situações onde essa solução se encaixaria e uma delas é a definição de Specifications.

Specification é um conceito que ganhou a “menção honrosa” de pattern depois que Domain-Driven Design se alastrou rapidamente em sites, blogs e fóruns. Contudo, podemos dizer que Specification é algo utilizado para testar se um objeto satisfaz a um critério. Verificar se um cliente tem direito a um desconto diferenciado, por exemplo.

A maioria das engines provê recursos que facilitam bastante o dia-a-dia de quem escreve/mantêm as regras, tais como: DSLs, IDEs e recursos de avaliação como Decision tables (que te livra de escrever uma montanha de if-then).

Apesar de ser mais utilizada para controlar o fluxo de processos executáveis (BPM), as regras podem ser invocadas de dentro de outras aplicações, através de uma casca EJB ou Web Service.

Finalizo com uma pergunta sobre o maior impeditivo na tentativa de alcançar os reais benefícios desse tipo de solução: Quantos consultores e business expert estão capacitados nesse tipo de recurso?

Consultor especialista em que?

A principal dúvida é sempre a diferença entre os “tipos de consultores SAP”, ou seja, suas áreas de atuação. A primeira coisa que precisamos ter em mente quando nos interessamos pelas soluções SAP é que existem duas linhas de profissionais: os consultores funcionais e os consultores de tecnologia – a diferença é clara, mesmo que existam áreas onde possamos mesclar o funcional com o técnico.

Os consultores funcionais são profissionais que detém o conhecimento sobre os processos de uma determinada linha de negócio, e como estes estão mapeados nos aplicativos. Em geral, um consultor funcional é especialista em um módulo do SAP – que são identificados por aquelas siglas que vemos em anúncios de empregos (ex.: FI, MM, SD, PP e etc.) – e trabalha mais próximo ao cliente na definição dos processos de negócio e utilização do sistema. Resumindo, os consultores funcionais sabem como trabalhar as informações dentro das soluções SAP e estão mais ligados ao negócio do que a tecnologia.

Os consultores de tecnologias SAP são os que conhecem a estrutura técnica das soluções e sabem como customiza-las e integra-las com outras aplicações. Resumindo: implantar, manter, customizar, desenvolver e compor novas soluções é o papel deste tipo de consultor. Como em qualquer processo de automatização, o trabalho dos consultores de tecnologia é tão importante quanto o dos funcionais.

Outra dúvida que eu gostaria de pontuar é como aprender e começar a trabalhar com SAP. Depois de definido o caminho que se deseja traçar (funcional ou técnico), a forma mais comum de aprender a utilizar as soluções da SAP é participar de uma academia ministrada pela própria empresa ou por parceiras educacionais. As academias são treinamentos focados em um módulo ou tecnologia SAP. São caras! Por isso é importante estar seguro daquilo que pretende fazer.

O que está mais próximo do seu perfil? Quais são as oportunidades profissionais após o treinamento? Qual a demanda do mercado na sua região? Que outros conhecimentos além da academia são necessários para atuar como consultor?

Estas questões devem ser observadas com cuidado antes de pagar caro por um treinamento desses. Como eu havia dito, existem também outras formas de obter conhecimento. Entretanto, seja por dificuldade em encontrar materiais, traçar um roteiro de estudos ou até mesmo contato com o próprio ambiente, ser um autodidata é difícil (e às vezes desestimulante). Nestes casos, as experiências anteriores são de grande importância na formação deste profissional.

Sou programador e quero atuar em projetos na plataforma SAP. Vou ter que aprender ABAP?

Depende. Esta resposta está ligada a área que você pretende atuar. Hoje é perfeitamente possível escrever soluções relacionadas a SAP usando linguagens mais populares (como Java e .NET) com uma curva de aprendizagem reduzida. Por outro lado, alguns recursos ainda são feitos usando-se apenas a linguagem da SAP.

E as certificações? É um requisito para atuar como consultor?

Sem querer entrar no mérito de que certificações provam ou não que você está apto a desenvolver alguma atividade (que a maioria delas não prova mesmo), eu diria que é bastante complicado iniciar ou conseguir algo interessante sem elas. Quem é experiente na área sabe o quanto este pensamento é mesquinho, mas é assim que funciona – alguns profissionais usam suas certificações como forma de ter reconhecimento por intimidação . Em alguns momentos, as empresas precisarão de profissionais certificados e as melhores oportunidades exigem isso. IMHO, o caminho é: aprender, pôr em prática e depois se certificar.

Pergunta de um desenvolvedor/arquiteto Java: Vale a pena estudar SAP Netweaver ou devo continuar me especializando em Java apenas?

Sim, vale a pena! O primeiro motivo é que você vai continuar desenvolvendo software da mesma forma que antes, vai continuar escrevendo código Java usando padrões de mercado e frameworks da moda. Em última análise, o Netweaver é composto por um servidor JEE como qualquer outro. O segundo motivo é que o mercado de SAP tem uma demanda grande por desenvolvedores qualificados e experientes. É ai que você entra! E é aqui que sua experiência em desenvolvimento de software é um diferencial (pois uma academia, por melhor que seja, não substitui anos de experiência).

Quanto ganha um consultor SAP?

Creio que este seja o ponto de maior interesse para a maioria. A variação de remuneração é grande e depende de uma série de fatores: localização, qualificação, experiência, os mesmos de sempre. O que devemos condierar é que, como qualquer profissional especialista em alguma coisa, o consultor é, em geral, bem pago. Agora não se iluda! Quem se limita apenas à criação de relatórios não terá a mesma relevância (e conseqüentemente remuneração) que um consultor funcional ou especialista técnico.

A cada dia cresce mais a demanda por profissionais da área de SAP, e para nós desenvolvedores isso se tornou cada vez mais atrativo. Agora além de “obter o cadastro de produtos do ERP”,… estamos trabalhando em soluções com um maior valor agregado, e o melhor de tudo: aproveitando tudo o que sabemos fazer!

Fica ai a dica para os interessados…

As vagas são limitadas, então quem quiser conferir as palestras sobre a plataforma SAP NetWeaver deve inscrever-se o quanto antes! Até lá…

Inscrições: http://www.sap.com.br/sapnwdd/ficha.php

Tenho visto um número cada vez maior de projetos .NET com uma quantidade exagerada de assemblies. IMHO, os namespaces são subutilizados. De forma geral, eu usaria mais namespaces e menos assemblies! Vou expor o meu sentimento em relação a isto:

Um exemplo típico é a camada de persistência (no jargão .NET: uma DAL, Data Access Layer). Se eu estou criando uma camada de persistência específica para minha aplicação, ou seja, que é capaz apenas de manipular os modelos do domínio em questão; então qual o problema em distribuí-la juntamente com minha camada de negócio em um único assembly? O fato de duas camadas diferentes estarem num mesmo assembly não torna o meu design menos coeso.

Estamos falando de um limite – conceito-chave da separação de interesses (Separation of Concern) - que delineia os interesses de um conjunto de classes da aplicação. A escolha entre um limite físico (assemblies) ou lógico (namespaces) dependerá das reais necessidades, vantagens e desvantagens.

Por exemplo, se um componente será reutilizado por várias aplicações, ou então uma equipe separada é responsável por desenvolvê-lo, é necessário defini-lo num assembly específico. Load on-demand também é um bom cenário para recursos em assemblies.

Separar camadas mutuamente dependentes em assemblies diferentes causa um problema de design conhecido como Circular Dependency. Isso quer dizer que os dois assemblies não podem depender diretamente um do outro. Um ponto interessante citado no artigo do Smacchia é que esta dependência resulta no que ele chama de “super componentes”. Se um assembly A depende diretamente do assembly B, e este depende do assembly C, é impossível executar algo no primeiro assembly sem ao menos ter que carregar os dois últimos.

Para resolvermos este impasse devemos retirar a ligação direta entre os assemblies com algum tipo de mapeamento ou interceptação. O que é mais comum (e indicado em alguns textos) é criarmos um terceiro assembly onde definiremos estruturas e interfaces comuns para persistência e negócio. É comum nestes casos ver modelos anêmicos usando o conjunto BO/DTO-VO-TO/DAO. Então fica a pergunta:

Se eu não consigo aproveitar minha lógica de persistência em outros cenários – já que ela depende da interface dos DTOs (ahrg!) e este deve refletir os atributos dos meus objetos de negócio (ou nos piores casos refletem as tabelas do banco) – Qual a vantagem da separação dos objetos de negócio e da persistência em assemblies diferentes?

Já tentou abrir e executar um solution com muitos projetos relacionados? É demorado, o build é lento (e às vezes exige que uma ordem de compilação dos projetos seja seguida) e propenso a erros de output e etc. Já imaginou o problema na distribuição? Voltamos aos tempos de DLL Hell – programadores Win32 já ouviram falar muito nisso!

Talvez você esteja se perguntando se deveria distribuir a sua aplicação inteira num único e onipotente assembly. Mas como dito anteriormente, essa questão vai depender dos seus requisitos de arquitetura – principalmente em como as camadas se comunicarão – e de muito bom senso. Eu procuro sempre refletir esta célebre frase do gênio Albert Einstein: “Make everything as simple as possible, but not simpler”

Referências

http://www.theserverside.net/tt/articles/showarticle.tss?id=ControllingDependencies
http://articles.techrepublic.com.com/5100-22-1044871.html
http://www.msdners.com//dev-archive/88/12-39-881434.shtm

http://codebetter.com/blogs/david.hayden/archive/2005/07/23/129745.aspx

O tema de hoje é: Domain-Specific Language. E quem vai responder as perguntas é ninguém mais que Phillip Calçado. Baseado em Melbourne, Austrália, Phillip é um experiente arquiteto e desenvolvedor de softwares atuando em grandes projetos na ThoughtWorks.

Laércio Queiroz: Vamos começar pelas definições. Como você define uma Domain-Specific Language?

Phillip Calçado: Uma DSL é uma linguagem estritamente relacionada com um domínio de aplicação. Por ser tão ligada a um domínio em específico ela é muito poderosa dentro dele e, provavelmente, muito ineficiente quando se trata de coisas que fogem a este domínio. Um bom exemplo é HTML. É uma linguagem específica para o domínio de definição de documentos em hipertexto. Se você for descrever um documento em hipertexto para a web utilizar HTML te dá poder e possibilidades; mas se você quiser,digamos, construir uma interface desktop ela não te ajuda muito.

Da mesma forma Java e C# são linguagens genéricas (GPLs – General Purpose Languages). Com estas linguagens você consegue descrever vários tipos de domínios com relativa eficiência mas elas não são particularmente excepcionais em nenhum deles.

lqueiroz: O conceito de DSLs não é novo. Na sua opinião o que fez o mercado dar maior atenção a este técnica agora?

pcalcado: Sim, DSLs são utilizadas há décadas em diversas plataformas de desenvolvimento. O interesse ressurgiu basicamente por dois motivos, creio. O primeiro deles foi à popularização de linguagens que tornam a criação de DSLs algo mais fácil, como Ruby. Hoje usamos dezenas de frameworks e bibliotecas que são -ou dizem ser -DSLs para esta plataforma e cada vez mais as pessoas estão ficando habituadas com e recebendo os benefícios desta abordagem. Engraçado que algumas pessoas estão usando termos como “Ruby-style” para estas técnicas, algo que não faz justiça ao fato que Ruby é apenas um usuário destas técnicas, que foram criadas, definidas, nomeadas e estão presentes de maneira mais profunda em outras plataformas.

Outro motivo é a necessidade de modelar o domínio com ferramentas mais poderosas. Nós usamos técnicas como Domain-Driven Design para tornar o nosso modelo de objetos mais próximo aos conceitos que estamos modelando –o negócio- mas ainda existe muito ruído causado por limitações técnicas. Um passo a frente é nos livramos dos objetos –ou qualquer outro conceito de engenharia de software- como unidade utilizada para modelagem. Objetos são um conceito artificial, não existem no domínio modelado são apenas uma ferramenta. Ao invés de usar a linguagem para modelar objetos que por sua vez modelam o domínio nós modelamos o domínio diretamente na linguagem utilizada.

lqueiroz: As DSLs podem ser classificadas em dois grandes grupos: Textual DSLs e Graphical DSLs. Considerando-se que as duas abordagens têm a mesma intenção, quais as motivações que definem qual o tipo mais adequado de DSL numa determinada situação?

pcalcado: Linguagens de programação, sejam DSLs ou GPLs, podem ser de diversos tipos. Nada impede que você programe utilizando musica ou braile ao invés de texto ou gráficos.

A escolha entre usar (ou criar) uma DSL gráfica ou textual depende do que se quer fazer. Durante décadas nós construímos mecanismos fantásticos para lidar com programas escritos em texto, então uma DSL textual se aproveita disso. Da mesma forma uma DSL gráfica pode ser amigável e/ou representar melhor um dado domínio.

Não existem muitas regras aqui, geralmente a decisão é focada em quem vai usar a linguagem. Se sua DSL vai ser utilizada por programadores profissionais geralmente eles são mais eficientes e lidam melhor com ferramentas textuais, se for usada por clientes e pessoas não tão qualificadas tecnicamente o ideal pode ser uma estrutura de assistentes e editores gráficos.

lqueiroz: Outra interpretação que vem causando confusão é a diferença entre os dois tipos de Textual DSLs: Internal x External. Qual a diferença entre as duas? Em qual momento deve-se escolher por um tipo?

pcalcado: DSLs Internas são aquelas que são criadas dentro de uma linguagem, uma DSL interna está limitada pela sintaxe da linguagem hospedeira. Uma DSL externa e uma linguagem gerada para ser processada por um parser e interpretada ou compilada para um formato executável.

Existem vantagens e desvantagens nas duas estratégias. Se você utiliza uma DSL Interna não precisa criar um parser, compilador ou interpretador: usa os da linguagem hospedeira, o que facilita muito as coisas. Por outro lado, com esta estratégia você perde a liberdade de sintaxe: sua DSL tem que ter uma sintaxe compatível com a linguagem hospedeira. Considere por exemplo o JMock, um framework de mock objects em Java. Apesar do JMock lidar com conceitos bem diferentes de Java o código que você escreve utilizando sua DSL ainda deve ser compilável pelo compilador Java.

Da mesma forma, se você utiliza uma DSL externa vai precisar escrever algum programa que leia e interprete essa linguagem. Ainda que ferramentas como o ANTLR tornem este processo bem simples o trabalho ainda existe e é considerável. A vantagem é que sua linguagem pode ser definida na sintaxe que você quiser já que quem escreve o parser é você.

lqueiroz: Um esforço considerável é exigido quando se pretende criar uma Textual DSL decente. Talvez por isso é mais freqüente a adaptação de uma linguagem (como: Ruby, Java ou C#) usando-a como base para emular as características de uma DSL. Os casos de uso dessas adaptações, em geral, limitam-se a facilitar a configuração de um framework ou subsistema (o que é conhecido também por configuration code). Este é a único contexto onde uma language adaptation se encaixa?

pcalcado: Você adapta uma linguagem para diversas coisas. Uma delas é criar uma DSL interna, neste caso você apenas usa a linguagem como base para criar outra, você não está preocupado em obedecer a convenções ou manter conceitos. Por exemplo você pode criar uma DSL procedural utilizando como base uma linguagem orientada a objetos.

Outra maneira é quando você não está interessado em criar uma outra linguagem, apenas em torna-la mais eficiente e/ou legível em um certo contexto. Um bom exemplo é Criteria API no Hibernate. Essa API usa um estilo chamado method chaining, algo que é comum em outras linguagens mas não faz parte do estilo que usamos em Java. Seria possível utilizar o estilo de Java mas com a adaptação os usuários da linguagem –nós- podem descrever em uma linha o que necessitaria de uma dezena se seguíssemos o estilo normal. Ainda assim ao utilizar Criteria API estamos preocupados em usar corretamente os conceitos da linguagem Java como objetos, classes e métodos.

lqueiroz: Tem sido comum ver exemplos de Fluent Interfaces que servem apenas para tornar o código mais legível. Esta legibilidade é uma conseqüência ou é o principal intento desta técnica?

pcalcado: Eu considero o termo Fluent Interface algo bem confuso. Segundo um de seus autores e principal evangelista, Martin Fowler, Fluent Interfaces são basicamente sinônimos de DSLs internas. Eu não consigo aceitar muito bem essa definição e usava o termo para algo diferente. Como lutar contra o autor não é algo muito inteligente devo passar a chamar minha visão sobre Fluent Interfaces –adaptações feitas na linguagem apenas para torna-la mais legível/eficiente- de outra coisa. Na verdade estou em busca de um nome.

Falando sobre legibilidade e DSLs, não existe uma reação real direta. Uma DSL não precisa ser parecida com linguagem natural ou mesmo sem algo facilmente legível. Mesmo quando a DSL é entendida pelos especialistas no domínio isso não quer dizer que será legível para todos.

Claro que o ideal é termos o máximo de legibilidade sempre mas isso não é necessariamente uma obrigação nas DSLs.

lqueiroz: Uma DSL pode ser utilizada para abstrair as regras de negócio de uma linguagem específica através de metadados, interpretadores e geração de algum tipo de artefato. Qual o seu sentimento sobre essa abordagem?

pcalcado: Esta abordagem é difundida pela Microsoft sob o nome de Software Factories, alem de alguns outros fornecedores com produtos mais antigos nessa linha. Eu considero a idéia que motiva tudo muito boa, mas não creio que esteja pronta para ser vendida como um produto de prateleira. As técnicas de transformação automatizada de modelo, como DSL Tools e MDA, ainda precisam passar por alguns passos importantes para que entendamos quando e como utiliza-las.

lqueiroz: As ferramentas de MDA que usam diagramas UML (ou de outro tipo que contenha notações que descrevam os comportamentos dos objetos) podem ser consideradas Graphical DSLs Tools?

pcalcado: Sim e não. Ferramentas de MDA em si trabalham com metamodelos em UML, uma GPL, por isso não são usuárias da técnica de DSLs. Entretanto -sem cair na polêmica sobre se UML serve para fazer este tipo de coisa- alguns fornecedores de MDA juram que você pode colocar uma DSL no topo da UML ou até como seu substituto. Eu nunca vi isso acontecer, nem em pratica nem em teoria, então não posso falar muito sobre este assunto.

lqueiroz: Existem diversas ferramentas que implementam DSLs gráficas como alternativa (às vezes a única forma) a uma declaração textual. A diferença básica entre as duas formas, textual e gráfica, é a forma como os conceitos do domínio são mapeados – utilizando wrappers/idiomas ou elementos visuais. Você concorda que o escopo dessas DSLs gráficas está sendo limitado ao uso em IDEs?

pcalcado: Uma DSL não tem obrigação de ser abrangente ou de não estar vinculada a uma ferramenta. O fato da IDE XYZ definir sua própria linguagem gráfica não é um problema do ponto de vista de engenharia de DSLs. Pode ser um problema para quem for comprar a ferramenta e ficar preso a ela mas de engenharia não é.

O problema que estas ferramentas geralmente trazem é que elas, como descreve Joel Spolsky, possuem abstrações com muitos vazamentos. Você não consegue se livrar completamente do código em função de um assistente gráfico, sempre vai precisar editar texto. Quando se está ciente disso e a ferramenta é utilizada apenas para produtividade os benefícios podem ser maiores que os problemas, mas geralmente essas coisas são vendidas como “a ferramenta que vai substituir todo o seu time de programadores e vai acabar com a escrita de linhas de código” e aí muitas empresas perdem dinheiro e muitos projetos falham.

lqueiroz: Além do Fragmental.tw quais as outras fontes de informação sobre o tema você recomendaria?

pcalcado: Existem algumas fontes excelentes mas são poucas. Martin Fowler está publicando um livro sobre o assunto e disponibiliza seu rascunho gratuitamente. Eu tenho pontos de discordância com o Fowler mas ainda considero a referência mais atual. Existem dezenas de papers na internet publicados desde os anos 70 sobre o assunto, a maioria trabalha questões muito relevantes ainda hoje. Para encontrar outras fontes eu criei alguns filtros no Google para me avisar todas as vezes que algo com o termo DSL é indexado, tem sido bastante útil. Algumas leituras sobre Lisp e Scheme são fundamentais porque muitos textos descrevem os conceitos usando essas linguagens.

No geral para um conceito que ainda está sendo estudado o melhor é escrever bastante, brincar com DSLs que não fazem nada ou até mesmo que são úteis, e ler como as DSLs atuais são implementadas.

Phillip, muito obrigado pela participação e pelos esclarecimentos. Até o próximo post.

Referências:

Fragmental.tw

Fragmental.com.br

Martin Fowler

Antes de qualquer coisa, é importante admitir que o DataSet é um mecanismo de manipulação de dados com diversas funcionalidades e que ocupa um importante papel dentro do ADO.NET. Porém, devemos analisar com cautela os casos onde devemos utilizá-lo.

Usar um DataSet em todas as situações onde você precisa manter algo em memória não é, nem de longe, uma boa prática. Se você pretende desenvolver uma aplicação OO, separando de forma coerente as suas camadas, dificilmente terá um DataSet em outra camada que não seja a responsável pela persistência.

Lembre-se de que o DataSet é, em última análise, um conjunto de dados desconectado. Uma cópia em memória das principais características da fonte de dados. Dessa forma, manipular os registros de um DataSet ao invés de objetos de negócio no cliente tem um forte sabor procedural e uma tendência à repetição de código. É altamente considerável evitar isto!

Desempenho. Você já parou para pensar que na maioria dos casos você não precisaria de um DataSet? O fato de o DataReader ser um cursor forward-only (não mantendo os registros em memória) o torna mais performático que o DataSet. Levando-se em consideração que numa aplicação OO, de uma forma geral, você apenas usa o DataSet para recuperar o estado dos seus objetos, substituí-lo por um DataReader aumentará consideravelmente a performance da aplicação.

Estes e outros motivos nos mostram mais um caso de utilização equivocada de um recurso. O problema não é o DataSet (muito pelo contrário), mas sim o desconhecimento ou uma interpretação errada das motivações e intenções do componente. Enfim, aí estão minhas considerações pessoais sobre o uso de DataSet em aplicações ASP.NET. Veja as referências abaixo e tire suas próprias conclusões!

Referências

http://aspnet.4guysfromrolla.com/articles/050405-1.aspx
http://www.simple-talk.com/dotnet/.net-framework/should-you-use-ado.net-datareader-or-dataset/

Mas o que é Continuous Integration? Continuous Integration (Integração Contínua) é um conjunto de práticas que visam diminuir os riscos de integração durante o processo de desenvolvimento de um software em equipe. Adotando-se estas práticas conseguimos evitar (ou pelo menos diminuir a incidência de) diversos problemas comuns durante a produção de um software.

CI é uma técnica de desenvolvimento clara e objetiva – faça corretamente os procedimentos e dificilmente você terá problemas de integração – e suas principais características são tão óbvias que certamente já devemos tê-las incorporadas em nosso cotidiano. O ponto chave da integração contínua é resolver os possíveis problemas de uma porção de código assim que eles ocorram. Para atingirmos este objetivo devemos seguir uma série de procedimentos, tais como: manter um repositório central, commits freqüentes (no mínimo todos os dias), builds e testes constantes, e uma máquina de integração.

Manter um ambiente de integração contínua manualmente lhe exigirá, na maioria dos casos, um esforço considerável. Contudo, para evitarmos ter de executar uma série de passos a cada commit, podemos automatizar essas tarefas usando um Continuous Integration Server.

Em geral, após configurar seu projeto num CI Server, o mesmo será responsável pela execução de boa parte das etapas do processo de build de forma assíncrona e reportará o resultado do build ao desenvolvedor.

Assim como no ABAP a SAP disponibiliza uma infra-estrutura de apoio ao desenvolvimento de software para a plataforma Java. Esta infra-estrutura é composta de:

- Uma IDE – Windows, menus e uma perspectiva no NetWeaver Developer Studio;

- Um repositório central – com o DTR, Design Time Repository;

- Builds automatizados – com o CBS, Component Build Service;

- Definição de um fluxo de concepção de um componente – desenvolvimento, integração, quality assurance e deploy – com o CMS, Change Management Service;

- Ferramentas para deploy – SDM, Software Deployment Manager.

- Um diretório central de informações sobre os softwares, componentes, serviço de namespace e etc.

- Um modelo de componentes que proporcionam maior coesão, dependências declarativas, relacionamentos unidirecionais e agilidade no desenvolvimento/manutenção dos elementos do software.

Conforme descrito acima o SAP NWDI compreende a maioria dos requisitos de um Continuous Integration Server e pode também ser utilizado para o desenvolvimento de soluções sem componentes específicos SAP.

IMHO, se você nunca trabalhou com um servidor de integração, poderá absorver melhor o assunto estudando as práticas da integração contínua e depois como os componentes do NWDI trabalham juntos em cada etapa e nos diferentes cenários do desenvolvimento em equipe (nesta ordem).

Referências:
SDN NWDI: https://www.sdn.sap.com/irj/sdn/wiki?path=/display/Java/NetWeaver%2bDevelopment%2bInfrastructure%2b(NWDI)
Integration Unit testing on SAP Web AS (Java): https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/9ef1967a-0901-0010-6c86-ed2251898764

Para maiores informações sobre integração contínua recomendo a leitura destes textos:
Martin Fowler: http://www.martinfowler.com/articles/continuousIntegration.html.
Wikipedia: http://en.wikipedia.org/wiki/Continuous_integration
Continuous Integration Server Matrix: http://damagecontrol.codehaus.org/Continuous+Integration+Server+Feature+Matrix

Certamente algumas perguntas ficam no ar… coisas do tipo:

Não é possível implementar o padrão Model-View-Controller na arquitetura WebForms?

Sim, é possível. O MVC nos diz como as camadas de uma aplicação ou componente devem interagir, visando à coesão e o baixo acoplamento, mantendo clara a separação dos interesses dos objetos de cada camada. Sendo assim, usar o modelo WebForms – ASPX, CS (CodeBehind), Model – mesmo com algumas limitações características do event-driven, pode ser considerada uma implementação válida do padrão.

Já que é possível trabalhar com MVC na forma atual, porque desenvolver um framework MVC para ASP.NET?

Essa é uma questão chave. Com WebForms, podemos retirar a dependência entre visualização e o modelo de forma satisfatória. Contudo, quando analisamos a relação entre o controlador e a visualização podemos constatar que não existe uma independência entre os dois acarretando numa série de problemas como por exemplo: Efetuar testes unitários nos seus controladores;
Controladores dependentes de visualização, uma relação de um-para-um, e principalmente do ambiente de execução – Um controlador pode ser aproveitado em diferentes ambientes como: Web e Desktop.

Alguns frameworks MVC decentes para Java já resolvem boa parte destes problemas de forma bastante elegante como o WebWork, (Struts 2?) e o brasileiro VRaptor.

Então, as principais vantagens que vejo nesta iniciativa da Microsoft (mesmo sem ter usado o framework ainda) são:

Controladores independentes de visualização e até mesmo de ambiente de execução (usando-se um container de injeção de dependências, como: Ninject e o StructureMap);

Habilita o desenvolvedor a escrever testes unitários para seus controladores substituindo facilmente as dependências de uma visualização ou quaisquer outros objetos com stubs (TDD, Test-Driven Development);

Profissionais acostumados com desenvolver com uma estrutura semelhante em outras plataformas se sentirão mais à vontade para utilizar o ASP.NET MVC.

Agora temos de usar, acompanhar a sua evolução e a resposta da comunidade .NET.

Referências:

ASP.NET – www.asp.net
ScottGu’s Blog – http://weblogs.asp.net/scottgu/archive/2007/10/14/asp-net-mvc-framework.aspx

Semana difícil,… intervalo grande desde o último post. Contudo, tenho o intuito de manter este espaço com conteúdos bacanas e úteis (!), e prepará-los ou simplesmente escreve-los leva tempo! (tempo que nos falta às vezes )

Vamos ao que interessa! Depois de ter participado do T3 (train the trainer) de SAP NetWeaver em Recife este ano e de ter feito a certificação, gostaria de deixar algumas dicas para quem está se preparando para fazer o exame.

O mais interessante de todo esse processo foi a desmistificação da plataforma SAP e saber que podemos aproveitar nossas experiências JEE com o SAP Netweaver minimizando consideravelmente as dificuldades na aprendizagem.

Antes de qualquer coisa, é importante afirmar que as principais fontes de informação sobre os tópicos explorados no exame são – adivinha? – os treinamentos e conteúdos disponíveis nos portais SAP. A prova é bastante clara, objetiva e difícil (!), então esteja preparado. Vale observar estas dicas que separei pelos tópicos da prova:

• J2EE

Segundo maior tópico em número de perguntas. Nenhuma surpresa, aqui é o bom e velho J2EE que conhecemos. Se você já prestou os exames SCWCD e/ou SCBCD ou tem conhecimentos equivalentes, não sentirá dificuldades.

Entretanto uma boa revisada em Servlets/JSPs e EJBs – principalmente no ciclo de vida e nas interfaces para acesso local, remoto ou ambos – é essencial e garantir uma boa pontuação neste tópico lhe ajudará a passar na prova.

• Open Integration

Este tópico é um mix de questões sobre temas específicos de tecnologias SAP e temas já conhecidos. A grande sacada em relação a estes temas independentes da SAP é identificar as diferenças de implementação e as nomenclaturas usadas principalmente no SAP NetWeaver Developer Studio.

Quanto aos temas mais específicos, procure dar uma atenção especial ao SAP Enterprise Connector (JCo), e a comunicação Java->R/3 e R/3->Java. Questões sobre Web Services certamente aparecerão…

• J2EE Persistence

Este tópico, em geral, tem o mesmo número de questões que o anterior. Nesta parte da prova um entendimento sobre OpenSQL e operações básicas com SQLJ são suficientes. Os quesitos mais explorados dentro deste tópico foram SQLJ e os Entity Beans.

• Java Development Infrastructure

Chegamos ao primeiro tópico totalmente específico SAP. Porém, não precisa temê-lo. Este tópico aborda um conjunto de procedimentos e tecnologias – utilizados no “mundo ABAP” e que foram migrados para o “mundo Java” – que são aplicadas em diversos momentos no ciclo de vida do software. Ex.: modelar, versionar e distribuir os componentes que compõem um produto.

Não são temas complicados, muito pelo contrário, só exigem uma vivência em desenvolvimento de software em equipe. Sendo assim, a principal dica para esta parte da prova é decorar as siglas dos componentes (como: DTR, CBS, CMS e etc.) e entender o papel de cada um dentro do NWDI.

• Web Dynpro

Chegamos ao temido Web Dynpro! O maior tópico em número de perguntas. Infelizmente, para esta parte da prova a única dica é estudar bastante, ficar atento às convenções e a estrutra dos componentes Web Dynpro e, se possível, praticar muito! A maioria das questões deste tópico são sobre Dynamic Programming, Hook Methods (callbacks) e os papéis do MVC abordados num componente Web Dynpo.

Fiquem atentos também as diferenças entre componentes visuais e não-visuais, e os elementos básicos de todo componente Web Dynpro.

Pronto. Estas são as minhas considerações sobre os tópicos do exame. Outra coisa que gostaria de ressaltar é o estilo das respostas. Todas as perguntas têm no mínimo 4 respostas e, diferente do estilo Prometric, o enunciado não informa o número de questões corretas. Todas as respostas têm dois radiobuttons que indicam True/False. Você precisa informar corretamente True ou False para todas as respostas da pergunta, o que eleva o grau de dificuldade da prova.

Espero ter ajudado. Boa sorte a todos!

Referências:

Detalhes Exame – https://websmp101.sap-ag.de/~sapidp/011000358700003595742004E
SDN – https://www.sdn.sap.com/
Help SAP – http://help.sap.com/

Colega A: Um projeto J2EE bem feito, para mim, tem que haver no mínimo um Façade, tem que ter DAOs e … DTOs.

Eu: DTOs? Depende…

Colega A: Como assim depende? Um projeto sem DTO?

Eu: Sim, sem DTO! Não há motivo para utilizarmos um DTO (Na verdade falávamos de Transfer Objects) na maioria das aplicações que desenvolvemos.

Colega B: Eu devo ou não usar DTOs,… TOs,… (arrg!) isso aí que vcs estão falando?

Colega B: Decidam-se…

Colega A: Ele deve ter visto isso em algum lugar e acha que pode escrever uma aplicação J2EE sem usar um DTO. Neste momento eu percebi que meu colega não havia gostado muito da idéia de ter seu modelo de arquitetura questionado. Vamos seguindo…

Eu: Alto lá! Eu sei para que servem os Transfer Objects e uma aplicação web onde as camadas residem na mesma JVM (a maioria dos projetos) não é um caso onde devemos implementá-los. Acompanhe meu raciocínio: A intenção do padrão Transfer Object é transferir dados entre tiers (e não layers) visando reduzir os custos das chamadas remotas num cenário distribuído. Logo, nossa aplicação não precisa de TOs!

Colega B: hmmmm

Colega A: Tudo bem, mas então como iremos mapear as entidades do banco? O Hibernate precisa de objetos para serem mapeados… e aí? Cara,… eu aprendi e sempre trabalhei criando uma classe que é um espelho de uma tabela do banco (TO) e uma classe contendo as regras de negócio, as validações (BO).

Eu: Sim, concordo com você! O Hibernate precisa de objetos, e objetos “de verdade” têm dados + comportamento. Ao criar a dupla ClienteTO + ClienteBO você está dividindo o domínio (objeto) Cliente em duas classes desnecessariamente. Veja a definição de um Acemic Domain Model do Matin Fowler.

Você trabalha com os TO como se fossem registros de uma tabela (um resultSet) as regras de negócio e as validações você escreve no BO (Business Object) e repete onde quer que você precise tratar dados do seu TO. Isso é programação estruturada, não é OOP! Eu não sei o porquê, mas entendo que este não seja um pensamento só seu. Já vi diversos profissionais programarem dessa forma (por uma interpretação errada dos padrões, ou muitas vezes obrigados a seguir uma arquitetura de referência adotada em sua empresa), eu mesmo já programei assim!

Colega A: É verdade…

Eu: Já li diversos textos e discussões em fóruns onde algumas pessoas ainda tentam, mas sem sucesso, justificar o uso de TO numa aplicação não distribuída. É a febre dos patterns! Às vezes você cria situações para justificar a injeção (palavra na moda ) de um pattern em seu design? Evite isso.

Colega A: Sim,… e o que vc passa para sua camada de apresentação? Se não tenho mais DTOs eu vou passar os objetos de domínio?

Eu: Sim! Você tem algum bom motivo para não passar os “BOs” ? Se for por questões de acoplamento, observe que um diagrama com TOs é mais complexo e tem mais acoplamento do que uma versão sem TOs. Se a questão é proteção de alguns dados e/ou métodos, se você programou sua View para interfaces e não para classes concretas, pode usar interfaces de negócio mais restritivas em relação à API do seu componente expondo somente o necessário (Lembrei das Virtual Interfaces de Web Services do SAP NW ).

Os colegas citados acima existem (!) e foram convidados a comentar este post, veremos se eles continuam pensando da mesma forma …

Fontes sobre o assunto:
Martin Fowler, http://www.martinfowler.com
J2EE AntiPatterns
Phillip Calçado “Shoes” (ThoughtWorks), http://fragmental.com.br/wiki/index.php?title=Fantoches
Discussão no GUJ: http://www.guj.com.br/posts/list/28889.java