O Lookup no Java EE 6 

É mais simples, podemos utilizar injeção de dependência e é compatível com as implementações anteriores.
Existe mais de uma maneira de fazê-lo, e aqui tentaremos abordar uma forma considerada boa prática.
Para saber mais sobre o assunto, pesquise por Portable global JNDI name que foi introduzido no Java EE 6 

A imagem abaixo demonstra como é possível fazer o lookup direto e o equivalente utilizando a injeção de dependência.

Importante: Esta é uma forma simples, porém em uma aplicação corporativa não é uma boa prática.

Não deve fazer, segundo as boas práticas de estratégia de implementação.

Mas quais são os problemas desta abordagem?
Existem alguns problemas relacionados à portabilidade, e uma limitação em termos de nomes. O lookup JNDI, é possível saber mais detalhes sobre o assunto, no wesbite do Java .

Nas versões mais antigas do Java EE, é possível minimizar este problema adicionando nomes lógicos nos descritores, deployment plan e fazendo lookup utilizando java:comp/env.

No Java EE 6 não é muito diferente, porém existem algumas facilidades:
1) Não é necessário adicionar itens aos descritores da aplicação (web.xml e ejb-jar.xml)
2) Alguns lookups são possíveis sem nenhum descritor, outros com apenas o deployment plan.

Abaixo é demonstrado como é feito um lookup a base de dados utilizando os recursos do Java EE 6:
(boa prática)

Em uma aplicação web, o @Resource é o responsável por colocar as informações, as quais você teria que colocar no web.xml

O Deployment plan, continua sendo o mesmo arquivo com o mapeamento entre os nomes lógicos e os nomes físicos. Como varias informações são fornecidas com o uso de annotations, este arquivo acaba sendo um pouco mais enxuto. 

Lookups de EJBs no Java EE 6:

Nos casos dos EJBs tem uma diferença, que melhorou no meu ponto de visão. Em lookups locais não é necessário nenhum tipo de descritor. No caso de lookups remotos apenas é necessário o deployment plan para fazer o mapeamento.

Outra diferença é que ficou mais simples de fazer o lookup, bem como é possível utilizar a injeção de dependência:

Object result = context.lookup(CepRepositoryBeanLocal.class.getName());
CepRepositoryBeanLocal service = (CepRepositoryBeanLocal) result;

E o código acima pode ser trocado por

@EJB CepRepositoryBeanLocal service;

Utilizando o @EJB, o container irá cuidar de prover uma implementação de CepRepositoryBean para a interface de negócio CepRepositoryBeanLocal.

Download dos exemplos:
Ambiente: JDK 1.6.24, JBoss 6.0, Eclipse 3.6


TDD What ? New or old ? Good or no ?

Currently or since I know myself as a professional, software failures are largely responsible for costs and time in the software development process.
While it is not possible to remove all existing errors in a given application, it is possible to considerably reduce the number of errors using a more elaborate testing infrastructure, which allows for identifying and removing defects earlier and more effectively.
These defects can result from various causes such as errors of knowledge, communication, analysis, transcription, coding, etc. There are basically three ways to handle software flaws:

1. Fault-avoidance: With appropriate specification, design, implementation and maintenance activities always aiming to avoid failures in the first place. It includes the use of advanced software construction methods, formal methods, and reuse of trusted software blocks.

2. Fault-elimination: Analytical compensation for errors committed during specification, design and implementation. Includes verification, validation and testing.

3. Fault-tolerance: real-time compensation of residual problems such as changes out of specification in the operating environment, user errors, etc.

Due to the fact that fault-avoidance is economically impractical for most companies, the technique of fault elimination is generally adopted by software manufacturers

In the US, do these errors move the software market by approximately 50 billion dollars, and in Brazil and South America? We can see that there is a culture of everything by the result, and after delivery by delivery, in many projects and forgotten the quality be it in the software architecture or in the choice of the project implementation strategy, the DEADLINE is focused by the DEADLINE.
Another point is the bureaucratization of technical activities, process must exist but these should also be support to the objectives and not against the objectives that includes being agile, safe, reusable, practical and that make a culture in the company be it with 10 professionals or with 100 In a company.

The culture of testing is old, as it says in King Chelomoh's Cohelet book, nothing new is just not revealed.

The practice involves the implementation of a system starting with test cases of an object, this is old, I at least have known these techniques since 1999, I will cite only one that defends this idea [Gelperin and Hetzel 1987]. Minimize the errors by focusing on the tests, and today as we are in the era of "JS frameworks", there is a semantics of confusing the implementation framework with work process framework with tools of griffe, which does not apply if they are not tested in the process by All, for all, not only by the 18-year-old project architect, this 18-year-old nowadays grant the role of software architect, senior software development positions to good early professionals, but with little experience, which For me 1996 was almost impossible to have a Jr. level in my classificatory parts of technical activities of the profession, I thought more imperative implementation than clear techniques, there have been many improvements, but today TDD - Test driven development can be put at high risk If you do not have experience in IT projects with software development with serious errors and also great achievements.
In many different techniques, used in the market and tested in the academic world, and professional can, I say by myself also, that the use of this technique is possible to reduce the complexity of software, increasing the maintainability of it. Failures are easily identified even in the development stage thanks to continuous feedback given to the programmer. The test units created allow you to more easily evaluate new defects that may have been inserted in the software facilitating the development of successive releases.

But a detail the professionals who do this are also with attributes of programmers, systems analysts know the world of implementation, this is my opinion for the success of TDD, adjust to lead to good results.


One good choice use systems development with MDA - Model Driven Architecture

One good choice use systems development with MDA - Model Driven Architecture

The system development lifecycle process is a problem-solving process where requirements maybe considered problems occurring within a domain, systems that address the requirements may be considered solutions residing within an environment, and problem solving involves understanding a problem, solving the problem, and implementing the solution. 

One choice to solving problem of process of development is using MDA as good choice and with development tools integrate. Can implement with languages as Java, Python, C++.

Every system development lifecycle process involves the following types of lifecycle activities:
  • Requirements gathering activities to capture requirements that define what a system should do. This results in a requirements model that describes the problem and what a solution entails, and is said to occur from a conceptualization perspective since it focuses on the problem.
  • Analysis activities to understand the requirements. This results in an analysis model that describes how an abstract or implementation-independent solution satisfies what is specified by the requirements model, and is said to occur from a specification perspective since it focuses on the problem and solution.
  • Design activities to determine how a system will satisfy its requirements. This results in a design model that describes how a real or implementation-specific solution satisfies what is specified by the analysis model, and is said to occur from a specification perspective since it focuses on the problem and solution.
  • Implementation activities to build a system. This results in an implementation model that describes the actual solution or physical system that satisfies what is specified by the design model, and is said to occur from an implementation or realization perspective since focuses on the solution.
  • Testing activities to verify that a system satisfies its requirements.
  • Deployment activities to make the system available to its users.
Furthermore, there are many types of approaches or lifecycle models, bellow :
 1. Iterative,
 2. Waterfall,
 3. And so forth

Applying these activities, however every approach must confront the forces of change and complexity.

Figure 1 shows a conceptual view of the system development lifecycle process.

The domain and environment are shown as circles. The problem and solution are shown as solid-outline rectangles within the circles. The problem-solving process is shown as a solid-line path from the problem to the solution, and each perspective is shown as a dashed-line path from the solid-line path to the activities related to that perspective. Activities are shown as a shape with a straight top and bottom and convex arcs on the two sides, and models are shown as solid-outline rectangles.

When an activity uses a model as input, a dashed arrow is shown from the model to the activity. When an activity produces or updates a model as output, a dashed arrow is shown from the activity to the model. Because the requirements model represents the problem and the implementation model represents the solution, a dashed arrow is shown from each model to the item it represents...